Kubernetes

Kubernetes网络模型

Kubernetes Networking 的核心是一种重要的基本设计理念:
每个Pod都有唯一的IP。
此 Pod IP 由该Pod中的所有容器共享,并且可以与所有其他Pod路由。是否曾经注意到Kubernetes节点上运行着一些“暂停”容器?它们被称为“沙盒容器”,其唯一的工作就是保留和保存由Pod中的所有容器共享的网络名称空间(netns)。这样,即使容器死亡,并且在其位置创建了一个新容器,容器IP也不会改变。这种按单机IP模式的巨大好处是与基础主机之间没有IP或端口冲突。而且,不必担心应用程序使用哪个端口。
有了这个,Kubernetes 唯一的要求就是,这些Pod IP可以从其他所有Pod进行路由/访问,而不管它们位于哪个节点上。

节点内通信

第一步是确保同一节点上的Pod能够互相通信。然后将该思想扩展到跨节点,到Internet等的通信。
在每个Kubernetes节点(在本例中为Linux机器)上,都有一个根网络名称空间(根为基础,而不是超级用户)-root netns。
主网络接口eth0在此根netns中。
2021-12-27-10-32-22-128866.png
同样,每个Pod都有其自己的网络,并且有一个虚拟以太网对将其连接到根网络。这基本上是一个管道对,一端在根网中,另一端在pod网中。
将Pod-end命名为eth0,因此Pod不了解底层主机,并认为它具有自己的根网络设置。另一端的名称类似于vethxxx。
可以使用ifconfig或ip a命令在节点上列出所有这些接口。
2021-12-27-10-32-22-382052.png
对节点上的所有Pod完成此操作。为了使这些Pod相互通信,使用了Linux以太网桥cbr0。Docker使用了一个类似的桥,名为docker0。
可以使用brctl show命令列出网桥。
2021-12-27-10-32-23-000354.png
假设一个数据包从pod1到pod2。
它将pod1的网络保留在eth0处,并将根网络保留在vethxxx。
将其传递给cbr0,后者使用ARP请求发现目的地,并说“谁拥有此IP?”
vethyyy说它具有该IP,因此网桥知道将数据包转发到何处。
数据包到达vethyyy,穿过管道对并到达pod2的网络。
Kubernetes 的底层网络 - 图4
这就是节点上的容器相互通信的方式。显然还有其他方法,但这可能是最简单的方法.

节点间通讯

正如之前提到的,pod也必须在节点之间可访问。Kubernetes并不关心它是如何完成的。可以使用L2(跨节点的ARP),L3(跨节点的IP路由-如云提供商路由表)覆盖网络。只要流量可以到达另一个节点上所需的Pod,这都没有关系。每个节点都为Pod IP分配了唯一的CIDR块(一系列IP地址),因此每个Pod具有一个唯一的IP,该IP与另一个节点上的Pod不冲突。
在大多数情况下,尤其是在云环境中,云提供商路由表可确保数据包到达正确的目的地。通过在每个节点上设置正确的路由,可以完成同一件事。还有许多其他的网络插件也可以发挥自己的作用。
在这里,有两个节点,类似于之前看到的。每个节点都有各种网络名称空间,网络接口和网桥。
Kubernetes 的底层网络 - 图5
假设一个数据包从pod1到pod4(在另一个节点上)。
它将pod1的网络保留在eth0处,并将根网络保留在vethxxx。
它传递给cbr0,后者发出ARP请求以查找目的地。
它从cbr0传到主网络接口eth0,因为此节点上没有人具有pod4的IP地址。
它将离开node1,这时候src = pod1和dst = pod4。
路由表具有为每个节点CIDR块设置的路由,并且将数据包路由到其CIDR块包含pod4 IP的节点。
因此,数据包到达主网络接口eth0的node2。现在,即使pod4不是eth0的IP,由于已将节点配置为启用IP转发,因此数据包仍转发到cbr0。在节点的路由表中查找与pod4 IP匹配的所有路由。它找到cbr0作为此节点的CIDR块的目标。可以使用route -n命令列出节点路由表.
桥接器接收数据包,发出ARP请求,然后发现IP属于vethyyy。
数据包穿过管道对并到达pod4