服务是如何实现的

kube-proxy

和Service相关的任何事情都有每个节点上运行的kube-proxy进程处理。开始的时候，kube-proxy确实是一个proxy，等待连接，对每个进来的连接，连接到一个pod。这称为userspace（用户空间）代理模式。后来，性能更好的iptables代理模式取代了它。iptables代理模式目前是默认的模式。

每个Service有其自己稳定的IP地址和端口。客户端（通常为pod）通过连接该IP和端口使用服务。IP地址是虚拟的，没有被分配给任何网络接口，当数据包离开节点时也不会列为数据包的源或目的IP地址。Service的一个关键细节是，它们包含一个IP、端口对（或者针对多端口Service有多个IP、端口对），所以服务IP本身并不代表任何东西。这就是为什么你不能够ping它们。

kube-proxy如何使用iptables

当API服务器中创建一个服务时，虚拟IP地址立刻就会分配给它。之后很短时间内，API服务器会通知所以运行在工作节点上的kube-proxy客户端有一个新服务已经被创建了。然后，每个kube-proxy都会让该服务在自己的运行节点上可寻址。原理是通过简历一些iptables规则，确保每个目的地为服务的IP/端口对的数据包被解析，目的地址被修改，这样数据包就会被重定向到支持服务的一个pod。

除了监控API对service的更改，kube-proxy也监控对endpoint对象的更改。

endpoint对象保存所有支持服务的pod的IP/端口对（一个IP/端口对也可以指向除pod之外的其他对象）。这就是为什么kube-proxy必须监听所有endpoint对象。毕竟endpoint对象在每次新创建或删除支持pod时都会发生变更，当pod的就绪状态发生变化或者pod的标签发生变化，就会落入或超出服务的范畴。

kube-proxy如何让客户端能够通过Service连接到这些pod。

包目的地初始设置为服务的IP和端口（在本例中，Service是在172.30.0.1:80）。发送到网络之前，节点A的内核会根据配置在该节点上的iptables规则处理数据包。

内核会检查数据包是否匹配任何这些iptables规则。其中有个规则规定如果有任何数据包的目的地IP等于172.30.0.1、目的地端口等于80，那么数据包的目的地IP和端口应该被替换为随机选中的pod的IP和端口。

本例中的数据包满足规则，故而它的IP/端口被改变了。在本例中，pod B2被随机选中了，所有数据包的目的地IP变更为10.1.2.1（pod B2的IP）,端口改为8080（Service中定义的目标端口）。就好像是，客户端pod直接发送数据包给pod B而不是通过Service。