Understanding Kubernetes Ingress

Ingress in Kubernetes is another kind of object that allows us to expose an internal service within the Kubernetes cluster to the external world over HTTP/S. In this post, we’ll explore Kubernetes Ingress and its significance. To start, let’s consider the general meaning of the word ingress—simply, it refers to the act of entering.

What is Ingress?

In general, the term ingress means "the act of entering." In Kubernetes, it holds a similar meaning but applies specifically to web traffic. The ingress concept in Kubernetes enables exposing internal services to the external world. This allows entities outside the Kubernetes cluster to access internal services through ingress.

Ingress doesn’t just expose services; it also allows us to define rules to route traffic to different backends. Additionally, ingress may provide features such as:

• Load balancing
• SSL termination
• Name-based virtual hosting

The exact capabilities depend on the ingress controller used in the cluster.

However, ingress is not the only way to expose internal services to the external world. Kubernetes offers other service types, such as NodePort and LoadBalancer, to achieve similar functionality.

Kubernetes Ingress in Action

Imagine you are working on two application deployments in Kubernetes.

1. Application 1: A listener application that listens for events, processes the data, and stores it in a database. This application does not expose any API, either internally or externally. You deploy this application in the cluster as a Kubernetes deployment without creating any service.
   
   

   

   Listener app

2. Application 2: A backend application that provides APIs for frontend applications. Since all frontend applications are within the same cluster, you decide to expose this backend application using a Kubernetes service of type ClusterIP. This allows the frontend applications to communicate with the backend through the Kubernetes service internally.

Internal frontend apps talk to backend via K8s internal service name

The Need for Ingress

After a few weeks, your team introduces a new requirement: another frontend application, which is outside the Kubernetes cluster, needs to access the backend application’s API.

Here’s the issue:

• The ClusterIP service you created exposes a virtual IP address from the cluster’s internal IP address space.
• This virtual IP is only reachable from within the cluster, making it inaccessible to external entities.

To solve this, you need to expose the backend service outside the cluster. This is where Kubernetes ingress becomes crucial.

Ingress is designed to expose internal Kubernetes services to the external world, enabling external entities to access services within the cluster. While there are other methods to achieve this, such as using NodePort or LoadBalancer, this post focuses on ingress.

Key Points About Kubernetes Ingress

Ingress is another Kubernetes object, similar to deployments and services. However, it requires an additional component called an ingress controller to function.

Key characteristics of Kubernetes ingress:

• Exposes Internal Services: Ingress enables external access to internal Kubernetes services.
• Advanced Traffic Management: It supports traffic routing to different backends based on defined rules, load balancing, SSL termination, and name-based virtual hosting.
• Ingress Controller: Ingress resources are managed by an ingress controller, which operates at Layer 7 of the OSI model.
• HTTP/S Traffic Only: Ingress works exclusively with HTTP and HTTPS protocols, typically on ports 80 and 443. For non-HTTP/S services, NodePort and LoadBalancer are alternatives.

Using Ingress

To meet the new requirement, you decide to use ingress to expose the backend API externally. Since the external frontend application requires access via HTTPS, you:

1. Choose a suitable ingress controller for your cluster.
2. Install the ingress controller.
3. Deploy an ingress resource to expose the backend service.

The following figure illustrates how these applications interact:

• Internal frontend applications continue to communicate with the backend through the Kubernetes service.
• The external frontend application connects to the backend via ingress.

Internal frontend apps talk to backend via K8s internal service and external apps via ingress

Choosing an Ingress Controller

To use ingress, you must install an ingress controller in your Kubernetes cluster. While ingress itself functions as an additional Kubernetes object, selecting the most suitable ingress controller is a crucial decision. Among the widely used ingress controllers, AWS, GCE, and Ingress-NGINX are officially supported and maintained by the Kubernetes project.

Conclusion

This article provided a high-level overview of Kubernetes ingress and how it helps expose internal services to external entities. Ingress plays a critical role in managing web traffic within Kubernetes clusters. Stay tuned for upcoming posts as we dive deeper into Kubernetes ingress and its capabilities!