Skip to content

Ingress-based Traffic Splitting

Ingress-based Traffic Splitting is a traffic management strategy used in Kubernetes to route a subset of external HTTP or HTTPS requests to a specific version of a service. This technique is commonly employed to implement Canary Deployments, allowing operators to test new versions with a small percentage of users before a full rollout.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

Mechanism

This functionality leverages the Ingress Controller, typically the Nginx Ingress Controller in Kubernetes, to operate at the Layer 7 (Application Layer) of the OSI model.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md] By creating a specific "Canary Ingress" resource alongside the main Ingress, administrators can define rules that split incoming traffic between the stable production version and the new canary version based on various criteria.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

Configuration Strategies

Traffic routing is configured via specific annotations on the Ingress resource.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md] The following strategies are supported by the Nginx Ingress Controller:

  • Header-based Routing: Traffic is routed if the request contains a specific header matching a defined value or regex pattern.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]
  • Cookie-based Routing: Traffic is routed based on the presence or value of a specific Cookie in the request.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]
  • Weight-based Routing: A specific percentage of traffic (0-100) is routed to the canary service.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

Priority of Rules

When multiple rules are present, the Ingress Controller evaluates them in a specific order of precedence.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md] The priority is generally as follows:

  1. Header-based (canary-by-header)
  2. Cookie-based (canary-by-cookie)
  3. Weight-based (canary-weight)

Implementation Workflow

A typical Ingress-based Canary Deployment involves the following steps^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]:

  1. Deploy the stable version (v1) and configure the main Ingress to route traffic to it.
  2. Deploy the new version (v2) alongside v1, ensuring it is running but not receiving external traffic yet.
  3. Create a Canary Ingress resource with annotations defining the split criteria (e.g., weight).
  4. Monitor the v2 version for stability.
  5. Once verified, update the main Ingress to point entirely to v2 and remove the Canary Ingress.
  6. Decommission the v1 resources.

Sources

^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]