Configuring Ingress Resources and Load Balancer Services

This topic describes example ingress routing (Layer 7) and load balancing (Layer 4) configurations for Kubernetes clusters deployed by VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) on vSphere with NSX 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 and path: /testpath in the incoming request:
  
  Ingress Rule Example 1

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: svc-ingress1
    annotations:
  spec:
    rules:
    - host: test.com
      http:
        paths:
        - path: /testpath
          pathType: Prefix
          backend:
            service:
              name: svc1
              port:
                number: 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 2

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: svc-ingress2
    annotations:
  spec:
    rules:
    - host: test.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: svc1
              port:
                number: 80
  

• If you create Ingress Rule Example 1 before Ingress Rule Example 2, then svc-ingress1 serves the test.com/testpath URI because inbound requests hit the host: test.com and path: /testpath NSX ingress rule first.

• If you create Ingress Rule Example 2 before Ingress Rule Example 1, then svc2-ingress2 serves the test.com/testpath URI because inbound requests hit the host: 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 to TCP. 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 or http.
• 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.