Progressive delivery has long been used in software development as a safer way to release new versions of an application. Instead of sending every user to the new version all at once, you gradually expose the change to smaller groups of users or environments. This reduces the blast radius if something goes wrong and gives teams a chance to validate new behavior first. For Kubernetes users, this is where Argo Rollouts has become a popular choice. It gives you more control than a standard rolling update and supports strategies such as canary and blue/green deployments. But Rollouts still needs a traffic layer that can actually steer requests between the stable and canary versions. This is where the Gateway API implementation in Isovalent Networking for Kubernetes becomes important. Progressive delivery is not only about creating the new Pods, it is also about controlling which traffic reaches them. Users are looking at Gateway API not only because of the retirement of Ingress NGINX, but also because of the Kubernetes Ingress API’s inherent limitations. The core Ingress API is centered around host and path based routing, while Gateway API gives Kubernetes a more expressive model, including HTTP header matching directly in HTTPRoute. With the Gateway API implementation in Isovalent Networking for Kubernetes, powered by Cilium, Argo Rollouts can use that routing model for header based canary releases without relying on controller-specific annotations or introducing a service mesh. In this blog I will go over how Argo Rollouts fits into progressive delivery, why the Gateway API plugin matters, and how header-based routing works with the Gateway API implementation in Isovalent Networking for Kubernetes in concert with it. Argo Rollouts as the Release Controller Kubernetes Deployments already give you rolling updates, which is a good default for many applications. The limitation is that a rolling update mostly focuses on replacing Pods over time. It does not give you the same level of control over traffic, pauses, analysis, or promotion decisions. Argo Rollouts is a Kubernetes controller that solves this gap by introducing a Rollout resource as a more advanced replacement for the standard Deployment when you need progressive delivery. It supports canary and blue/green deployments while still working with familiar Kubernetes objects like Pods, ReplicaSets, and Services. With a canary deployment, a new version is released gradually. For example, you may send 10% of traffic to the new version, pause, run analysis, then move to 25%, 50%, and eventually 100%. If a metric looks wrong, you can stop before every user is affected. With a blue/green deployment, you run two versions side by side. One version is active, while the other is staged and ready. Once validated, traffic switches to the new version. Argo Rollouts can also work with different traffic managers which includes Istio, NGINX, ALB, Kong, Traefik, and SMI. The challenge is that this support has historically depended on provider-specific integrations in the controller, so new capabilities may arrive unevenly. For header-based routing, this means Argo Rollouts has traditionally called out Istio support while Gateway API users were left with a gap. Gateway API Becomes the Common Traffic Layer The Gateway API plugin for Argo Rollouts changes the model. Instead of requiring Argo Rollouts to know about every traffic provider directly, the plugin lets Rollouts manage Gateway API resources such as HTTPRoute. If your provider implements the required Gateway API behavior, Argo Rollouts can use it through the common API. For Gateway API users, this is a natural fit. Cilium supports Gateway API resources such as GatewayClass, Gateway, and HTTPRoute, and Isovalent Networking for Kubernetes builds on top of Cilium to bring those capabilities into a supported enterprise networking platform. Argo Rollouts can express rollout intent through Gateway API while the provider handles the traffic programming. The main thing to note is the new header-based routing support. The Argo Project recently announced header-based routing support for the Gateway API plugin, bringing the same style of setHeaderRoute workflow to Gateway API providers. With Gateway API 1.2 adding named rules, the plugin can manage header routes directly in the HTTPRoute instead of tracking them through a separate ConfigMap. With this in place, a Rollout can still use percentage-based traffic shifting, while also sending requests with a header such as X-Canary: true directly to the canary service. Other requests continue to follow the normal route behavior. This is a big improvement for teams standardizing on Gateway API. Application teams describe rollout behavior in the Rollout, platform teams provide Gateway API as the traffic layer, and neither team needs a service mesh just to support header-based canary routing. When Percentage-Based Canaries Are Not Enough Canary deployments are useful because they reduce risk by sending only a portion of traffic to a new version. But the default model is usually request based. If you set a canary weight to 20%, the traffic manager sends roughly 20% of requests to the canary and the rest to the stable version. That is helpful for protecting the whole application, but it does not always protect the user experience. For backend services, random request distribution may be fine. For user-facing applications, it can get strange quickly. If the new version changes the UI, cookies, or session assumptions, a single user may bounce between old and new versions during the same rollout. That is where header-based routing becomes useful. Instead of relying only on random percentages, you can decide which requests should see the canary by matching an HTTP header. For example: Only internal users with X-Canary: internal see the new version Only QA traffic with X-Test-Group: qa reaches the canary Only users from a specific geography or customer segment get early access Only requests coming through a specific load balancer path are pinned to the canary This gives teams a more intentional rollout pattern. You can still use percentages to slowly increase exposure, while choosing known users or traffic sources for early validation. With Ingress, this kind of routing often depends on controller-specific annotations. With Argo Rollouts and the Gateway API plugin, the same pattern can now be expressed through Gateway API resources. For Gateway API users, header-based canary routing can be part of the Kubernetes networking model already running in the cluster. Watching It Work with Isovalent’s Gateway API For this demo, I already have Kubernetes running with Cilium and Gateway API enabled. I also have the Argo Rollouts kubectl plugin installed, and I am using the Argo Rollouts demo application starting with the argoproj/rollouts-demo:blue image. The demo uses a few Kubernetes objects. The Gateway uses the Cilium GatewayClass and listens on port 80. The HTTPRoute uses the hostname colors.7f000001.nip.io and points to two Services: argo-rollouts-stable-service and argo-rollouts-canary-service. Those Services give Argo Rollouts stable and canary targets to shift traffic between. Both select the same application label, but Rollouts updates the underlying ReplicaSets so each Service sends traffic to the right version. The main object to look at is the Rollout: There are a few things to note here. The canaryService and stableService tell Rollouts which Services to use for each version of the app. The trafficRouting section tells Rollouts to use the Gateway API plugin and modify the argo-rollouts-http-route object. The managedRoutes entry named qa-team matches the name used in setHeaderRoute. The Gateway API plugin also needs additional RBAC. In this example, the Argo Rollouts ServiceAccount gets permission to get, patch, and update HTTPRoute resources because the plugin modifies Gateway API objects during the rollout. To start, I verified that the application is serving the blue version: You can see this on the Web App as well: Now I can update the application to the yellow version using the Argo Rollouts plugin: This can also be done by editing the image in the Rollout object directly, but the plugin makes it easy for the demo. At this point, the Rollout is paused with a 50% canary weight. If I send normal traffic to the application, I start seeing both versions: The Web App also shows a 50/50 split: In the curl run, the split was exactly five blue and five yellow responses. In practice, it may not always be perfectly 50/50 for a small number of requests, but the general behavior is that normal traffic is split between stable and canary. This is where the problem from the previous section shows up. Percentage based canaries are useful, but they are not always enough when you want a specific group of users or testers to consistently see the new version. Since the Rollout also added a header route, I can send the X-Canary: true header and consistently reach the yellow version: Normal users can continue through the weighted rollout, while QA, internal users, or a specific traffic source can be routed directly to the canary version using Gateway API header matching. In a real application, the login flow could assign the QA user to a canary cohort by setting a session or cookie value, which the frontend or an upstream proxy then translates into the X-Canary: true request header. With the canary header being sent by the browser, the logged-in member of the QA team reaches the canary release 100% of the time: Bringing It Together In this blog we showed how to use Argo Rollouts with the Gateway API implementation in Isovalent Networking for Kubernetes as the traffic layer for progressive delivery. This allows teams to use Gateway API for controlled canary releases, including header-based routing, without needing to introduce a service mesh just for this capability. We also looked at why Gateway API matters for this workflow. Ingress is still useful, but its core API does not provide portable header-based routing. Gateway API gives that routing intent a first-class resource model, and the Argo Rollouts Gateway API plugin lets Rollouts use that model across compliant providers. Header-based routing with Argo Rollouts no longer needs to be tied to a service mesh. With the Gateway API implementation in Isovalent Networking for Kubernetes, platform teams can use Gateway API as the traffic layer, application teams can keep using Argo Rollouts for progressive delivery, and both teams get a cleaner path for controlled canary releases.