Multiple listeners with HTTP routes
The NetScaler Kubernetes Gateway Controller supports multiple listeners within a single Gateway resource, as defined by the Kubernetes Gateway API. This capability provides greater flexibility and control over how external traffic is managed and routed to services within your Kubernetes cluster.
With multiple listener support, you can:
- Expose multiple ports on the same set of gateway IP addresses, so that different applications or services can be accessed through distinct ports.
- Support different protocols, such as HTTP and HTTPS, on separate ports while using the same gateway IP address.
- Apply unique TLS configurations for each listener, enabling secure communication tailored to specific requirements.
- Define separate routing rules for each listener, allowing you to manage and direct different inbound traffic flows.
This enhanced listener functionality enables advanced traffic management scenarios, such as hosting multiple secure and non-secure applications behind a single Gateway, or segmenting traffic for compliance and security purposes. By using multiple listeners, you can optimize your application delivery and improve the scalability and security of your Kubernetes environment.
Sample configuration
The following sample configuration in Kubernetes results in creating three content switching virtual servers and an ipset for each content switching virtual server.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway-http
namespace: default
spec:
gatewayClassName: my-gateway-class
addresses:
- type: IPAddress
value: <ip1>
- type: IPAddress
value: <ip2>
- type: IPAddress
value: <ip3>
listeners:
- name: http-listener
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
- name: http-listener1
protocol: HTTP
port: 81
allowedRoutes:
namespaces:
from: All
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- kind: Secret
name: my-secret
group: ""
allowedRoutes:
namespaces:
from: All
<!--NeedCopy-->
Namespace filters
By default, Gateways enforce strict namespace isolation. This means only routes such as HTTPRoute
that exist in the same namespace as the Gateway resource can attach to that Gateway. This default behavior provides a secure and isolated routing environment, ensuring that only trusted routes within the same namespace can influence the Gateway’s traffic management.
To support more advanced routing scenarios, you can enable cross-namespace routing by configuring the allowedRoutes
field within each listener definition of your Gateway resource. The allowedRoutes
field provides granular control over which namespaces are permitted to attach routes to a specific listener, allowing for flexible and secure multitenant or multi-team deployments.
The allowedRoutes.namespaces.from
field supports three distinct modes for namespace selection:
-
Same (Default): - Only routes from the same namespace as the Gateway are allowed to attach. This mode is the most restrictive and secure option, suitable for environments where strict isolation is required.
-
All: - Routes from any namespace in the Kubernetes cluster can attach to the Gateway listener. This mode offers maximum flexibility, enabling centralized Gateway resources to serve routes from multiple namespaces. However, it is important to consider the security implications and implement appropriate RBAC controls when using this mode.
-
Selector: - Routes are allowed to attach based on namespace label matching criteria. This mode uses Kubernetes label selectors to enable sophisticated namespace-based routing policies. For example, you can allow only namespaces with a specific label (such as
team=frontend
) to attach routes to a listener, providing fine-grained multitenant control.Note:
If the namespace label is changed after
HTTPRoute
is applied, the changes do not get reflected in Gateway Controller.