Ingress

The core function of an Ingress is to route external HTTP and HTTPS requests to internal services based on defined rules. These rules typically inspect the host header (e.g., api.example.com) and the request path (e.g., /v1/users).

• Path-Based Routing: Directs traffic to different backend services based on the URL path. For example, /web goes to the frontend service, while /api goes to the backend API service.
• Host-Based Routing: Directs traffic based on the domain name, allowing multiple websites or subdomains to be served from the same cluster IP address.
• Default Backend: A catch-all service that handles requests that do not match any of the defined rules.

Ingress controllers can handle the decryption of HTTPS traffic, offloading the cryptographic workload from the backend services. This is managed via Ingress TLS specifications.

• Certificate Management: The Ingress references a Kubernetes Secret object that contains the TLS private key and certificate (e.g., a .crt and .key file).
• Centralized Security: SSL termination at the Ingress layer simplifies certificate management and renewal for all services behind it.
• Supports SNI: Modern Ingress controllers support Server Name Indication (SNI), allowing multiple TLS certificates to be hosted on a single IP address, essential for host-based routing with HTTPS.

An Ingress controller provides load balancing functionality, distributing client requests across all healthy pods backing a service. This is a critical feature for scalability and high availability.

• Session Affinity: Also known as sticky sessions, this feature ensures requests from the same client are directed to the same backend pod, which is necessary for stateful applications.
• Algorithm Variety: Common load balancing algorithms include round-robin, least connections, and IP hash.
• Health Check Integration: The load balancer uses readiness probes from the Kubernetes pods to determine which backends are eligible to receive traffic, preventing requests from being sent to failing instances.

The Ingress resource defines the rules, but an Ingress Controller is the actual process that fulfills those rules. It is a specialized load balancer implementation running as a pod in the cluster.

• Implementation Variants: Popular controllers include NGINX Ingress Controller, Traefik, HAProxy Ingress, and cloud-provider specific ones like AWS ALB Ingress Controller and GKE Ingress.
• Dynamic Configuration: The controller watches the Kubernetes API for changes to Ingress resources and updates its configuration (e.g., an NGINX config file) in real-time.
• Requires a Service: The controller itself is exposed via a Kubernetes Service of type LoadBalancer or NodePort to receive external traffic.

This feature allows multiple domain names or subdomains to be served from a single public IP address, a fundamental capability for modern web hosting on Kubernetes.

• Host Rule: An Ingress rule specifies a host field (e.g., blog.example.com). The Ingress controller matches the HTTP Host header in the incoming request to this rule.
• Cost and IP Efficiency: Eliminates the need for a unique public IP address per website or service, conserving IPv4 addresses and reducing cloud infrastructure costs.
• Example Rule:

yamlCopy
rules:
- host: "app.company.com"
  http:
    paths:
    - path: "/"
      pathType: Prefix
      backend:
        service:
          name: frontend-svc
          port:
            number: 80

Ingress behavior is extensively customized using annotations. These are key-value pairs attached to the Ingress manifest that provide instructions to the specific Ingress Controller.

• Controller-Specific: Annotations are not standardized by the Kubernetes API; their function depends on the controller implementation. For example, nginx.ingress.kubernetes.io/rewrite-target is specific to the NGINX controller.
• Common Customizations:
  • Rate Limiting: Configuring requests-per-second limits per client or service.
  • CORS: Enabling Cross-Origin Resource Sharing headers.
  • Authentication: Basic auth, OAuth, or external auth URL configuration.
  • Custom Timeouts: Setting proxy connect, read, and send timeouts.
• Alternative to IngressClass: Before the IngressClass resource, annotations like kubernetes.io/ingress.class: "nginx" were used to designate which controller should handle the Ingress.

A network device or software component that distributes incoming network traffic across multiple backend servers to ensure no single server is overwhelmed. In Kubernetes:

• A Service of type LoadBalancer provisions an external cloud load balancer (e.g., AWS NLB, GCP Cloud Load Balancing) that points to cluster pods.
• An Ingress Controller often acts as a Layer 7 (HTTP/HTTPS) load balancer, providing more advanced routing rules (host/path-based) compared to the simpler Layer 4 (TCP/UDP) load balancing of a LoadBalancer Service.

A server that sits in front of web servers and forwards client requests to those servers. It is the core architectural pattern implemented by Ingress controllers (e.g., NGINX, Envoy, Traefik). Core functions include:

• SSL/TLS termination: Decrypting HTTPS traffic before passing it to backend services.
• Caching: Storing static content to reduce backend load.
• Compression: Minimizing payload size.
• Security: Acting as a shield, hiding backend server identities and providing a layer for basic firewall rules. An Ingress resource essentially configures the routing rules for the cluster's reverse proxy.

A Kubernetes Service type that exposes the service on a static port on each node's IP address. It is a more primitive alternative to Ingress and LoadBalancer for external access.

• How it works: Traffic to NodeIP:NodePort is routed to the clusterIP service, then to a pod.
• Use Case: Primarily for development, debugging, or when a load balancer is not available. It does not provide L7 routing, SSL termination, or virtual hosts like Ingress.
• Drawback: Requires manual management of port conflicts and external traffic routing to node IPs.