☸️ Kubernetes Deployments vs. Argo Rollouts: How Traffic Really Switches Between Old and New Versions

Kubernetes Deployments vs. Argo Rollouts: How Traffic Really Switches Between Old and New Versions

When I first started learning Kubernetes deployments, I understood the concepts of Rolling Update, Blue-Green, and Canary. But one question kept bothering me:

How does Kubernetes actually switch users from the old version to the new version?

Does it change the Service?

Does it move traffic?

Does it kill old pods first?

After digging into Kubernetes and Argo Rollouts, I realized that understanding ReplicaSets, Services, and readiness probes makes everything much easier.

Let's walk through it step by step.


Standard Kubernetes Deployment

A normal Kubernetes deployment uses a Deployment resource. kind: Deployment

The Deployment controller is responsible for updating your application.

Suppose your application is currently running Version 1.

                   Users
                  │
              Kubernetes Service
                  │
          ReplicaSet (Version 1)
          ├── Pod
          ├── Pod
          └── Pod

The Service sends requests to every Ready pod that matches its selector.

For example:

selector:
  app: box-api

The Service doesn't know anything about application versions. It simply routes traffic to matching, healthy pods.


What Happens When You Deploy a New Version?

Now imagine changing the image from:

image: box-api:v1

to

image: box-api:v2

Kubernetes notices that the pod template has changed.

Instead of modifying existing pods, it creates a new ReplicaSet- ReplicaSet v1 , ReplicaSet v2

Both ReplicaSets temporarily exist at the same time.

               Service
                  │
        ┌─────────┴─────────┐
        │                   │
     v1 Pods             v2 Pods

This surprises many people the first time they learn Kubernetes.

The Service doesn't switch between versions.

Instead, it sends traffic to all Ready pods, regardless of which ReplicaSet they belong to.


How Kubernetes Performs a Rolling Update

The Deployment strategy controls the rollout.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

These two settings are extremely important.

maxSurge

maxSurge tells Kubernetes how many extra pods it may create during a deployment.

Suppose you normally run three replicas.

Initially:

v1
v1
v1

With maxSurge: 1, Kubernetes first creates one additional Version 2 pod.

v1
v1
v1
v2 (Starting)

Notice that it doesn't immediately remove an old pod.

Readiness Probe

Before the new pod receives production traffic, Kubernetes waits for the readiness probe to succeed.

Pod Starts
      │
Readiness Probe
      │
 Ready?

If the probe fails:

  • The pod stays out of Service.

  • Users continue using the old pods.

If the probe succeeds:

  • Kubernetes adds the pod to the Service endpoints.

Only then does Kubernetes remove one old pod.

v1
v1
v2

The process repeats until every Version 1 pod has been replaced.


Can This Still Produce HTTP 500 Errors?

Yes.

Even if Kubernetes performs a perfect rolling update, users can still receive errors.

Some common causes include:

  • The readiness probe reports success too early.

  • The application contains a bug.

  • Database migrations are not backward compatible.

  • The application shuts down before finishing requests.

  • External dependencies fail.

This is because Kubernetes only knows whether a pod is Ready.

It has no idea whether your application is actually behaving correctly.


Enter Argo Rollouts

Argo Rollouts replaces the standard Deployment with a Rollout resource.

kind: Rollout

Instead of only supporting Rolling Updates, it introduces advanced deployment strategies such as:

  • Blue-Green

  • Canary

The biggest difference is that Argo gives you much finer control over when and how production traffic moves to the new version.

Blue-Green Deployment

Blue-Green is a deployment strategy where two versions of the application exist at the same time:

  • Blue = Current production version

  • Green = New version being deployed

Argo Rollouts typically manages this using two Kubernetes Services:

  • Active Service – serves production traffic.

  • Preview Service – exposes the new version for testing before it reaches production.

Initial State

Production users access Version 1 through the Active Service.

Users
   │
Active Service
   │
Version 1 Pods


Deploying Version 2

When a new version is deployed, Argo Rollouts creates a new ReplicaSet for Version 2 and exposes it through the Preview Service.

Users
   │
Active Service
   │
Version 1 Pods

Tester
   │
Preview Service
   │
Version 2 Pods

Production users continue using Version 1.

Only testers or automated validation systems access Version 2 through the Preview Service.

This allows engineers to verify that the new release behaves correctly before exposing it to production traffic.


Promotion

