Ingress

Generally, Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Gateway, HTTPRoute and GRPCRoute Resources. The older generation of Kubernetes Ingress uses the Ingress Resource.

A Kubernetes Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting, among other things. An Ingress or Gateway Controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

Gateway and Ingress Controllers are not started automatically with a cluster. To choose the Controller implementation that best fits your cluster might be a difficult task, as there are several available, some general purpose (e.g. Traefik) and some specifically optimized for a certain cloud provider (e.g. AKS Application Gateway Ingress Controller or AWS ALB Ingress Controller), some standalone (e.g. ingress-nginx, haproxy-based solutions or envoy-based solutions) and some being part of a more encompassing solution framework (e.g. Istio Ingress). Confer to this overview for Gateway and this for Ingress for more details. And you may deploy any number of Ingress Controllers within a cluster and add resource annotations (e.g. kubernetes.io/ingress.class: "nginx") or - starting with Kubernetes v1.18 - add an ingressClassName field for selecting the desired one ad-hoc, or even install and configure them each to only serve a specific namespace, allowing you to always pick the best for the task at hand, of course at the price of additional complexity.

An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer. And of course you are free to continue exposing HTTP/HTTPS via LoadBalancer if you so desire. It’s just that Gateway and Ingress Controllers can provide some additional value, as we are about to see.

In the course of these exercises we will now cover two common Ingress Controller implementations:

• Nginx (official K8s blog Ingress NGINX retirement )
• Traefik
• Gateway API

A third option, the Ingress Controller as provided as part of the Istio Service Mesh , will be covered in a later chapter.

Namespaces

However, with the Controllers being a pre-defined cluster-wide central solution, we need to take care to not step on each others’ toes in the following exercises. For that we will prefix some parts of the following resources with a user-specific namespace. We have seen namespaces referenced in some commands before, but what are they?

Namespaces are a way to divide cluster resources between multiple users, via role-based access control (RBAC), ServiceAccounts, and resource quotas, and they provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. During the course of these exercises each of you has already been working within their own private namespace, making use of a specific ServiceAccount with appropriate permissions, but that won’t suffice now anymore when we introduce a cluster-wide central solution for exposing workloads to the general public where each public name needs to be unique.