/kubernetes

Kubernetes Skill

> Skill, Kubernetes, Orchestration, Helm, Cloud Native

Context

Use this skill when writing, reviewing, or debugging Kubernetes manifests and Helm charts. This covers Deployment, Service, Ingress, ConfigMap, and Secret resources; RBAC configuration; resource requests and limits; liveness/readiness/startup probes; Horizontal Pod Autoscaler (HPA); and Helm chart structure. The AI will act as a Kubernetes specialist who understands the operational implications of every manifest field.

Variables

• `{{application_name}}`: Name of the application/service being deployed (e.g., `payments-api`, `frontend`).
• `{{workload_type}}`: Type of workload (e.g., `Deployment`, `StatefulSet`, `DaemonSet`, `CronJob`).
• `{{resource_requirements}}`: Expected traffic and resource profile (e.g., `low traffic — 100m CPU / 128Mi memory`, `high traffic — autoscaling 3-20 replicas`).
• `{{cluster_context}}`: Cluster details (e.g., AWS EKS 1.30, GKE Autopilot, on-prem kubeadm, k3s).
• `{{packaging}}`: How to deliver the manifests (e.g., raw YAML, Kustomize overlay, Helm chart).

Prompt

Adopt the persona of a Senior Kubernetes / Cloud Native Engineer. I need to deploy the following workload:

Application: {{application_name}}
Workload Type: {{workload_type}}
Resource Requirements: {{resource_requirements}}
Cluster: {{cluster_context}}
Packaging: {{packaging}}

Design the Kubernetes configuration adhering to these standards:

1. **Workload Manifest:** Write the `{{workload_type}}` manifest with a `spec.template` that includes all required fields. Set `spec.revisionHistoryLimit: 3`. Use `RollingUpdate` strategy with appropriate `maxSurge` and `maxUnavailable` values explained.
2. **Resource Management:** Always set both `requests` and `limits` for `cpu` and `memory`. Explain the difference between requests (scheduling) and limits (throttling/OOM). Set the `requests`/`limits` ratio appropriately based on the workload type (bursty vs. steady).
3. **Probes:** Configure `livenessProbe`, `readinessProbe`, and `startupProbe` with appropriate `initialDelaySeconds`, `periodSeconds`, and `failureThreshold` values. Explain why a missing `startupProbe` can cause liveness probe loops during slow startup.
4. **Security Context:** Set `securityContext` at both Pod and container level: `runAsNonRoot: true`, `runAsUser: 1000`, `readOnlyRootFilesystem: true`, `allowPrivilegeEscalation: false`, `capabilities: drop: [ALL]`.
5. **RBAC:** Create a dedicated `ServiceAccount` for the application. Define `Role` and `RoleBinding` with only the permissions the application needs. Never use the `default` ServiceAccount.
6. **Configuration & Secrets:** Use `ConfigMap` for non-sensitive configuration. Use `Secret` for sensitive data, and recommend an External Secrets Operator integration for production. Never use `env` with a hardcoded secret value.
7. **Autoscaling:** If high traffic, provide an `HorizontalPodAutoscaler` targeting CPU and/or custom metrics. Explain `minReplicas` and `maxReplicas` choices.
8. **Helm (if applicable):** Structure the chart with `values.yaml` containing all tunables. Use `_helpers.tpl` for label and name templates. Provide a `values.production.yaml` overlay.

Provide all YAML manifests or Helm chart files with inline comments explaining every non-obvious decision.

Example Usage

**Input:**

Adopt the persona of a Senior Kubernetes / Cloud Native Engineer. I need to deploy the following workload:

Application: payments-api
Workload Type: Deployment
Resource Requirements: Medium traffic — starts slow (30s JVM warmup), steady-state at ~200m CPU / 256Mi, needs to scale from 2 to 10 replicas under load
Cluster: AWS EKS 1.30
Packaging: Helm chart

Design the Kubernetes configuration adhering to these standards:
[...rest of prompt...]

**Expected Output:**

• Helm chart structure: `Chart.yaml`, `values.yaml`, `values.production.yaml`, `templates/deployment.yaml`, `templates/service.yaml`, `templates/hpa.yaml`, `templates/serviceaccount.yaml`, `templates/rbac.yaml`
• `startupProbe` with `failureThreshold: 30` and `periodSeconds: 5` to handle 30s JVM startup
• `readinessProbe` on `/health/ready` to gate traffic until warm
• `resources: requests: {cpu: 200m, memory: 256Mi}, limits: {cpu: 500m, memory: 512Mi}`
• `HPA` scaling on CPU 70% utilization, min 2 / max 10 replicas
• `securityContext` with `readOnlyRootFilesystem: true` and a writable `emptyDir` volume for `/tmp`
• `ServiceAccount` with `automountServiceAccountToken: false` since the app doesn't need K8s API access