Kubernetes 10 - Ingress

While Kubernetes offers various Service types for exposing applications, they primarily operate at the network level. But what if you need more sophisticated routing based on hostnames or URLs? This is where Ingress comes into play.

What is Ingress?

Ingress is a Kubernetes resource that acts as a smart router for your cluster. It operates at OSI Layer 7 (Application Layer), which means it can make routing decisions based on HTTP and HTTPS traffic. This capability allows for more flexible and powerful traffic management compared to standard Kubernetes Services.

Key Features of Ingress:

  • URL-based routing
  • Host-based routing
  • SSL/TLS termination
  • Load balancing
  • Name-based virtual hosting

Why do we need Ingress?

Traditional Kubernetes Service types (like ClusterIP, NodePort, and LoadBalancer) work well for many scenarios, but they have limitations:

  1. They operate at lower network layers (Layer 4 - Transport Layer)
  2. They can’t route traffic based on application-level information like hostnames or URL paths

Ingress fills this gap by providing a way to configure routing rules based on HTTP/HTTPS requests. This enables you to:

  • Route traffic to different services based on the requested hostname Example: route requests for api.example.com to one service and web.example.com to another
  • Direct requests to specific services based on URL paths Example: send /api/* requests to an API service and /app/* to a web app service
  • Implement SSL/TLS termination Ingress can handle HTTPS connections and forward decrypted traffic to your services
  • Set up name-based virtual hosting Host multiple domains on a single IP address

How Does Ingress Work?

Ingress itself is just a set of rules defined in a YAML file. To make these rules work, you need an Ingress Controller. The Ingress Controller is responsible for reading the Ingress resource configurations and implementing them, typically using a reverse proxy or load balancer.

Components of Ingress:

  1. Ingress Resource: A Kubernetes object that defines the routing rules.
  2. Ingress Controller: The component that implements the Ingress rules.
  3. Reverse Proxy/Load Balancer: Often part of the Ingress Controller, handles the actual traffic routing.

Basic Ingress Workflow:

  1. User sends a request to your domain
  2. DNS resolves to the Ingress Controller’s IP
  3. Ingress Controller receives the request
  4. Controller checks the Ingress rules
  5. Request is forwarded to the appropriate backend service

There are several Ingress Controllers available, each with its own features and implementation specifics:

  1. Nginx Ingress Controller:

    • One of the most popular and widely used
    • Offers good performance and flexibility
    • Supports advanced features like rewriting and authentication
  2. Traefik:

    • Known for its ease of use and dynamic configuration
    • Integrates well with cloud-native environments
    • Provides automatic HTTPS with Let’s Encrypt
  3. HAProxy:

    • Offers high performance and reliability
    • Known for its low latency and high throughput
    • Provides detailed metrics and monitoring
  4. F5:

    • Provides enterprise-grade traffic management
    • Offers advanced security features
    • Suitable for large-scale deployments
  5. Envoy:

    • A modern, high-performance proxy
    • Designed for cloud-native applications
    • Offers advanced features like circuit breaking and rate limiting
  6. Istio:

    • Part of a larger service mesh solution
    • Provides advanced traffic management capabilities
    • Offers strong security and observability features

Setting Up Ingress

To use Ingress in your cluster, you typically need to:

  1. Choose and install an Ingress Controller
  2. Configure your DNS to point to the Ingress Controller’s IP or load balancer
  3. Create Ingress resources to define routing rules

Here’s a simple example of an Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  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: web-service
                port:
                  number: 80

This Ingress rule routes traffic for myapp.example.com/api to the api-service and all other traffic to the web-service.




    Enjoy Reading This Article?

    Here are some more articles you might like to read next:

  • Dependency Injection
  • CPU Cache
  • Understanding Linear Blended Skinning in 3D Animation
  • Starvation in Operating Systems
  • Virtual Memory