11.5 服务是如何实现的
在第5 章中学习过Service,Service允许长时间对外暴露一系列pod、稳定的IP地址以及端口。为了聚焦Service的目的以及它们如何被使用，我们当时并没有深入探究其工作原理。但是，要真正理解服务，并更好地了解当事情的行为与预期不一致时应该从哪着手，就需要了解服务的实现原理。
11.5.1 引入kube-proxy
和Service相关的任何事情都由每个节点上运行的kube-proxy进程处理。开始的时候，kube-proxy确实是一个proxy，等待连接，对每个进来的连接，连接到一个pod。这称为userspace（用户空间）代理模式。后来，性能更好的iptables代理模式取代了它。iptables代理模式目前是默认的模式，如果你有需要也仍然可以配置Kubernetes使用旧模式。
在我们继续之前，先快速回顾一下Service的几个知识点，对理解下面几段有帮助。
我们之前了解过，每个Service有其自己稳定的IP地址和端口。客户端（通常为pod）通过连接该IP和端口使用服务。IP地址是虚拟的，没有被分配给任何网络接口，当数据包离开节点时也不会列为数据包的源或目的IP地址。Service的一个关键细节是，它们包含一个IP、端口对（或者针对多端口Service有多个IP、端口对），所以服务IP本身并不代表任何东西。这就是为什么你不能够ping它们。
11.5.2 kube-proxy 如何使用iptables
当在API服务器中创建一个服务时，虚拟IP地址立刻就会分配给它。之后很短时间内，API服务器会通知所有运行在工作节点上的kube-proxy客户端有一个新服务已经被创建了。然后，每个kube-proxy都会让该服务在自己的运行节点上可寻址。原理是通过建立一些iptables规则，确保每个目的地为服务的IP/端口对的数据包被解析，目的地址被修改，这样数据包就会被重定向到支持服务的一个pod。
除了监控API对Service的更改，kube-proxy也监控对Endpoint对象的更改。我们在第5章讨论过，下面回顾一下，因为你基本上不会去手动创建它们，所以比较容易忘记它们的存在。Endpoint对象保存所有支持服务的pod的IP/端口对（一个IP/端口对也可以指向除pod之外的其他对象）。这就是为什么kube-proxy必须监听所有Endpoint对象。毕竟Endpoint对象在每次新创建或删除支持pod时都会发生变更，当pod的就绪状态发生变化或者pod的标签发生变化，就会落入或超出服务的范畴。
现在让我们了解一下kube-proxy如何让客户端能够通过Service连接到这些pod，如图11.17所示。
图11.17 发送到服务虚拟IP/端口对的网络包会被修改、重定向到一个随机选择的后端pod
图中描述kube-proxy做了什么，以及数据包如何通过客户端pod发送到支持服务的一个pod上。让我们检查一下当通过客户端pod（图中的pod A）发送数据包时发生了什么。
包目的地初始设置为服务的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。
实际上可能比描述的要更复杂一点儿，但是上述内容是你需要理解的最重要的内容。
