Kubernetes Ingress

What is Kubernetes Ingress?

Kubernetes Ingress is an API object that helps developers expose their applications and manage external access by providing http/s routing rules to the services within a Kubernetes cluster. It can simplify production environments because it facilitates a simple method of establishing rules to route traffic rather than creating specialized load balancers or manually exposing each service within a node. Today’s production environments need powerful features like content-based routing, multiple protocol support, and strong authentication. Kubernetes Ingress provides these capabilities and allows developers to configure all of them within the cluster.

Ingress consists of an Ingress API object and the Ingress Controller. As mentioned, Kubernetes Ingress is an API object that describes the desired state for exposing services for access from outside the Kubernetes cluster. The Ingress Controller represents the actual implementation of the Ingress API by processing Ingress Resource information while running as a pod within the Kubernetes cluster. A basic Ingress implementation provides URLs exposed for external connections, name-based routing support, and load balancing/traffic routing rules.

What is an Ingress Controller?

As mentioned, the Ingress Controller is the actual implementation of the Kubernetes Ingress API. It covers all layer four to layer seven network services and typically acts as a load balancer by distributing traffic across pods. It’s also responsible for processing all Ingress resource information.

In terms of actual implementation, the Ingress Controller is an application hosted inside a Kubernetes cluster that actively manages a load balancer following Ingress Resources and pre-defined Ingress Rules. It works with all types of load balancers, including software-based, hardware-based, or cloud service balancers. There are many load balancer options on the market, and each one requires a different Ingress Controller implementation. There are also many Ingress Controllers available with various features and capabilities.

What is the difference between Ingress and Egress?

In Kubernetes, enabling secure network traffic is primarily based on defining Ingress and Egress rules. From the vantage point of a Kubernetes pod, Ingress Rules govern traffic originating from external connections coming into the pod, while Egress Rules govern traffic arising from within the pod heading externally.

Ingress Controllers

Ingress Resources depend on Ingress Controllers to function. Developers and operators must ensure that they choose to correct Ingress Controller implementation to suit their architecture. One popular example is the NGINX Ingress Controller, which works with an NGINX proxy webserver. It features an app-centric configuration model based on role-based access control and supports multi-tenancy. NGINX also includes specialized NGINX Ingress Resources, which provide an NGINX‑specific configuration schema with enhanced features relative to the generic Kubernetes Ingress Resources. Whether using a vendor-specific Ingress Controller like NGINX, or bootstrapping your own, it’s essential to tailor your solution to the specific requirements of your implementation.

Here are some of the critical considerations for selecting the suitable Ingress Controller for your system:

Protocol Support
Downtime tolerance for updates
Resiliency
Load Balancing Algorithms
High Availability

High availability, in particular, is a critical factor in selecting the most suitable Ingress Controller because not all of them support it. In addition to choosing the right product, there are some additional practices to consider to ensure higher availability:

Use multiple Ingress controller pod instances
Configure the cluster to place Ingress Controller pods into different nodes

Example Ingress Controller Setup

To set up an Ingress Controller, you need to have a Kubernetes cluster and the kubectl CLI tool configured to communicate with the cluster. This example shows how to enable the NGINX Ingress Controller with minikube:

In your CLI, start by enabling the Ingress Controller with the command minikube addons enable ingress

Next, verify that the NGINX controller is running correctly with the command kubectl get pods -n kube-system

What’s next?

Kubernetes networking and Ingress are set for a significant evolution soon with the release of the Gateway API. The key enhancements/design principles are:

Extensibility- The Gateway API will feature enhanced customization and extensibility within the API.
Role-oriented- The resource model will reflect common Kubernetes use cases in routing and service networking.
Expressive- The Gateway API will have expressive features like header manipulation, traffic mirroring, TCP/UDP routing, and many other features that were previously only possible through customizations.

When considered holistically, this amounts to a product that provides better support for multi-tenant infrastructure with extensibility that will allow room to evolve for future use cases.