CodeWithAbdessamad

Ingress

Ingress

In the world of Kubernetes, networking is the backbone that connects your applications, services, and the outside world. When you want to expose your applications to the internet or to other services within your cluster, Ingress is the key to the solution. In this section, we’ll dive deep into how Ingress works and how to use it to route traffic effectively.

Routing Traffic

At its core, Ingress is a networking component that manages incoming traffic to your Kubernetes cluster. It acts as a single entry point for external requests, allowing you to route traffic to different services based on rules you define. This is crucial for:

  • HTTP/HTTPS routing (e.g., routing requests to different backend services by path or host)
  • Load balancing (distributing traffic across multiple replicas of a service)
  • SSL termination (handling TLS encryption at the Ingress level)
  • Traffic management (e.g., rate limiting, request forwarding)

Let’s walk through a concrete example. Imagine you have two services: web-ui and api-service. You want to route traffic to web-ui when the host is example.com and to api-service when the host is api.example.com. Here’s how you’d define an Ingress resource:

<code class="language-yaml">apiVersion: networking.k8s.io/v1
<p>kind: Ingress</p>
<p>metadata:</p>
<p>  name: example-ingress</p>
<p>  annotations:</p>
<p>    nginx.ingress.kubernetes.io/rewrite-target: /</p>
<p>spec:</p>
<p>  rules:</p>
<p>  - host: example.com</p>
<p>    http:</p>
<p>      paths:</p>
<p>      - path: /</p>
<p>        pathType: Prefix</p>
<p>        backend:</p>
<p>          service:</p>
<p>            name: web-ui</p>
<p>            port:</p>
<p>              number: 80</p>
<p>  - host: api.example.com</p>
<p>    http:</p>
<p>      paths:</p>
<p>      - path: /</p>
<p>        pathType: Prefix</p>
<p>        backend:</p>
<p>          service:</p>
<p>            name: api-service</p>
<p>            port:</p>
<p>              number: 80</code>

This Ingress resource uses Nginx (via annotations) to route traffic based on host and path. The pathType: Prefix means that the path is matched as a prefix (so / matches any path starting with /). Note that in this example, we’re using a simple HTTP Ingress without TLS.

Key Takeaway: Ingress resources define routing rules that translate external requests into internal service calls. The actual routing is handled by the Ingress Controller (which we’ll discuss next).

Ingress Controllers

Now that we understand the what of Ingress, let’s explore the how. An Ingress Controller is a component that implements the Ingress API. It’s the “engine” that takes the Ingress resource definitions and translates them into network rules (like a reverse proxy). Without an Ingress Controller, the Ingress API is just a specification — it won’t do anything.

There are several popular Ingress Controllers:

  • Nginx Ingress Controller: A high-performance, widely used controller that’s great for complex routing scenarios.
  • Traefik: Known for its flexibility and dynamic configuration (it can auto-discover services and update routing without restarting).
  • AWS ALB Ingress Controller: For AWS environments, this controller integrates with AWS Load Balancers.

Let’s deploy the Nginx Ingress Controller and see it in action. First, we create a deployment for the controller:

<code class="language-yaml">apiVersion: apps/v1
<p>kind: Deployment</p>
<p>metadata:</p>
<p>  name: nginx-ingress-controller</p>
<p>spec:</p>
<p>  replicas: 2</p>
<p>  selector:</p>
<p>    matchLabels:</p>
<p>      app: nginx-ingress-controller</p>
<p>  template:</p>
<p>    metadata:</p>
<p>      labels:</p>
<p>        app: nginx-ingress-controller</p>
<p>    spec:</p>
<p>      containers:</p>
<p>      - name: nginx</p>
<p>        image: k8s.gcr.io/ingress-nginx/controller:v0.44.0</p>
<p>        ports:</p>
<p>        - containerPort: 80</p>
<p>        - containerPort: 443</p>
<p>        env:</p>
<p>        - name: POD_NAME</p>
<p>          valueFrom:</p>
<p>            fieldRef:</p>
<p>              fieldPath: metadata.name</p>
<p>        - name: POD_NAMESPACE</p>
<p>          valueFrom:</p>
<p>            fieldRef:</p>
<p>              fieldPath: metadata.namespace</code>

How it works: When you create an Ingress resource (like the one we defined in the previous section), the Ingress Controller (Nginx in this case) watches for changes and updates its configuration to route traffic accordingly. It acts as a reverse proxy that handles the routing rules.

Let’s add a simple Ingress resource to our example:

<code class="language-yaml">apiVersion: networking.k8s.io/v1
<p>kind: Ingress</p>
<p>metadata:</p>
<p>  name: example-ingress</p>
<p>spec:</p>
<p>  rules:</p>
<p>  - host: example.com</p>
<p>    http:</p>
<p>      paths:</p>
<p>      - path: /</p>
<p>        pathType: Prefix</p>
<p>        backend:</p>
<p>          service:</p>
<p>            name: web-ui</p>
<p>            port:</p>
<p>              number: 80</code>

After creating the Ingress, the Nginx Ingress Controller will automatically generate a configuration that routes traffic to the web-ui service.

Why Ingress Controllers matter: They are the bridge between the abstract Ingress API and the physical network. Without them, you wouldn’t have the ability to route traffic to your services.

Summary

In this section, we’ve explored the core concepts of Ingress — specifically routing traffic and Ingress Controllers. You now understand how to define routing rules and deploy a controller to implement them. This foundational knowledge is critical for building secure, scalable, and maintainable cloud-native applications. Remember: Ingress is the gateway to your Kubernetes applications, and mastering it is key to becoming a Kubernetes expert. 🌐