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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: DongDuong2001
• Source: DongDuong2001/pudo-code-system
• License: MIT
• Homepage: https://dongduong2001.github.io/pudo-code-system/

Install and usage instructions live in the source repository linked above.