Argo Rollouts with Ingress Controllers: NGINX, ALB & Gateway API

Table of Contents

Introduction

The entry point of your cluster is arguably the most critical component in any deployment strategy. While service meshes handle internal communication, Ingress controllers manage how the outside world interacts with your application. Argo Rollouts excels at bridging the gap between your deployment logic and your edge networking. Automating the configuration of your Ingress allows you to shift public-facing traffic with surgical precision.

In this guide, we will explore the nuances of integrating Argo Rollouts with the most popular Ingress solutions: NGINX, AWS Load Balancer Controller (ALB), and the emerging Kubernetes Gateway API. We will examine how these integrations facilitate zero-downtime releases.

Whether you are operating in a public cloud or an on-premise data center, mastering Ingress-based traffic shifting is a prerequisite for achieving professional-grade progressive delivery.

Key Takeaways

Ingress-based routing is often the first step for teams adopting progressive delivery before moving to a full service mesh.
NGINX is the most widely used controller, offering robust weighted routing through specialized annotations.
The AWS ALB Controller enables native integration with cloud-level load-balancing features such as Target Groups.
Gateway API represents the future of Kubernetes networking, providing a standardized way to manage traffic across different providers.
Argo Rollouts automates the “annotation dance,” preventing manual configuration errors during high-stakes releases.
Traffic shifting at the Ingress level is compatible with both Canary and Blue-Green deployment strategies.
Integrating with Ingress controllers simplifies A/B Testing Workflows Using Argo Rollouts by enabling sticky sessions at the edge.

What Is Ingress-Based Traffic Routing?

Ingress-based traffic routing refers to the method of shifting traffic at the “North-South” entry point of your cluster. Instead of shifting traffic between pods, the Ingress controller shifts traffic between two different Kubernetes Services.

Argo Rollouts manages this by dynamically updating the Ingress resource or the associated Service objects. This ensures that the traffic split happens at the highest possible layer before the request reaches your application.

Why Is Ingress Shifting Better Than Pod Scaling?

Pod scaling is a blunt instrument. If you have 10 pods and want to shift 10% of traffic, you have to spin up exactly one canary pod. This is inefficient and doesn’t scale well for small or very large deployments.

Exact Percentages: Ingress controllers allow you to shift exactly 1% or 5% of traffic, regardless of how many pods are running.
Resource Efficiency: You can run a single small canary pod while still routing a very specific, tiny amount of traffic to it.
Request Isolation: Ingress-based shifting ensures that the traffic split is handled by a dedicated high-performance proxy.
Protocol Awareness: Modern controllers can handle HTTP/2, WebSockets, and gRPC traffic shifting with ease.

How Does Argo Rollouts Interface with Ingress?

Argo Rollouts uses a “provider” pattern. In your Rollout manifest, you specify which Ingress controller you are using. Argo then uses its internal logic to apply the correct annotations or resource updates.

For example, when using NGINX, Argo will modify the nginx.ingress.kubernetes.io/canary-weight annotation. The NGINX controller detects this change and immediately adjusts traffic distribution in its NGINX configuration.

Why Choose NGINX for Your Rollout Strategy?

The NGINX Ingress Controller is the “old reliable” of the Kubernetes world. It is highly configurable, battle-tested, and supports weighted traffic shifting natively through its canary feature set.

When you use NGINX with Argo, you benefit from a massive community and a wealth of documentation. It is the perfect starting point for teams looking to implement Installing & Using Traffic Router Plugins With Argo Rollouts or standard ingress patterns.

Benefits of NGINX Canary Annotations

NGINX uses a set of “canary” annotations to manage traffic splits. Argo Rollouts automates the application of these annotations, so you don’t have to manage them manually in your CI/CD pipelines.

Weighted Shifting: The primary mechanism for moving percentages of traffic from the stable service to the canary service.
Header-Based Routing: Route users to a canary version based on specific HTTP headers, such as Region or User-Agent.
Cookie Persistence: Ensure that a user who starts on the canary version stays there for their entire session.
Simplicity: Unlike a service mesh, NGINX doesn’t require sidecars, reducing the architectural complexity of your cluster.

Configure the NGINX Traffic Router

To link Argo to NGINX, you define a trafficRouting block in your Rollout YAML. You must provide the name of the Ingress resource that Argo is authorized to manage.

Argo will then manage the “Canary Ingress”, a temporary Ingress object that sits alongside your primary one. This dual-ingress approach is what allows NGINX to perform weighted splits without disrupting the main production entry point.

What Is the AWS Load Balancer Controller (ALB) Integration?

For teams running on EKS, the AWS Load Balancer Controller (ALB) is often the preferred choice. It allows you to leverage AWS’s native application load balancers to manage your Kubernetes traffic. Argo Rollouts integrates with the ALB controller by modifying “Action” annotations. This allows the ALB to shift traffic between different Target Groups representing your stable and canary versions.

Why Use ALB for Progressive Delivery?

Using the ALB controller offloads the heavy lifting of traffic management to the AWS infrastructure. This provides a high-availability solution that scales automatically with your traffic patterns.

