K8s Manifest Generate

Generates complete, production-ready Kubernetes manifests with best practices (health checks, resource limits, security contexts, auto-scaling).

When to Use This

• Deploying application to Kubernetes
• Need complete manifest set (Deployment, Service, Ingress, etc.)
• Want production-ready configuration
• Need auto-scaling setup
• Using Helm (use /k8s-helm-chart instead)
• Simple one-off task (use kubectl run)

How It Works

You are a Kubernetes expert. When user runs /k8s-manifest-generate or /km:

1. Detect application type:

• Stateless (web app, API) → Deployment
• Stateful (database, queue) → StatefulSet
• Batch processing → Job or CronJob
• Node-level agent → DaemonSet

1. Ask key questions:

• Container image and tag?
• Port(s) exposed?
• Resource requirements (CPU, memory)?
• Need persistent storage?
• External access required (Ingress)?
• Auto-scaling needed?
• Environment variables?

1. Generate manifest set:

• Namespace (isolation)
• ConfigMap (configuration)
• Secret (credentials template)
• Deployment/StatefulSet (workload)
• Service (networking)
• Ingress (external access, if needed)
• HPA (auto-scaling, if needed)
• PVC (storage, if needed)

1. Apply best practices:

• Resource requests and limits
• Liveness and readiness probes
• Non-root security context
• Rolling update strategy
• Pod disruption budget (if >1 replica)
• Labels for organization

1. Provide deployment guide:

• kubectl apply commands
• Verification steps
• Troubleshooting tips

Output Format

---
# All manifests in single file
# Can be applied with: kubectl apply -f manifests.yaml

## Deployment Instructions

### 1. Update secrets:
[List of secrets to update]

### 2. Apply manifests:

kubectl apply -f manifests.yaml

### 3. Verify:

kubectl get pods -n

## Expected Results

- Pods: Running
- Service: ClusterIP assigned
- Ingress: Address assigned (if applicable)

Examples

Example 1: Node.js Web App

User: /km

Questions:

• App type? → Stateless web app
• Image? → myregistry/webapp:1.0.0
• Port? → 3000
• Resources? → 250m CPU, 512Mi memory
• Storage? → No
• External access? → Yes (Ingress)
• Auto-scale? → Yes (2-10 replicas)

Output:

---
# webapp-manifests.yaml
# Production-ready Kubernetes manifests for Node.js web app

apiVersion: v1
kind: Namespace
metadata:
  name: webapp

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: webapp-config
  namespace: webapp
data:
  NODE_ENV: "production"
  LOG_LEVEL: "info"
…

Example 2: PostgreSQL StatefulSet

User: /km

Questions:

• App type? → Stateful database
• Image? → postgres:15-alpine
• Port? → 5432
• Resources? → 500m CPU, 2Gi memory
• Storage? → Yes, 10Gi
• External access? → No (internal only)
• Auto-scale? → No (databases don't auto-scale)

Output:

---
# postgres-manifests.yaml
# Production-ready PostgreSQL StatefulSet

apiVersion: v1
kind: Namespace
metadata:
  name: database

---
apiVersion: v1
kind: Secret
metadata:
  name: postgres-secrets
  namespace: database
type: Opaque
stringData:
  # UPDATE THESE VALUES!
…

Example 3: Batch CronJob

User: /km

Questions:

• App type? → Scheduled batch job
• Image? → myregistry/data-sync:1.0.0
• Schedule? → Every day at 2 AM
• Resources? → 1 CPU, 2Gi memory
• Completion? → Run to completion, keep last 3 successful

Output:

---
# data-sync-cronjob.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: batch-jobs

---
apiVersion: v1
kind: Secret
metadata:
  name: sync-secrets
  namespace: batch-jobs
type: Opaque
stringData:
  # UPDATE THESE VALUES!
  S3_ACCESS_KEY: "your-access-key"
  S3_SECRET_KEY: "your-secret-key"
…

Pro Tips

Always set resource limits (prevents cluster instability) Use readiness probes (prevents routing to unhealthy pods) Non-root user is critical for security StatefulSets for databases, Deployments for apps Use namespaces to isolate applications

Troubleshooting

Issue: Pod stuck in Pending → Check resources: kubectl describe pod -n → Verify node capacity sufficient for requests

Issue: Pod CrashLoopBackOff → Check logs: kubectl logs -n --previous → Verify health check endpoints exist