Phase 3: CI/CD & Automation

Rolling Updates in Kubernetes

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you have a super important LEGO city, and one of the most critical buildings is the city's main library. Everyone uses it all the time to get books and learn new things. Now, let's say you've designed an even better, super-modern LEGO library. It's stronger, has more cool rooms, and is much faster at giving out books! You want to replace the old library with this new one, but there's a big problem: you can't just knock down the old library all at once, because then nobody in your LEGO city could get books for a while, and that would make everyone grumpy!

This is where a clever trick called "rolling updates" comes in. Instead of tearing down the old library all at once, you start by building just a small part of your new, improved library right next to the old one. Once that small new part is completely finished and ready for visitors (meaning it's stable and functional, and can give out books), you carefully remove just one equivalent small part of the old library. Now you have a mix of old and new, but the library is still very much open for business.

You keep doing this, piece by piece. You build another small section of the new library, make sure it's ready for visitors, and then take away another small section of the old one. You slowly "roll out" the new parts while "rolling in" the old ones, bit by bit, until eventually, the entire old library has been replaced by the shiny new one, without ever having to close the doors completely. Visitors always had at least part of the library available to them throughout the whole process!

Grown-ups called DevOps Engineers use this exact idea when they update important computer programs that run things like your favorite video games online, or the apps that help your parents order groceries. This means they can always make the programs better, add new features, or fix problems, without anyone even noticing a pause in the service. So, when you build things like online games or helpful apps in the future, you'll know how to keep them running smoothly all the time, even when you're making big changes!

Rolling Updates are Kubernetes' default and most common strategy for updating applications without downtime. Instead of taking down all instances of your old application version and then bringing up all instances of the new one (a "recreate" strategy), rolling updates gradually replace old pods with new ones. This ensures that a minimum number of application instances are always available to serve traffic, providing a seamless experience for users. For a DevOps Engineer, mastering rolling updates is fundamental for implementing robust CI/CD pipelines that deliver high availability and continuous service delivery even during frequent updates.

Kubernetes orchestrates rolling updates through its Deployment controller. When you update the image tag or other pod spec details in your Deployment manifest, Kubernetes starts creating new pods with the updated configuration. Crucially, it waits for these new pods to become "ready" (as defined by your readiness probes) before terminating an equivalent number of old pods. This process repeats iteratively until all old pods are replaced by new ones. You control the pace and risk tolerance of this rollout using two key parameters within the strategy.rollingUpdate section: maxUnavailable (maximum number of pods that can be unavailable during the update) and maxSurge (maximum number of pods that can be created above the desired replica count).

The primary advantage of rolling updates is the zero-downtime deployment, which is critical for production environments. It also allows for easy rollbacks to a previous stable version if issues are detected, as Kubernetes retains a history of your deployments. While generally slower than a full "recreate" strategy, this gradual approach significantly reduces the risk of service interruption. For successful rolling updates, proper implementation of readiness and liveness probes in your application is non-negotiable, ensuring Kubernetes only directs traffic to healthy, fully initialized new pods and removes unhealthy old ones effectively. Understanding how to configure maxUnavailable and maxSurge is key to balancing update speed with service availability and resource usage.

Key Takeaways

  • Enables zero-downtime application updates by gradually replacing pods.
  • Kubernetes Deployment controller manages the update process automatically.
  • Configured using maxUnavailable and maxSurge parameters in the Deployment strategy.
  • Relies heavily on application readiness probes to determine pod health.
  • Allows for easy rollbacks to previous stable versions.

Code Example

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25% # Allows 25% of replicas to be unavailable during update
      maxSurge: 25%       # Allows 25% more replicas than desired temporarily
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v2.0 # The new image version to deploy
        ports:
        - containerPort: 80

How this code works

This code defines a Kubernetes Deployment called my-app-deployment, responsible for managing an application. Its primary job is to ensure three copies (replicas: 3) of my-app are always running, and crucially, to update the application to a new image: my-registry/my-app:v2.0 without interruption. The strategy field, set to type: RollingUpdate, dictates this process. Instead of taking the entire application offline to apply changes, Kubernetes will update pods gradually, maintaining continuous availability.

The rollingUpdate section fine-tunes this zero-downtime strategy. maxUnavailable: 25% means that during the update, no more than 25% of the total replicas (in this case, one out of three pods) can be out of service at any given time. Complementing this, maxSurge: 25% allows Kubernetes to temporarily create up to 25% more pods than desired (one extra pod here). This ensures new application versions are fully launched and serving traffic before older versions are removed. A subtle point for beginners is that RollingUpdate is the default deployment strategy for Kubernetes Deployments, and maxUnavailable: 25% and maxSurge: 25% are also the default values if not specified, making these lines explicit for clarity and control over this common behavior.

Related Articles

Hand-picked reads to go deeper on deployment strategies.

Back to DevOps Engineer Roadmap