AI Tools Compared

Writing Kubernetes manifests by hand is error-prone — the YAML is verbose, security defaults are non-obvious, and a missing field can cause silent misconfigurations that only surface under load. AI tools have gotten good at generating correct, production-ready manifests.

Tools Compared

What Good Manifest Generation Looks Like

A production-safe Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
  namespace: production
  labels:
    app: api-service
    version: "1.2.3"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api-service
    spec:
      terminationGracePeriodSeconds: 60
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 2000
      containers:
        - name: api-service
          image: my-registry/api-service:1.2.3
          ports:
            - containerPort: 8080
              name: http
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            initialDelaySeconds: 10
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir: {}

Most AI tools generate the basic structure. The gaps appear in: security context, readOnlyRootFilesystem (with the required tmp volume), rolling update strategy, and probe configuration.

K8sGPT

K8sGPT connects to your cluster and uses AI to analyze resources and generate fixes.

brew install k8sgpt

k8sgpt auth add --backend anthropic --model claude-sonnet-4-5

k8sgpt analyze --explain

# Output:
# Namespace: production
# Error: Pod/api-service-7d8f9 - Back-off restarting failed container
# Explanation: The container is crashing due to OOMKilled events.
#    The memory limit (128Mi) is insufficient for the observed usage (~340Mi).
# Suggestion: Increase memory limit to at least 512Mi.

k8sgpt generate --description "A deployment for a Node.js API on port 3000 with 2 replicas"

K8sGPT’s manifest generation is basic. Where it excels is cluster analysis — connecting to real cluster state and explaining why pods are failing.

Using Claude for Manifest Generation

Claude produces the most complete manifests when given a detailed prompt:

Generate a production-ready Kubernetes Deployment for a Python FastAPI service.

Requirements:
- Image: my-registry/fastapi-app:${VERSION}
- Port: 8000, Replicas: 3, Namespace: production
- Resources: 256Mi-512Mi memory, 100m-500m CPU
- Health checks on /health endpoint
- Zero-downtime rolling updates
- Security: run as non-root, read-only filesystem, drop all capabilities
- Environment variables from ConfigMap "fastapi-config" and Secret "fastapi-secrets"

Claude’s output includes all security fields plus:

          envFrom:
            - configMapRef:
                name: fastapi-config
            - secretRef:
                name: fastapi-secrets
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name

It also adds topologySpreadConstraints to spread pods across availability zones — an optimization ChatGPT only adds when explicitly requested.

Helm Chart Generation

For reusable infrastructure, Claude’s Helm chart output includes:

ChatGPT’s output was missing the HPA template and helpers, and hardcoded the ingress class instead of templating it.

Generating Manifests with IDE Plugins

In Cursor (Cmd+K inline):

# Prompt:
"Generate a CronJob that runs a Python cleanup script every day at 2 AM,
restart policy Never, backoffLimit 3"
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup-job
spec:
  schedule: "0 2 * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 3
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: cleanup
              image: python:3.12-slim
              command: ["python", "/scripts/cleanup.py"]
              resources:
                requests:
                  memory: "128Mi"
                  cpu: "50m"
                limits:
                  memory: "256Mi"
                  cpu: "200m"

The schedule, restart policy, and resource limits were all correctly handled. Missing: security context hardening (Cursor doesn’t add this by default without being asked).

Security Checklist for AI-Generated Manifests

brew install kube-score
kube-score score generated-deployment.yaml

# Flags missing:
# - Pod security context
# - Container resource limits
# - Read-only root filesystem
# - Dropped capabilities
# - Network policies

Common gaps in AI-generated manifests:

Multi-Resource Manifest Generation

Real applications need more than a Deployment. Here’s a prompt pattern that gets Claude to output a complete set:

Generate a full Kubernetes application stack for a Node.js REST API with PostgreSQL.
Include: Deployment, Service (ClusterIP), Ingress (nginx), HorizontalPodAutoscaler,
PodDisruptionBudget, NetworkPolicy (allow only from ingress), and a ConfigMap for
non-secret environment variables. Namespace: staging.

Claude outputs all 7 resources in a single YAML file separated by ---. The NetworkPolicy in particular is often omitted by other tools — it restricts ingress to only traffic from the nginx ingress controller, which is the correct production pattern.

ChatGPT produces 5 of the 7 resources and typically skips the PodDisruptionBudget and NetworkPolicy unless you ask separately.

StatefulSet Generation for Databases

StatefulSets require different logic than Deployments — volume claim templates, stable network identities, and ordered updates. Prompt pattern:

Generate a StatefulSet for Redis Sentinel with 3 replicas. Include:
- Persistent volume claim template (10Gi SSD)
- Headless service for stable DNS
- A regular service for clients
- ConfigMap for redis.conf
- Pod anti-affinity to spread replicas across nodes

The generated headless service is critical: without clusterIP: None, StatefulSet pods don’t get stable DNS entries. Claude includes this automatically; K8sGPT’s generator omits it and requires the headless service to be specified separately.

Comparison Summary

Tool Manifest Quality Security Defaults Helm Support Cluster Integration
Claude Excellent Good (needs explicit request) Excellent No
ChatGPT Good Fair Good No
K8sGPT Basic Fair No Yes
Cursor Good Fair Good Via plugins

When to Use Each Tool

Claude with detailed prompts — new manifest generation from scratch, Helm chart creation, multi-resource application stacks. Best results with explicit security requirements in the prompt.

K8sGPT — diagnosing existing cluster problems. Connect it to a failing cluster and ask it to explain what’s wrong. Not the right tool for greenfield generation.

Cursor/Copilot in IDE — quick inline generation when you’re already editing YAML. Fast for CronJobs, Services, and ConfigMaps. Falls short on complex StatefulSets without prompting for security context.

ChatGPT — good fallback when Claude API is unavailable. Produces correct basic manifests but requires extra prompting for production-grade security defaults.

For new manifest generation: Claude with a detailed prompt. For cluster diagnosis: K8sGPT. For IDE-native quick generation: Cursor.

Built by theluckystrike — More at zovo.one