What are the basics of Kubernetes deployment?
The Deployment object
You describe the desired state in a YAML manifest. It includes the number of replicas, a label selector and a pod template with the container image and ports. Kubernetes compares what you asked for with what is running and works to close the gap.
Under the hood, a Deployment manages ReplicaSets. Each change to the pod template creates a new ReplicaSet, and the Deployment shifts pods between them gradually.
- replicas sets how many pods should run
- selector matches the pods it manages
- template defines the container and image
- strategy controls how updates roll out
Rolling updates and rollbacks
By default, the Deployment uses a RollingUpdate strategy. The maxSurge and maxUnavailable settings control how many extra pods can be created and how many can be offline at once. Watch progress with kubectl rollout status.
If an update goes wrong, kubectl rollout undo returns the Deployment to the previous ReplicaSet. Old revisions are kept only up to the configured history limit, so do not rely on very old rollbacks.
Making deployments reliable
Readiness probes tell Kubernetes when a pod can receive traffic. Without them, users can hit a pod that is still starting. Resource requests and limits help the scheduler place pods sensibly.
Use specific image tags, such as a version number or commit hash, instead of latest. That way you always know what is running and can roll back to a known version.
Common mistakes
- Using the latest image tag, which makes it unclear what version is live.
- Leaving out readiness probes, so traffic reaches pods that are not ready yet.
