17 庖丁解牛：kube-proxy

整体概览

在第 3 节中，我们了解到 kube-proxy 的存在，而在第 7 中，我们学习到了如何将运行于 K8S 中的服务以 Service 的方式暴露出来，以供访问。

本节，我们来介绍下 kube-proxy 了解下它是如何支撑起这种类似服务发现和代理相关功能的。

kube-proxy 是什么

kube-proxy 是 K8S 运行于每个 Node 上的网络代理组件，提供了 TCP 和 UDP 的连接转发支持。

我们已经知道，当 Pod 在创建和销毁的过程中，IP 可能会发生变化，而这就容易造成对其有依赖的服务的异常，所以通常情况下，我们都会使用 Service 将后端 Pod 暴露出来，而 Service 则较为稳定。

还是以我们之前的 SayThx 项目为例，但我们只部署其中没有任何依赖的后端资源 Redis 。

进入配置文件所在目录后，开始创建相关资源：

可以看到 Redis 正在运行，并通过 NodePort 类型的 Service 暴露出来，我们访问来确认下。

可以看到已经可以正常访问。接下来，我们来看下 31269 这个端口的状态。

可以看到该端口是由 kube-proxy 所占用的。

接下来，查看当前集群的 Service 和 Endpoint

可以很直观的看到 Endpoint 当中的便是 Pod 的 IP，现在我们将该服务进行扩容（实际情况下并不会这样处理）。

直接通过 kubectl scale 操作

查看 Endpoint 信息：

可以看到 Endpoint 已经自动发生了变化，而这也意味着 Service 代理的后端节点将增加一个。

kube-proxy 如何工作

kube-proxy 在 Linux 系统上当前支持三种模式，可通过 –proxy-mode 配置：

• userspace：这是很早期的一种方案，但效率上显著不足，不推荐使用。
• iptables：当前的默认模式。比 userspace 要快，但问题是会给机器上产生很多 iptables 规则。
• ipvs：为了解决 iptables 的性能问题而引入，采用增量的方式进行更新。

下面我们以 iptables 的模式稍作介绍。

以上输出已经尽量删掉了无关的内容。

当开始访问的时候先要经过 PREROUTING 链，转到 KUBE-SERVICES 链，当查询到匹配的规则之后，请求将转向 KUBE-SVC-SMQNAAUIAENDDGYQ 链，进而到达 KUBE-SEP-QX7VDAS5KDY6V3EV 对应于我们的 Pod。(注：为了简洁，上述 iptables 规则是部署一个 Pod 时的场景)

当搞懂了这些之后，如果你想了解这些 iptables 规则实际又是如何创建和维护的，那可以参考下 proxier 的具体实现，这里不再展开。

总结

本节中我们介绍了 kube-proxy 的主要功能和基本流程，了解到了它对于服务注册发现和代理访问等起到了很大的作用。而它在 Linux 下的代理模式也有 userspace，iptables 和 ipvs 等。

默认情况下我们使用 iptables 的代理模式，当创建新的 Service ，或者 Pod 进行变化时，kube-proxy 便会去维护 iptables 规则，以确保请求可以正确的到达后端服务。

当然，本节中并没有提到 kube-proxy 的 session affinity 相关的特性，如有需要可进行下尝试。

下节，我们将介绍实际运行着容器的 Docker，大致了解下在 K8S 中它所起的作用，及他们之间的交互方式。