Kubernetes Ingress Controller¶
A Kubernetes Ingress controller is a specialized load balancer responsible for implementing the rules defined by Kubernetes Ingress resources.^[400-devops-06-kubernetes-k8s-paas-03k8s.md] While the Ingress resource defines the "rules" (such as domain name and URL path routing), the Ingress Controller is the engine that actually listens for traffic, processes the requests, and forwards them to the appropriate backend [[Service|Services]].^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
Functionality¶
The core function of an Ingress Controller is to manage external access to services within a Kubernetes cluster, typically via HTTP and HTTPS.^[400-devops-06-kubernetes-k8s-paas-03k8s.md] It acts as a bridge, forwarding requests from the cluster edge to specific internal services.
Ingress controllers operate at the Layer 7 (Application Layer) of the OSI model.^[400-devops-06-kubernetes-k8s-paas-03k8s.md] This is distinct from standard Kubernetes Services, which operate at Layer 4 (Transport Layer) and handle TCP/UDP routing without inspecting the HTTP content.^[400-devops-06-kubernetes-k8s-paas-03k8s.md] Because they operate at Layer 7, Ingress controllers can make routing decisions based on HTTP headers, hostnames, and request paths.
Architecture and Workflow¶
A typical deployment involves the following components:
- Ingress Resource: A YAML configuration file defining routing rules (e.g.,
traefik.od.com-> Service X).^[400-devops-06-kubernetes-k8s-paas-03k8s.md] - Ingress Controller: The application (e.g., Nginx, Traefik) running as a Pod within the cluster that watches the API server for Ingress resources and updates its configuration accordingly.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
- External Infrastructure: An external reverse proxy (such as Nginx) or DNS configuration is typically required to direct traffic from the internet to the Ingress Controller pods running on the worker nodes.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
Example: Traefik¶
Traefik is a popular modern HTTP reverse proxy used as an Ingress Controller.^[400-devops-06-kubernetes-k8s-paas-03k8s.md] It dynamically updates its configuration by monitoring the Kubernetes API, automatically generating routing rules whenever microservices (Services or Pods) are added, removed, or updated.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
Traffic Flow¶
When a user accesses a service (e.g., https://example.com.od.com):
1. DNS resolves the domain to the external load balancer or Node IP.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
2. The request is forwarded to the Ingress Controller (listening on a host port like 81).^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
3. The Ingress Controller matches the request against Ingress rules (Host/Path).^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
4. Traffic is proxied to the correct backend Service and subsequently to a Pod.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
Comparison with NodePort¶
While it is possible to expose services using NodePort, using an Ingress Controller is often preferred for HTTP/HTTPS traffic because:
* Layer 7 Capabilities: It supports routing based on hostnames and paths, not just IP and port.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
* Consolidation: A single Ingress Controller can handle routing for multiple services, avoiding the need to open multiple ports on every node.^[400-devops-06-kubernetes-k8s-paas-kubernetes-yaml.md]
* Performance: NodePort sometimes cannot leverage the higher-performance ipvs mode of kube-proxy (depending on configuration/implementation details), whereas Ingress controllers are designed for high-throughput proxying.^[400-devops-06-kubernetes-k8s-paas-03k8s.md]
Sources¶
- 400-devops-06-kubernetes-k8s-paas-03k8s.md
- 400-devops-06-kubernetes-k8s-paas-kubernetes-yaml.md