Kubernetes Ingress for Layer 7 Routing¶

Kubernetes Ingress is an API resource that manages external access to services within a cluster, typically through HTTP and HTTPS.^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md] Unlike Services, which operate primarily at Layer 4 (Transport layer), Ingress provides Layer 7 (Application layer) routing capabilities.^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]

Core Functionality¶

Ingress acts as a layer of abstraction over [[Services]], allowing for more sophisticated traffic management rules.^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md] It functions as a set of routing rules that determine how external traffic reaches specific Services, effectively acting as a "Smart Proxy" or entry point into the cluster.[^inferred]

Layer 7 Routing¶

By operating at Layer 7, Ingress can make routing decisions based on HTTP/HTTPS attributes rather than just IP addresses and ports.^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md] This enables traffic distribution based on: * Domain names (Host-based routing) * Request paths (Path-based routing)

Ingress Controllers¶

An Ingress resource is useless without an Ingress Controller.^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md] While the Ingress resource defines the rules, the Ingress Controller is the component that actually implements them by reading the Ingress configuration and managing a proxy server (like Nginx, HAProxy, or Envoy).

Nginx Ingress is the officially maintained controller in the Kubernetes ecosystem.[^inferred][400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]

Advanced Routing Strategies: Canary Deployments¶

Ingress controllers like Nginx Ingress support advanced deployment strategies through specific Annotations.[^inferred][400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md] A common use case is Canary Deployment, where a new version of a service is rolled out to a small subset of users to verify stability before a full rollout.[^inferred]

Canary Annotations¶

The Nginx Ingress Controller provides several annotations to facilitate traffic splitting for canary releases^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]:

nginx.ingress.kubernetes.io/canary: Must be set to "true" to enable canary functionality for the specific Ingress rule.
nginx.ingress.kubernetes.io/canary-weight: Specifies the percentage of traffic (0-100) to route to the canary version.
nginx.ingress.kubernetes.io/canary-by-header: Routes traffic based on the presence or value of a specific HTTP Header.
nginx.ingress.kubernetes.io/canary-by-cookie: Routes traffic based on a specific Cookie.

Traffic Priority¶

When multiple canary rules are configured, the priority for determining which rule applies follows this order^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]: 1. Header matches 2. Cookie matches 3. Weight-based distribution

Sources¶

^[400-devops__06-Kubernetes__k8s-ithelp__Day15__README.md]