Prepare for Kubernetes 1.8 Ingress changes

[alexellis]

In Kubernetes 1.18 the Ingress definitions have changed slightly.

In particular the Kubernetes release notes [1] mention the change about ingressClass becoming part of the spec, instead of being an annotation.

If we can add both, perhaps that will help keep backwards compatibility for the time being?

[1] https://kubernetes.io/docs/setup/release/notes/#extending-ingress-with-and-replacing-a-deprecated-annotation-with-ingressclass

Alex

[aledbf]

mention the change about ingressClass becoming part of the spec, instead of being an annotation.

Keep in mind you need to create an ingressClass object and configure the ingress controller to use it.

[alexellis]

That is something that I missed, until I did a deep dive on the release notes.

So does ingress-nginx create this or not? How about others like Traefik v2?

[aledbf]

So does ingress-nginx create this or not?

No. That is up to the operator. The IngressClass is a global resource and most of the users (at least in ingress-nginx) don't have enough permissions for that.

kubernetes/ingress-nginx#5410

[alexellis]

I'm feeling fairly confused by this, so I imagine most users will be in a world of pain. The annotation was "soft" deprecated in favour of the new ingressClass, but if the IngressController or its helm package doesn't create it, how are we expected to know what to do?

The reason I raised the issue was for this component to be compatible with K8s 1.18. What would you do in this situation @aledbf ?

[aledbf]

Please check kubernetes/ingress-nginx#5410

We keep using the same flag in the ingress controller deployment --ingress-class
This means we don't break existing ingress definition using the ingress.class annotation.
If you are using k8s v1.18 and want to use the IngressClassName field you need to create an IngressClass object with the same name used in --ingress-class.

[robscott]

I do think the ideal is for users to create and manage IngressClass resources. The ideal use case would be configuring classes with different combinations of parameters to be used with the same controller. Admittedly not every controller is going to support a parameters resource, but I think a parameters CRD with appropriate validation provides significant advantages over annotations. Hopefully that's valuable enough for some.

[matoszz]

There needs to be more instructions provided for folks running multiple controllers; having a basic definition with controller: "k8s.io/ingress-nginx" makes it unclear if you need to name specific to the actual controller deployment or service