Skip to content

AWS Application Load Balancer (ALB)


  • ALB Ingress Controller v1.1.5 or greater


AWS ALB Ingress Controller enables traffic management through an Ingress object which configures an ALB to route traffic to one or more Kubernetes services. ALBs supports the ability to split traffic through the concept of weighted target groups. This feature is supported by the AWS ALB Ingress Controller through annotations made in the Ingress object to configure "actions".

ALBs are configured via listeners and rules with actions. Listeners define how traffic from client comes in, and rules define how to handle those requests with various actions. One action allows users to forward traffic to multiple TargetGroups (with each being defined as a Kubernetes service) You can read more about ALB concepts here.

An ALB Ingress defines a desired ALB with listener and rules through its annotations and spec. To leverage multiple target groups, ALB Ingress controller looks to an annotation on an Ingress called<service-name>. To indicate that the action annotation should be used for an specific ingress rule, the value "use-annotations" is used as the port value in lieue of a named or numeric port. Below is an example of an ingress which splits traffic between two Kubernetes services, canary-service and stable-service, with a traffic weight of 80 and 20 respectively:

apiVersion: extensions/v1beta1
kind: Ingress
  annotations: |
      } alb
  name: ingress
    - http:
          - backend:
              serviceName: stable-service
              servicePort: use-annotation
            path: /*

This Ingress uses the annotation to define how to route traffic to the various services for the rule with the stable-service serviceName instead of sending traffic to the canary-service service. You can read more about these annotations on the official documentation.

Integration with Argo Rollouts

To configure a Rollout to split traffic between the canary and stable services during update via its ALB integration, the following fields should be specified:

kind: Rollout
      canaryService: canary-service  # required
      stableService: stable-service  # required
          ingress: ingress  # required
          servicePort: 443  # required
          rootService: # optional
          annotationPrefix: # optional

The ingress field is a reference to an Ingress in the same namespace of the Rollout, and the servicePort field refers a port of a service. The Rollout requires the Ingress and servicePort to modify the ALB to route traffic to the stable and canary Services. Within the Ingress, looks for the stableService (or the optional rootService if specified) within the Ingress's rules and adds an action annotation for that the action. As the Rollout progresses through the Canary steps, the controller updates the Ingress's action annotation to reflect the desired state of the Rollout enabling traffic splitting between two different versions.

Since the ALB Ingress controller allows users to configure the annotation prefix used by the Ingress controller, Rollouts can specify the optional annotationPrefix field. The Ingress uses that prefix instead of the default if the field set.

The Rollout adds another annotation called to the Ingress to help the controller manage the Ingresses. This annotation indicates which actions are being managed by Rollout objects (since multiple Rollouts can reference one Ingress). If a Rollout is deleted, the Argo Rollouts controller uses this annotation to see that this action is no longer managed, and it is reset to only the stable service with 100 weight.

Using Argo Rollouts with multiple ALB ingress controllers

As a default, the Argo Rollouts controller only operates on ingresses with the annotation set to alb. A user can configure the controller to operate on Ingresses with different values by specifying the --alb-ingress-classes flag. A user can list the --alb-ingress-classes flag multiple times if the Argo Rollouts controller should operate on multiple values. This may be desired when a cluster has multiple Ingress controllers that operate on different values.

If the controller needs to operate on any Ingress without the annotation, the flag can be specified with an empty string (e.g. --alb-ingress-classes '').