Kubernetes从懵圈到熟练：集群服务的三个要点和一种实现

在过滤器框架一节，我们看到netfilter是一个过滤器框架。netfilter在数据“管到”上切了5个口，分别在这5个口上，做一些数据包处理工作。虽然固定切口位置以及网络包处理方式分类已经极大的优化了过滤器框架，但是有一个关键的问题，就是我们还是得在管道上做修改以满足新的功能。换句话说，这个框架没有做到管道和过滤功能两者的彻底解耦。

为了实现管道和过滤功能两者的解耦，netfilter用了表这个概念。表就是netfilter的过滤中心，其核心功能是过滤方式的分类(表)，以及每种过滤方式中，过滤规则的组织(链)。

把过滤功能和管道解耦之后，所有对数据包的处理，都变成了对表的配置。而管道上的5个切口，仅仅变成了流量的出入口，负责把流量发送到过滤中心，并把处理之后的流量沿着管道继续传送下去。

如上图，在表中，netfilter把规则组织成为链。表中有针对每个管道切口的默认链，也有我们自己加入的自定义链。默认链是数据的入口，默认链可以通过跳转到自定义链来完成一些复杂的功能。这里允许增加自定义链的好处是显然的。为了完成一个复杂过滤功能，比如实现Kubernetes集群节点的反向代理，我们可以使用自定义链来模块化我们规则。

用自定义链实现服务的反向代理

集群服务的反向代理，实际上就是利用自定义链，模块化地实现了数据包的DNAT转换。KUBE-SERVICE是整个反向代理的入口链，其对应所有服务的总入口;KUBE-SVC-XXXX链是具体某一个服务的入口链，KUBE-SERVICE链会根据服务IP，跳转到具体服务的KUBE-SVC-XXXX链;而KUBE-SEP-XXXX链代表着某一个具体Pod的地址和端口，即endpoint，具体服务链KUBE-SVC-XXXX会以一定算法(一般是随机)，跳转到endpoint链。

而如前文中提到的，因为这里需要做的是DNAT，即改变目的地址，这样的修改，必须在路由之前发生以保证数据包可以被路由正确处理。所以KUBE-SERVICE会被PREROUTING和OUTPUT两个默认链所调用。

总结

通过这篇文章，大家应该对Kubernetes集群服务的概念以及实现，有了更深层次的认识。我们基本上需要把握三个要点。一、服务本质上是负载均衡;二、服务负载均衡的实现采用了与服务网格类似的Sidecar的模式，而不是LVS类型的独占模式;三、kube-proxy本质上是一个集群控制器。除此之外，我们思考了过滤器框架的设计，并在此基础上，理解使用iptables实现的服务负载均衡的原理。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!