Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to networking.k8s.io/v1 Ingress API #2050

Closed
rifelpet opened this issue Jun 4, 2021 · 17 comments · Fixed by #2433
Closed

Migrate to networking.k8s.io/v1 Ingress API #2050

rifelpet opened this issue Jun 4, 2021 · 17 comments · Fixed by #2433
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects

Comments

@rifelpet
Copy link
Contributor

rifelpet commented Jun 4, 2021

Kubernetes 1.22 will drop support for networking.k8s.io/v1beta1 which was introduced in Kubernetes 1.19.

https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122

aws-load-balancer-controller still uses v1beta1:

networking "k8s.io/api/networking/v1beta1"

Here are pod logs from v2.2.0 running in a v1.22.0-alpha.2 cluster. The container fails to start due to networking.k8s.io/v1beta1 not being recognized.

In order to support Kubernetes 1.22, aws-load-balancer-controller will need to migrate to the networking.k8s.io/v1 Ingress API.

@M00nF1sh
Copy link
Collaborator

/kind feature
We have been plan on this, the tricky part is that networking/v1 is not supported in 1.18, but 1.18 will still be supported by EKS when EKS announces support for 1.22.

So i think we'll need a way to dynamically discover the available Ingress versions and use networking/v1beta1 for v1.18 and translate it into networking/v1 from controller-side.

we'll figure this out before 1.22 is generally supported, If you have any thoughts in mind, feel free to raise a PR.

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jul 14, 2021
@olemarkus
Copy link
Contributor

This is a fairly common issue that we have seen on the kOps side for quite some time. We use k8s version to decide which version of an addon to install (by default).
I.e from our perspective, it is perfectly fine to drop 1.18 support for newer releases using networking/v1, and kOps will just deploy an older version on older k8s versions. Cluster Autoscaler would be the most well-known addon that even maintains one branch per k8s minor version.

Trying to discover which version of a resource and support all variation sounds like something that could become complicated over time.

@olemarkus
Copy link
Contributor

Any updates on this one now that 1.22 is out? We are looking to make all the kOps addons work for our stable release scheduled not too long from now.

@technotaff-nbs
Copy link

technotaff-nbs commented Oct 1, 2021

This is causing us some grief, we are prepping all of our clusters for future releases and block most deprecated APIs.

Will this be fixed in 2.3? EKS 1.22 is due around mid-November if previous cadence are replicated.

@ggermis
Copy link

ggermis commented Nov 3, 2021

I wouldn't categorize this as a feature request anymore but a high priority issue since kubernetes has a stable 1.22 release since august 4th (almost 3 months). This is blocking anyone from upgrading (or even preparing to upgrade) their cluster

@mariomerco
Copy link

I wouldn't categorize this as a feature request anymore but a high priority issue since kubernetes has a stable 1.22 release since august 4th (almost 3 months). This is blocking anyone from upgrading (or even preparing to upgrade) their cluster

Same in here, this is blocking us to prepare ourselves to upgrade our EKS clusters whenever 1.22 comes available.

@lucazz
Copy link

lucazz commented Nov 3, 2021

Same here, different stack but the same issue.
This prevents us from rolling out newer versions of EKS clusters w/ terraform.

@BuffaloWill
Copy link

Same here. This is a blocker for us as well.

@slithernix
Copy link

Totally blocked on updating for this, which blocks us on another issue that causes some of our devs real headaches.

@BrianKopp
Copy link
Contributor

@ggermis
Copy link

ggermis commented Nov 19, 2021

@BrianKopp The issue is not the creation of the Ingress object with the v1 version, but that the aws-loadbalancer-controller looks for it using v1beta1

Code that looks for the ingress objects is at: https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/controllers/ingress/group_controller.go#L224

The definition of ingressResourcesGroupVersion is at: https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/controllers/ingress/group_controller.go#L39

So while you can create an Ingress object with group networking.k8s.io/v1, it will not be seen / picked u by the aws loadbalancer controller who will only look for objects with group networking.k8s.io/v1beta1

@BrianKopp
Copy link
Contributor

Ah, thank you for that clarification! I totally misunderstood!

I see this being a feature tracked in 2.4.0. Is there already a WIP on these changes? Or are you seeking contributions?

@avivgold098
Copy link

Thx for the update!

Blocker for our organization upgrade to 1.22.*

@seh
Copy link
Contributor

seh commented Nov 26, 2021

Is anyone working on fixing this, or is this project intending on hanging back at Kubernetes version 1.21? The "networking.k8s.io/v1" GV has been available for a year and a half—before this project's first release using the new name.

@olemarkus
Copy link
Contributor

With 1.23 being out, users are now stuck two minor versions behind. K8s 1.21 is EOL as 1.24 is released in April, and users need time to upgrade before then as well.

@kishorj
Copy link
Collaborator

kishorj commented Dec 9, 2021

We will move to the v1 apis for 2.4.0 and later releases. This issue is on the top of our list at the moment.

@sftim
Copy link
Contributor

sftim commented Dec 21, 2021

If there's a related need to select a default version of the controller in its Helm chart, try something like:

{{- if .Capabilities.APIVersions.Has "networking.k8s.io/v1/Ingress" -}}
2.4.0
{{- else -}}
2.3.1
{{- end -}}

in a helper.

@kishorj kishorj moved this from In progress to Done in v2.4.0 Jan 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
No open projects
Development

Successfully merging a pull request may close this issue.