[EKS]: Support AWS Load Balancer Controller in EKS add-ons
Add support for managing AWS Load Balancer Controller with EKS add-ons.
The Load Balancer Controller seems like something that should be on the controlplane rather than an add-on. Same goes for the CSI driver.
Here is an example of an issue we have where we find ourselves falling short between AWS & EKS with load balancers.
I would like to take advantage of VPC endpoint service to allow another AWS account to use private endpoint to talk to something running within kubernetes and not over public network.
Would look something like this: AWS Account A [Lambda -> Private endpoint] -> Account B [ VPC endpoint service -> Internal NLB -> Kubernetes -> Service]
The problem here is kind of a chicken & egg situation that requires cluster post installs. We're not able to set up the VPC endpoint service until the NLB exists but the NLB won't exist until kubectl apply (helm install in our case) happens on the application side because that has the load balancer resource.
Our "hack around this:
- terraform for initial infrastructure (vpc, eks, etc)
- helm install (applications)
- terraform post install (vpc endpoint service now that the NLB exists from the application)
Will the aws-load-balancer-controller EKS Add-On support customizations?
I currently use the helm chart in the eks-charts repo to install this controller. Here are the helm values that we specify:
replicaCount: 1
podAnnotations:
nice.com/owner: [email protected]
nice.com/product: aws-load-balancer-controller
serviceAnnotations:
nice.com/owner: [email protected]
nice.com/product: aws-load-balancer-controller
clusterName: {{ .Values.global.eksClusterName }}
serviceAccount:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/role-for-aws-load-balancer-controller
nice.com/owner: [email protected]
nice.com/product: aws-load-balancer-controller
create: true
name: aws-load-balancer-controller
rbac:
create: true
podSecurityContext:
fsGroup: 65534
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
allowPrivilegeEscalation: false
terminationGracePeriodSeconds: 10
resources:
limits:
cpu: 200m
memory: 128Mi
requests:
cpu: 100m
memory: 50Mi
ingressClass: alb
enableShield: true
enableWaf: true
enableWafv2: true
logLevel: info
We are debating whether it makes sense to add support LB controller in EKS add-ons before #1333 (which will be config for all add-ons, not just vpc cni) is available. This is helpful to see the options you are currently setting.
@mikestef9 could we get an update on the plan for this feature?
Definitely, having AWS Load Balancer Controller in EKS as an add-on will help the EKS customers to use it in a easy-way and upgrading versions without breaking services.
AWS Load Balancer Controller is specific for AWS, so it makes even more sense to be an add-on
+1 to this issue. It'll be a major ease-of-use upgrade to have AWS Load Balancer Controller in EKS as an add-on.
@mikestef9 Guys, do you have any plans to adding this addon in EKS add-ons?
If you do add this functionality, can I request that when you delete the addon and then the cluster it cleans up all the load balancers it spawned in the cluster as a pre-delete hook job?
It's a bain of my life to deal with deleting EKS stacks with <insert IAC tool here> to have dangling load balancers preventing VPCs being deleted.
I'm aware the official solution is to clear down the workloads on the cluster first before IAC deletes the infrastructure but it's not always that trivial to do.
Thanks
This would save me loads of time, but based on this, not sure I'll be the one to get to save that time. I'm hoping someone in the future will benefit from my bumping of this issue.
If aws-load-balancer-controller becomes an addon and relieves us from managing the associated cert-manager manifests, that would be fantastic. Since cert-manager loses support every two years, regular updates are required to stay current. However, updates are typically done one version at a time, which still incurs some maintenance overhead. If both aws-load-balancer-controller and cert-manager transition to addons, it would significantly reduce operational costs. I'm eagerly looking forward to the migration to addons!
Please, it makes complete sense to have this in the Add-on offering. Looking forward to it!
@MitchIonascu Have you considered EKS Auto Mode, which does not only solve this particular issue but manages other add-ons like AWS VPC CNI, kube-proxy, EBS CSI and Karpenter as well!
@MitchIonascu Have you considered EKS Auto Mode, which does not only solve this particular issue but manages other add-ons like AWS VPC CNI, kube-proxy, EBS CSI and Karpenter as well!
Thank you! Unfortunately is not something we are considering given the lack of control. We like to manage our own EKS clusters and would love to have it as an add-on.
Such simple thing to ask for that after terraform i already have a cluster which can be used. Dont know why such a simple request takes 5 years and is still open.
Hey, any updates here?
Chiming in, this would be great to have
Starting with Kubernetes v1.31, the remaining in-tree cloud provider integrations will be fully removed as part of the release (https://kubernetes.io/blog/2024/07/19/kubernetes-1-31-upcoming-changes/).
Since an AWS Load Balancer Controller will no longer be available by default as it was before, in my opinion it makes sense to revisit this request and provide this specific AWS controller as a plugin, similar to how other components (EBS driver, VPC CNI, metrics-server, etc.) are delivered 🙏
Could we get an update on the plan for this feature? cc. @mikestef9