就像k8s中的其他东西一样，service只是一个资源，一个中央数据库中的记录。它描述了如何配置一些程序来做一些事情。事实上，service会影响集群中多个组件的配置和行为，但这里最重要的是kube-proxy。根据名称，很多人可能对这个组件的作用有个大概的了解，但是 kube-proxy 的一些特性使它与haproxy或linkerd等典型的反向代理有很大的不同。
代理的一般的行为是通过两个打开的连接在客户端和服务器之间传递流量。
客户端向内连接到服务端口，而代理向外连接到一个服务器。由于所有这类代理都在用户空间运行，这意味着数据包在每次通过代理时都会被编入用户空间并返回到内核空间。
最初kube-proxy也是作为这样的用户空间代理实现的，但有一个变化。代理需要一个接口，用于监听客户端连接，并用于连接到服务器。在一个节点上可用的唯一接口可能是：
- 主机接口
- Pod网络上的虚拟接口
为什么不在这些网络中使用一个地址呢?
我不了解内部一些原因，但我想在项目的早期这样做会使网络的路由规则变得复杂，这些网络是为满足pod和节点的需要而设计的，而它们在集群中都只是短暂的实体。
service显然需要它们自己的、稳定的、不冲突的网络地址空间，而一个虚拟ip系统才是有效的而且可以自由控制。然而，正如我们所注意到的，在这个网络上没有实际的设备。你可以在路由规则、防火墙过滤器等中使用虚拟网络，但你不能实际监听端口或通过不存在的接口打开一个连接。
k8s使用linux内核的一个名为 netfilter 的特性和一个名为 iptables 的用户空间接口来解决这个问题。
在这篇已经很长的文章(加上上个部分)中没有足够的篇幅来详细说明这是如何工作的。如果你想了解更多，netfilter官网 是一个很好的开始。
以下是一个基于规则的包处理引擎。它在内核空间中运行，并在它生命周期的不同时刻查看每个包。它根据规则匹配数据包，当它发现匹配的规则时，它采取指定的操作。它可以采取的众多操作之一是将数据包重定向到另一个目的地。
没错，netfilter是一个内核空间代理。下面演示了kube-proxy作为用户空间代理运行时netfilter所扮演的角色。
在这种模式下，kube-proxy 在本地主机接口上打开一个端口(在上面的示例中是10400)，用来监听对test-service的请求，插入netfilter规则，将目的地为服务IP的数据包重新路由到它自己的端口，并将这些请求转发到端口8080上的pod。这就是对10.3.241.152:80的请求神奇地变成对10.0.2.2:8080的请求的原因。
考虑到netfilter的功能，kube-proxy需要打开一个端口，并为该服务插入正确的netfilter规则，这是为了响应来自主api服务器的集群更改。
这个故事还有一个小插曲。我在上面提到过，由于封送数据包，用户空间代理非常昂贵。在k8s 1.2中，kube-proxy获得了在iptables模式下运行的能力。在这种模式下，kube-proxy基本上不再是集群间连接的代理，而是委托netfilter来检测绑定到服务ip的数据包并将它们重定向到pods，所有这些工作都在内核空间中进行。在这种模式下，kube-proxy的工作或多或少受限于保持netfilter规则同步。
总结
最后，让我们将上面描述的与文章开头对可靠代理的要求进行比较。service代理系统是否持久?
- 默认情况下，kube-proxy作为一个systemd单元运行，所以如果它失败了，它将被重新启动。
- 在谷歌容器引擎中，它作为一个pod运行，由一个daemonset控制。
- 作为一个用户空间代理，kube-proxy 仍然是一个单点连接故障。
- 当以iptables模式运行时，从本地pod尝试连接的角度来看，系统具有很高的持久性，因为如果节点处于启动状态，netfilter也会处于启动状态。
第二个问题：service代理是否知道有可以处理请求的健康服务器pod？
如上所述，kube-proxy监听主api服务器以获取集群中的更改，其中包括对服务和point的更改。
- 当它接收更新时，它使用iptables来保持netfilter规则同步。
- 当创建一个新服务并填充其端点时，kube-proxy获得通知并创建必要的规则。
- 类似地，它在删除服务时删除规则。对端点的健康状况检查由kubelet执行，kubelet是在每个节点上运行的另一个组件，当发现不健康的端点时，kubelet通过api服务器通知kube-proxy，并编辑netfilter规则删除该端点，直到它再次恢复健康。
本文正在参与 “网络协议必知必会”征文活动
