第6章简便的服务模子

程序员 · 2024-10-3 03:38:46

6.1 服务的本质是什么

K8s集群的服务，着实就是负载平衡或反向署理。这跟阿里云的负载平衡有很多类似的地方、和负载平衡一样，服务有它的IP所在以及前端端口，同时服务反面会挂载多个容器组作为其“后端服务器”，这些“后端服务器”有自己的IP所在以及监听端口。如下图所示。

当如许的负载平衡和后端的架构与K8s集群联合的时间，我们可以想到的最直观的实现方式，就是集群中某一个节点专门做负载平衡（类似Linux假造服务器）的脚色，见图6-2，而其他节点则用来承载后端容器组。

如许的实现方法有一个巨大的缺陷，就是单点题目。K8s集群是Google多年来主动化运维实践的结晶，如许的实现显然与其主动化运维的哲学背离。
6.2 自带通讯员

边车（sidecar）模式是微服务范畴的焦点概念。边车模式换一个平凡一点的说法，就是自带通讯员模式。如图6-3所示。
在K8s集群中，服务的实现实际上是为每一个集群节点部署了一个反向署理sidecar、而全部对集群服务的访问，都会被节点上的反向署理转换成对服务后端容器组的访问。根本上，节点和这些sidecar的关系如图6-4所示。

6.3 让服务照进实际

K8s集群的服务本质上是负载平衡，即反向署理；在具体实现中，这个反向署理，并不是部署在集群某一个节点上的，二是作为集群节点的sidecar部署在每个节点上的。
在这里让服务“照”进反向署理这个“实际”的，是K8s集群的一个控制器，即kube-proxy。简朴来说，kube-proxy作为部署在集群节点上的控制器，通过集群API Server监听着集群状态变革。当有新的服务被创建的时间，kube-proxy会把集群服务的状态、属性，翻译成反向署理的设置，整个过程如图6-5所示。
那剩下的题目就是反向署理（即图6-5中的proxy）的实现了
6.4 基于Netfilter的实现

K8s集群节点实现服务反向署理的方法现在紧张有三种，即userspace、iptables以及ipvs。本章以阿里云Flannel集群网络为范本，仅对基于iptables的服务实现做深入探究。
6.4.1 过滤器框架

Netfilter实际上是一个过滤器框架。Netfilter在网络包收发及路由的“管道”上，一共"切"开了5个扣，分别是PREROUTING、FORWARD、POSTROUTING、INPUT、以及OUTPUT，同时Netfilter界说了包罗NAT、Filter在内的多少个网络包处置处罚方式。NetFilter框架如图6-9所示。
须要注意的是，Routing和FORWARD很大步调上增长了以上Netfilter的复杂水平，如果我们不思量Routing和FORWARD，那么NetFilter就会变得和我们的水过滤框架一样简朴。
6.4.2 节点网络大图

参考图6-10所示的K8s集群节点网络全貌。横向来看，节点上的网络情况被分割成差异的网络定名空间，包罗主机网络定名空间和Pod网络定名空间；纵向来看，每个网络定名空间包罗完备的网络栈：从应用到协议栈，再到网络设备。
在网络设备这一层，我们通过cni0假造网桥组建出体系内部的一个假造局域网。Pod网络通过Veth对毗连到这个假造局域网内，cni0假造局域网通过主机路由以及网口eth0与外部通讯。
在网络协议栈这一层，我们可以通过在Netfilter过滤器框架上编程，来实现集群节点的反向署理。
实现反向署理，归根结底就是做DNAT，即把发送给集群服务IP所在和端口的数据包，修改成发给具体容器组的IP所在和端口。参考图6-9中的Netfilter过滤器框架。在Netfilter里，可以通过在PREROUTING、OUTPUT以及POSTROUTING三个位置参加NAT规则，来改变数据包的源所在或目标所在。
由于这里须要做的是DNAT，须要改变目标所在，如许的修改必须在路由（Routing）之前发生以包管数据包可以被路由准确处置处罚，以是实现反向署理的规则，须要被加到PREROUTING和OUTPUT两个位置。
此中，PREROUTING的规则用来处置处罚从Pod访问服务的流量。数据包从Pod网络Veth发送到cni0之后，进入主机协议栈，起首会颠末Netfilter PREROUTING的处置处罚，以是发送给服务的数据包，会在这个位置做DNAT。颠末DNAT处置处罚之后，数据包的目标所在酿成另一个Pod的所在，从而颠末主机路由转发到eth0，发送给准确的集群节点。
而添加在OUTPUT这个位置的DNAT规则，则用来处从主机网络发给服务的数据包，原理也是类似的，即在颠末路由之前修改目标所在，以方便路由转发。
6.4.3 升级过滤器框架

在"过滤器框架"一节，我们看到Netfilter是一个过滤器框架。Netfilter在数据“管道”上“切“了5个口，分别在这5个扣上做了一些数据包处置处罚工作。固然固定切口位置以及网络包处置处罚方式分类已经极大地优化了过滤器框架，但是有一个关键的题目，就是我们还须要再管道上做修改以满意新的功能。换句话说，这个框架没有做到管道和过滤功能两者的彻底解耦。
为了实现管道和过滤功能两者的解耦，Netfilter用了表的概念，表就是Netfilter的过滤中央，其焦点功能是过滤方式的分类（表），以及每种过滤方式中过滤规则的构造（链），如图6-11所示。
把管道和过滤功能解耦之后，全部对数据包的处置处罚都酿成了对表的设置。而管道上的5个切口，仅仅酿成了流量的收支口，负责把流量发送到过滤中央，并把处置处罚之后的流量沿着管道继续传送下去。
Netfilter把表中的规则构造成链。表中有针对每个管道切口的默认链，也有我们我们自己参加的自界说链。默认链是数据的入口，默认链可以通过跳转到自界说链来完成一些复杂的功能，比如实现K8s集群节点的反向署理，我们可以使用自界说链来使我们的规则模块化。
6.4.4 用自界说链实现服务的反向署理

集群服务的反向署理，实际上就是使用自界说链，模块化实现数据包的DNAT转换。KUBE-SERVICE是整个反向署理的入口链，其对应全部服务的总入口；KUBE-SVC-XXXX链是具体某一个服务的入口链。KUBE-SERVICE链会根据服务IP所在，跳转到具体服务的KUBE-SVC-XXXX链。KUBE-SEP-XXXX链代表着某一个具体Pod的所在和端口，即Endpoint，具体服务链KUBE-SVC-XXXXX会按照肯定的负载平衡算法跳转到Endpoint链，其团体布局如图6-12所示。

而如前面提到的，由于这里须要做的是DNAT，即改变目标所在，如许的修改必须在路由之前发生以包管数据包可以被路由准确处置处罚，以是KUBE-SERVICE会被PREROUTING和OUTPUT两个默认链所调用、
6.5总结

服务本质上是负载平衡
服务负载平衡的实现接纳了与服务网格类似的边车模式，而不是LVS范例的独占模式。
kube-proxy本质上是一个集群控制器。

第6章简便的服务模子

所属分类: 问答交流

新帖推荐: 30日

推荐作品

第6章 简便的服务模子

所属分类: 问答交流

新帖推荐: 30日

推荐作品

第6章简便的服务模子