with one click
kubernetes-deployment
Deploy, manage, and scale applications on Kubernetes clusters using manifests, Helm charts, and autoscaling configurations.
Menu
Deploy, manage, and scale applications on Kubernetes clusters using manifests, Helm charts, and autoscaling configurations.
| name | kubernetes-deployment |
| description | Deploy, manage, and scale applications on Kubernetes clusters using manifests, Helm charts, and autoscaling configurations. |
| license | MIT |
| metadata | {"author":"awesome-ai-agent-skills","version":"1.0.0"} |
This skill enables the agent to deploy and manage applications on Kubernetes clusters. The agent can generate deployment manifests, services, ingress rules, Helm charts, and autoscaling configurations. It handles the full lifecycle from initial deployment through scaling, rolling updates, and troubleshooting, following production best practices for resource management, security, and reliability.
Configure Cluster Access: The agent verifies that kubectl is configured with the correct cluster context and namespace. It checks connectivity with kubectl cluster-info and confirms that the user has sufficient RBAC permissions to create and manage resources in the target namespace. If a kubeconfig is not present, the agent guides the user through authentication (e.g., aws eks update-kubeconfig, gcloud container clusters get-credentials).
Define Deployment Manifests: The agent creates Kubernetes deployment manifests specifying the container image, replica count, resource requests and limits, environment variables, liveness and readiness probes, and pod anti-affinity rules. Labels and annotations are applied consistently for service discovery, monitoring, and operations. The agent uses specific image tags (never latest) and sets imagePullPolicy appropriately.
Configure Services and Ingress: The agent creates Service resources to expose deployments within the cluster (ClusterIP) or externally (LoadBalancer, NodePort). For HTTP workloads, the agent configures Ingress resources with TLS termination using cert-manager, path-based routing, and rate limiting annotations. The agent selects the appropriate service type based on the deployment environment and traffic requirements.
Apply Manifests and Verify Rollout: The agent applies manifests using kubectl apply -f and monitors the rollout with kubectl rollout status. It verifies that all pods reach the Running state, health checks pass, and the service endpoints are registered. If a rollout stalls, the agent checks pod events with kubectl describe pod and logs with kubectl logs to diagnose the issue, and can execute kubectl rollout undo to revert to the previous version.
Configure Autoscaling: The agent sets up Horizontal Pod Autoscalers (HPA) to scale the replica count based on CPU utilization, memory usage, or custom metrics. It defines minimum and maximum replica counts, scale-up and scale-down behavior, and stabilization windows to prevent thrashing. For workloads with variable resource needs, the agent can also configure Vertical Pod Autoscalers (VPA).
Manage with Helm Charts: For complex applications with multiple environments, the agent packages Kubernetes manifests into Helm charts with templated values. Helm enables versioned releases, atomic upgrades with automatic rollback on failure, and environment-specific value overrides. The agent uses helm upgrade --install for idempotent deployments and helm diff to preview changes before applying.
Provide the agent with your application's container image, resource requirements, desired replica count, and target Kubernetes cluster details.
Example prompt:
Deploy my app to the production EKS cluster:
- Image: myregistry.io/myapp:v2.1.0
- 3 replicas with CPU/memory limits
- Liveness and readiness probes on /health
- Expose via Ingress at api.example.com with TLS
- HPA scaling between 3-10 replicas based on CPU
deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: production
labels:
app: myapp
version: v2.1.0
spec:
replicas: 3
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
version: v2.1.0
spec:
serviceAccountName: myapp
terminationGracePeriodSeconds: 60
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values: [myapp]
topologyKey: kubernetes.io/hostname
containers:
- name: myapp
image: myregistry.io/myapp:v2.1.0
ports:
- containerPort: 3000
name: http
env:
- name: NODE_ENV
value: "production"
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: myapp-secrets
key: database-url
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: "1"
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 15"]
service.yaml:
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: production
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: http
type: ClusterIP
ingress.yaml:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp
namespace: production
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
ingressClassName: nginx
tls:
- hosts:
- api.example.com
secretName: myapp-tls
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp
port:
number: 80
Install or upgrade using Helm with custom values:
helm upgrade --install myapp ./charts/myapp \
--namespace production \
--set image.tag=v2.1.0 \
--set replicaCount=3 \
--set autoscaling.enabled=true \
--values values-production.yaml \
--wait --timeout 5m \
--atomic
hpa.yaml — Horizontal Pod Autoscaler:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Percent
value: 50
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 25
periodSeconds: 120
Deployment steps:
kubectl create namespace production (if it does not exist)kubectl apply -f deployment.yaml -f service.yaml -f ingress.yamlkubectl apply -f hpa.yamlkubectl rollout status deployment/myapp -n productionkubectl get hpa myapp -n production to verify autoscaler targetsinitialDelaySeconds to avoid killing pods during startup.default service account or granting cluster-admin to workloads. Use Roles and RoleBindings scoped to the namespace rather than ClusterRoles when possible.--atomic for automatic rollback on failure and --wait to block until resources are healthy.minAvailable: 2 ensures at least 2 pods are running at all times.kubectl logs <pod> --previous to see the crash output and kubectl describe pod <pod> for events. Common causes include misconfigured environment variables, missing secrets, or failed database connections.docker pull, check imagePullSecrets on the pod spec, and ensure the node has network access to the registry.progressDeadlineSeconds is 600 seconds, after which Kubernetes marks the rollout as failed. Use kubectl rollout undo deployment/myapp to revert immediately rather than waiting for the deadline.helm upgrade was interrupted (e.g., by a timeout), the release may be in a pending-upgrade or failed state. Use helm history myapp to inspect the state and helm rollback myapp <revision> to recover before attempting another upgrade.Identify at-risk customer accounts by analyzing usage patterns, engagement signals, and support history to generate churn risk scores and intervention recommendations.
Analyze NPS, CSAT, and qualitative customer feedback to extract themes, identify trends, and generate actionable insight reports.
Write clear, searchable help center articles and FAQ entries based on support data, product documentation, and common customer questions.
Design structured customer onboarding workflows with phased checklists, email templates, success milestones, and ownership assignments.
Classify, prioritize, and route incoming support tickets by extracting intent and entities, assigning severity, and generating initial responses.
Create and manage budgets with variance analysis and departmental allocation