Cisco Container Platform uses NGINX to offer advanced layer 7 load balancing solutions. NGINX can handle a large number of requests and at the same time, it can be run on Kubernetes containers.

The NGINX load balancer is automatically provisioned as part of Kubernetes cluster creation. Each Kubernetes cluster is provisioned with a single L7 NGINX load balancer. You can access the load balancer using its virtual IP address, which can be found by running the command kubectl get svc -n ccp.

To use the NGINX load balancer, you must create an Ingress resource. Ingress is a Kubernetes object that allows you to define HTTP load balancing rules to allow inbound connections to reach the cluster services. You can configure Ingress to create external URLs for services, load balance traffic, terminate SSL, offer name-based virtual hosting, and so on.

Cisco Container Platform supports the following types of L7 Ingresses:

• Simple fanout

  It enables you to access the website using http.

  Example

  cafe.test.com ->   10.1.1.1   ->   /tea      tea-svc:80 
                                                          /coffee   coffee-svc:80 
  

  For this type of Ingress, you need to create a yaml file that defines the Ingress rules.

  Sample yaml file

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
  name: cafe-ingress
  spec:
  rules:
  -host: cafe.test.com
  http:
      paths:
      -path:/
      backend:
      serviceName: tea-svc
      servicePort: 80
      -path:/
      backend:
      serviceName: tea-svc
      servicePort: 80

• Simple fanout with SSL termination

  It enables you to access the website using https.

  Example

  https://cafe.test.com   ->   10.1.1.1   ->   /tea       tea-svc:80
                                               /coffee    coffee-svc:80

  For this type of Ingress, you need to create the following yaml files:

  • A yaml file that defines the Secret

    Sample yaml file

    apiVersion: v1
    kind: Secret
    metadata:
      name: cafe-secret
    type: Opaque
    data:
      tls.crt: base64 encoded cert
      tls.key: base64 encoded key

  • A yaml file that defines the Ingress rules

    Sample yaml file

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      tls:
      -hosts:
      -cafe.test.com
       secretName: cafe-secret
      rules:
      -host: cafe.example.com
      http:
       paths:
       -path:/
       backend:
         serviceName: tea-svc
         sevicePort: 80
       -path:/
       backend:
         serviceName: coffee-svc
         servicePort: 80

• Name based virtual hosting

  It enables you to access the website using multiple host names.

  Example

  tea.test.com    --|          |-> tea.test.com      s1:80
                    |10.1.1.1  |
  coffee.test.com --|          |-> coffee.test.com  s2:80 
  

  For this type of Ingress, you need to create a yaml file that defines the Ingress rules.

  Sample yaml file

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata
  name: cafe-ingress
  spec:
   rules:
   -host: tea.test.com
   http:
      paths:
      -path:/
      backend:
      serviceName: tea-svc
      servicePort: 80
  -host: coffee.test.com
  http:
  paths:
  -path:/
  backend:
  serviceName: coffee-svc
  servicePort: 80

Note	You can download the yaml files that are shown in this topic from the following link: https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example

For more information on a sample scenario of implementing Ingress, see Deploying Cafe Application with Ingress.

NGINX supports L4 TCP and UDP Ingress load balancing. It uses the NGINX helm chart that contains the TCP or UDP service mappings, instead of the Ingress resources as in the case of L7 support.

Cisco Container Platform supports Kubernetes NetworkPolicies. The NetworkPolicies are independent of the underlying container network plugin.

Cisco Container Platform supports load balancer services on tenant clusters.

While creating a tenant cluster, you need to choose the number of load balancer IP addresses that you want to allocate for a tenant cluster from a VIP pool that you want to use.

Note	The cluster creation operation fails if the number of requested load balancer IP addresses is more than the available IP addresses in the pool.

For more information, see Creating Kubernetes Clusters on vSphere On-prem Clusters.

Once load balancer IP addresses are allocated for a tenant cluster, externally reachable load balancer IP addresses are automatically provisioned for the load balancer services.

The following code provides an example of creating a service of type LoadBalancer.

        apiVersion: v1 
        kind: Service 
        metadata: 
             name: frontend 
             labels: 
                     app: guestbook 
                     tier: frontend 
             type: LoadBalancer

You can update the number of available load balancer IP addresses from the Edit Cluster screen. You need to be aware of the number of used addresses in order to update the number of allocated load balancer IP addresses.

For example:

Suppose the current tenant is allocated with five load balancer IP addresses. If there are three load balanced services running, you cannot reduce the number of load balancer IP addresses to three or less as there are services using those IP addresses already.

Note	When you delete a tenant cluster, the allocated load balancer IP addresses are recycled to the VIP pool.