DSR is important because of how LoadBalancers work in k8s: you can configure them with either externalTrafficPolicy=Cluster, or externalTrafficPolicy=Local. Under vanilla k8s with kube-proxy, both options are a tradeoff that sacrifice something.
-
-
Prikaži ovu nit
-
With externalTrafficPolicy=Cluster, all nodes can receive and forward traffic for an LB IP. Incoming connections are balanced evenly across the service's pods. But, you lose the source IP of the connection, because kube-proxy has to NAT the traffic to the target node/pod.
Prikaži ovu nit -
With externalTrafficPolicy=Local, only nodes with service pods can receive traffic. This complicates the LB layer (e.g. MetalLB), and unless you take precautions the connection won't balance evenly across the service's pods. But, you get to see the true source IP.
Prikaži ovu nit -
With DSR in Cilium, you can have the best of both worlds: the Cluster traffic policy will still spread connections evenly across available pods, but the response traffic coming from the pods will flow directly out and back to the client, without bouncing around the cluster.
Prikaži ovu nit -
No bouncing around the cluster means there's no need to rewrite the source IP. So you get even balancing of connections, all service pods utilized at once, efficient traffic flow through the cluster, and the client's source IP.
Prikaži ovu nit -
With Cilium's DSR mode, Kubernetes can finally claim to have proper service LB capabilities, the ones I wanted when I first wrote MetalLB. Back then I had to compromise on some nice properties of the Google topologies I was mimicking, because I didn't have Maglevs.
Prikaži ovu nit -
Well, sounds like Cilium's about to give me Maglev for Kubernetes, and I can finally have the setup I wanted. DSR should be beta in Cilium 1.7 (toggle a flag to enable), and fingers crossed it'll be on by default in 1.8. I can't wait!
Prikaži ovu nit -
And for DSR dorks: it's implemented by adding the "DSR response ip:port" as an IP option to the packet as it flows through the inbound path. The packet is still DNATed to the appropriate pod, but flows to that pod's node with an extra IP option tacked on.
Prikaži ovu nit -
As the target node receives the traffic, before passing it on to the pod, it creates a local conntrack entry, reminding it that response packets need to be SNATed to the service's ip:port. Then it delivers the packet (with original client ip:port) to the pod.
Prikaži ovu nit -
When the pod responds, the local node SNATs the packets to the LB ip:port, and sends them straight back to the client, no detour via the node that originally received the inbound traffic.
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.