It’a single entry point into the cluster. It’s basically a layer-7 load balancer that is managed within the K8s cluster. It provides features like SSL termination, and request based routing to different services.

Ingress uses an existing reverse proxy solution like Nignx or Traefik to run an Ingress Controller. Then a set of ingress rules are configured using definition files. These are called as Ingress Resources. A K8s cluster does not have an ingress controller by default. If you just configure ingress resources, it won’t work.

Note: Ingress Controllers are not just regular reverse-proxy solutions. They have additional intelligence built into them to monitor the K8s cluster for new ingress resources and configure themselves accordingly. The ingress controller needs a service account to do this.

The ingress controller requires a NodePort Service to be exposed at a node port on the cluster. Alternatively, the ingress controller requires a LoadBalancer Service to be exposed as a public IP. DNS server can then be configured to point to the IP of the cloud-native NLB.

Deploying Ingress Controller

• An ingress controller is deployed as just another deployment in K8s.
• The example below uses the build image of ingress controller using Nginx as reverse proxy.
• The program to run the ingress controller is present at /nginx-ingress-controller which is passed as args.
• Nginx requires some configuration to run as expected. Instead of configuring these in the deployment definition file. These should be decoupled into a ConfigMap nginx-configuration. This config file is passed in args as well.
• Nginx ingress controller requires two environment variables POD_NAME and POD_NAMESPACE to be passed. This can be fetched from the metadata.
• Finally, expose the ports on the ingress controller pod to allow the service to reach the pod.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
	name: nginx-ingress-controller
spec:
	replicas: 1
	selector:
		matchLabels:
			name: nginx-ingress
	template:
		metadata:
			labels:
				name: nginx-ingress
		spec:
			containers:
				- name: nginx-ingress-controller
					image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.21.0
			args:
				- /nginx-ingress-controller
				- --configmap=$(POD_NAMESPACE)/nginx-configuration

			env:
				- name: POD_NAME
					valueFrom:
						fieldRef:
							fieldPath: metadata.name
				- name: POD_NAMESPACE
					valueFrom:
						fieldRef:
							fieldPath: metadata.namespace

			ports:
				- name: http
					containerPort: 80
				- name: https
					containerPort: 443
			

A NodePort service can then be configured to make the ingress controller accessible at a node port in the cluster.

apiVersion: v1
kind: Service
metadata:
	name: nginx-ingress
spec:
	type: NodePort
	ports:
		- port: 80
			targetPort: 80
			protocol: TCP
			name: http
		- port: 443
			targetPort: 443
			protocol: TCP
			name: https
	selector:
		name: nginx-ingress

Ingress Resource

Ingress resources are set of rules and configuration applied on the ingress controller. This includes path based routing, subdomain based routing, etc. The backend in the ingress definition file defines the service name and the port at which the application service is running.

For every hostname or domain name, we need a separate rule. For each rule, we can route traffic based on the path.

Ingress to route all traffic to a backend service

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: ingress-wear
spec:
	backend:
		serviceName: wear-service
		servicePort: 80