Kubernetes - Networking inside cluster -

user_11711488 0
Viewed 320

I am trying to understand Kubernetes networking and came across the following snippet...in GKE network documentation...GKE - Networking. This says...

Kubernetes manages connectivity among Pods and Services using the kube-proxy component, which runs on each node. kube-proxy, which is not an in-line proxy, but an egress-based load-balancing controller, watches the Kubernetes API server and continually maps the ClusterIP to healthy Pods by adding and removing destination NAT (DNAT) rules to the node's iptables subsystem. When a container running in a Pod sends traffic to a Service's ClusterIP, the node selects a Pod at random and routes the traffic to that Pod.

I have two questions on this...

  1. Assume there are 5 nodes out of which 3 nodes are part of service. Now one of the pod (from node that is not part of service) wants to communicate with service... It finds service by FQDN of service.. Does the kube-proxy with in this node send traffic to one of the pod that is part of service ?
  2. Also, it says kube-proxy load balances the traffic across the full set of pods... how is that done ? If there is one single node that takes of traffic routing, it understand which one is the next node/pod to get traffic.. but Service picks nodes(with in a service) randomly right ?

Can someone please clarify ?

Thanks in advance.

kubernetes load-balancing
2 Answers

Please find the answers for your questions:

1) Does the kube-proxy with in this node send traffic to one of the pod that is part of service ?

Yes, kube-proxy will route the traffic to the correct pod(s). Each node in the cluster will have kube-proxy and each kube-proxy will write the iptable rules to redirect the traffic to pods when serviceIP is used.

2) Lets take this example:

We have 4 node cluster and two applications running with 2 replicas.

node1 -> application1_pod1
node2 -> application1_pod2
node3 -> application2_pod1
node4 -> application2_pod2 
(all 4 pods are running in different node)

Now application1 wants to talk to application2 using application2's service name.

1. application1_pod1 may talk to application2_pod1
1.1 (once this is done, node1 iptables will route next traffic to application2_pod2)
2. application1_pod2 may talk to application2_pod1 (as the iptables of node2 is not aware of previous traffic in node1)
2.1 (once this is done, node2 iptables will route next traffic to application2_pod2)
3. application1_pod1 will talk to application2_pod2 (because of 1.1)
4. application1_pod2 will talk to application2_pod2 (because of 2.1)

So at the end of step 2, traffic to application2_pod1 is 100% and traffic to application2_pod2 is 0%. At the end of step 4, traffic to application2_pod2 is 50% and traffic to application2_pod2 is 50%.

So it is strictly not round-robin, but eventually round-robin.

How service IP is converted to podIP ?

ServiceIP is virtualIP. PodIP is basically containerIP (associated with some running process). ServiceIP points to PodIPs in round-robin.

kube-proxy will write iptable rules like below in each node: (lets say there are 3 pods)

When destination is equal to serviceIP, then route to 

- PodIP1 with 33% probability, 
- PodIP2 with 33% probability and
- PodIP3 with 34% probability

In order to achieve this, kube-proxy will listen to service(basically endpoints) creation and updates from API server.

user_53059620

Check this section of official doc

kube-proxy runs in 3 different proxy mode:

  1. User space proxy mode
  2. iptables proxy mode
  3. IPVS proxy mode

The implementation detail are different, but generally speaking, kube-proxy manages connections to Services and Endpoints. And like a proxy should, it can redirect traffics not belong to its node to correct ones.

So...

1) Yes

2) The doc you refer to is specifically for GKE. If you check k8s official doc, you will find only kube-proxy in iptables mode chooses a backend at random., other mode will either use round-robin or user specified method to dispatch traffics.

user_50391170
Related