[EKS]: Support AWS Load Balancer Controller in EKS add-ons

[leandrocostam]

Add support for managing AWS Load Balancer Controller with EKS add-ons.

[gregoryfranklin]

The Load Balancer Controller seems like something that should be on the controlplane rather than an add-on. Same goes for the CSI driver.

[ckdarby]

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)

[jwenz723]

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: owner@email.com
    nice.com/product: aws-load-balancer-controller
serviceAnnotations:
    nice.com/owner: owner@email.com
    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: owner@email.com
    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

[mikestef9]

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.

[nathan-boyd]

@mikestef9 could we get an update on the plan for this feature?

[luarx]

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

[ashpreetbedi]

+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.

[malcolm061990]

@mikestef9 Guys, do you have any plans to adding this addon in EKS add-ons?

[danielloader]

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 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

[sebas-w]

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.