Kubernetes Service Access principle

There are three types of IP in the k8s cluster:

1: Host's physical NIC IP, e.g. 192.168.255.*

2:CNI the IP of the network card created, such as 172.16.*.*

3: Virtual IP (i.e. Clusterip, cannot ping through, connect via proxy), 172.19.*.*

If you view the network card on any one machine name can see so many network cards. Such as.

Eth0 is the real network card: IP segment 192.168.255.*

The k8s is a network card created to flatten the pod management, and this is 172.16.1.1 so other nodes may be 172.16.2.1,172.16.3.1

Other network cards that see many veth are actually connected to the network card. A veth represents a pod, so the pod IP of this node is 172.16.1.*

Pods of different nodes, such as 172.16.2.5->172.16.1.3, are directly accessible, and the underlying implementation (tunneling technology) can be used without much attention.

The pod itself is stateless. That is, after the pod restart, his IP has changed, so the introduction of a service as the target of services access, the service IP is also a virtual thing, such as a nginx pod, it associated with a service called My-nginx, Then here is a process for access.

1: Any one pod access My-nginx

2: Obtain the cluster IP address from the DNS server configured in/etc/resolv.conf. Can see 172.19.0.10 this as a DNS server, when the cluster installation has been fixed, when the application is created automatically write service and cluster IP such a mapping relationship, then the pod gets my-nginx cluster IP

3:k8s will create a proxy service at each node, created by proxy iptable rules, of course, when Nginx created the rules and created, when the pod connection Culster IP will be forwarded to the Nginx pod IP, So you connect through the service +port, but the direct ping service is not ping, iptable only implement TCP/UDP forwarding

Kubernetes Service Access principle