Application Deployment
Deployment mechanics, rollouts, and package tooling dominate this domain.
Deployments and rollouts
A Deployment owns a ReplicaSet per revision. kubectl set image deploy/web web=nginx:1.25 then kubectl rollout status deploy/web shows progress; kubectl rollout undo deploy/web --to-revision=2 reverts. Control the update with strategy.rollingUpdate.maxSurge and maxUnavailable (both default 25%). Trap: setting both to 0 is invalid and the API rejects it - a rollout with zero surge and zero unavailability can never progress. revisionHistoryLimit (default 10) bounds how far back you can undo.
When a rollout hangs, kubectl rollout status times out and kubectl describe deploy shows a FailedCreate or image pull event; the old ReplicaSet keeps serving traffic until the new Pods become Ready.
StatefulSets and DaemonSets
StatefulSets give stable names (web-0, web-1) and per-Pod PVCs via volumeClaimTemplates, usually paired with a headless Service. Scaling down does not delete the PVCs. DaemonSets place one Pod per eligible node and typically need tolerations for control-plane taints.
Helm and Kustomize
Helm: helm install rel chart -f values.yaml, helm upgrade --install, helm rollback rel 1, helm template to render locally, helm list -A. Trap: helm upgrade with a values file replaces merged defaults, so keys you removed revert to chart defaults. Kustomize: kubectl apply -k ./overlay needs a directory containing kustomization.yaml; fields like namePrefix, images, patches, and labels transform base resources.
Worked example: a canary is two Deployments (web-stable, web-canary) sharing the label app=web, with the Service selector steering all traffic until you scale the canary replicas up.
Rule of thumb: ship changes through Deployments, verify with rollout status, and always confirm rollout history before undoing.