IngressClass¶
Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a
class, a reference to an IngressClass resource that contains additional configuration including the name of the
controller that should implement the class. IngressClass resources contain an optional parameters field. This can be
used to reference additional implementation-specific configuration for this class.
For the AWS Load Balancer controller, the implementation-specific configuration is
IngressClassParams in the elbv2.k8s.aws API group.
Example
- specify controller as
ingress.k8s.aws/albto denote Ingresses should be managed by AWS Load Balancer Controller.apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: awesome-class spec: controller: ingress.k8s.aws/alb - specify additional configurations by referencing an IngressClassParams resource.
apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: awesome-class spec: controller: ingress.k8s.aws/alb parameters: apiGroup: elbv2.k8s.aws kind: IngressClassParams name: awesome-class-cfg
You can mark a particular IngressClass as the default for your cluster. Setting the
ingressclass.kubernetes.io/is-default-class annotation to true on an IngressClass resource will ensure that new
Ingresses without an ingressClassName field specified will be assigned this default IngressClass.
Deprecated kubernetes.io/ingress.class annotation¶
Before the IngressClass resource and ingressClassName field were added in Kubernetes 1.18, Ingress classes were
specified with a kubernetes.io/ingress.class annotation on the Ingress. This annotation was never formally defined,
but was widely supported by Ingress controllers.
The newer ingressClassName field on Ingresses is a replacement for that annotation, but is not a direct equivalent.
While the annotation was generally used to reference the name of the Ingress controller that should implement the
Ingress, the field is a reference to an IngressClass resource that contains additional Ingress configuration, including
the name of the Ingress controller.
disable kubernetes.io/ingress.class annotation
In order to maintain backwards-compatibility, kubernetes.io/ingress.class annotation is still supported currently.
You can enforce IngressClass resource adoption by disable the kubernetes.io/ingress.class annotation via --disable-ingress-class-annotation controller flag.
IngressClassParams¶
IngressClassParams is a CRD specific to the AWS Load Balancer Controller, which can be used along with IngressClass’s parameter field. You can use IngressClassParams to enforce settings for a set of Ingresses.
Example
- with scheme & ipAddressType & tags
apiVersion: elbv2.k8s.aws/v1beta1 kind: IngressClassParams metadata: name: awesome-class spec: scheme: internal ipAddressType: dualstack tags: - key: org value: my-org - with namespaceSelector
apiVersion: elbv2.k8s.aws/v1beta1 kind: IngressClassParams metadata: name: awesome-class spec: namespaceSelector: matchLabels: team: team-a - with IngressGroup
apiVersion: elbv2.k8s.aws/v1beta1 kind: IngressClassParams metadata: name: awesome-class spec: group: name: my-group
IngressClassParams specification¶
spec.namespaceSelector¶
namespaceSelector is an optional setting that follows general Kubernetes
label selector
semantics.
Cluster administrators can use the namespaceSelector field to restrict the namespaces of Ingresses that are allowed to specify the IngressClass.
- If
namespaceSelectorspecified, only Ingresses in selected namespaces can use IngressClasses with this parameter. The controller will refuse to reconcile for Ingresses that violatesnamespaceSelector. - If
namespaceSelectorun-specified, all Ingresses in any namespace can use IngressClasses with this parameter.
spec.group¶
group is an optional setting. The only available sub-field is group.name.
Cluster administrators can use group.name field to denote the groupName for all Ingresses belong to this IngressClass.
- If
group.namespecified, all Ingresses with this IngressClass will belong to the same IngressGroup specified and result in a single ALB. Ifgroup.nameis not specified, Ingresses with this IngressClass can use the older / legacyalb.ingress.kubernetes.io/group.nameannotation to specify their IngressGroup. Ingresses that belong to the same IngressClass can form different IngressGroups via that annotation.
spec.scheme¶
scheme is an optional setting. The available options are internet-facing or internal.
Cluster administrators can use the scheme field to restrict the scheme for all Ingresses that belong to this IngressClass.
- If
schemespecified, all Ingresses with this IngressClass will have the specified scheme. - If
schemeun-specified, Ingresses with this IngressClass can continue to usealb.ingress.kubernetes.io/scheme annotationto specify scheme.
spec.ipAddressType¶
ipAddressType is an optional setting. The available options are ipv4 or dualstack.
Cluster administrators can use ipAddressType field to restrict the ipAddressType for all Ingresses that belong to this IngressClass.
- If
ipAddressTypespecified, all Ingresses with this IngressClass will have the specified ipAddressType. - If
ipAddressTypeun-specified, Ingresses with this IngressClass can continue to usealb.ingress.kubernetes.io/ip-address-typeannotation to specify ipAddressType.
spec.tags¶
tags is an optional setting.
Cluster administrators can use tags field to specify the custom tags for AWS resources provisioned for all Ingresses belong to this IngressClass.
- If
tagsis set, AWS resources provisioned for all Ingresses with this IngressClass will have the specified tags. - You can also use controller-level flag
--default-tagsoralb.ingress.kubernetes.io/tagsannotation to specify custom tags. These tags will be merged together based on tag-key. If same tag-key appears in multiple sources, the priority is as follows:- controller-level flag
--default-tagswill have the highest priority. spec.tagsin IngressClassParams will have the middle priority.alb.ingress.kubernetes.io/tagsannotation will have the lowest priority.
- controller-level flag