Application networking in Kubernetes

Traffic entering a Kubernetes cluster and moving between its workloads can run on three L7 options: Ingress, a service mesh or Gateway API.

This guide recaps the cluster network model, then compares the three with YAML for each: an observability application configured with Ingress and with Gateway API, and a scenario adding header-based matching, a redirect and a canary split.

The main topics covered in this e-book:

The Kubernetes network model: CNI plugins, Services, kube-proxy and CoreDNS
Ingress for north-south traffic, with a path-based routing example
Service mesh for east-west traffic, including an SMI TrafficSplit canary
Gateway API roles, xRoutes and its three support levels
Ingress and Gateway API YAML side by side, basic and advanced scenarios

Application networking in Kubernetes — document render

Why download this e-book?

How do Pods connect and talk in Kubernetes?
The ebook explains the Kubernetes network model: CNI plugins such as Calico, Cilium and Flannel, Services and kube-proxy, and the internal DNS, CoreDNS.
When is Ingress the right fit?
Ingress handles north-south traffic entering the cluster with L7 routing. A path-based routing example shows several applications sharing one domain name through a common entry point.
What does a service mesh add?
A service mesh gives fine-grained control of east-west traffic between workloads. The ebook shows a traffic split configured with the SMI specification and how to tell which cases suit Ingress and which suit a service mesh.
Why look at Gateway API?
Gateway API offers a wider set of advanced functions in a standard way and can be considered the successor to Ingress. The ebook covers its roles and support levels and rebuilds an Ingress configuration with it.