Native AWS Integration: Leverage AWS WAF, Shield, and ACM certificates directly at the load balancer level.
Multi-Cluster Support: Shift traffic between different clusters or VPCs using a single global load balancer.
Target Group Shifting: The ALB handles the shifting between “Stable” and “Canary” target groups with zero dropped connections.
Deep Observability: Use Canary Deployment with Metrics Analysis (Prometheus & Datadog) by pulling metrics directly from CloudWatch or the ALB logs.

How to Set Up ALB Weighted Routing?

The setup involves creating a Rollout that references the ALB Ingress resource. You must also ensure that your Services are configured as Type: NodePort or use the target-type: ip annotation.

Argo will update the alb.ingress.kubernetes.io/actions.<service-name> annotation. This annotation contains a JSON string that defines the weights for each target group. The ALB controller detects this change and updates the AWS API.

How Does Gateway API Change the Landscape?

The Kubernetes Gateway API is the successor to the Ingress API. It is designed to be more expressive, extensible, and role-oriented, providing a better experience for both developers and operators.

Argo Rollouts now supports the Gateway API, allowing you to use HTTPRoute objects to manage your traffic. This makes your rollout logic more portable across providers such as GKE, Istio, or Linkerd.

What Is an HTTPRoute in Argo Rollouts?

An HTTPRoute is a resource that defines how traffic should be routed based on hostnames, paths, and headers. Argo Rollouts manipulates the weight field within the backendRefs section of this resource.

Standardized Syntax: Use the same YAML structure regardless of whether you are using a cloud load balancer or a service mesh.
Multiple Backends: Easily split traffic between more than two versions of an application for complex multivariate testing.
Protocol Support: Gateway API has native support for HTTP, HTTPS, TCP, UDP, and TLS routing.
Role Separation: Allow developers to manage their own routes while platform teams manage the global Gateway infrastructure.

Gateway API the Future of Rollouts

The Gateway API addresses many limitations of the original Ingress API, such as its reliance on vendor-specific annotations. It provides a first-class way to handle traffic splitting, recognized by the entire community.

As more teams adopt Argo Rollouts with Service Mesh (Istio, Linkerd, Traefik), the Gateway API will serve as the common language that unifies these networking layers under a single configuration model.

How to Set Up the Ingress Configuration YAML?

Setting up an Ingress-based rollout requires a clear mapping between your Rollout and Ingress resources. This is defined in the spec.strategy.canary.trafficRouting section.

You must provide the name of the Ingress and the names of the stable and canary services. This “trinity” of resources is what Argo uses to orchestrate the traffic movement during a release.

What Are the Required Fields for NGINX?

For NGINX, the configuration is straightforward. You specify the provider as nginx and provide the name of your Ingress.

Ingress Name: The name of the Kubernetes Ingress object you want Argo to manage.
Stable Service: The service that currently points to your production-ready pods.
Canary Service: The service that points to the new version being tested.
Additional Annotations: You can specify custom annotations that Argo should apply to the temporary Canary Ingress.

How to Configure Multiple Ingresses?

In some complex environments, you might have multiple Ingress controllers handling different types of traffic (e.g., internal vs. external). Argo Rollouts can manage multiple Ingress resources for a single rollout.

This ensures that your A/B Testing Workflows Using Argo Rollouts are consistent across all entry points. You simply list each Ingress resource in the trafficRouting array within your manifest.

What Happens During an Ingress-Based Rollout?

When you trigger a rollout by updating your container image, Argo Rollouts begins its step-by-step progression. At each “traffic step,” it calculates the new weights and updates the Ingress resource.

The Ingress controller (NGINX, ALB, etc.) detects this update and reloads its configuration. Within seconds, a portion of your real-world traffic is redirected to the new version of your application.

How to Monitor Traffic Shifting in Real-Time?

Monitoring is critical to ensure that traffic is actually moving as intended. You can use the Argo Rollouts CLI or dashboard to see the current weight assigned to the canary version.

CLI Visualization: Use kubectl argo rollouts get rollout <name> to see a real-time tree view of your pods and traffic weights.
Dashboard Access: The Argo UI provides a graphical representation of the traffic split and the health of the associated services.
Prometheus Tracking: Monitor the argo_rollout_info metric to see the weight changes over time in your Grafana dashboards.
Ingress Logs: Check your controller logs to verify that requests are being routed to the correct backend services.

How to Validate the Routing Logic?

Before proceeding to higher weights, it is a best practice to run a validation check. This is often done using an AnalysisRun that queries your monitoring provider.

By performing Canary Deployment with Metrics Analysis (Prometheus & Datadog), you can verify that the Ingress is delivering traffic correctly and that the new pods are responding without errors.

How to Handle Sticky Sessions with Ingress?

Sticky sessions (or session affinity) are often required for stateful applications or A/B tests. They ensure that a user isn’t “flipped” between versions mid-journey.

Argo Rollouts supports sticky sessions by allowing you to configure cookie-based affinity in your Ingress-based rollouts. This is especially important for A/B Testing Workflows Using Argo Rollouts.

