Argo Rollouts Gateway API Plugin

The Ping-Pong feature enables zero-downtime rollouts for long-lived TCP and gRPC connections.

Why use it?

In a standard canary rollout, the canaryService and stableService use selector swaps at promotion time. For load balancers that track connections at the target-group level (like AWS NLB), this swap triggers target deregistration and re-registration, which drops all in-flight connections.

How it works

Instead of swapping selectors, Ping-Pong uses two persistent services (pingService and pongService) whose selectors never change. The rollout controller alternates which one is considered "stable" via the status.canary.stablePingPong field. The plugin then shifts traffic weight between these two services via the Gateway API route. Because no Kubernetes Service selectors are modified during promotion, connections are not dropped.

Requirement: This feature requires Argo Rollouts v1.10 or later.

Instead of explicitly naming every route, you can use label selectors to automatically discover and manage routes. This is ideal for dynamic environments or when managing a large number of routes.

How to use label selectors

1. Label your routes: Add specific labels to your HTTPRoute (or other route types) resources.
2. Configure the Rollout: Use the corresponding selector property (e.g., httpRouteSelector) in the argoproj-labs/gatewayAPI plugin configuration to match those labels.

Supported Selector Types

• httpRouteSelector: For HTTPRoute resources
• grpcRouteSelector: For GRPCRoute resources
• tcpRouteSelector: For TCPRoute resources

You can use multiple selectors simultaneously in a single Rollout.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  namespace: default
spec:
  strategy:
    canary:
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRouteSelector:
              matchLabels:
                app: my-app
                canary-enabled: "true"
            namespace: default
      steps:
      - setWeight: 10
      # ...

To enable traffic splitting, you must create a Gateway resource using the kgateway GatewayClass and an HTTPRoute that references both your stable and canary services.

1. Create the Gateway:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: argo-rollouts-gateway
  namespace: argo-rollouts
spec:
  gatewayClassName: kgateway
  listeners:
    - protocol: HTTP
      name: http
      port: 80

2. Create the HTTPRoute: Attach the route to the Gateway and define backendRefs for both the stable and canary services.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: argo-rollouts-http-route
  namespace: argo-rollouts
spec:
  parentRefs:
    - name: argo-rollouts-gateway
      namespace: argo-rollouts
  rules:
    - matches: []
      backendRefs:
        - name: argo-rollouts-stable-service
          port: 80
        - name: argo-rollouts-canary-service
          port: 80

To use Traefik as a Gateway API implementation for Argo Rollouts, you must first install the Gateway API CRDs and then install Traefik via Helm with the kubernetesGateway provider enabled.

1. Install Gateway API CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

2. Install Traefik: Use the Traefik Helm chart (version 40.0.0) and enable the Kubernetes Gateway provider.

3. Verify Installation: Wait for the deployment to be available and ensure the GatewayClass named traefik is created and shows ACCEPTED: True in the kubectl get gatewayclass output.

# Install Gateway API CRDs
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

# Install Traefik
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm install traefik traefik/traefik \
  --set providers.kubernetesGateway.enabled=true \
  --version 40.0.0 \
  --namespace traefik \
  --create-namespace

# Wait for availability
kubectl wait --timeout=5m -n traefik deployment/traefik --for=condition=Available

# Verify GatewayClass
kubectl get gatewayclass

To develop and debug the plugin locally, follow these steps:

1. Start your local Kubernetes cluster.
2. Configure the plugin location: Create a ConfigMap named argo-rollouts-config in the Argo Rollouts controller's namespace (use default if running locally). In the manifest, use a file:// directive to point to your local build:

   file://<path to the local build>

3. Prepare Argo Rollouts CRDs:

   kubectl create namespace argo-rollouts
   kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

   Note: Delete the in-cluster Argo Rollouts controller deployment after this step, as you will run the controller locally.
4. Run the controller locally:

   cd ~/go/src/github.com/argoproj/argo-rollouts
   go run ./cmd/rollouts-controller/main.go

Once running, the controller will find your local plugin and run it as an RPC server. You can attach any Go debugger to the process to set breakpoints.

# 1. Create ConfigMap with file:// directive
# 2. Install CRDs
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# 3. Run controller locally
cd ~/go/src/github.com/argoproj/argo-rollouts
go run ./cmd/rollouts-controller/main.go