alb.ingress.kubernetes.io/subnets specifies the Availability Zones that the ALB will route traffic to. See Load Balancer subnets for more details.
You must specify at least two subnets in different AZs. Either subnetID or subnetName(Name tag on subnets) can be used.
+You must specify at least two subnets in different AZs unless utilizing the outpost locale, in which case a single subnet suffices. Either subnetID or subnetName(Name tag on subnets) can be used.
+You must not mix subnets from different locales: availability-zone, local-zone, wavelength-zone, outpost.
Tip
diff --git a/v2.7/guide/service/annotations/index.html b/v2.7/guide/service/annotations/index.html index d0f6a657a..ce5283318 100644 --- a/v2.7/guide/service/annotations/index.html +++ b/v2.7/guide/service/annotations/index.html @@ -1376,6 +1376,12 @@service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: preserve_client_ip.enabled=true
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: target_health_state.unhealthy.connection_termination.enabled=false,target_health_state.unhealthy.draining_interval_seconds=30
+service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true
service.beta.kubernetes.io/aws-load-balancer-attributes: dns_record.client_routing_policy=availability_zone_affinity
+service.beta.kubernetes.io/aws-load-balancer-inbound-sg-rules-on-private-link-traffic specifies whether to apply security group rules to traffic sent to the load balancer through AWS PrivateLink.
+Example
+service.beta.kubernetes.io/aws-load-balancer-inbound-sg-rules-on-private-link-traffic: "off"
+The AWS Load Balancer Controller manages Kubernetes Services in a compatible way with the AWS cloud provider's legacy service controller.
diff --git a/v2.7/guide/targetgroupbinding/targetgroupbinding/index.html b/v2.7/guide/targetgroupbinding/targetgroupbinding/index.html index a34d10736..ecfb11be1 100644 --- a/v2.7/guide/targetgroupbinding/targetgroupbinding/index.html +++ b/v2.7/guide/targetgroupbinding/targetgroupbinding/index.html @@ -735,6 +735,20 @@ Sample YAML + + +usage to support Ingress and Service
The AWS LoadBalancer controller internally used TargetGroupBinding to support the functionality for Ingress and Service resource as well. -It automatically creates TargetGroupBinding in the same namespace of the Service used.
+It automatically creates TargetGroupBinding in the same namespace of the Service used.You can view all TargetGroupBindings in a namespace by kubectl get targetgroupbindings -n <your-namespace> -o wide
TargetGroupBinding CR supports the explicit definition of the Virtual Private Cloud (VPC) of your TargetGroup.
+If the VpcID is not explicitly specified, a mutating webhook will automatically call AWS API to find the VpcID for your TargetGroup and set it to correct value.
+apiVersion: elbv2.k8s.aws/v1beta1
+kind: TargetGroupBinding
+metadata:
+ name: my-tgb
+spec:
+ serviceRef:
+ name: awesome-service # route traffic to the awesome-service
+ port: 80
+ targetGroupARN: <arn-to-targetGroup>
+ vpcID: <vpcID>
+For TargetType: instance, all nodes of a cluster that match the following
diff --git a/v2.7/search/search_index.json b/v2.7/search/search_index.json
index ae5719a35..31d88f14b 100644
--- a/v2.7/search/search_index.json
+++ b/v2.7/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"A Kubernetes controller for Elastic Load Balancers AWS Load Balancer Controller \u00b6 AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers . It satisfies Kubernetes Service resources by provisioning Network Load Balancers . This project was formerly known as \"AWS ALB Ingress Controller\", we rebranded it to be \"AWS Load Balancer Controller\". AWS ALB Ingress Controller was originated by Ticketmaster and CoreOS as part of Ticketmaster's move to AWS and CoreOS Tectonic. Learn more about Ticketmaster's Kubernetes initiative from Justin Dean's video at Tectonic Summit . AWS ALB Ingress Controller was donated to Kubernetes SIG-AWS to allow AWS, CoreOS, Ticketmaster and other SIG-AWS contributors to officially maintain the project. SIG-AWS reached this consensus on June 1, 2018. Support Policy \u00b6 Currently, AWS provides security updates and bug fixes to the latest available minor versions of AWS LBC. For other ad-hoc supports on older versions, please reach out through AWS support ticket.","title":"Welcome"},{"location":"#aws-load-balancer-controller","text":"AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers . It satisfies Kubernetes Service resources by provisioning Network Load Balancers . This project was formerly known as \"AWS ALB Ingress Controller\", we rebranded it to be \"AWS Load Balancer Controller\". AWS ALB Ingress Controller was originated by Ticketmaster and CoreOS as part of Ticketmaster's move to AWS and CoreOS Tectonic. Learn more about Ticketmaster's Kubernetes initiative from Justin Dean's video at Tectonic Summit . AWS ALB Ingress Controller was donated to Kubernetes SIG-AWS to allow AWS, CoreOS, Ticketmaster and other SIG-AWS contributors to officially maintain the project. SIG-AWS reached this consensus on June 1, 2018.","title":"AWS Load Balancer Controller"},{"location":"#support-policy","text":"Currently, AWS provides security updates and bug fixes to the latest available minor versions of AWS LBC. For other ad-hoc supports on older versions, please reach out through AWS support ticket.","title":"Support Policy"},{"location":"CONTRIBUTING/","text":"Contributing Guidelines \u00b6 Welcome to Kubernetes. We are excited about the prospect of you joining our community ! The Kubernetes community abides by the CNCF code of conduct . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. Getting Started \u00b6 Building the project \u00b6 Controller development documentation has instructions on how to build the project and project specific expectations. Contributing to docs \u00b6 The documentation is generated using Material for MkDocs . In order to generate and preview docs locally, use the steps below - Install pipenv run make docs-preview . This will generate and serve docs locally at http://127.0.0.1:8000 Contributing \u00b6 We also have more documentation on how to get started contributing here: Contributor License Agreement Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests Kubernetes Contributor Guide - Main contributor documentation, or you can just jump directly to the contributing section Contributor Cheat Sheet - Common resources for existing developers Mentorship \u00b6 Mentoring Initiatives - We have a diverse set of mentorship programs available that are always looking for volunteers! Contact Information \u00b6 Slack channel Mailing list","title":"Contributing Guidelines"},{"location":"CONTRIBUTING/#contributing-guidelines","text":"Welcome to Kubernetes. We are excited about the prospect of you joining our community ! The Kubernetes community abides by the CNCF code of conduct . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.","title":"Contributing Guidelines"},{"location":"CONTRIBUTING/#getting-started","text":"","title":"Getting Started"},{"location":"CONTRIBUTING/#building-the-project","text":"Controller development documentation has instructions on how to build the project and project specific expectations.","title":"Building the project"},{"location":"CONTRIBUTING/#contributing-to-docs","text":"The documentation is generated using Material for MkDocs . In order to generate and preview docs locally, use the steps below - Install pipenv run make docs-preview . This will generate and serve docs locally at http://127.0.0.1:8000","title":"Contributing to docs"},{"location":"CONTRIBUTING/#contributing","text":"We also have more documentation on how to get started contributing here: Contributor License Agreement Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests Kubernetes Contributor Guide - Main contributor documentation, or you can just jump directly to the contributing section Contributor Cheat Sheet - Common resources for existing developers","title":"Contributing"},{"location":"CONTRIBUTING/#mentorship","text":"Mentoring Initiatives - We have a diverse set of mentorship programs available that are always looking for volunteers!","title":"Mentorship"},{"location":"CONTRIBUTING/#contact-information","text":"Slack channel Mailing list","title":"Contact Information"},{"location":"code-of-conduct/","text":"Kubernetes Community Code of Conduct \u00b6 Please refer to our Kubernetes Community Code of Conduct","title":"Kubernetes Community Code of Conduct"},{"location":"code-of-conduct/#kubernetes-community-code-of-conduct","text":"Please refer to our Kubernetes Community Code of Conduct","title":"Kubernetes Community Code of Conduct"},{"location":"controller-devel/","text":"AWS Load Balancer Controller Development Guide \u00b6 We'll walk you through the setup to start contributing to the AWS Load Balancer Controller project. No matter if you're contributing code or docs, follow the steps below to set up your development environment. Issue before PR Of course we're happy about code drops via PRs, however, in order to give us time to plan ahead and also to avoid disappointment, consider creating an issue first and submit a PR later. This also helps us to coordinate between different contributors and should in general help keeping everyone happy. Prerequisites \u00b6 Please ensure that you have properly installed Go . Go version We recommend to use a Go version of 1.14 or above for development. Fork upstream repository \u00b6 The first step in setting up your AWS Load Balancer controller development environment is to fork the upstream AWS Load Balancer controller repository to your personal Github account. Ensure source code organization directories exist \u00b6 Make sure in your $GOPATH/src that you have directories for the sigs.k8s.io organization: mkdir -p $GOPATH /src/github.com/sigs.k8s.io git clone forked repository and add upstream remote \u00b6 For the forked repository, you will git clone the repository into the appropriate folder in your $GOPATH . Once git clone 'd, you will want to set up a Git remote called \"upstream\" (remember that \"origin\" will be pointing at your forked repository location in your personal Github space). You can use this script to do this for you: GITHUB_ID = \"your GH username\" cd $GOPATH /src/github.com/sigs.k8s.io git clone git@github.com: $GITHUB_ID /aws-load-balancer-controller cd aws-load-balancer-controller/ git remote add upstream git@github.com:kubernetes-sigs/aws-load-balancer-controller git fetch --all Create your local branch \u00b6 Next, you create a local branch where you work on your feature or bug fix. Let's say you want to enhance the docs, so set BRANCH_NAME=docs-improve and then: git fetch --all && git checkout -b $BRANCH_NAME upstream/main Commit changes \u00b6 Make your changes locally, commit and push using: git commit -a -m \"improves the docs a lot\" git push origin $BRANCH_NAME Create a pull request \u00b6 Finally, submit a pull request against the upstream source repository. We monitor the GitHub repo and try to follow up with comments within a working day. Building the controller \u00b6 To build the controller binary, run the following command. make controller To install CRDs into a Kubernetes cluster, run the following command. make install To uninstall CRD from a Kubernetes cluster, run the following command. make uninstall To build the container image for the controller and push to a container registry, run the following command. make docker-push To deploy the CRDs and the container image to a Kubernetes cluster, run the following command. make deploy","title":"AWS Load Balancer Controller Development Guide"},{"location":"controller-devel/#aws-load-balancer-controller-development-guide","text":"We'll walk you through the setup to start contributing to the AWS Load Balancer Controller project. No matter if you're contributing code or docs, follow the steps below to set up your development environment. Issue before PR Of course we're happy about code drops via PRs, however, in order to give us time to plan ahead and also to avoid disappointment, consider creating an issue first and submit a PR later. This also helps us to coordinate between different contributors and should in general help keeping everyone happy.","title":"AWS Load Balancer Controller Development Guide"},{"location":"controller-devel/#prerequisites","text":"Please ensure that you have properly installed Go . Go version We recommend to use a Go version of 1.14 or above for development.","title":"Prerequisites"},{"location":"controller-devel/#fork-upstream-repository","text":"The first step in setting up your AWS Load Balancer controller development environment is to fork the upstream AWS Load Balancer controller repository to your personal Github account.","title":"Fork upstream repository"},{"location":"controller-devel/#ensure-source-code-organization-directories-exist","text":"Make sure in your $GOPATH/src that you have directories for the sigs.k8s.io organization: mkdir -p $GOPATH /src/github.com/sigs.k8s.io","title":"Ensure source code organization directories exist"},{"location":"controller-devel/#git-clone-forked-repository-and-add-upstream-remote","text":"For the forked repository, you will git clone the repository into the appropriate folder in your $GOPATH . Once git clone 'd, you will want to set up a Git remote called \"upstream\" (remember that \"origin\" will be pointing at your forked repository location in your personal Github space). You can use this script to do this for you: GITHUB_ID = \"your GH username\" cd $GOPATH /src/github.com/sigs.k8s.io git clone git@github.com: $GITHUB_ID /aws-load-balancer-controller cd aws-load-balancer-controller/ git remote add upstream git@github.com:kubernetes-sigs/aws-load-balancer-controller git fetch --all","title":"git clone forked repository and add upstream remote"},{"location":"controller-devel/#create-your-local-branch","text":"Next, you create a local branch where you work on your feature or bug fix. Let's say you want to enhance the docs, so set BRANCH_NAME=docs-improve and then: git fetch --all && git checkout -b $BRANCH_NAME upstream/main","title":"Create your local branch"},{"location":"controller-devel/#commit-changes","text":"Make your changes locally, commit and push using: git commit -a -m \"improves the docs a lot\" git push origin $BRANCH_NAME","title":"Commit changes"},{"location":"controller-devel/#create-a-pull-request","text":"Finally, submit a pull request against the upstream source repository. We monitor the GitHub repo and try to follow up with comments within a working day.","title":"Create a pull request"},{"location":"controller-devel/#building-the-controller","text":"To build the controller binary, run the following command. make controller To install CRDs into a Kubernetes cluster, run the following command. make install To uninstall CRD from a Kubernetes cluster, run the following command. make uninstall To build the container image for the controller and push to a container registry, run the following command. make docker-push To deploy the CRDs and the container image to a Kubernetes cluster, run the following command. make deploy","title":"Building the controller"},{"location":"how-it-works/","text":"How AWS Load Balancer controller works \u00b6 Design \u00b6 The following diagram details the AWS components this controller creates. It also demonstrates the route ingress traffic takes from the ALB to the Kubernetes cluster. Note The controller manages the configurations of the resources it creates, and we do not recommend out-of-band modifications to these resources because the controller may revert the manual changes during reconciliation. We recommend to use configuration options provided as best practice, such as ingress and service annotations, controller command line flags and IngressClassParams. Ingress Creation \u00b6 This section describes each step (circle) above. This example demonstrates satisfying 1 ingress resource. [1] : The controller watches for ingress events from the API server. When it finds ingress resources that satisfy its requirements, it begins the creation of AWS resources. [2] : An ALB (ELBv2) is created in AWS for the new ingress resource. This ALB can be internet-facing or internal. You can also specify the subnets it's created in using annotations. [3] : Target Groups are created in AWS for each unique Kubernetes service described in the ingress resource. [4] : Listeners are created for every port detailed in your ingress resource annotations. When no port is specified, sensible defaults ( 80 or 443 ) are used. Certificates may also be attached via annotations. [5] : Rules are created for each path specified in your ingress resource. This ensures traffic to a specific path is routed to the correct Kubernetes Service. Along with the above, the controller also... deletes AWS components when ingress resources are removed from k8s. modifies AWS components when ingress resources change in k8s. assembles a list of existing ingress-related AWS components on start-up, allowing you to recover if the controller were to be restarted. Ingress Traffic \u00b6 AWS Load Balancer controller supports two traffic modes: Instance mode IP mode By default, Instance mode is used, users can explicitly select the mode via alb.ingress.kubernetes.io/target-type annotation. Instance mode \u00b6 Ingress traffic starts at the ALB and reaches the Kubernetes nodes through each service's NodePort. This means that services referenced from ingress resources must be exposed by type:NodePort in order to be reached by the ALB. IP mode \u00b6 Ingress traffic starts at the ALB and reaches the Kubernetes pods directly. CNIs must support directly accessible POD ip via secondary IP addresses on ENI .","title":"How it works"},{"location":"how-it-works/#how-aws-load-balancer-controller-works","text":"","title":"How AWS Load Balancer controller works"},{"location":"how-it-works/#design","text":"The following diagram details the AWS components this controller creates. It also demonstrates the route ingress traffic takes from the ALB to the Kubernetes cluster. Note The controller manages the configurations of the resources it creates, and we do not recommend out-of-band modifications to these resources because the controller may revert the manual changes during reconciliation. We recommend to use configuration options provided as best practice, such as ingress and service annotations, controller command line flags and IngressClassParams.","title":"Design"},{"location":"how-it-works/#ingress-creation","text":"This section describes each step (circle) above. This example demonstrates satisfying 1 ingress resource. [1] : The controller watches for ingress events from the API server. When it finds ingress resources that satisfy its requirements, it begins the creation of AWS resources. [2] : An ALB (ELBv2) is created in AWS for the new ingress resource. This ALB can be internet-facing or internal. You can also specify the subnets it's created in using annotations. [3] : Target Groups are created in AWS for each unique Kubernetes service described in the ingress resource. [4] : Listeners are created for every port detailed in your ingress resource annotations. When no port is specified, sensible defaults ( 80 or 443 ) are used. Certificates may also be attached via annotations. [5] : Rules are created for each path specified in your ingress resource. This ensures traffic to a specific path is routed to the correct Kubernetes Service. Along with the above, the controller also... deletes AWS components when ingress resources are removed from k8s. modifies AWS components when ingress resources change in k8s. assembles a list of existing ingress-related AWS components on start-up, allowing you to recover if the controller were to be restarted.","title":"Ingress Creation"},{"location":"how-it-works/#ingress-traffic","text":"AWS Load Balancer controller supports two traffic modes: Instance mode IP mode By default, Instance mode is used, users can explicitly select the mode via alb.ingress.kubernetes.io/target-type annotation.","title":"Ingress Traffic"},{"location":"how-it-works/#instance-mode","text":"Ingress traffic starts at the ALB and reaches the Kubernetes nodes through each service's NodePort. This means that services referenced from ingress resources must be exposed by type:NodePort in order to be reached by the ALB.","title":"Instance mode"},{"location":"how-it-works/#ip-mode","text":"Ingress traffic starts at the ALB and reaches the Kubernetes pods directly. CNIs must support directly accessible POD ip via secondary IP addresses on ENI .","title":"IP mode"},{"location":"release/","text":"AWS Load Balancer Controller Release Process \u00b6 Create the Release Commit \u00b6 Run hack/set-version to set the new version number and commit the resulting changes. This is called the \"release commit\". Merge the Release Commit \u00b6 Create a pull request with the release commit. Get it reviewed and merged to main . Upon merge to main , GitHub Actions will create a release tag for the new release. If the release is a \".0-beta.1\" release, GitHub Actions will also create a release branch for the minor version. (Remaining steps in process yet to be documented.)","title":"AWS Load Balancer Controller Release Process"},{"location":"release/#aws-load-balancer-controller-release-process","text":"","title":"AWS Load Balancer Controller Release Process"},{"location":"release/#create-the-release-commit","text":"Run hack/set-version to set the new version number and commit the resulting changes. This is called the \"release commit\".","title":"Create the Release Commit"},{"location":"release/#merge-the-release-commit","text":"Create a pull request with the release commit. Get it reviewed and merged to main . Upon merge to main , GitHub Actions will create a release tag for the new release. If the release is a \".0-beta.1\" release, GitHub Actions will also create a release branch for the minor version. (Remaining steps in process yet to be documented.)","title":"Merge the Release Commit"},{"location":"deploy/configurations/","text":"Controller configuration options \u00b6 This document covers configuration of the AWS Load Balancer controller limitation The v2.0.0+ version of AWSLoadBalancerController currently only support one controller deployment(with one or multiple replicas) per cluster. The AWSLoadBalancerController assumes it's the solo owner of worker node security group rules with elbv2.k8s.aws/targetGroupBinding=shared description, running multiple controller deployment will cause these controllers compete with each other updating worker node security group rules. We will remove this limitation in future versions: tracking issue AWS API Access \u00b6 To perform operations, the controller must have required IAM role capabilities for accessing and provisioning ALB resources. There are many ways to achieve this, such as loading AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY as environment variables or using kube2iam . Refer to the installation guide for installing the controller in your kubernetes cluster and for the minimum required IAM permissions. Setting Ingress Resource Scope \u00b6 You can limit the ingresses ALB ingress controller controls by combining following two approaches: Limiting ingress class \u00b6 Setting the --ingress-class argument constrains the controller's scope to ingresses with matching ingressClassName field. An example of the container spec portion of the controller, only listening for resources with the class \"alb\", would be as follows. spec : containers : - args : - --ingress-class=alb Now, only ingress resources with the appropriate class are picked up, as seen below. apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : echoserver namespace : echoserver spec : ingressClassName : alb ... If the ingress class is not specified, the controller will reconcile Ingress objects without the ingress class specified or ingress class alb . Limiting Namespaces \u00b6 Setting the --watch-namespace argument constrains the controller's scope to a single namespace. Ingress events outside of the namespace specified are not be seen by the controller. An example of the container spec, for a controller watching only the default namespace, is as follows. spec : containers : - args : - --watch-namespace=default Currently, you can set only 1 namespace to watch in this flag. See this Kubernetes issue for more details. Controller command line flags \u00b6 The --cluster-name flag is mandatory and the value must match the name of the kubernetes cluster. If you specify an incorrect name, the subnet auto-discovery will not work. Flag Type Default Description aws-api-endpoints AWS API Endpoints Config AWS API endpoints mapping, format: serviceID1=URL1,serviceID2=URL2 aws-api-throttle AWS Throttle Config default value throttle settings for AWS APIs, format: serviceID1:operationRegex1=rate:burst,serviceID2:operationRegex2=rate:burst aws-max-retries int 10 Maximum retries for AWS APIs aws-region string instance metadata AWS Region for the kubernetes cluster aws-vpc-id string instance metadata AWS VPC ID for the Kubernetes cluster backend-security-group string Backend security group id to use for the ingress rules on the worker node SG cluster-name string Kubernetes cluster name default-ssl-policy string ELBSecurityPolicy-2016-08 Default SSL Policy that will be applied to all Ingresses or Services that do not have the SSL Policy annotation default-tags stringMap AWS Tags that will be applied to all AWS resources managed by this controller. Specified Tags takes highest priority default-target-type string instance Default target type for Ingresses and Services - ip, instance disable-ingress-class-annotation boolean false Disable new usage of the kubernetes.io/ingress.class annotation disable-ingress-group-name-annotation boolean false Disallow new use of the alb.ingress.kubernetes.io/group.name annotation disable-restricted-sg-rules boolean false Disable the usage of restricted security group rules enable-backend-security-group boolean true Enable sharing of security groups for backend traffic enable-endpoint-slices boolean false Use EndpointSlices instead of Endpoints for pod endpoint and TargetGroupBinding resolution for load balancers with IP targets. enable-leader-election boolean true Enable leader election for the load balancer controller manager. Enabling this will ensure there is only one active controller manager enable-pod-readiness-gate-inject boolean true If enabled, targetHealth readiness gate will get injected to the pod spec for the matching endpoint pods enable-shield boolean true Enable Shield addon for ALB enable-waf boolean true Enable WAF addon for ALB enable-wafv2 boolean true Enable WAF V2 addon for ALB external-managed-tags stringList AWS Tag keys that will be managed externally. Specified Tags are ignored during reconciliation feature-gates stringMap A set of key=value pairs to enable or disable features health-probe-bind-addr string :61779 The address the health probes binds to ingress-class string alb Name of the ingress class this controller satisfies ingress-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for ingress kubeconfig string in-cluster config Path to the kubeconfig file containing authorization and API server information leader-election-id string aws-load-balancer-controller-leader Name of the leader election ID to use for this controller leader-election-namespace string Name of the leader election ID to use for this controller load-balancer-class string service.k8s.aws/nlb Name of the load balancer class specified in service spec.loadBalancerClass reconciled by this controller log-level string info Set the controller log level - info, debug metrics-bind-addr string :8080 The address the metric endpoint binds to service-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for service sync-period duration 10h0m0s Period at which the controller forces the repopulation of its local object stores targetgroupbinding-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for targetGroupBinding targetgroupbinding-max-exponential-backoff-delay duration 16m40s Maximum duration of exponential backoff for targetGroupBinding reconcile failures tolerate-non-existent-backend-service boolean true Whether to allow rules which refer to backend services that do not exist (When enabled, it will return 503 error if backend service not exist) tolerate-non-existent-backend-action boolean true Whether to allow rules which refer to backend actions that do not exist (When enabled, it will return 503 error if backend action not exist) watch-namespace string Namespace the controller watches for updates to Kubernetes objects, If empty, all namespaces are watched. webhook-bind-port int 9443 The TCP port the Webhook server binds to webhook-cert-dir string /tmp/k8s-webhook-server/serving-certs The directory that contains the server key and certificate webhook-cert-file string tls.crt The server certificate name webhook-key-file string tls.key The server key name disable-ingress-class-annotation \u00b6 --disable-ingress-class-annotation controls whether to disable new usage of the kubernetes.io/ingress.class annotation. Once disabled: you can no longer create Ingresses with the value of the kubernetes.io/ingress.class annotation equal to alb (can be overridden via --ingress-class flag of this controller). you can no longer update Ingresses to set the value of the kubernetes.io/ingress.class annotation equal to alb (can be overridden via --ingress-class flag of this controller). you can still create Ingresses with a kubernetes.io/ingress.class annotation that has other values (for example: \"nginx\") disable-ingress-group-name-annotation \u00b6 --disable-ingress-group-name-annotation controls whether to disable new usage of alb.ingress.kubernetes.io/group.name annotation. Once disabled: you can no longer create Ingresses with the alb.ingress.kubernetes.io/group.name annotation. you can no longer alter the value of an alb.ingress.kubernetes.io/group.name annotation on an existing Ingress. sync-period \u00b6 --sync-period defines a fixed interval for the controller to reconcile all resources even if there is no change, default to 10 hr. Please be mindful that frequent reconciliations may incur unnecessary AWS API usage. As best practice, we do not recommend users to manually modify the resources managed by the controller. And users should not depend on the controller auto-reconciliation to revert the manual modification, or to mitigate any security risks. waf-addons \u00b6 By default, the controller assumes sole ownership of the WAF addons associated to the provisioned ALBs, via the flag --enable-waf and --enable-wafv2 . And the users should disable them accordingly if they want a third party like AWS Firewall Manager to associate or remove the WAF-ACL of the ALBs. Once disabled, the controller shall not take any actions on the waf addons of the provisioned ALBs. throttle config \u00b6 Controller uses the following default throttle config: WAF Regional:^AssociateWebACL|DisassociateWebACL=0.5:1,WAF Regional:^GetWebACLForResource|ListResourcesForWebACL=1:1,WAFV2:^AssociateWebACL|DisassociateWebACL=0.5:1,WAFV2:^GetWebACLForResource|ListResourcesForWebACL=1:1,Elastic Load Balancing v2:^RegisterTargets|^DeregisterTargets=4:20,Elastic Load Balancing v2:.*=10:40 Client side throttling enables gradual scaling of the api calls. Additional throttle config can be specified via the --aws-api-throttle flag. You can get the ServiceID from the API definition in AWS SDK. For e.g, ELBv2 it is Elastic Load Balancing v2 . Here is an example of throttle config to specify client side throttling of ELBv2 calls. --aws-api-throttle=Elastic Load Balancing v2:RegisterTargets|DeregisterTargets=4:20,Elastic Load Balancing v2:.*=10:40 Instance metadata \u00b6 If running on EC2, the default values are obtained from the instance metadata service. Feature Gates \u00b6 They are a set of kye=value pairs that describe AWS load balance controller features. You can use it as flags --feature-gates=key1=value1,key2=value2 Features-gate Supported Key Type Default Value Description ListenerRulesTagging string true Enable or disable tagging AWS load balancer listeners and rules WeightedTargetGroups string true Enable or disable weighted target groups ServiceTypeLoadBalancerOnly string false If enabled, controller will be limited to reconciling service of type LoadBalancer EndpointsFailOpen string true Enable or disable allowing endpoints with ready:unknown state in the target groups. EnableServiceController string true Toggles support for Service type resources. EnableIPTargetType string true Used to toggle support for target-type ip across Ingress and Service type resources. EnableRGTAPI string false If enabled, the tagging manager will describe resource tags via RGT APIs, otherwise via ELB APIs. In order to enable RGT API, tag:GetResources is needed in controller IAM policy. SubnetsClusterTagCheck string true Enable or disable the check for kubernetes.io/cluster/${cluster-name} during subnet auto-discovery NLBHealthCheckAdvancedConfiguration string true Enable or disable advanced health check configuration for NLB, for example health check timeout ALBSingleSubnet string false If enabled, controller will allow using only 1 subnet for provisioning ALB, which need to get whitelisted by ELB in advance NLBSecurityGroup string true Enable or disable all NLB security groups actions including frontend sg creation, backend sg creation, and backend sg modifications","title":"Configurations"},{"location":"deploy/configurations/#controller-configuration-options","text":"This document covers configuration of the AWS Load Balancer controller limitation The v2.0.0+ version of AWSLoadBalancerController currently only support one controller deployment(with one or multiple replicas) per cluster. The AWSLoadBalancerController assumes it's the solo owner of worker node security group rules with elbv2.k8s.aws/targetGroupBinding=shared description, running multiple controller deployment will cause these controllers compete with each other updating worker node security group rules. We will remove this limitation in future versions: tracking issue","title":"Controller configuration options"},{"location":"deploy/configurations/#aws-api-access","text":"To perform operations, the controller must have required IAM role capabilities for accessing and provisioning ALB resources. There are many ways to achieve this, such as loading AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY as environment variables or using kube2iam . Refer to the installation guide for installing the controller in your kubernetes cluster and for the minimum required IAM permissions.","title":"AWS API Access"},{"location":"deploy/configurations/#setting-ingress-resource-scope","text":"You can limit the ingresses ALB ingress controller controls by combining following two approaches:","title":"Setting Ingress Resource Scope"},{"location":"deploy/configurations/#limiting-ingress-class","text":"Setting the --ingress-class argument constrains the controller's scope to ingresses with matching ingressClassName field. An example of the container spec portion of the controller, only listening for resources with the class \"alb\", would be as follows. spec : containers : - args : - --ingress-class=alb Now, only ingress resources with the appropriate class are picked up, as seen below. apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : echoserver namespace : echoserver spec : ingressClassName : alb ... If the ingress class is not specified, the controller will reconcile Ingress objects without the ingress class specified or ingress class alb .","title":"Limiting ingress class"},{"location":"deploy/configurations/#limiting-namespaces","text":"Setting the --watch-namespace argument constrains the controller's scope to a single namespace. Ingress events outside of the namespace specified are not be seen by the controller. An example of the container spec, for a controller watching only the default namespace, is as follows. spec : containers : - args : - --watch-namespace=default Currently, you can set only 1 namespace to watch in this flag. See this Kubernetes issue for more details.","title":"Limiting Namespaces"},{"location":"deploy/configurations/#controller-command-line-flags","text":"The --cluster-name flag is mandatory and the value must match the name of the kubernetes cluster. If you specify an incorrect name, the subnet auto-discovery will not work. Flag Type Default Description aws-api-endpoints AWS API Endpoints Config AWS API endpoints mapping, format: serviceID1=URL1,serviceID2=URL2 aws-api-throttle AWS Throttle Config default value throttle settings for AWS APIs, format: serviceID1:operationRegex1=rate:burst,serviceID2:operationRegex2=rate:burst aws-max-retries int 10 Maximum retries for AWS APIs aws-region string instance metadata AWS Region for the kubernetes cluster aws-vpc-id string instance metadata AWS VPC ID for the Kubernetes cluster backend-security-group string Backend security group id to use for the ingress rules on the worker node SG cluster-name string Kubernetes cluster name default-ssl-policy string ELBSecurityPolicy-2016-08 Default SSL Policy that will be applied to all Ingresses or Services that do not have the SSL Policy annotation default-tags stringMap AWS Tags that will be applied to all AWS resources managed by this controller. Specified Tags takes highest priority default-target-type string instance Default target type for Ingresses and Services - ip, instance disable-ingress-class-annotation boolean false Disable new usage of the kubernetes.io/ingress.class annotation disable-ingress-group-name-annotation boolean false Disallow new use of the alb.ingress.kubernetes.io/group.name annotation disable-restricted-sg-rules boolean false Disable the usage of restricted security group rules enable-backend-security-group boolean true Enable sharing of security groups for backend traffic enable-endpoint-slices boolean false Use EndpointSlices instead of Endpoints for pod endpoint and TargetGroupBinding resolution for load balancers with IP targets. enable-leader-election boolean true Enable leader election for the load balancer controller manager. Enabling this will ensure there is only one active controller manager enable-pod-readiness-gate-inject boolean true If enabled, targetHealth readiness gate will get injected to the pod spec for the matching endpoint pods enable-shield boolean true Enable Shield addon for ALB enable-waf boolean true Enable WAF addon for ALB enable-wafv2 boolean true Enable WAF V2 addon for ALB external-managed-tags stringList AWS Tag keys that will be managed externally. Specified Tags are ignored during reconciliation feature-gates stringMap A set of key=value pairs to enable or disable features health-probe-bind-addr string :61779 The address the health probes binds to ingress-class string alb Name of the ingress class this controller satisfies ingress-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for ingress kubeconfig string in-cluster config Path to the kubeconfig file containing authorization and API server information leader-election-id string aws-load-balancer-controller-leader Name of the leader election ID to use for this controller leader-election-namespace string Name of the leader election ID to use for this controller load-balancer-class string service.k8s.aws/nlb Name of the load balancer class specified in service spec.loadBalancerClass reconciled by this controller log-level string info Set the controller log level - info, debug metrics-bind-addr string :8080 The address the metric endpoint binds to service-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for service sync-period duration 10h0m0s Period at which the controller forces the repopulation of its local object stores targetgroupbinding-max-concurrent-reconciles int 3 Maximum number of concurrently running reconcile loops for targetGroupBinding targetgroupbinding-max-exponential-backoff-delay duration 16m40s Maximum duration of exponential backoff for targetGroupBinding reconcile failures tolerate-non-existent-backend-service boolean true Whether to allow rules which refer to backend services that do not exist (When enabled, it will return 503 error if backend service not exist) tolerate-non-existent-backend-action boolean true Whether to allow rules which refer to backend actions that do not exist (When enabled, it will return 503 error if backend action not exist) watch-namespace string Namespace the controller watches for updates to Kubernetes objects, If empty, all namespaces are watched. webhook-bind-port int 9443 The TCP port the Webhook server binds to webhook-cert-dir string /tmp/k8s-webhook-server/serving-certs The directory that contains the server key and certificate webhook-cert-file string tls.crt The server certificate name webhook-key-file string tls.key The server key name","title":"Controller command line flags"},{"location":"deploy/configurations/#disable-ingress-class-annotation","text":"--disable-ingress-class-annotation controls whether to disable new usage of the kubernetes.io/ingress.class annotation. Once disabled: you can no longer create Ingresses with the value of the kubernetes.io/ingress.class annotation equal to alb (can be overridden via --ingress-class flag of this controller). you can no longer update Ingresses to set the value of the kubernetes.io/ingress.class annotation equal to alb (can be overridden via --ingress-class flag of this controller). you can still create Ingresses with a kubernetes.io/ingress.class annotation that has other values (for example: \"nginx\")","title":"disable-ingress-class-annotation"},{"location":"deploy/configurations/#disable-ingress-group-name-annotation","text":"--disable-ingress-group-name-annotation controls whether to disable new usage of alb.ingress.kubernetes.io/group.name annotation. Once disabled: you can no longer create Ingresses with the alb.ingress.kubernetes.io/group.name annotation. you can no longer alter the value of an alb.ingress.kubernetes.io/group.name annotation on an existing Ingress.","title":"disable-ingress-group-name-annotation"},{"location":"deploy/configurations/#sync-period","text":"--sync-period defines a fixed interval for the controller to reconcile all resources even if there is no change, default to 10 hr. Please be mindful that frequent reconciliations may incur unnecessary AWS API usage. As best practice, we do not recommend users to manually modify the resources managed by the controller. And users should not depend on the controller auto-reconciliation to revert the manual modification, or to mitigate any security risks.","title":"sync-period"},{"location":"deploy/configurations/#waf-addons","text":"By default, the controller assumes sole ownership of the WAF addons associated to the provisioned ALBs, via the flag --enable-waf and --enable-wafv2 . And the users should disable them accordingly if they want a third party like AWS Firewall Manager to associate or remove the WAF-ACL of the ALBs. Once disabled, the controller shall not take any actions on the waf addons of the provisioned ALBs.","title":"waf-addons"},{"location":"deploy/configurations/#throttle-config","text":"Controller uses the following default throttle config: WAF Regional:^AssociateWebACL|DisassociateWebACL=0.5:1,WAF Regional:^GetWebACLForResource|ListResourcesForWebACL=1:1,WAFV2:^AssociateWebACL|DisassociateWebACL=0.5:1,WAFV2:^GetWebACLForResource|ListResourcesForWebACL=1:1,Elastic Load Balancing v2:^RegisterTargets|^DeregisterTargets=4:20,Elastic Load Balancing v2:.*=10:40 Client side throttling enables gradual scaling of the api calls. Additional throttle config can be specified via the --aws-api-throttle flag. You can get the ServiceID from the API definition in AWS SDK. For e.g, ELBv2 it is Elastic Load Balancing v2 . Here is an example of throttle config to specify client side throttling of ELBv2 calls. --aws-api-throttle=Elastic Load Balancing v2:RegisterTargets|DeregisterTargets=4:20,Elastic Load Balancing v2:.*=10:40","title":"throttle config"},{"location":"deploy/configurations/#instance-metadata","text":"If running on EC2, the default values are obtained from the instance metadata service.","title":"Instance metadata"},{"location":"deploy/configurations/#feature-gates","text":"They are a set of kye=value pairs that describe AWS load balance controller features. You can use it as flags --feature-gates=key1=value1,key2=value2 Features-gate Supported Key Type Default Value Description ListenerRulesTagging string true Enable or disable tagging AWS load balancer listeners and rules WeightedTargetGroups string true Enable or disable weighted target groups ServiceTypeLoadBalancerOnly string false If enabled, controller will be limited to reconciling service of type LoadBalancer EndpointsFailOpen string true Enable or disable allowing endpoints with ready:unknown state in the target groups. EnableServiceController string true Toggles support for Service type resources. EnableIPTargetType string true Used to toggle support for target-type ip across Ingress and Service type resources. EnableRGTAPI string false If enabled, the tagging manager will describe resource tags via RGT APIs, otherwise via ELB APIs. In order to enable RGT API, tag:GetResources is needed in controller IAM policy. SubnetsClusterTagCheck string true Enable or disable the check for kubernetes.io/cluster/${cluster-name} during subnet auto-discovery NLBHealthCheckAdvancedConfiguration string true Enable or disable advanced health check configuration for NLB, for example health check timeout ALBSingleSubnet string false If enabled, controller will allow using only 1 subnet for provisioning ALB, which need to get whitelisted by ELB in advance NLBSecurityGroup string true Enable or disable all NLB security groups actions including frontend sg creation, backend sg creation, and backend sg modifications","title":"Feature Gates"},{"location":"deploy/installation/","text":"AWS Load Balancer Controller installation \u00b6 The AWS Load Balancer controller (LBC) provisions AWS Network Load Balancer (NLB) and Application Load Balancer (ALB) resources. The LBC watches for new service or ingress Kubernetes resources and configures AWS resources. The LBC is supported by AWS. Some clusters may be using the legacy \"in-tree\" functionality to provision AWS load balancers. The AWS Load Balancer Controller should be installed instead. Existing AWS ALB Ingress Controller users The AWS ALB Ingress controller must be uninstalled before installing the AWS Load Balancer Controller. Please follow our migration guide to do a migration. When using AWS Load Balancer Controller v2.5+ The AWS LBC provides a mutating webhook for service resources to set the spec.loadBalancerClass field for service of type LoadBalancer on create. This makes the AWS LBC the default controller for service of type LoadBalancer. You can disable this feature and revert to set Cloud Controller Manager (in-tree controller) as the default by setting the helm chart value enableServiceMutatorWebhook to false with --set enableServiceMutatorWebhook=false . You will no longer be able to provision new Classic Load Balancer (CLB) from your kubernetes service unless you disable this feature. Existing CLB will continue to work fine. Supported Kubernetes versions \u00b6 AWS Load Balancer Controller v2.0.0~v2.1.3 requires Kubernetes 1.15+ AWS Load Balancer Controller v2.2.0~v2.3.1 requires Kubernetes 1.16-1.21 AWS Load Balancer Controller v2.4.0+ requires Kubernetes 1.19+ AWS Load Balancer Controller v2.5.0+ requires Kubernetes 1.22+ Deployment considerations \u00b6 Additional requirements for non-EKS clusters: \u00b6 Ensure subnets are tagged appropriately for auto-discovery to work For IP targets, pods must have IPs from the VPC subnets. You can configure the amazon-vpc-cni-k8s plugin for this purpose. Additional requirements for isolated cluster: \u00b6 Isolated clusters are clusters without internet access, and instead reply on VPC endpoints for all required connects. When installing the AWS LBC in isolated clusters, you need to disable shield, waf and wafv2 via controller flags --enable-shield=false, --enable-waf=false, --enable-wafv2=false Using the Amazon EC2 instance metadata server version 2 (IMDSv2) \u00b6 We recommend blocking the access to instance metadata by requiring the instance to use IMDSv2 only. For more information, please refer to the AWS guidance here . If you are using the IMDSv2, set the hop limit to 2 or higher in order to allow the LBC to perform the metadata introspection. You can set the IMDSv2 as follows: aws ec2 modify-instance-metadata-options --http-put-response-hop-limit 2 --http-tokens required --region