Argo Rollouts - Ingress/VS

[danielnginx]

How it's done in NGF: https://community.f5.com/kb/technicalarticles/powering-progressive-deployment-in-kubernetes-with-nginx-and-argo-rollouts/331646

Examples of cases:

#7484

https://f5.lightning.force.com/lightning/r/Case/500Po00001gLWqrIAG/view

https://f5.lightning.force.com/lightning/r/Case/500Hs00001yZ31kIAC/view

User Story

As an infrastructure team using Argo Rollouts and F5 NGINX Ingress Controller, I can progressively shift traffic between stable and canary application versions so that I can perform safer releases without changing the application.

• Uses a dedicated Argo Rollouts traffic-router plugin.
• Focuses on Kubernetes Ingress resources.
• Supports stable and canary Services.
• Does not depend on the community Ingress-NGINX canary annotations.
• Follows the same plugin approach used for NGINX Gateway Fabric.

Feature Overview

This feature provides an Argo Rollouts traffic-router plugin for F5 NGINX Ingress Controller.

The plugin receives the requested canary weight from Argo Rollouts and updates the NGINX Ingress Controller traffic configuration for the associated Ingress.

The existing Argo documentation must also clearly distinguish the retired community Ingress-NGINX controller from F5 NGINX Ingress Controller.

What

The integration will:

1. Associate an Argo Rollout with an Ingress managed by F5 NGINX Ingress Controller.
2. Shift traffic between stable and canary Services.
3. Apply traffic-weight changes requested by Argo Rollouts.
4. Support promotion, pause, abort, and rollback.
5. Confirm that NGINX Ingress Controller accepted the requested configuration.
6. Clearly report configuration or reconciliation failures.
7. (For the Community team - alter the Argo Rollouts documentation to differentiate between ingress-nginx and F5 NGINX Ingress Controller https://argo-rollouts.readthedocs.io/en/stable/features/traffic-management/nginx/

Why

The integration provides:

• Progressive delivery for NGINX Ingress Controller users.
• Reduced release risk through gradual traffic shifting.
• Automated rollback when a rollout fails.
• Clear product differentiation between F5 NGINX Ingress Controller and community Ingress-NGINX.
• A migration path for users moving away from the retired community controller.
• A consistent Argo plugin model across NGINX products.

Acceptance Criteria

• Argo Rollouts can reference an Ingress managed by F5 NGINX Ingress Controller.
• Argo can set the percentage of traffic sent to stable and canary Services.
• Traffic weights can be changed throughout a rollout.
• A paused rollout retains its current traffic distribution.
• Promotion moves all traffic to the new application version.
• Abort or rollback restores traffic to the stable version.
• Argo does not advance until the requested NGINX configuration is accepted.
• Invalid configuration does not replace the last valid traffic configuration.
• Existing Ingress settings, including host, path, and TLS, remain unchanged.
• Applications not using the plugin are unaffected.
• Failures are visible through Argo status, Kubernetes events, or logs.

Functional Requirements

• The integration must use an Argo Rollouts traffic-router plugin.

• The plugin must support Argo canary strategies.

• The plugin must work with separate stable and canary Services.

• Users must be able to identify the target Ingress and route.

• Traffic weights must support the complete range from stable-only to canary-only.

• The plugin must support:

  • Incremental weight changes.
  • Pause and resume.
  • Promotion.
  • Abort and rollback.
  • Rollout retry.

• The plugin must verify that NGINX Ingress Controller accepted the requested configuration.

• The plugin must preserve unrelated Ingress configuration.

• Multiple independent rollouts must be supported in the same cluster.

• Plugin operations must be safe to retry.

• The plugin must clean up rollout-managed configuration when it is no longer needed.

• The feature must work on Kubernetes and should support OpenShift.

Non-Functional Requirements

• Traffic changes must be applied promptly after Argo requests them.
• Traffic updates must not introduce unnecessary request interruption.
• The plugin must not add another service to the request path.
• Controller or plugin restarts must not lose the current traffic state.
• Existing NGINX Ingress Controller performance must not be materially affected.
• The integration must work with highly available Argo and NGINX deployments.

Documentation Requirements

• Flow Overview: How Argo Rollouts, the plugin, NGINX Ingress Controller, and the application Services interact.
• Deployment Guide: How to install and configure the plugin.
• Configuration Guide: How to associate a Rollout with an Ingress.
• Quickstart: A canary rollout with several traffic-weight steps.
• Rollback Example: A failed rollout returning traffic to the stable version.
• Troubleshooting Guide: Missing resources, permissions, configuration rejection, and traffic-weight issues.
• Argo Documentation Update: Rename the existing “NGINX” integration to “Ingress-NGINX,” identify it as retired, and document F5 NGINX Ingress Controller as a separate provider.

Out of Scope

• Replacing or modifying Argo’s existing Ingress-NGINX integration.
• Supporting Ingress-NGINX canary annotations in NGINX Ingress Controller.
• Installing or managing Argo Rollouts.
• Application health analysis or metric providers.
• Changes to application code.
• Traffic mirroring or advanced targeting.
• Service mesh or cross-cluster rollouts.
• VirtualServer or VirtualServerRoute support in the first milestone.

Definition of Done

• An Argo Rollouts plugin for F5 NGINX Ingress Controller is available.

• The plugin supports weighted stable and canary traffic.

• Promotion, pause, abort, and rollback are verified.

• Argo waits until the requested NGINX configuration is accepted.

• Tests cover:

  • Stable-only traffic.
  • Incremental canary traffic.
  • Paused rollout.
  • Successful promotion.
  • Abort and rollback.
  • Invalid configuration.
  • Missing resources.
  • Plugin and controller restart.
  • Cleanup after rollout completion.

• Existing Ingress behavior remains backward compatible.

• Kubernetes and OpenShift support is verified.

• Argo documentation clearly distinguishes Ingress-NGINX from F5 NGINX Ingress Controller.

• All required documentation is complete and published.

[github-actions]

Hi @danielnginx thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

If your issue concerns any of the enterprise features please open a ticket with F5 directly (For NGINX Plus customers NGINX Ingress Controller (when used with NGINX Plus) is covered by the support contract.)

Cheers!