Once validation is complete, Argo promotes the rollout by switching the Active Service.

Users
   │
Active Service
   │
Version 2 Pods

Unlike a standard Kubernetes rolling deployment, Argo does not gradually replace old pods with new pods.

Instead, it changes the Active Service selector so production traffic is routed to the new ReplicaSet.

From the users' perspective, traffic changes like this:

Before Promotion 100% → Version 1

After Promotion 100% → Version 2


What Happens During Automatic Promotion?

If the rollout is configured with:

strategy:
  blueGreen:
    autoPromotionEnabled: true

Argo Rollouts waits until the new ReplicaSet is healthy. Specifically, it waits for Kubernetes to report that the new pods are Ready.

If all pods become Ready, Argo automatically switches production traffic from Version 1 to Version 2.


What If the New Version Has an Application Bug?

This is an important distinction.

Imagine the following scenario: Pods start successfully , Readiness probe passes , Containers remain healthy , Every /checkout request returns HTTP 500 ......

͢͢͢From Kubernetes' perspective:

Pods = Ready
ReplicaSet = Healthy

From Argo Rollouts' perspective:

Deployment = Healthy

Since Kubernetes reports healthy pods, Argo has no reason to stop the rollout.

It automatically promotes Version 2.

Users
   │
Active Service
   │
Version 2 Pods (Returning HTTP 500)

Now every production user is using the broken version.

By default, Blue-Green does not automatically detect application-level failures such as:

  • HTTP 500 responses

  • Broken business logic

  • Failed checkout flows

  • Database query failures

  • Incorrect API responses

It only knows whether Kubernetes considers the new pods healthy.


When Does Blue-Green Stop Automatically?

Blue-Green automatically prevents promotion only when Kubernetes reports infrastructure or pod failures.

Examples include: ImagePullBackOff, CrashLoopBackOff, Readiness probe failure, Pods never becoming Ready

Flow:

Deploy Version 2
        │
Pods become Ready?
        │
   No ─────────► Promotion never happens
        │
       Yes
        │
Automatic Promotion

In these cases, production traffic continues using Version 1.


Can Blue-Green Automatically Roll Back?

Yes...but only if application health is monitored. Argo Rollouts supports AnalysisRuns, which can integrate with monitoring systems such as Datadog, Prometheus, or CloudWatch.

Example flow:

Deploy Version 2
        │
Pods Ready
        │
Promote
        │
Run Analysis
        │
High HTTP 5xx Rate?
        │
Yes ─────────► Abort or Roll Back

Without an AnalysisRun or manual validation, Argo only evaluates pod health, not application health.


Canary Deployment

Canary deployments move traffic gradually. Instead of switching everyone at once, traffic shifts in stages.

90% → Version 1, 10% → Version 2

Later:

75% → Version 1, 25% → Version 2

Eventually: 100% → Version 2

This reduces deployment risk because only a small portion of users initially receives the new release.


Does Canary Automatically Detect HTTP 500 Errors?

Not by itself.

This is one of the biggest misconceptions about Canary deployments.

Suppose the rollout is fully automatic.

10%
↓

25%
↓

50%
↓

100%

If there is: No Datadog, No Prometheus, No CloudWatch analysis, No AnalysisRun, No manual pause

Argo Rollouts has no way to know whether the application is returning HTTP 500 responses.

As long as the pods are: Running, Ready

Argo assumes the deployment is healthy.


What Can Argo Detect Automatically?

Argo can detect infrastructure and pod-level failures.

Examples include: CrashLoopBackOff, ImagePullBackOff, Readiness probe failures, Pods that never become Ready

In those cases, the rollout stops because Kubernetes reports that the new ReplicaSet isn't healthy.


What Argo Cannot Detect Without Monitoring

Argo cannot automatically detect:  HTTP 500 responses, Checkout failures, Business logic bugs, Incorrect API responses, Database query failures

Those require application-level monitoring or manual validation.


Key Takeaways

The most important lesson I learned is that deployment strategy and application health are two different problems.

A standard Kubernetes Deployment focuses on safely replacing pods.

Blue-Green focuses on validating a complete new environment before switching everyone.

Canary focuses on gradually exposing production traffic to the new version.

Neither strategy magically fixes application bugs or HTTP 500 errors.

A successful deployment combines:

  • Proper readiness probes

  • Graceful shutdown

  • Backward-compatible database changes

  • Safe rollout strategy

  • Monitoring and observability