Why Is Session Stickiness Important for Canaries?

Without stickiness, a user might experience inconsistent behavior if Version A and Version B have different UI elements or API contracts. This can lead to a degraded user experience and “dirty” metrics.

User Consistency: Keep the user on a single version to ensure a coherent experience.
Metric Integrity: Prevent a single user’s actions from being recorded across both versions of a test.
Application State: Ensure that session data stored in memory or specific backend caches remains accessible.
Debugging: Makes it easier to trace a specific user’s path through the system during a rollout failure.

Configure Affinity in NGINX and ALB

In NGINX, you use the nginx.ingress.kubernetes.io/canary-by-cookie annotation. For ALB, you configure the target group attributes to enable “stickiness” with a defined duration.

Argo Rollouts can be configured to automatically manage these settings. By ensuring your Installing & Using Traffic Router Plugins With Argo Rollouts or native providers are correctly tuned, you can maintain session integrity throughout the entire deployment lifecycle.

How to Manage Blue-Green Deployments with Ingress?

While we often focus on Canary deployments, Ingress controllers are equally powerful for Blue-Green strategies. In a Blue-Green setup, the Ingress acts as a “cutover” switch. Instead of a gradual weight shift, Argo Rollouts prepares the “Green” environment, then updates the Ingress to route 100% of traffic to it in a single atomic operation.

What Are the Steps for an Ingress Blue-Green?

An Ingress-based Blue-Green rollout follows a specific sequence to ensure the new version is fully ready before traffic is routed to it.

Preview Phase: Argo spins up the new pods and creates a “Preview” service for internal testing.
Active Switch: Once the Green pods pass their health checks, Argo updates the Ingress to point to the Green service.
Post-Promotion Analysis: The system continues to monitor metrics to ensure the new version is stable under full load.
Scale Down: After a successful “soak period,” the old Blue pods are scaled down to zero.

Why Is Blue-Green Safer with Ingress?

Because the Ingress update is a single API call to Kubernetes, the switch is nearly instantaneous. This minimizes the “mixed-version” state that can occur with traditional deployment methods.

If a problem is detected immediately after the switch, Argo can perform a “fast rollback” by simply reverting the Ingress resource to point back to the Blue service, which is still running and ready.

What Are the Best Practices for Ingress Rollouts?

To ensure your rollouts are as safe as possible, you should follow several best practices centered around automation, security, and visibility.

Start with small traffic increments (e.g., 5%) and increase the “soak time” as the weight grows. This gives your Canary Deployment with Metrics Analysis (Prometheus & Datadog) enough time to collect meaningful data.

Why Should You Automate Analysis?

Never rely on manual verification for traffic shifting. Human error and “dashboard fatigue” are the leading causes of deployment failures.

Automated Gates: Use AnalysisTemplates to define “pass/fail” criteria for every step of the rollout.
Early Detection: Catch regressions at 5% traffic before they impact the remaining 95% of your users.
Consistency: Ensure that every service in your organization follows the same rigorous health standards.
Velocity: Automation allows you to deploy during off-hours or high-traffic periods with confidence.

How to Secure Your Ingress During a Rollout?

Security shouldn’t take a backseat during a deployment. Ensure that your Canary Ingress has the same TLS certificates, WAF rules, and authentication policies as your primary Ingress.

If you are using Installing & Using Traffic Router Plugins With Argo Rollouts for custom hardware, verify that your security middleware is correctly applied to the dynamic routes created by the plugin.

Conclusion

Integrating Argo Rollouts with Ingress controllers like NGINX, ALB, and the Gateway API is the foundation of modern progressive delivery. It provides the control and precision needed to manage production traffic safely. By moving your traffic-shifting logic to the edge, you gain the flexibility to perform complex canary releases, Blue-Green swaps, and A/B Testing Workflows Using Argo Rollouts without the overhead of a full-service mesh.

As you continue to refine your deployment strategies, remember that the Ingress is your first line of defense. A well-configured Ingress integration ensures that every release is a non-event for your users.

FAQs

Can I use NGINX and Istio together?

Yes, many teams use NGINX as their external Ingress controller and Istio as their internal service mesh. In this scenario, Argo Rollouts can manage the NGINX Ingress to shift North-South traffic.

What happens if the Ingress update fails?

If Argo cannot update the Ingress resource (e.g., due to an RBAC error), the rollout will pause and signal a failure. The traffic will remain on the stable version until the issue is resolved.

Is the Gateway API ready for production?

Yes, the Gateway API is now GA (Generally Available) for many providers like GKE and Istio. It is the recommended path for new Kubernetes installations looking for a future-proof networking model.

How do I handle multiple hostnames on one Ingress?

Argo Rollouts can manage specific paths or hostnames within a multi-rule Ingress. You simply define the rules or host matches in your traffic routing configuration to ensure only the correct traffic is shifted.

Does ALB shifting support gRPC?

Yes, the AWS ALB Controller supports gRPC traffic. You must ensure your Target Groups are configured with the appropriate protocol and that your Argo Rollouts steps are tuned for the long-lived connections typical of gRPC.

Latest Post: