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所示。