Deployments: Declarative Updates for Kubernetes Applications

Previously in this course, we explored the ReplicaSet controller, which manages the desired state of Pod replicas. While ReplicaSets ensure your application is running, they don't natively handle the logic required to upgrade your application from one version to another.

In this lesson, we introduce the Deployment—the primary controller for managing application lifecycles. By moving from raw Pods or ReplicaSets to Deployments, you gain the ability to perform automated, zero-downtime rolling updates and manage versioning declaratively.

The Problem with Direct Updates

When you manage Pods manually, updating an application usually involves deleting old Pods and creating new ones. This causes a service disruption: there is a window of time where no containers are running.

Even with a ReplicaSet, if you manually update the image in the template, you have to delete the old Pods one by one. If the new image has a bug, you’re left with a broken application and no easy way to revert. A Deployment solves this by abstracting the update process. It manages the ReplicaSets for you, orchestrating the transition between versions.

Creating Your First Deployment

A Deployment manifest looks similar to a Pod or ReplicaSet, but it includes a strategy section and the metadata required to track rollouts.

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

When you apply this file, Kubernetes creates a Deployment, which in turn creates a ReplicaSet, which finally spawns your 3 Pods.

Performing a Rolling Update

The power of a Deployment lies in its ability to perform a rolling update. This process replaces Pods of the old version with Pods of the new version incrementally.

To trigger an update, you simply change the image field in your YAML file and run kubectl apply. Kubernetes will:

1. Spin up a new Pod (or a set of new Pods) using the new image.
2. Wait for it to pass readiness checks (as we covered in Readiness Probes).
3. Terminate one old Pod.
4. Repeat until all replicas are running the new version.

Example: Updating the Nginx image If you update nginx:1.14.2 to nginx:1.16.1 in your manifest and run kubectl apply -f deployment.yaml, watch the rollout status:

Bash
kubectl rollout status deployment/nginx-deployment

Verifying Zero-Downtime

During a rolling update, the Deployment controller ensures that the maxUnavailable and maxSurge parameters are respected. By default, Kubernetes ensures that at least 75% of your desired replicas are available at all times.

This guarantees that even while the cluster is swapping out old containers for new ones, traffic continues to be routed to healthy endpoints.

Hands-on Exercise

1. Create the nginx-deployment.yaml file provided above and apply it: kubectl apply -f nginx-deployment.yaml.
2. Inspect the rollout: kubectl get rs (you will see the ReplicaSet created by the Deployment).
3. Open a second terminal and run kubectl get pods -w to watch the Pod churn in real-time.
4. Update the image in your YAML to nginx:1.17.0, apply the change, and watch the Pods transition from the old version to the new version.

Common Pitfalls

• Assuming instant updates: A rolling update takes time. If your readinessProbe is misconfigured, the Deployment might hang because it thinks the new Pods are never ready.
• Hardcoding versions: Always aim to use specific image tags. Using latest is a common anti-pattern that makes rollouts unpredictable, as you won't know exactly which version is being deployed.
• Ignoring resource limits: If you don't define Resource Requests and Limits, a rolling update might fail because the cluster lacks enough free memory to spin up the "surge" Pods.

FAQ

Q: How do I know if my update is going well? Use kubectl rollout status deployment/<name> to follow the progress. If something goes wrong, the command will exit with an error.

Q: Do I ever need to delete the ReplicaSet manually? No. When you use a Deployment, you should treat the Deployment as the single source of truth. The Deployment manages the ReplicaSet, and the ReplicaSet manages the Pods.

Q: What happens if I update the Deployment while an update is already in progress? Kubernetes will stop the current rollout and start a new one to reach the latest desired state.

Recap

We’ve learned that a Deployment is the standard way to manage application updates in Kubernetes. By using declarative manifests, we can trigger rolling updates that maintain high availability. We've verified that the system handles the transition between versions automatically, ensuring zero downtime for our end users.

Up next: Rolling Back Deployments — how to revert to a previous version if your new update causes issues.