Internal Traffic Cluster vs Local
What keeps a call from inside the cluster on the Node it started on? With internalTrafficPolicy Cluster and no trafficDistribution, kube-proxy on each Node writes every ready endpoint into its rules, so a call can be DNAT-ed to another Node. With Local it writes only the endpoints on its own Node, which lets a Pod reach its node-local DaemonSet agent, and it never falls back to another Node, so in iptables mode a Node with no local endpoint left drops the call.
Play the animation 3 steps, animated, best on a wide screen
Internal Traffic Cluster vs Local, step by step
-
A DaemonSet runs one agent Pod per Node behind Service node-agent. With the default Cluster, kube-proxy on each Node writes both agents into its Service rules, so a call can be DNAT-ed to either one. Here both calls land on the agent of the other Node and cross the cluster network.
Play from step 1 -
Set internalTrafficPolicy to Local. On the next sync, kube-proxy on each Node rewrites its rules: Node-1 keeps only agent-1 and Node-2 only agent-2. The same call to the same ClusterIP now stays on its own Node. This lets a Pod reach the node-local agent of a DaemonSet, such as a log shipper or a metrics agent.
Play from step 2 -
Local never falls back to another Node. Once agent-2 turns ready=false and is not terminating, kube-proxy on Node-2 writes a DROP rule for the ClusterIP, in the default iptables mode, so this call hangs until it times out though agent-1 is ready. Local suits a DaemonSet only while every Node with callers runs a ready agent.
Play from step 3