Aws-load-balancer-controller: What's happening with v2 GA

[rverma-jm]

It seems that the GA for v2 (shared ALB) is taking for ever. But there was no support on v2 at all. Even the pod IAM is not yet supported.
Can we cherry pick relevant v2 code in master to get things in action.

[M00nF1sh]

hi,
sorry for that, I got switched to work on AppMesh recently due to priority, will be back on to continue V2 GA.

[rverma-jm]

Thanks, do let me know how can I help.

[iverberk]

@M00nF1sh / AWS First of all, we appreciate all the work that you have done on the ALB ingress controller and are using it extensively in our setup. However, the timelines for v2 GA are getting absurd.

We absolutely needed the grouping functionality because otherwise it would become prohibitively expensive to run an ALB for each service. You decided to do a total rewrite of the codebase to support this, which leaves us in the state that we are now in: two totally different versions that are not supporting the same feature set. We decided to go ahead and use the V2 release after consulting with you that this was going to be the next version and you were going to migrate everything over. Because of the total rewrite this seemed like a huge undertaking for a single person and apparently it is, because V2 is now effectively stalled.

As you know, on many occasions @arminc and others have tried to offer help and even asked several AWS people directly to help support this and make the priorities clear, as we feel this is an important part of the AWS K8s ecosystem. Every time we get an answer that this project is important and that you will work on it 'soon', yet we see very little to no progress in terms of v2 GA and you seem to be working on something else all the time. One example of missing functionality in the V2 branch is the alb.ingress.kubernetes.io/conditions. annotation.

We are very disappointed with the way AWS is handling this open-source project and hope to see a final effort to get V2 sorted in the near future. @mhausenblas can you also chime in since we reached out to you to hear if AWS was giving priority to this project. You said it was and we would like to know if this is still the case.

[mhausenblas]

Thanks for pointing this out @iverberk and let me follow up internally.

[rverma-jm]

@iverberk aptly said, I indeed expect that support for a better ingress controller should be given enough importance with respect to consumer's requirements. These are literally essential and build blocks for one's infra. We used 1.2 alpha and finally moved to nginx because of many issues and not a single update in last 1 year on that.

[M00nF1sh]

@rverma-jm @iverberk i'm really sorry for the disappointment caused. I was too optimistic about the timeline and priority. we definitely needs some help here.
The current problem with V2 GA is it's missing unit test and code review from my peers. (TBH, i believe the 1.2.0.alpha1 should work more reliably than current version other than missing features)
Here is my plan:

1. unit test and code review all existing code from V2 to V2 GA branch. (maybe it make more sense to merge it into master branch. so the master branch can contain some unused code :D)
   
   
   
   • https://github.com/kubernetes-sigs/aws-alb-ingress-controller/pull/1166
   
   
   • needs help to for other piece of code as well. (model builder & model deployer).
   
   
