Update to latest API group for Ingress to support K8s 1.22+

[alexellis]

Expected Behaviour

K8s < 1.22 and > 1.22 should work without changes.

Current Behaviour

Only < 1.22 is supported due to the API group being used going away.

List All Possible Solutions and Workarounds

Have an if statement based upon the kube API server version returned.

Steps to Reproduce (for bugs)

1. Create a new cluster with minikube or kind using 1.22
2. Deploy
3. Try to create FunctionIngress
4. See it fail

Context

Must fix to continue being used on latest K8s versions.

[alexellis]

/add label: help wanted,good first issue

[miguelhrocha]

I can take care of this @alexellis

[alexellis]

I'll look out for a PR @miguelhrocha - but If we don't see one within a week, or when users start having issues, we may need to jump in.

Let me know what kind of timeline you have in mind?

[alexellis]

@LucasRoesler it seems we've had no motion on this and missed the release date, so could you put this onto your list, or find someone else to take up the task?

I liked the way you solved the problem for arkade by checking the capabilities of the API server instead of looking purely at the K8s API version.

[LucasRoesler]

@alexellis can you clarify the scope you are expecting on this? I just looked at it and it seems like you are talking about adding an if-statement to the Controller so that it can work with both the new networking/v1 and with the betav1 apis at the same time. This is not a trivial change, those return types are different, so every spot of the code that in anyway interacts, watches, or creates Ingresses will need some extensive refactoring. The first place this impacts is here

ingress-operator/pkg/controller/controller.go

Lines 109 to 110 in 6dcc233

	ingressInformer := kubeInformerFactory.Networking().V1beta1().Ingresses()
	ingressLister := ingressInformer.Lister()

or for example here

ingress-operator/pkg/controller/controller.go

Line 268 in 6dcc233

ingress, getIngressErr := ingresses.Get(fni.Name)

where an ingress is returned. The typed client is going to return two different and incompatible types.

Further, i noticed that the project is using the 0.17.0 client, so this also requires an upgrade of client-go to at least 0.19.0, just to have access to the networking v1 API.

There might be a way to try and deal with this via interfaces ... but I am not really sure it is possible or potentially even a good idea. It will be complex code. Alternatively you could try deal with the untyped API instead, but again, it is going to be messy.

There is also a code-generator module pinned at 0.17.0, which may also need to be updated. I am not sure if it is impacted by this in anyway https://kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122

[alexellis]

The dependencies can be updated to 1.19

But if we don't have the if statement, then we will prevent people using Kubernetes 1.18 and lower from using this component.

A bit of context from the ingress-nginx project:

kubernetes/ingress-nginx#7156

[LucasRoesler]

@alexellis i am not willing to personally take on support for this, i totally understand that it means dropping support for k8s < 1.19, but this project is often used with nginx-ingress has already done this, so my initial feeling is that unless you see significant new features coming to ingress-operator, it is easier to feeze support for k8s < 1.19 with ingress-operator <= 0.6.7.

At install, we can toggle the version in the helm chart based on the cluster capabilities

[alexellis]

Minimum supported versions:

GKE = 1.17
AWS EKS = 1.16

What to do?