Argo Rollouts reduces deployment risk.....but the application still has to be healthy.


Final Thoughts

Understanding how Kubernetes actually replaces pods makes Blue-Green and Canary much easier to understand.

Once you know that Deployments manage ReplicaSets, Services route to Ready pods, and Argo Rollouts controls traffic progression instead of simply replacing pods, advanced deployment strategies become much less mysterious.

In my next post, I'll dive deeper into how Argo Rollouts works internally with ReplicaSets, Services, AWS ALB, traffic routing, promotion, and rollback.


Popular posts from this blog

☁️ AWS Global Accelerator (GA) + Route 53

🟧☁️ AWS + 🌍 Global Accelerator (GA) + 🌐 Route 53 what they are and how they work together (especially for ALB/EKS). ☁️ AWS = Cloud platform 🌍 GA = Fast global routing + static IPs 🌐 Route 53 = DNS ☁️ What is AWS? AWS (Amazon Web Services) is Amazon’s cloud platform where you run servers, containers, databases, networking, DNS, monitoring, and more. EC2 (servers), EKS (Kubernetes), RDS (databases) ALB/NLB (load balancers), S3 (storage), Route 53 (DNS) What is AWS Global Accelerator? Global Accelerator (GA) improves availability and performance by routing users through AWS’s private global network to the nearest healthy endpoint . Key idea: Users hit GA (static Anycast IPs). GA picks the best Region/endpoint automatically. Static Anycast IPs (2 fixed IP addresse...
Read more

🐳 Docker Filesystem Internals (AdvancEd)

Docker Filesystem Internals (Advanced) This post is for readers who already understand Docker basics and want to learn how Docker manages files internally. If you are new to Docker, read the beginner guide first. Containers Do NOT Have Their Own Disk A common misunderstanding is that Docker containers have their own disk. In reality: Containers do not have a separate physical filesystem. Docker creates a filesystem view using layers stored on the host machine. This layered filesystem is implemented using a Union Filesystem , most commonly OverlayFS on Linux. Docker Images Are Read-Only Layers A Docker image is made up of multiple read-only layers. Each instruction in a Dockerfile creates a new layer. FROM python:3.11 RUN pip install flask COPY app.py . This results in layers lik...
Read more

Understanding RabbitMQ Classic Mirrored Queues and Quorum Queues

Image
💚💚 💚 Understanding RabbitMQ Classic Mirrored Queues and Quorum  Queues 💚💚 💚   I understood RabbitMQ only after I understood why Classic Mirrored Queues were replaced . When I first started learning RabbitMQ, I kept hearing: Classic Queues Classic Mirrored Queues Quorum Queues Raft Consensus Everyone said:  "Use Quorum Queues." But I couldn't understand why. To understand Quorum Queues , I first had to understand how Classic Mirrored Queues worked.
Read more

🐳 Docker Tutorial for Beginners: Step-by-Step with a Simple Example

Docker Explained Using a Very Simple App (Beginner Friendly) Goal: Build a tiny Python app, run it normally, then run the same app using Docker, and understand why Docker helps. Step 1: Create a Very Small Python App Create a file named app.py : print("Hello I am running inside Docker!") Step 2: Run the App WITHOUT Docker Run this on your machine: python app.py Common real-life problems: Python not installed, wrong Python version, missing dependencies, different OS behavior this is where the “works on my machine” issue starts. Step 3: Introduce Docker Instead of relying on your system, Docker lets you package the runtime (Python) together with your app. We’ll do that using a Dockerfile . Step 4: Create a Dockerfile Create a file named Dockerfile (no extension): FROM python:3.11 WORKDIR /app COPY app.py . CMD ["py...
Read more

☸️What’s Inside EKS? A Beginner’s Guide to Its Core Components

Image
 EKS (Elastic Kubernetes Service) EKS is a managed service by AWS that runs Kubernetes for you. It takes care of setting up and managing the Kubernetes control plane so you can focus on running your applications. Kubernetes  Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications. It helps run apps reliably across a cluster of machines, automatically handling scheduling, scaling, updates, and recovery. Pod A Pod is the smallest unit in Kubernetes. It can hold one or more containers that share the same network and storage. All containers in a pod are scheduled and managed together. Container A Container is a lightweight, standalone package that includes everything an app needs to run — code, runtime, libraries, and dependencies. It ensures the app runs the same no matter where it’s deployed. 👀1 pod can have multiple containers but 1 container cannot belongs to multiple pods.
Read more

☸️ Kubernetes Taints and Tolerations(with Node Affinity)

Kubernetes Taints and Tolerations(with Node Affinity + EKS Upgrade Context) Kubernetes scheduling is the process of deciding which node runs a given Pod . This page explains how Kubernetes keeps Pods away from “inappropriate” nodes using taints (node-side restrictions) and tolerations (pod-side permissions), and how that relates to node affinity (pod-side attraction). 1) Core idea: attraction vs repulsion Node affinity (attraction) Node affinity is a property of Pods that attracts them to a set of nodes. You can express it as: Hard requirement (must match), or Preference (nice to have). Taints (repulsion) Taints are the opposite of node affinity. They allow a node to repel a set of Pods. Tolerations (permission) Tolerations are applied to Pods. A toleration allows the scheduler to schedule Pods onto nodes with matching taints. Important...
Read more

AWS Load Balancer Controller Upgrade Guide: v2.x to v3.3

Image
AWS Load Balancer Controller Upgrade Guide: v2.x to v3.3 What is AWS Load Balancer Controller? AWS Load Balancer Controller is a Kubernetes controller that integrates Amazon EKS with AWS Elastic Load Balancing services. It watches Kubernetes resources and automatically creates or updates AWS load balancing resources based on the desired state defined inside the cluster. Instead of manually creating load balancers, listeners, target groups, and security group rules in AWS, teams can define Kubernetes resources such as Ingresses and Services. The controller then reconciles those resources with AWS. What Does It Manage? AWS Load Balancer Controller commonly manages: Application Load Balancers (ALB) Network Load Balancers (NLB) Listeners and listener rules Target groups Target registration and deregistration Security group rules Ingress resources TargetGroupBinding resources Beca...
Read more

🐳 Build a Tiny Flask Web App in Docker (with Ports)

docker run -p 8080:5000 flask-hello Then open in your browser: http://localhost:8080 Step 6: Stop the container Press Ctrl + C in the terminal. Quick Troubleshooting Browser says “This site can’t be reached”: Make sure the container is running and you used the -p port mapping. Flask runs but not accessible: Confirm Flask is running with host="0.0.0.0" inside Docker (not 127.0.0.1 ). Port already in use: Try using a different host port, for example: docker run -p 9090:5000 flask-hello Next Post Ideas Docker image layers and caching (explained simply) Docker volumes : keeping data after a container stops Running the same container in Kubernetes (Pod basics)
Read more

☁️ Amazon S3 Explained: More Than Just Object Storage

Amazon S3 Explained: More Than Just Object Storage When people hear Amazon S3 , they usually think it is only used to store files like images, logs, backups, or documents. That is true, but S3 has grown into much more than simple object storage. Today, S3 can be used for object storage, file-like access, immutable backups, lifecycle management, static websites, event-driven workflows, analytics, and data lake storage. In this post, let us understand what S3 is and how it is used in real-world AWS environments. 1. What is Amazon S3? Amazon S3 stands for Simple Storage Service . It is mainly an object storage service . In S3, data is stored as objects inside buckets. Bucket → Object Each object usually contains: The actual data Metadata A unique object key Example: Bucket name: my-app-logs Object key: logs/2026/app.log Even though this looks like a folder path, S3 does not work like a traditional filesystem internally. The folder-like str...
Read more

☸️ CoreDNS and AWS VPC CNI in EKS

CoreDNS vs AWS VPC CNI in EKS: What Each Component Actually Does When working with Amazon EKS , two important components help your Kubernetes cluster communicate properly: CoreDNS and AWS VPC CNI . Both are part of the networking story, but they do very different jobs. CoreDNS helps pods find services by name, while AWS VPC CNI gives pods network connectivity using IP addresses from your AWS VPC. In simple words: CoreDNS answers: “What IP address belongs to this service name?” AWS VPC CNI answers: “How does traffic reach that pod over the network?” 1. What is CoreDNS? CoreDNS is the DNS server used inside Kubernetes. Its main job is to resolve Kubernetes service names into IP addresses. For example, if one pod wants to call another service using a name like: user-service.default.svc.cluster.local CoreDNS resolves that service name into the correct Kubernetes service IP. What CoreDNS Does Resolves Kubernetes service names Supports pod-to...
Read more