Kubernetes研究：图解Kubernetes网络

您已经在库本内斯集群中运行了一系列服务并从中受益，或者您正在计划这样做。虽然有一系列工具可以帮助您构建和管理集群，但是您仍然对集群的底层如何工作以及如何处理出现的问题感到困惑。我以前是这样的。

诚然库本涅斯对初学者来说很简单，但是我们仍然不得不承认它的底层实现是极其复杂的。Kubernetes由许多成分组成。如果你想为失败场景做好准备，你必须知道组件是如何协同工作的。网络是最复杂甚至最关键的组件之一。所以我开始确切了解库本涅斯是如何工作的。我读了很多文章，读了很多演讲，甚至浏览了代码库。这是我得到的。

Kubernetes网络模型的核心点是Kubernes网络有一个重要的基本设计原则:每个Pod都有一个独特的IP。此容器知识产权由容器内的所有容器共享，所有其他容器都可以路由到容器。您是否注意到一些“暂停”容器正在您的库本内节点上运行？

它们被称为“沙箱容器”。他们唯一的任务是保持和持有一个网络命名空间(netns)，它由Pod中的所有容器共享。

这样，即使容器死亡，并且创建了一个新的容器来替换容器，容器知识产权也不会改变。这种每机架IP模型的最大优势是机架和底层主机之间不会有IP或端口冲突。我们不必担心应用程序使用哪个端口。满足这一要求后，库本内斯唯一的要求是所有其他PODs都可以访问这些Pod IP，而不管这些PODs在哪个节点上。

节点内通信的第一步是确保同一节点上的Pod可以相互通信，然后可以扩展到跨节点通信、互联网通信等。

kubernetesnode(根网络命名空间)在每个kubernesnode(这个场景指的是一台Linux机器)上，都有一个根命名空间(根被用作引用，而不是超级用户)-根网络。最重要的网络接口eth0在这个根网络下。

kubernetnode (Pod网络名称空间)同样，每个Pod都有自己的网络，通过虚拟以太网对连接到根网络。这基本上是一对管子，一端在根网中，另一端在荚网中。我们称Pod端的网络接口为eth0，所以Pod不需要知道底层主机，它认为自己有根网络设备。例如，另一端叫做vethxxx。您可以使用ifconfig或ip a命令列出节点上的所有这些接口。

KubernetsNode(Linux Netwbridge)节点上的所有PODs都完成了这个过程。为了让这些PODs相互通信，将使用linux的以太网桥cbr0。Docker使用一个类似的桥，叫做docker0。您可以使用brctl show命令列出所有桥。

kubernetonde(same node pod到pod通信)假设网络数据包从pod1到pod2。

它从pod1中netns的eth0端口离开，并通过vethxxx进入根netns。

然后被传递给cbr0，CBR 0使用ARP请求说“谁拥有这个IP”来找到目标地址。

vethyyy说它有这个IP，所以网桥知道把数据包转发到哪里。

数据包到达vethyyy，穿过管道对，到达pod2的netns。这是同一节点中内容设备之间的通信流。

当然，还有其他方法，但这无疑是最简单的方法，也是码头工人使用它的方法。节点间通信正如我前面提到的，Pod也需要跨节点可达。Kubernetes不关心它是如何实现的。我们可以使用L2(节点间ARP)、L3(节点间IP路由，如云提供商的路由表)、覆盖网络，甚至信鸽。没关系，只要流量可以到达另一个节点的预期Pod。每个节点为Pod IPs分配一个唯一的CIDR块(一系列的IP地址)，因此每个Pod都有一个唯一的IP，并且不会与其他节点上的Pod冲突。在大多数情况下，尤其是在云环境中，云提供商的路由表确保数据包到达正确的目的地。我们可以通过在每个节点上建立正确的路由来实现相同的目标。许多其他网络插件以自己的方式实现了这个目标。

这里我们有两个节点，类似于我们之前看到的。每个节点都有不同的网络名称空间、网络接口和网桥。

具有路由表的Kubernetes节点(跨节点pod到pod通信)假设数据包将从pod1到达pod4(在不同的节点上)。它从pod1网络的eth0端口离开，通过vethxxx进入根网络。然后，它被传递给cbr0，CBR 0通过发送ARP请求找到目标地址。

此节点上没有Pod的IP地址为pod4，因此数据包从cbr0传输到主网络接口eth0。数据包的源地址是pod1，目的地址是pod4。它离开节点1，以这种方式进入电缆。路由表中有每个节点的CIDR块的路由设置，它将数据包路由到CIDR块包含pod4 IP的节点。因此，数据包到达节点2的主网络接口eth0。现在，即使pod4不是eth0的IP，数据包仍然可以被转发到cbr0，因为节点被配置为启用了IP转发。该节点的路由表查找任何与pod4 IP相匹配的路由。发现cbr0是该节点的CIDR块的目标地址。您可以使用route -n命令列出该节点的路由表。它将显示cbr0的路由，类型如下:

bridge接收数据包，发送ARP请求，发现目标IP属于vethyyy。数据包通过管道对到达pod4。这是库本内斯网络的基础。下次遇到问题时，一定要先检查这些网桥和路由表。之前我们谈到了库本内斯的网络模型。

我们观察了数据包如何在同一节点上的PODs之间以及跨节点的PODs之间流动。我们还注意到了Linux网桥和路由表在这个过程中的作用。现在我们将进一步阐述这些概念以及覆盖网络是如何工作的。我们还将了解库本内斯不断变化的Pod是如何从运行的应用程序中抽象出来并在幕后处理的。

覆盖网络默认情况下不需要覆盖网络，但它们在特定情况下非常有用。例如，当我们没有足够的知识产权空间，或者网络不能处理额外的路由，或者当我们需要叠加提供一些额外的管理功能时。常见的情况是云提供商的路由表可以处理有限数量的路由。例如，AWS路由表可以支持多达50条路由，而不会影响网络性能。因此，如果我们有超过50个库本内节点，AWS路由表将是不够的。在这种情况下，使用覆盖网络将有助于我们。

本质上，覆盖是将另一层数据包封装在跨节点的本地网络数据包中。您可能不想使用覆盖网络，因为封装和解封装所有消息会导致延迟和复杂性开销通常这是不必要的，所以我们应该只在知道为什么需要它的时候使用它。

为了了解覆盖网络中流量的流向，我们以CoreOS开源项目法兰绒为例。

kubernetonde with route table(cross node pod-to-pop traffic flow with francow overlay network ),这里我们注意到它与我们之前看到的设施相同，只是在根网络中添加了一个名为flannel0的虚拟以太网设备。它是虚拟可扩展局域网(VXLAN)的一个实现，但在Linux上，它只是另一个网络接口。数据包从pod1到pod4(在不同节点)的流向如下所示:

1。它离开pod1网络的eth0端口，通过vethxxx进入根网络。

2，然后传递给cbr0，CBR 0通过发送ARP请求找到目标地址。

4，数据包离开节点时，将节点的IP信息作为源地址和目的地址。

5。云提供商的路由表已经知道如何在节点之间发送消息，因此消息被发送到目标地址节点2。

A.数据包到达节点2的eth0网卡。由于目标端口是特定的VXLAN端口，内核将消息发送到flannel0。B flannel0解封装消息并将其发送到根命名空间。从现在开始，消息的路径与我们在第1部分前面看到的非覆盖网络一致。由于IP转发开启，内核根据路由表将消息转发给cbr0。