Gateway API tutorials
Use TCPRoute
Available since
version 1.10
The Gateway API defines specialized resources for routing different types of network traffic. You would use a TCPRoute resource to route TCP traffic.
To add routing for TCP traffic, you must define a Gateway that references your GatewayClass. You must also define a TCPRoute that uses that Gateway, specifying the ports required for your Service(s), and update your HAProxy Kubernetes Ingress Controller to listen on those same ports. Your Service(s) will then be able to send and receive TCP traffic through your Route.
Define a Gateway Jump to heading
With Gateway objects, cluster operators can choose which Gateway API implementations to use. In this example, we will use the HAProxy Kubernetes Ingress Controller which implements Gateway API.
Prerequisite: Configure the ingress controller
Before proceeding, be sure you have updated your ingress controller to enable the Gateway API.
To create a Gateway that listens on port 8000 and handles routing for Services in the default namespace:
-
Create a file that defines a Gateway object.
Below, in a file named
example-gateway.yaml
, we define a Gateway that uses the ingress controller thehaproxy-ingress-gatewayclass
GatewayClass references. You created this GatewayClass when you enabled Gateway API for the ingress controller:example-gateway.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: Gatewaymetadata:name: default-namespace-gatewaynamespace: defaultspec:gatewayClassName: haproxy-ingress-gatewayclasslisteners:- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener1port: 8000protocol: TCPexample-gateway.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: Gatewaymetadata:name: default-namespace-gatewaynamespace: defaultspec:gatewayClassName: haproxy-ingress-gatewayclasslisteners:- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener1port: 8000protocol: TCPIn this example, the Gateway is deployed to the default namespace, and will accept routes from the same namespace. Cluster operators can also deploy Gateways that accept routes from specific namespaces by changing the
allowedRoutes.namespaces
section to have afrom
attribute of either:Value Description All Matches routes from any namespace. Same Matches routes from the same namespace where the Gateway is deployed. Selector Matches routes from namespaces matching the selector
attribute. In this case, add a selector attribute to define the match criteria.This Gateway object includes
TCPRoute
in itsallowedRoutes.kinds
section. This advertises that this Gateway, and by extension the ingress controller, watches for routes of this kind. -
Apply the changes with
kubectl
:nixkubectl apply -f example-gateway.yamlnixkubectl apply -f example-gateway.yaml -
Optional: If you will be creating TCPRoute objects that are in a namespace different from the namespace of the target Service, you must define a ReferenceGrant object that allows cross-namespace communication.
The ReferenceGrant definition below allows a Route in the
default
namespace to reference a Service in thefoo
namespace. Note that theto
section does not need a namespace because a ReferenceGrant can refer only to resources defined in its own namespace.foo-referencegrant.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: ReferenceGrantmetadata:name: refgrantns1namespace: foospec:from:- group: "gateway.networking.k8s.io"kind: "TCPRoute"namespace: defaultto:- group: ""kind: "Service"foo-referencegrant.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: ReferenceGrantmetadata:name: refgrantns1namespace: foospec:from:- group: "gateway.networking.k8s.io"kind: "TCPRoute"namespace: defaultto:- group: ""kind: "Service"Apply the changes with
kubectl
:nixkubectl apply -f foo-referencegrant.yamlnixkubectl apply -f foo-referencegrant.yaml
Define Routes Jump to heading
Setting allowed Routes
Earlier when defining the Gateway, you set allowedRoutes
to accept Routes of kind TCPRoute
. This means that only those types of Routes will be handled by that Gateway.
To define routing for TCP traffic to an application named example-service
:
-
Create a file named
example-route.yaml
with the following contents:example-route.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-routenamespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultrules:- backendRefs:- group: ''kind: Servicename: example-serviceport: 8000weight: 10example-route.yamlyamlapiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-routenamespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultrules:- backendRefs:- group: ''kind: Servicename: example-serviceport: 8000weight: 10In this definition:
- The
parentRefs
section references the Gateways to which a Route wants to attach. This TCPRoute will attach to listeners defined in theGateway
whoseallowedRoutes
have matching kind and namespace rules. - The
backendRefs
section refers to Services where connections should be sent. Each item’sport
attribute is the Service’s listening port. Theweight
attribute sets the proportion of connections that should go to the Service, which is calculated byweight/(sum of all weights in this backendRefs list)
.
- The
-
Apply the changes with
kubectl
:nixkubectl apply -f example-route.yamlnixkubectl apply -f example-route.yaml
Update your ingress controller Jump to heading
To enable connectivity between the ingress controller and your Gateway, and therefore Route, you must update the ingress controller’s Service and Deployment objects to include the ports you configured in your Gateway and Route. Whether you installed the ingress controller via Helm or via kubectl will determine how you perform these updates.
Update with Helm Jump to heading
-
Create a file named
values.yaml
that sets TCP ports where the controller should listen. If you created a values file for your initial installation, or for altering other settings, such as enabling Gateway API, reuse this file, updating it with the following:values.yamlyamlcontroller:kubernetesGateway:enabled: truegatewayControllerName: haproxy.org/gateway-controllerservice:tcpPorts:- name: listener1protocol: TCPport: 8000targetPort: 8000values.yamlyamlcontroller:kubernetesGateway:enabled: truegatewayControllerName: haproxy.org/gateway-controllerservice:tcpPorts:- name: listener1protocol: TCPport: 8000targetPort: 8000- For each TCP port, add a section to
controller.service.tcpPorts
. Add the following for each port:- Provide a name for the port. The name of the port cannot exceed 11 characters.
port
andtargetPort
are both the port at which you will listen for TCP traffic.- Set
protocol
toTCP
.
Caution
Be sure your values file also includes the properties you added when you enabled Gateway API, namely the section
kubernetesGateway
. If you leave these out, Gateway API will be disabled. - For each TCP port, add a section to
-
Execute the
helm upgrade
command, providing the name of the YAML values file with-f
.nixhelm upgrade haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \--namespace haproxy-controller \-f values.yamlnixhelm upgrade haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \--namespace haproxy-controller \-f values.yamlnixhelm upgrade haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \--create-namespace \--namespace haproxy-controller \--set controller.imageCredentials.registry=kubernetes-registry.haproxy.com \--set controller.imageCredentials.username=<KEY> \--set controller.imageCredentials.password=<KEY> \--set controller.image.repository=kubernetes-registry.haproxy.com/hapee-ingress \--set controller.image.tag=v3.0 \-f values.yamlnixhelm upgrade haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \--create-namespace \--namespace haproxy-controller \--set controller.imageCredentials.registry=kubernetes-registry.haproxy.com \--set controller.imageCredentials.username=<KEY> \--set controller.imageCredentials.password=<KEY> \--set controller.image.repository=kubernetes-registry.haproxy.com/hapee-ingress \--set controller.image.tag=v3.0 \-f values.yamlAbout Helm upgrade
Performing a
helm upgrade
in this way uses the values file to automatically update thekubernetes-ingress-controller
Deployment and Service. You can view the changes usingkubectl get
as follows:nixkubectl get deployment haproxy-kubernetes-ingress -n haproxy-controller -o yamlnixkubectl get deployment haproxy-kubernetes-ingress -n haproxy-controller -o yamlYou will see the
--gateway-controller-name
startup argument was added to the Deployment:deployment/haproxy-kubernetes-ingressyamlapiVersion: apps/v1kind: Deploymentmetadata:[...]name: haproxy-kubernetes-ingressnamespace: haproxy-controllerspec:[...]template:[...]spec:containers:- args:- --gateway-controller-name=haproxy.org/gateway-controllerdeployment/haproxy-kubernetes-ingressyamlapiVersion: apps/v1kind: Deploymentmetadata:[...]name: haproxy-kubernetes-ingressnamespace: haproxy-controllerspec:[...]template:[...]spec:containers:- args:- --gateway-controller-name=haproxy.org/gateway-controllerThe Deployment and Service name for the community version is
kubernetes-ingress-controller
and ishaproxy-ingress
for the enterprise version. To see the Service issue this command:nixkubectl get service haproxy-kubernetes-ingress -n haproxy-controller -o yamlnixkubectl get service haproxy-kubernetes-ingress -n haproxy-controller -o yamlYou will see that your TCP ports have been added to the Service:
haproxy-kubernetes-ingress serviceyamlapiVersion: v1kind: Servicemetadata:[...]name: haproxy-kubernetes-ingressnamespace: haproxy-controllerspec:[...]ports:[...]- name: listener1nodePort: 30305port: 8000protocol: TCPtargetPort: 8000haproxy-kubernetes-ingress serviceyamlapiVersion: v1kind: Servicemetadata:[...]name: haproxy-kubernetes-ingressnamespace: haproxy-controllerspec:[...]ports:[...]- name: listener1nodePort: 30305port: 8000protocol: TCPtargetPort: 8000
Update with kubectl Jump to heading
To enable connectivity between your Service and the Gateway and Route using kubectl
and YAML files, we will create patch files to patch the ingress controller Deployment and Service.
-
Examine your current ingress controller Deployment. This command will show your Deployment in YAML. Make note of any additional arguments in
args
for thehaproxy-ingress
container. You will need these arguments in the next step.nixkubectl get deployment haproxy-kubernetes-ingress -n haproxy-controller -o yamlnixkubectl get deployment haproxy-kubernetes-ingress -n haproxy-controller -o yamlnixkubectl get deployment haproxy-ingress -n ingress-controller -o yamlnixkubectl get deployment haproxy-ingress -n ingress-controller -o yaml -
Create a new file named
deployment-enable-gateway-api-patch.yaml
and add the following to it. Be sure to include in this Deployment patch file any additional startup arguments (args
) that exist, or startup arguments that you have added to your Deployment. The entireargs
list is replaced upon applying the patch:deployment-enable-gateway-api-patch.yamlyamlspec:template:spec:containers:- name: haproxy-ingressargs:- --configmap=haproxy-controller/haproxy-kubernetes-ingress- --gateway-controller-name=haproxy.org/gateway-controllerdeployment-enable-gateway-api-patch.yamlyamlspec:template:spec:containers:- name: haproxy-ingressargs:- --configmap=haproxy-controller/haproxy-kubernetes-ingress- --gateway-controller-name=haproxy.org/gateway-controller -
Apply the Deployment patch:
nixkubectl patch deployment haproxy-kubernetes-ingress --patch-file=deployment-enable-gateway-api-patch.yaml -n haproxy-controllernixkubectl patch deployment haproxy-kubernetes-ingress --patch-file=deployment-enable-gateway-api-patch.yaml -n haproxy-controlleroutputtextdeployment.apps/haproxy-kubernetes-ingress patchedoutputtextdeployment.apps/haproxy-kubernetes-ingress patchednixkubectl patch deployment haproxy-ingress --patch-file=deployment-enable-gateway-api-patch.yaml -n haproxy-controllernixkubectl patch deployment haproxy-ingress --patch-file=deployment-enable-gateway-api-patch.yaml -n haproxy-controlleroutputtextdeployment.apps/haproxy-ingress patchedoutputtextdeployment.apps/haproxy-ingress patched -
(Optional): Add an annotation to the Deployment to track the change within the resource. This will make it so that when you review the rollout history of the Deployment, this change has a record associated with it, which may assist in tracking changes and performing rollbacks. Note that this overwrites the original entry, which was blank.
nixkubectl annotate deployment haproxy-kubernetes-ingress kubernetes.io/change-cause="Updated haproxy-kubernetes-ingress Deployment to enable Gateway API support" --overwrite=true -n haproxy-controllernixkubectl annotate deployment haproxy-kubernetes-ingress kubernetes.io/change-cause="Updated haproxy-kubernetes-ingress Deployment to enable Gateway API support" --overwrite=true -n haproxy-controlleroutputtextdeployment.apps/haproxy-kubernetes-ingress annotatedoutputtextdeployment.apps/haproxy-kubernetes-ingress annotatedCheck the rollout history:
nixkubectl rollout history deployment/haproxy-kubernetes-ingress -n haproxy-controllernixkubectl rollout history deployment/haproxy-kubernetes-ingress -n haproxy-controlleroutputtextREVISION CHANGE-CAUSE1 <none>2 Updated haproxy-kubernetes-ingress deployment to enable Gateway API supportoutputtextREVISION CHANGE-CAUSE1 <none>2 Updated haproxy-kubernetes-ingress deployment to enable Gateway API supportnixkubectl annotate deployment haproxy-ingress kubernetes.io/change-cause="Updated haproxy-ingress Deployment to enable Gateway API support" --overwrite=true -n haproxy-controllernixkubectl annotate deployment haproxy-ingress kubernetes.io/change-cause="Updated haproxy-ingress Deployment to enable Gateway API support" --overwrite=true -n haproxy-controlleroutputtextdeployment.apps/haproxy-kubernetes-ingress annotatedoutputtextdeployment.apps/haproxy-kubernetes-ingress annotatedCheck the rollout history:
nixkubectl rollout history deployment/haproxy-ingress --revision=2 -n haproxy-controllernixkubectl rollout history deployment/haproxy-ingress --revision=2 -n haproxy-controlleroutputtextREVISION CHANGE-CAUSE1 <none>2 Updated haproxy-ingress deployment to enable Gateway APIoutputtextREVISION CHANGE-CAUSE1 <none>2 Updated haproxy-ingress deployment to enable Gateway API -
Update the ingress controller’s Service object to include the ports you configured in your Gateway and Route. Consider the following snippet from the HAProxy Kubernetes Ingress Controller’s Service:
Tip
To retrieve the details for the Service in YAML format, use the following command. This command is for the enterprise version of the ingress controller:
nixkubectl get service haproxy-ingress -n haproxy-controller -o yaml haproxy-ingress-service.yamlnixkubectl get service haproxy-ingress -n haproxy-controller -o yaml haproxy-ingress-service.yamlThe
haproxy-ingress-service.yaml
file will contain the YAML representation of the Service. Change the Service name you provide to the command fromhaproxy-ingress
tohaproxy-kubernetes-ingress
to use this command with the community version.haproxy-ingress.yamlyamlspec:selector:run: haproxy-ingresstype: NodePortports:- name: httpport: 80protocol: TCPtargetPort: 80- name: httpsport: 443protocol: TCPtargetPort: 443- name: statport: 1024protocol: TCPtargetPort: 1024- name: listener1protocol: TCPport: 8000targetPort: 8000haproxy-ingress.yamlyamlspec:selector:run: haproxy-ingresstype: NodePortports:- name: httpport: 80protocol: TCPtargetPort: 80- name: httpsport: 443protocol: TCPtargetPort: 443- name: statport: 1024protocol: TCPtargetPort: 1024- name: listener1protocol: TCPport: 8000targetPort: 8000We want to add
listener1
to the list of ports on which the ingress controller listens. We can accomplish this using a patch. To patch the Service: -
Create a new file named
service-enable-gateway-api-patch.yaml
and add an entry for each new port to theports
section. When you apply the patch, it will append new ports to the existingports
list; it will not overwrite the existing ports.service-enable-gateway-api-patch.yamlyamlspec:ports:- name: listener1protocol: TCPport: 8000targetPort: 8000service-enable-gateway-api-patch.yamlyamlspec:ports:- name: listener1protocol: TCPport: 8000targetPort: 8000- For each TCP port, add a section to
ports
. Add the following for each port:- Provide a name for the port. The name of the port cannot exceed 11 characters.
- Set
protocol
toTCP
. port
andtargetPort
are both the port at which you will listen for TCP traffic.
- For each TCP port, add a section to
-
Apply the Service patch:
nixkubectl patch service haproxy-kubernetes-ingress --patch-file=service-enable-gateway-api-patch.yaml -n haproxy-controllernixkubectl patch service haproxy-kubernetes-ingress --patch-file=service-enable-gateway-api-patch.yaml -n haproxy-controlleroutputtextservice/haproxy-kubernetes-ingress patchedoutputtextservice/haproxy-kubernetes-ingress patchednixkubectl patch service haproxy-ingress --patch-file=service-enable-gateway-api-patch.yaml -n haproxy-controllernixkubectl patch service haproxy-ingress --patch-file=service-enable-gateway-api-patch.yaml -n haproxy-controlleroutputtextservice/haproxy-ingress patchedoutputtextservice/haproxy-ingress patchedTrack changes to Service resources
Unlike Deployments, Services do not support rollout history. You can, however, view the previous version of the resource by calling
kubectl get service
as follows. This example is for the enterprise version. Change the service namehaproxy-ingress
tohaproxy-kubernetes-ingress
for use with the community version.nixkubectl get service haproxy-ingress -n haproxy-controller -o yaml service_last_revision.yamlnixkubectl get service haproxy-ingress -n haproxy-controller -o yaml service_last_revision.yamlIn the output file, there will be a property in
metadata.annotations
namedkubectl.kubernetes.io/last-applied-configuration
. Consider this a record of the previous configuration, prior to the patch being applied.yamlapiVersion: v1kind: Servicemetadata:annotations:kubectl.kubernetes.io/last-applied-configuration: |{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"run":"haproxy-ingress"},"name":"haproxy-ingress","namespace":"haproxy-controller"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":80},{"name":"https","port":443,"protocol":"TCP","targetPort":443},{"name":"stat","port":1024,"protocol":"TCP","targetPort":1024}],"selector":{"run":"haproxy-ingress"},"type":"NodePort"}}yamlapiVersion: v1kind: Servicemetadata:annotations:kubectl.kubernetes.io/last-applied-configuration: |{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"run":"haproxy-ingress"},"name":"haproxy-ingress","namespace":"haproxy-controller"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":80},{"name":"https","port":443,"protocol":"TCP","targetPort":443},{"name":"stat","port":1024,"protocol":"TCP","targetPort":1024}],"selector":{"run":"haproxy-ingress"},"type":"NodePort"}}You can use a utility such as
yq
to convert this JSON to YAML after saving the JSON to its own file, such as one namedlast_revision.json
:nixyq -oy last_revision.json &> last_revision.yamlnixyq -oy last_revision.json &> last_revision.yamlYou can then examine, edit, save as a backup, or apply the previous YAML that is now in the
last_revision.yaml
file.
Deploy an example application to test the Route Jump to heading
To test connectivity with the Gateway and Route, we will deploy an example application using a Deployment and a Service. Here, we define an example application using the busybox
Docker container image. It will run netcat
on port 8080, receiving TCP traffic:
-
Create a file named
busybox.yaml
and paste the following YAML into it to define the example application. Both the Deployment and the Service are present in this YAML:example-service.yamlyamlapiVersion: apps/v1kind: Deploymentmetadata:name: busybox-deploymentlabels:app: busyboxspec:replicas: 1selector:matchLabels:app: busyboxtemplate:metadata:labels:app: busyboxspec:containers:- name: busyboximage: busyboxcommand: ["sh", "-c", "while true; do nc -v -lk -p 8080; done"]ports:- containerPort: 8080protocol: TCP---apiVersion: v1kind: Servicemetadata:name: example-servicespec:selector:app: busyboxports:- protocol: TCPport: 8000targetPort: 8080example-service.yamlyamlapiVersion: apps/v1kind: Deploymentmetadata:name: busybox-deploymentlabels:app: busyboxspec:replicas: 1selector:matchLabels:app: busyboxtemplate:metadata:labels:app: busyboxspec:containers:- name: busyboximage: busyboxcommand: ["sh", "-c", "while true; do nc -v -lk -p 8080; done"]ports:- containerPort: 8080protocol: TCP---apiVersion: v1kind: Servicemetadata:name: example-servicespec:selector:app: busyboxports:- protocol: TCPport: 8000targetPort: 8080Note that the Service is named
example-service
, the same Service name you specified when you defined your Route in the previous steps. This is how the TCPRoute knows what Service to route to. -
Apply the changes with
kubectl
:nixkubectl apply -f busybox.yamlnixkubectl apply -f busybox.yaml
Test the connection through the load balancer (click to expand)
To test the connection through the load balancer (and through the Gateway and TCPRoute) to the BusyBox instance running netcat
:
-
Get the name of the BusyBox pod by calling
kubectl get pod
:nixkubectl get podnixkubectl get podExample outputNAME READY STATUS RESTARTS AGE busybox-deployment-6fbb645fd4-cfkwp 1/1 Running 0 12m
Example outputNAME READY STATUS RESTARTS AGE busybox-deployment-6fbb645fd4-cfkwp 1/1 Running 0 12m
-
Use the following command to find the NodePort assigned to your Service. In this example the NodePort is 30190, the NodePort associated with the TCP port 8000.
nixkubectl get service -n haproxy-controllernixkubectl get service -n haproxy-controlleroutputtextNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEhaproxy-kubernetes-ingress NodePort 10.106.101.211 <none> 80:30187/TCP,443:32147/TCP,443:32147/UDP,1024:30168/TCP,6060:30721/TCP,8000:30190/TCP 20moutputtextNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEhaproxy-kubernetes-ingress NodePort 10.106.101.211 <none> 80:30187/TCP,443:32147/TCP,443:32147/UDP,1024:30168/TCP,6060:30721/TCP,8000:30190/TCP 20m -
From a server that has connection to your cluster, such as the server from which you run
kubectl
, usenetcat
to connect to the port assigned as the NodePort for your TCP Service. There is no output from this command.nixnc 127.0.0.1 30190nixnc 127.0.0.1 30190 -
Check the logs of the BusyBox pod to confirm that a connection was made:
nixkubectl logs busybox-deployment-6fbb645fd4-cfkwpnixkubectl logs busybox-deployment-6fbb645fd4-cfkwpoutputconnect to [::ffff:10.0.2.134]:8080 from 10-0-1-186.haproxy-kubernetes-ingress.haproxy-controller.svc.cluster.local:55288 ([::ffff:10.0.1.186]:55288)
outputconnect to [::ffff:10.0.2.134]:8080 from 10-0-1-186.haproxy-kubernetes-ingress.haproxy-controller.svc.cluster.local:55288 ([::ffff:10.0.1.186]:55288)
Optional: route to multiple TCPRoutes from the same Gateway Jump to heading
You can use the same Gateway to route to multiple TCPRoutes. In this case, you would want to alter your Gateway as follows, adding a separate listener
for each each TCPRoute
. Note that listener1
listens for external traffic on port 8000 and listener2
on port 8001:
example-gateway.yamlyaml
apiVersion: gateway.networking.k8s.io/v1alpha2kind: Gatewaymetadata:name: default-namespace-gatewaynamespace: defaultspec:gatewayClassName: haproxy-ingress-gatewayclasslisteners:- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener1port: 8000protocol: TCP- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener2port: 8001protocol: TCP[...]
example-gateway.yamlyaml
apiVersion: gateway.networking.k8s.io/v1alpha2kind: Gatewaymetadata:name: default-namespace-gatewaynamespace: defaultspec:gatewayClassName: haproxy-ingress-gatewayclasslisteners:- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener1port: 8000protocol: TCP- allowedRoutes:kinds:- group: gateway.networking.k8s.iokind: TCPRoutenamespaces:from: Samename: listener2port: 8001protocol: TCP[...]
Reference each listener in separate TCPRoutes. In this example, there are two routes, example-route1
corresponding to listener1
, and example-route2
corresponding to listener2
. Use the sectionName
property to denote which listener the TCPRoute should use from the specified Gateway. Note that both Routes will communicate with their respective Services on port 8000:
example-routes.yamlyaml
apiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-route1namespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultsectionName: listener1rules:- backendRefs:- group: ''kind: Servicename: example-service1port: 8000weight: 10---apiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-route2namespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultsectionName: listener2rules:- backendRefs:- group: ''kind: Servicename: example-service2port: 8000weight: 10
example-routes.yamlyaml
apiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-route1namespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultsectionName: listener1rules:- backendRefs:- group: ''kind: Servicename: example-service1port: 8000weight: 10---apiVersion: gateway.networking.k8s.io/v1alpha2kind: TCPRoutemetadata:name: example-route2namespace: defaultspec:parentRefs:- group: gateway.networking.k8s.iokind: Gatewayname: default-namespace-gatewaynamespace: defaultsectionName: listener2rules:- backendRefs:- group: ''kind: Servicename: example-service2port: 8000weight: 10
See also: Jump to heading
Do you have any suggestions on how we can improve the content of this page?