Skip to content

Getting Started - AWS ALB Ingress Controller

This guide covers how Argo Rollouts integrates with the AWS Application Load Balancer (ALB) for traffic shaping. This guide builds upon the concepts of the basic getting started guide.


  • Kubernetes cluster with AWS ALB Ingress Controller installed


See the Setup ALB ingress controller on how to setup a Kubernetes cluster with AWS ALB Ingress Controller

1. Deploy the Rollout, Services, and Ingress

When AWS ALB is used as the traffic router, the Rollout canary strategy must define the following mandatory fields:

kind: Rollout
  name: rollouts-demo
      # Reference to a Service which the controller updates to point to the canary ReplicaSet
      canaryService: rollouts-demo-canary
      # Reference to a Service which the controller updates to point to the stable ReplicaSet
      stableService: rollouts-demo-stable
          # Reference to an Ingress in the same namespace of the Rollout
          ingress: rollouts-demo-ingress
          # Reference to a port of the Service
          servicePort: 80

The Ingress in trafficRouting.alb.ingress is required to have a custom action which splits between the stable and canary Services, referenced in the rollout. In this guide, those Services are named: rollouts-demo-stable and rollouts-demo-canary respectively. The weight values for these services used should be initially set to 100% stable, and 0% on the canary. During an update, these values will be modified by the controller.

kind: Ingress
  name: rollouts-demo-ingress
  annotations: alb internet-facing |
    - http:
          - path: /*
              serviceName: rollouts-demo-stable
              servicePort: use-annotation

Run the following commands to deploy:

  • A Rollout
  • Two Services (stable and canary)
  • An Ingress
kubectl apply -f
kubectl apply -f
kubectl apply -f

After applying the manifests you should see the following rollout, services, and ingress resources in the cluster:

$ kubectl get ro
rollouts-demo   1         1         1            1

$ kubectl get svc
NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
rollouts-demo-canary   NodePort     <none>        80:30224/TCP   2m43s
rollouts-demo-stable   NodePort   <none>        80:31135/TCP   2m43s

$ kubectl get ingress
NAME                    HOSTS   ADDRESS                                                                       PORTS   AGE
rollouts-demo-ingress   *   80      6m36s
kubectl argo rollouts get rollout rollouts-demo

Rollout ALB

2. Perform an update

Update the rollout by changing the image, and wait for it to reach the paused state.

kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
kubectl argo rollouts get rollout rollouts-demo

Rollout ALB Paused

At this point, both the canary and stable version of the Rollout are running, with 5% of the traffic directed to the canary. To understand how this works, inspect the listener rules for the ALB. When looking at the listener rules, we see that the forward action weights have been modified by the controller to reflect the current weight of the canary.

ALB Listener_Rules

The controller has added rollouts-pod-template-hash selector to the Services and attached the same label to the Pods. Therefore, you can split the traffic by simply forwarding the requests to the Services according to the weights.

As the Rollout progresses through steps, the forward action weights will be adjusted to match the current setWeight of the steps.