Ingress Mode is designed to allow DevOps Teams to use the LoadMaster as an Ingress Controller for their Kubernetes Clusters in place of containerized ingress controllers.

Ingress mode allows you to define the ingress with an ingress controller. The LoadMaster creates one Virtual Service with one or more SubVSs. Any Virtual Services created by Kubernetes are labeled as L7+K8S in the Layer column on the View/Modify Services screen.

Each SubVS maps to the corresponding service in Kubernetes as defined by the ingress object rules. This means you do not need a separate Virtual Service for each service. The one Virtual Service performs routing based on the path and/or host as defined. If a new pod is added, a new Real Server gets automatically added to the relevant SubVS.

In Ingress Mode, ingress IP address and port numbers are defined in the Kubernetes Ingress Object in addition to attributes used to route specific traffic to particular service pods. In this mode, the Virtual Service is created based on the information defined (if appropriate values are used). If more traffic paths and services are added, these are updated on the Virtual Service with each service typically represented as a SubVS. If a service scales, more Real Servers are added.

Ingress Mode is the standard Kubernetes Ingress Controller operating mode designed for cross-functional teams operating purely through the Kubernetes API.

The advantages and disadvantages of ingress mode are listed below.

Advantages:

  • Efficient routing of traffic to pods

  • Eliminates unnecessary East-West traffic

  • Single Virtual Service for multiple services

  • No need for double load balancing

  • Kubernetes endpoints can be administered along with monolithic load-balanced services

Disadvantages:

  • May need routes to pods defined

  • Pod network must not overlap with network IP addresses

  • Nodes must be on the same subnet as the LoadMaster