Best practices & real-world patterns

The checklist that separates a cluster that runs one demo app from one that safely runs a real team's workloads.

• Always set resource requests and limits on containers — without them, one runaway Pod can starve everything else on its node.
• Add liveness and readiness probes — liveness tells Kubernetes when to restart a stuck container; readiness tells it when a Pod is actually ready to receive traffic.
• Use namespaces to separate teams or environments (dev/staging/prod) inside one cluster, and pair them with ResourceQuotas.
• Never deploy bare Pods for anything real — always go through a Deployment (or StatefulSet for stateful apps).
• Keep manifests in git and apply them through CI, not by hand from a laptop — "kubectl apply from memory" doesn't scale past one person.
• Use a real secrets solution (sealed-secrets, Vault, cloud secret managers) instead of trusting default base64 Secrets with anything sensitive.
• Label everything consistently (app, env, team) — it's what Services, monitoring, and cost reporting all key off.

# resource requests/limits + probes, on one container
resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits:   { cpu: "500m", memory: "512Mi" }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
  initialDelaySeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
  initialDelaySeconds: 5