Ingress y enrutamiento en Kubernetes

So far, we've used Services like NodePort or LoadBalancer to expose our applications outside the Kubernetes cluster.

While effective, these have limitations for complex routing, host-based rules, or managing TLS certificates for multiple applications.

This is where Ingress comes in! It acts as an entry point for external traffic, offering more advanced routing capabilities.

Let's clarify the roles:

• Service: Provides stable networking for Pods within the cluster and can expose a single application externally (e.g., NodePort, LoadBalancer).
• Ingress: Manages external access to multiple Services, offering features like URL routing, host-based routing, and SSL/TLS termination.

Think of Ingress as a smart traffic controller for your external requests.

An Ingress resource itself doesn't do anything on its own. It's just a set of rules you define.

You need an Ingress Controller running in your cluster. This controller watches for Ingress resources and configures a proxy (like Nginx, HAProxy, or Traefik) to fulfill those rules.

Without an Ingress Controller, your Ingress rules are ignored!

An Ingress resource uses YAML to define how traffic should be routed. Here's a basic structure:

It specifies rules based on hostnames and paths, directing traffic to a specific Kubernetes Service.

One powerful feature is host-based routing. You can direct traffic for different hostnames to different backend Services.

For example, blog.example.com goes to your blog service, and api.example.com goes to your API service.

You can also route traffic based on the URL path. This is useful for exposing different parts of a single application or microservices under one domain.

For instance, myapp.com/users might go to a user service, while myapp.com/products goes to a product service.

What if no host or path rule matches an incoming request?

You can define a default backend in your Ingress. This directs all unmatched traffic to a specific Service, often a simple "404 Not Found" page or a default landing page.

It's good practice to always include a default backend for robustness.

Security is crucial! Ingress can also handle TLS termination. This means the Ingress Controller decrypts incoming HTTPS traffic before forwarding it to your backend Services (which can then run on plain HTTP).

This offloads SSL/TLS certificate management from your application Pods to the Ingress Controller.

You'll need a Kubernetes Secret containing your TLS certificate and key.

To enable TLS, you reference a Kubernetes Secret in your Ingress definition. This Secret must contain the TLS certificate and private key.

The Ingress Controller will then use this certificate for HTTPS connections to your domain.

Consider an Ingress resource with the following rule:

  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Which service will a request to http://myapp.example.com/api/v1/users be routed to?

In this lesson, you've learned about Kubernetes Ingress, a powerful tool for managing external access to your cluster.

• Ingress provides advanced routing features like host and path-based rules.
• An Ingress Controller is essential to make Ingress rules work.
• You can easily secure your applications with TLS termination using Ingress and Kubernetes Secrets.

Ingress simplifies exposing complex applications and microservices to the outside world!