Kubernetes Deployments: Replica Management and Rolling Updates

Hello! Let's dive into our next lesson on Kubernetes.

In our previous session, we laid the theoretical foundation, exploring the architecture of a Kubernetes cluster. You learned about the control plane acting as the brain, the worker nodes as the muscle, and the Pod as the fundamental unit that runs your containers. We ended by discussing Kubernetes's declarative nature: you define the desired state, and the control plane's controllers work to make it a reality.

Today, we'll put that theory into practice. We're moving from the "what" to the "how." Our goal is to implement a Kubernetes Deployment to manage application replicas and perform rolling updates for zero-downtime deployments. This is a core competency for any developer working with microservices on Kubernetes and a very common topic in technical interviews.

From Pods to Deployments

While a Pod is the smallest deployable unit, you rarely create individual Pods directly in a production environment. What happens if the node it's running on fails? Or if you need to scale up to handle more traffic?

This is where the Deployment object comes in. A Deployment is a higher-level resource that provides declarative updates to Pods. In simple terms, you tell the Deployment: "I want 3 replicas of my application, using this container image, to be running at all times."

The Deployment controller (part of the Controller Manager you learned about) then takes over. It creates a helper object called a ReplicaSet, which in turn is responsible for creating and maintaining the desired number of Pods. If a Pod dies, the ReplicaSet ensures a new one is created.

The real power of Deployments shines when you need to update your application. Instead of manually stopping old Pods and starting new ones, you simply update the Deployment's Pod template (e.g., with a new container image version), and the Deployment controller manages the update process for you, aiming to do so with no downtime.

The Rolling Update Strategy

The default and most common strategy used by Deployments is the rolling update. This strategy allows your application to remain available throughout the update process by incrementally replacing old Pods with new ones.

This GIF provides a great high-level visualization of the process:

To understand the mechanics and benefits of this strategy, let's turn to a guide from Semaphore.

As you read, the rolling update ensures continuous availability by making sure a certain number of Pods are always running and ready to serve traffic. This process is highly configurable using two key parameters in your Deployment manifest:

• maxUnavailable: The maximum number of Pods that can be unavailable during the update. This can be an absolute number (e.g., 1) or a percentage of the desired replicas (e.g., 25%).
• maxSurge: The maximum number of Pods that can be created above the desired number of replicas. This can also be an absolute number or a percentage.

These two settings allow you to balance deployment speed against risk and resource consumption. For example, with replicas: 4, maxUnavailable: 1, and maxSurge: 1, Kubernetes can take down one old Pod and bring up one new Pod. At any given time during the update, you will have between 3 (4 - 1) and 5 (4 + 1) Pods in total.

This chart visualizes how these parameters work together with 5 desired replicas:

Implementing a Production-Ready Deployment

Now, let's create a Deployment. A basic Deployment is simple, but for production use and to achieve true zero-downtime, we need to add a few more things.

Let's break down the provided nginx-server.yaml and highlight the production-readiness aspects:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  revisionHistoryLimit: 5 # Good practice: limits stored old ReplicaSets
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 33%
  minReadySeconds: 5 # Safety buffer: wait 5s after a pod is ready before it's 'available'
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.3 # Key: Use a specific version tag, not 'latest'
        ports:
        - containerPort: 80
        # This probe is critical for zero-downtime updates
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 30
        # This probe keeps unhealthy pods from staying in service
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 45

The most critical elements for a zero-downtime deployment here are the probes:

• livenessProbe: Asks "Is my application still alive?". If this probe fails, Kubernetes will kill the container and restart it. This helps recover from deadlocks or frozen states.
• readinessProbe: Asks "Is my application ready to serve traffic?". A new Pod will not receive any traffic until its readiness probe passes. During a rolling update, Kubernetes waits for the new Pod's readiness probe to succeed before it considers terminating an old Pod. This is the key mechanism that prevents requests from being sent to a new application instance that is still starting up.

For your Spring Boot applications, you would configure these probes to hit the Spring Boot Actuator endpoints you implemented earlier (e.g., /actuator/health/liveness and /actuator/health/readiness).

Managing Rollouts with kubectl

Once you have your Deployment.yaml file, you use kubectl to bring it to life and manage its lifecycle.

Here's a summary of the essential commands you just reviewed:

• Create or update: kubectl apply -f your-deployment.yaml
• Trigger an update imperatively: kubectl set image deployment/nginx-deployment nginx=nginx:1.25-alpine
• Check rollout status: kubectl rollout status deployment/nginx-deployment
• View deployment history: kubectl rollout history deployment/nginx-deployment
• Roll back to the previous version: kubectl rollout undo deployment/nginx-deployment
• Roll back to a specific revision: kubectl rollout undo deployment/nginx-deployment --to-revision=2

Understanding how rollbacks work is key. When you update a Deployment, Kubernetes doesn't discard the old ReplicaSet; it just scales it down to zero. The revisionHistoryLimit determines how many old ReplicaSets are kept. A rollback is simply a matter of scaling the new ReplicaSet down and the desired old ReplicaSet back up. It's fast and reliable.

The "Near" Zero-Downtime Caveat: An Interview Deep Dive

For a senior-level interview, it's not enough to know how to do a rolling update. You need to understand its limitations. Is a default rolling update truly zero-downtime? The answer is "usually, but not always."

The core issue is a potential race condition:

1. Kubernetes decides to terminate an old Pod. It removes the Pod from the Service's list of endpoints.
2. The kube-proxy on all nodes and any Ingress controllers need to be updated with this new list of endpoints. This takes a small amount of time to propagate.
3. Kubernetes sends a SIGTERM signal to the Pod, starting its graceful shutdown process.
4. If a request arrives at a node before its kube-proxy has been updated, it might still try to forward the request to the terminating Pod, resulting in a connection error.

How do we solve this?

• Graceful Shutdown: Your Spring Boot application should handle the SIGTERM signal correctly, finishing in-flight requests but not accepting new ones. Spring Boot does this by default.
• preStop Lifecycle Hook: This is a powerful tool. You can configure a hook in your Pod spec that executes before the SIGTERM signal is sent. A common practice is to add a simple sleep command (e.g., sleep 5). This pauses the termination process, giving the cluster's networking components enough time to update before your application even begins to shut down.

Mentioning this race condition and the preStop hook as a mitigation strategy in an interview demonstrates a deep, practical understanding of production systems.

Conclusion

Today, you've learned how to translate the architectural theory of Kubernetes into a practical, core deployment workflow. You now understand how to define, manage, and safely update a stateless application with zero downtime.

Key Takeaways:

• A Deployment is a declarative Kubernetes object used to manage a set of replicated Pods.
• The rolling update strategy ensures service availability by incrementally replacing old Pods with new ones.
• The maxSurge and maxUnavailable parameters control the speed and safety of the rollout.
• For true zero-downtime, readiness probes are essential to ensure new Pods are ready for traffic before being added to the service.
• The kubectl rollout commands (status, history, undo) are your tools for managing the update lifecycle.
• Real-world zero-downtime requires handling the endpoint update race condition, often by using a preStop hook and ensuring graceful application shutdown.

In our next lesson, we will address a crucial question: now that we have our Deployment running, how do clients actually access it? We will cover exposing applications using different Kubernetes Service types (ClusterIP, NodePort, LoadBalancer), which provides the stable networking layer on top of your dynamically changing Pods.