kubernetes: Add support for IngressClass introduced in Kubernetes v1.18

[mikkeloscar]

Kubernetes v1.18 introduced a dedicated resource + field for defining IngressClass. See the documentation here: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class

It would make sense for skipper to support ingress class in this way going forward.

@szuecs added:
Spec changes in Kubernetes:

1. there is a new field spec.ingressClassName in ingress.v1.networking.k8s.io
2. there is a new top level object IngressClass

% kubectl explain ingress.spec.ingressClassName
KIND:     Ingress
VERSION:  networking.k8s.io/v1

FIELD:    ingressClassName <string>

DESCRIPTION:
     IngressClassName is the name of the IngressClass cluster resource. The
     associated IngressClass defines which controller will implement the
     resource. This replaces the deprecated `kubernetes.io/ingress.class`
     annotation. For backwards compatibility, when that annotation is set, it
     must be given precedence over this field. The controller may emit a warning
     if the field and annotation have different values. Implementations of this
     API should ignore Ingresses without a class specified. An IngressClass
     resource may be marked as default, which can be used to set a default value
     for this field. For more information, refer to the IngressClass
     documentation.

IngressClass

% kubectl explain ingressclass
KIND:     IngressClass
VERSION:  networking.k8s.io/v1

DESCRIPTION:
     IngressClass represents the class of the Ingress, referenced by the Ingress
     Spec. The `ingressclass.kubernetes.io/is-default-class` annotation can be
     used to indicate that an IngressClass should be considered default. When a
     single IngressClass resource has this annotation set to true, new Ingress
     resources without a class specified will be assigned this default class.

[szuecs]

SGTM, because of Kubernetes, not that I think the change makes sense. The move towards v2: GatewayClass/Gateway/Route we likely don't do, because it creates only complexity without value.
I tried to make my points in the proposal phase of this and was not really head, so better go for RouteGroups.

[myaser]

hello, I would like to contribute to this issue

[szuecs]

Thanks I am happy to read a PR.
Let's see if this a good first issue, if not just tell us and we find something that maybe fits better.
If you won't make it, it's also fine, but please tell, such that I can un-assign it again.

[szuecs]

#1892 implements v1 ingress with the new pathType and new kind, but with fallback to the old annotation. We do not yet lookup the ingressclass object, but we can read the string from the field and if this is the matching one by -kubernetes-ingress-class it should filter the settings correctly.

[tstephen-relx]

Hi there,
Any thoughts about implementing the ingressclass read? In our multi-ingress controller scenario the other controller implements the ingressclass which means we now have to restore the deprecated annotation. Otherwise, the ingress creation is rejected.