如果大家已经使用了 kubernetes技术，并运行了一些测试或生产的服务，可能已经能体会到 K8s 技术带来的革命性变化，如果还没有用过的小伙伴，我建议尽快入坑，毕竟这是技术趋势。
目前尽管已经有很多工具可以用来设置和管理集群，但我们仍然需要知道在k8s底层发生了什么，尤其在碰到问题时，只有知道到底层原理才有可能从某个现象去分析到底是哪里出了问题，才能去解决实际问题。
从技术上说 Kubernetes 其实在底层它是非常复杂的，它有很多组件，因此，必须了解它们如何相互配合并协同工作，才能实际去理解实际中的问题，那说到这里，不得不说K8s的网络是最复杂且最关键之一。
因此，这篇我们通过图文来深入理解 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中。
同样，每个Pod都有其自己的网络，并且有一个虚拟以太网对将其连接到根网络。这基本上是一个管道对，一端在根网中，另一端在pod网中。
我们将Pod-end命名为eth0，因此Pod不了解底层主机，并认为它具有自己的根网络设置。另一端的名称类似于vethxxx。
可以使用ifconfig或ip a命令在节点上列出所有这些接口。
对节点上的所有Pod完成此操作。为了使这些Pod相互通信，使用了Linux以太网桥cbr0。Docker使用了一个类似的桥，名为docker0。
可以使用brctl show命令列出网桥。
假设一个数据包从pod1到pod2。
它将pod1的网络保留在eth0处，并将根网络保留在vethxxx。
将其传递给cbr0，后者使用ARP请求发现目的地，并说“谁拥有此IP？”
vethyyy说它具有该IP，因此网桥知道将数据包转发到何处。
数据包到达vethyyy，穿过管道对并到达pod2的网络。
这就是节点上的容器相互通信的方式。显然还有其他方法，但这可能是最简单的方法.
节点间通讯
正如之前提到的，pod也必须在节点之间可访问。Kubernetes并不关心它是如何完成的。我们可以使用L2（跨节点的ARP），L3（跨节点的IP路由-如云提供商路由表）覆盖网络。只要流量可以到达另一个节点上所需的Pod，这都没有关系。每个节点都为Pod IP分配了唯一的CIDR块（一系列IP地址），因此每个Pod具有一个唯一的IP，该IP与另一个节点上的Pod不冲突。
在大多数情况下，尤其是在云环境中，云提供商路由表可确保数据包到达正确的目的地。通过在每个节点上设置正确的路由，可以完成同一件事。还有许多其他的网络插件也可以发挥自己的作用。
在这里，我们有两个节点，类似于我们之前看到的。每个节点都有各种网络名称空间，网络接口和网桥。
假设一个数据包从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
