kubernetes service访问原理

k8s集群中有三类IP：

1:宿主机的物理网卡IP，好比192.168.255.*

2:cni建立的网卡的IP，好比172.16.*.*

3:虚拟的IP(即ClusterIP ，没法ping通，经过代理链接)，172.19.*.*

 

若是在任何一台机器上查看网卡name能看到那么多网卡。以下图。

eth0是真实的网卡：IP段192.168.255.*

cni是k8s为了扁平化管理pod而建立的网卡，这里是172.16.1.1 那么其余节点可能就是172.16.2.1，172.16.3.1

其余看到不少veth的网卡其实是跟cni网卡相连的。一个veth就表明一个pod，因此这个节点的pod ip就是172.16.1.*

不一样节点的pod好比172.16.2.5->172.16.1.3是直接能够访问，底层实现的方式（隧道技术）能够不用太关注。

 

pod自己是没有状态的。也就是pod重启以后他的ip就发生了变化，因此这里引入了一个service做为服务访问的目标，service ip也是虚拟出的一个东西，好比起了一个nginx的pod，它关联了一个叫my-nginx的服务，那么如下是访问的一个流程。

 

 1：任何一个pod访问my-nginx

2：从/etc/resolv.conf中配置的DNS服务器获取cluster ip地址。能够看到172.19.0.10这个做为DNS服务器，在集群安装的时候已经固定好了，在建立应用的时候会自动写入service 和cluster ip这样一个映射关系，那么pod就得到了my-nginx的cluster ip

3：k8s会在每一个节点建立一个proxy的服务，由proxy建立iptable规则，固然在nginx建立的时候规则以及建立好了，当pod链接culster ip的时候就会被转发到nginx pod的ip，因此你经过service +port的形式链接有效，可是直接ping service是没法ping通的，iptable只实现的tcp/udp的转发