Ingress Mode

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.

In Ingress mode, it is possible to define multiple Ingress resources. You can map the master Ingress resource (with multiple associated Slave Ingress resources) to one Virtual Service using the following annotation:

kemp.ax/ingress.ref: "<namespace>:<ingressname>"

It is necessary to ensure that either:

• All the Ingress resources are defined in one namespace (Master, Slave, and Services), or;

• The master Ingress is defined in the "default" namespace and the Slave Ingress resources are defined in different namespaces

Here is an example YAML file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: master-ingress
	namespace: default
	annotations:
		"kemp.ax/vsip": "10.35.46.104"
		"kemp.ax/vsport": "443"
		"kemp.ax/vsprot": "tcp"
		"kemp.ax/vstype": "http"
		"kemp.ax/sslaccel": "1"
		"kemp.ax/certfile": "server"
spec:
	ingressClassName: lmingress
	defaultBackend:
		service:
			name: qa-default
			port:
				number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: slave-ingress1
	namespace: slave1
	annotations:
		"kemp.ax/ingress.ref": "default/master-ingress"
spec:
	ingressClassName: lmingress
	rules:
	- host: slave1.kemptech.net
		http:
			paths:
			- path: /api/v1/deployer
				pathType: Prefix
				backend:
					service:
						name: service1
						port:
							number: 80
			- path: /api/v1/logout
				pathType: Prefix
				backend:
					service:
					name: service1
					port:
						number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: slave-ingress2
	namespace: slave2
	annotations:
		"kemp.ax/ingress.ref": "default/master-ingress"
spec:
	ingressClassName: lmingress
	rules:
	- host: slave2.kemptech.net
		http:
			paths:
			- path: /api/v1/server
				pathType: Prefix
				backend:
					service:
						name: service2
						port:
							number: 80
			- path: /api/v1/authenticate
				pathType: Prefix
				backend:
					service:
						name: service2
						port:
							number: 80
			

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

• Create multiple rules for one service/SubVS instead of multiple SubVSs

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