How to Write a Kubernetes Deployment YAML (Production-Ready)

The minimal production Deployment

A toy Deployment works in a demo. A production Deployment guarantees zero-downtime rollouts and prevents one container from starving its neighbors. The key fields that make that difference:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0   # never take a pod down before a new one is Ready
      maxSurge: 1         # spin up one extra pod during the rollout
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: busybox:1.36
        command: ["sleep", "86400"]
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 200m
            memory: 128Mi
        readinessProbe:
          exec:
            command: ["/bin/true"]
          initialDelaySeconds: 5

Why maxUnavailable: 0 matters

The default maxUnavailable is 25%, which means Kubernetes can kill a running pod before its replacement is ready. Setting maxUnavailable: 0 forces a "surge before remove" order: Kubernetes brings a new pod to Ready first, then terminates the old one. With two replicas that means your service never drops below full capacity during a rollout.

Requests vs limits

• requests - what the scheduler reserves on the node. A pod is only placed where this much CPU/memory is free.
• limits - the hard ceiling. Hit the memory limit and the container is OOMKilled; hit the CPU limit and it is throttled. Omitting limits lets one runaway container starve the whole node.

Matching ClusterIP Service

A Deployment is unreachable without a Service. The selector must match the pod labels exactly:

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  type: ClusterIP
  selector:
    app: api       # must match spec.template.metadata.labels
  ports:
  - port: 80
    targetPort: 80

ClusterIP is the default - it gives the Service a stable in-cluster IP. Nothing outside the cluster can reach it, which is the right default for an internal API.

Verify the rollout

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl rollout status deployment/api   # blocks until all pods are Ready
kubectl get pods,svc                    # confirm 2/2 Running + ClusterIP assigned

rollout status returns exit code 0 on success - useful in CI pipelines to gate a deploy.