Configuring Ingress Resources and Load Balancer Services
Page last updated:
This topic describes example configurations for ingress routing (Layer 7) and load balancing (Layer 4) for Kubernetes clusters deployed by VMware Tanzu Kubernetes Grid Integrated Edition on vSphere with NSX-T integration.
Note: The examples in this topic are based on NCP v2.3.2.
Kubernetes Ingress Rules
A Kubernetes ingress resource exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the ingress resource.
You define ingress resource configuration in the manifest of your Kubernetes deployment. When you define an ingress rule, the hostname and path values are both optional. It is common to define an ingress rule that specifies a hostname and no path, but defining an ingress rule without a hostname is uncommon. You can use wildcard DNS entries to route traffic to the exposed ingress resource.
When you define two ingress rules with the same hostname, include both the hostname and path in the ingress rules to avoid ambiguity.
Rules:
- If multiple ingress rules use the same hostname and the same path, the first rule you create takes priority.
- If an ingress rule that includes only a hostname precedes a rule that includes both the same hostname and a path,
the first rule takes priority.
For example:
The following NSX ingress rule includes both a host and a path specification. The rule matches
host: test.com
andpath: /testpath
in the incoming request:
Ingress Rule Example 1apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: svc-ingress1 spec: rules: - host: test.com http: paths: - path: /testpath backend: serviceName: svc1 servicePort: 80
The following NSX ingress rule includes only a host specification. The rule matches all
host: test.com
in the incoming request:
Ingress Rule Example 2apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: svc-ingress2 spec: rules: - host: test.com http: paths: - path: backend: serviceName: svc1 servicePort: 80
If you create Ingress Rule Example 1 before Ingress Rule Example 2, then
svc-ingress1
serves thetest.com/testpath
URI because inbound requests hit thehost: test.com
andpath: /testpath
NSX ingress rule first.If you create Ingress Rule Example 2 before Ingress Rule Example 1, then
svc2-ingress2
serves thetest.com/testpath
URI because inbound requests hit thehost: test.com
NSX ingress rule first.
For more information about Kubernetes ingress resources, see Ingress in the Kubernetes documentation.
The NSX-T Load Balancer Service
NSX-T supports autoscaling, which spins up a new Kubernetes type: LoadBalancer
service
if the previous one has reached its scale limit. The NSX-T load balancer that is
automatically provisioned by Tanzu Kubernetes Grid Integrated Edition provides two Layer 7 virtual servers
for Kubernetes ingress resources, one for HTTP and the other for HTTPS.
For more information, see Supported Load Balancer Features in the NSX-T documentation.
The following is the format for the Kubernetes LoadBalancer
service definition:
kind: Service
apiVersion: v1
metadata:
name: SERVICE-NAME
spec:
type: LoadBalancer
selector:
app: APP-NAME
ports:
- protocol: PROTOCOL
port: PORT
targetPort: TARGET-PORT
name: PORT-NAME
Where:
SERVICE-NAME
is the name for your load balancer service.APP-NAME
is the name of your app serviced by the load balancer service.PROTOCOL
(Optional) is the network protocol to service. If the protocol is not specified it defaults toTCP
. For more information about supported protocols, see Supported protocols in the Kubernetes documentation.PORT
is the listening port. An integer value is supported. For example,80
.TARGET-PORT
is the target port. Either an integer or a string value is supported. For example,8080
orhttp
.PORT-NAME
(Optional) is the port name. Kubernetes requires the port name be specified for multi-port services.
For example, the following is a LoadBalancer
service definition for an
Tanzu Kubernetes Grid Integrated Edition-provisioned cluster with NSX-T:
kind: Service
apiVersion: v1
metadata:
name: test-service
spec:
type: LoadBalancer
selector:
app: testApp
ports:
- protocol: TCP
port: 80
targetPort: 8080
name: web
Note: With NCP v2.3.2 and earlier, the named targetPort
must be an integer, not a string. If you define a service type: LoadBalancer
with NSX-T,
the value of targetPort
must be a port number, not a port name.
For more information about the Kubernetes LoadBalancer
service definition see
Type LoadBalancer
in the Kubernetes documentation.
When deploying a Kubernetes LoadBalancer
service,
NSX-T automatically creates a new virtual IP address (VIP) on the existing load balancer.
Please send any feedback you have to pks-feedback@pivotal.io.