2. make the endpointBinding a CRD object(https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/v2/pkg/apis/ingress/v1alpha1/endpointbinding_types.go#L26), which should handle: (welcome help here)
   
   
   
   • target types(instance & ip)
   
   
   • podReadiness probe
   
   
   • worker node security group
   
   
   • ALB/NLB targetGroup. (we can use it to support NLB service IP mode as well, the in-tree cloudProvider interface prevents us to support NLB IP mode)
   
   
3. feature gaps. (advanced routing)
4. full E2E coverage. (welcome help here).
5. potential support for service-API once it's ready: (https://kubernetes-sigs.github.io/service-apis/community/).
   The goal of the "model builder & model deployer" in step 1 is to make sure we only need to write a model builder to service-API while model deployer is shared. (And ideally model deployer can support NLB as well)

BTW, some background, currently appMesh GA is taking more priority than this, but i'll try do a review for the endpointBinding a CRD design. we will have 4 peer onboard on April and 2 are ramping up now, so there will be more AWS resources working on this

[rverma-jm]

@M00nF1sh I raised this earlier as well, we know there is some overlapping functionalities in nlb and alb. Specially target type ip support and sni support.

I was wondering isn't it possible to put the common code in kubernetes and the use that here.
And if we get to share a NLB also, I think that would really awesome.

[M00nF1sh]

@rverma-jm
Yes, it's indeed possible to share a lot code even for NLB's instance mode. (we have plans to revisit the cloudProvider's NLB/ELB support).
But it will happen after we finished the cloudProvider out-of-tree migration: https://github.com/kubernetes/cloud-provider-aws, where we can iterate faster. (and then it can share same library between ALB & NLB).
For the NLB's IP mode, we cannot rely on the service controller, since the cloudProvider's interface for serviceControllers sends notifications based on instance changes instead of pod changes, there needs to be a standalone controller loop. (can be in either ALB / our out-of-tree cloudProvider if share same code base). we have plans to add a annotation to k8s service to denote skip the in-tree service handling logic to make this standalone controller loop works.

[rverma-jm]

Looks good, would be nice if this can be put in some roadmap where we can
contribute in steps as well as the community have so vision.

On Sat, 28 Mar, 2020, 12:31 am M00nF1sh, [e-mail] wrote:

@rverma-jm https://github.com/rverma-jm
Yes, it's indeed possible to share a lot code even for NLB's instance
mode. (we have plans to revisit the cloudProvider's NLB/ELB support).
But it will happen after we finished the cloudProvider out-of-tree
migration: https://github.com/kubernetes/cloud-provider-aws, where we can
iterate faster. (and then it can share same library between ALB & NLB).
For the NLB's IP mode, we cannot rely on the service controller, since the
cloudProvider's interface for serviceControllers sends notifications based
on instance changes instead of pod changes, there needs to be a standalone
controller loop. (can be in either ALB / cloudProvider if share same code
base). we have plans to add a annotation to k8s service to denote skip the
in-tree service handling logic to make this standalone controller loop
works.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/1197#issuecomment-605214820,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN4B5LQWIGXR5AKMIWEQSEDRJTZZFANCNFSM4LPETBZA
.

[frederiksf]

April half way and no activity so far as i can see here. @M00nF1sh is there any (deadline) date determined?

[M00nF1sh]

@frederiksf I have to work on appmesh for about a month, will be back working on this on May. (I can finish all v2 work for a month work)

[leoskyrocker]

@iverberk for grouping, have you looked into https://github.com/jakubkulhan/ingress-merge? (If I didn't misunderstand what you meant by grouping.)

[runningman84]

ingress-merge does not help because most of the times our apps or in different namespaces...

[oded-dd]

@M00nF1sh Any progress on that? It is super important to our organization, we are starting to look for ALB alternatives unfortunately. Can you please provide a clear estimation?

[techdragon]

There has been a single commit to the v2 branch since the end of January, the rate of progress on this issue is _deeply_ concerning. (I do however understand this seems to be mostly due to things outside of your control @M00nF1sh)

Do you have any updates on v2 @M00nF1sh or @mhausenblas ?

[sbkg0002]

Is there any update on this?

[astrived]

@oded-dd @techdragon @sbkg0002 we are actively working on v2 and are addressing known issues and feature gaps identified against v1, given that few features are missing here. Stay tuned you will see upcoming release dates published in couple of weeks.

[mikestef9]

To provide a further update, we are indeed actively working on a production ready v2 version, but it will not be released as part of this repository.

This issue has some context, https://github.com/aws/containers-roadmap/issues/981 but will provide it here as well

We will be launching a new open source project, the aws-load-balancer-controller, that initially will house controller code for both ALB Ingress v2, and NLB IP mode. Eventually, we will also add support for the upcoming Service APIs to this controller. And further down the line as part of the out of tree cloud provider move, we will add the NLB instance mode (that currently lives in-tree) to this controller as well. In the longer term, that means we'll have a single project to manage AWS load balancers via Kubernetes.

To be clear, having a new repository will not affect any development timelines, but it does mean you will have to install a new controller in your cluster in order to get ALB ingress grouping features, and any other new features down the line.

Still working on a more granular timeline to share, but this is a top priority for the EKS team right now that is under active development.

[khacminh]

Because the ALB doesn't support HTTP/2 to the backend targets, I really need feature that the ALB Ingress v2 can support the NLB IP mode

[astrived]

ALB is working on adding grpc/http2 support tentatively Q3 2020. We will follow up and add support for the same once the features are launched.

[Dudssource]

My guess it's almost there:
https://github.com/aws/eks-charts/pull/240

[astrived]

We are doing the final phase of testing for the new aws-loadbalancer-controller and the RC image is here https://github.com/kubernetes-sigs/aws-alb-ingress-controller/releases/tag/v2.0.0-rc5. You can find details here https://github.com/kubernetes-sigs/aws-alb-ingress-controller/tree/v2_ga. Stay tuned for What's new coming soon ! With regards to GRPC/HTTP2 support will be added in follow up release given that ALB team is working on the launch.

[astrived]

We have published the v2.0.0 release at https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/tag/v2.0.0 The documents have been updated https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html and https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html and the blog post is here https://aws.amazon.com/blogs/containers/introducing-aws-load-balancer-controller/