SDP 25.11 is not the latest You're viewing SDP 25.11, not the current release (SDP 26.3).

View ListenerClass in SDP 26.3 View SDP 26.3 →

Custom resource

ListenerClass

Auto-generated derived type for ListenerClassSpec via `CustomResource`

View SDP 25.11 release Download CRD (YAML)

API group: listeners.stackable.tech
API versions in 25.11: v1alpha1
Scope: Cluster
Operator: Stackable Listener Operator
Roles: none

Schema

ListenerClass.listeners.stackable.tech .spec fields for SDP 25.11.

Schema

serviceType # string · enum required * The method used to access the services.

The method used to access the services.

allowed: NodePortLoadBalancerClusterIP
loadBalancerAllocateNodePorts # boolean = true
Configures whether a LoadBalancer service should also allocate node ports (like NodePort). Ignored unless serviceType is LoadBalancer.

Configures whether a LoadBalancer service should also allocate node ports (like NodePort). Ignored unless serviceType is LoadBalancer.
loadBalancerClass # string
Configures a custom Service loadBalancerClass, which can be used to access secondary load balancer controllers that are installed in the cluster, or to provision custom addresses manually. Ignored unless serviceType is LoadBalancer.

Configures a custom Service loadBalancerClass, which can be used to access secondary load balancer controllers that are installed in the cluster, or to provision custom addresses manually. Ignored unless serviceType is LoadBalancer.
pinnedNodePorts # boolean = false
Whether or not a Pod exposed using a NodePort should be pinned to a specific Kubernetes node. By pinning the Pod to a specific (stable) Kubernetes node, stable addresses can be provided using NodePorts. The pinning is achieved by listener-operator setting the volume.kubernetes.io/selected-node annotation on the Listener PVC. However, this only works on setups with long-living nodes. If your nodes are rotated on a regular basis, the Pods previously running on a removed node will be stuck in Pending until you delete the PVC with the pinning. Because of this we don't enable pinning by default to support all environments.

Whether or not a Pod exposed using a NodePort should be pinned to a specific Kubernetes node. By pinning the Pod to a specific (stable) Kubernetes node, stable addresses can be provided using NodePorts. The pinning is achieved by listener-operator setting the volume.kubernetes.io/selected-node annotation on the Listener PVC. However, this only works on setups with long-living nodes. If your nodes are rotated on a regular basis, the Pods previously running on a removed node will be stuck in Pending until you delete the PVC with the pinning. Because of this we don't enable pinning by default to support all environments.
preferredAddressType # string · enum = "HostnameConservative"
Whether addresses should prefer using the IP address (IP) or the hostname (Hostname). Can also be set to HostnameConservative, which will use IP for NodePort service types, but Hostname for everything else. The other type will be used if the preferred type is not available. Defaults to HostnameConservative.

Whether addresses should prefer using the IP address (IP) or the hostname (Hostname). Can also be set to HostnameConservative, which will use IP for NodePort service types, but Hostname for everything else. The other type will be used if the preferred type is not available. Defaults to HostnameConservative.

allowed: HostnameIPHostnameConservative
serviceAnnotations # object = {} Annotations that should be added to the Service object.

Annotations that should be added to the Service object.
serviceExternalTrafficPolicy # string · enum
Service Internal Traffic Policy enables internal traffic restrictions to only route internal traffic to endpoints within the node the traffic originated from. The "internal" traffic here refers to traffic originated from Pods in the current cluster. This can help to reduce costs and improve performance. See [Kubernetes docs][k8s-docs]. [k8s-docs]: https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/

Service Internal Traffic Policy enables internal traffic restrictions to only route internal traffic to endpoints within the node the traffic originated from. The "internal" traffic here refers to traffic originated from Pods in the current cluster. This can help to reduce costs and improve performance. See [Kubernetes docs][k8s-docs]. [k8s-docs]: https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/

allowed: ClusterLocal