Skip to content

Layer 7 Traffic Routing

Layer 7 Traffic Routing involves the distribution of network traffic based on information found at the application layer (Layer 7) of the OSI model, such as HTTP and HTTPS protocols.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

In the context of Kubernetes, this routing capability is primarily provided by Ingress. Unlike Services which typically operate at Layer 4 (Transport layer), Ingress allows for more granular control by using domain names and request paths to forward traffic to different Services within the cluster.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

Nginx Ingress Implementation

Nginx Ingress is a common implementation that utilizes specific annotations to manage traffic flow.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md] This allows for sophisticated routing strategies without requiring fundamental changes to the application code.

Traffic Splitting Strategies

Nginx Ingress supports several methods for splitting external traffic, often used for deployment strategies like Canary Deployment^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]:

  • Canary-by-Header: Routes traffic to a specific backend if the request headers match a defined value or pattern.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]
  • Canary-by-Cookie: Routes traffic based on the presence or value of a specific cookie in the request.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]
  • Canary-by-Weight: Distributes a percentage of traffic (0-100) to a specific backend, useful for shifting load gradually.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

The priority for these rules generally follows the order: Header, then Cookie, then Weight.^[400-devops-06-kubernetes-k8s-ithelp-day15-readme.md]

Sources

  • 400-devops-06-kubernetes-k8s-ithelp-day15-readme.md