Pod
首先来回顾一下Pod：
Pod 是用于构建应用程序的最小可部署对象。单个 Pod 代表集群中正在运行的工作负载，并封装一个或多个 Docker 容器、任何所需的存储以及唯一的 IP 地址。
Kuber***es 网络模型
集群中每一个 Pod 都会获得自己的、 独一无二的 IP 地址。一个Pod里的一组容器共享相同的IP地址。
Kuber***es 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）：
- Pod 能够与所有其他节点上的 Pod 通信， 且不需要网络地址转译（NAT）
- 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信。
考虑到这些限制，我们剩下四个不同的网络问题需要解决：
- 容器到容器网络
- Pod 到 Pod 网络
- Pod 到服务网络
- 互联网到服务网络
同一Pod上的容器之间进行通信
通常，我们将虚拟机中的网络通信视为直接与以太网设备交互。默认情况下，Linux 将每个进程分配给根网络命名空间，以提供对外部世界的访问。如下图所示：
Pod 被建模为一组共享网络命名空间的 Docker 容器。Pod 中的容器都具有通过分配给 Pod 的网络命名空间分配的相同 IP 地址和端口空间，并且可以通过 localhost 找到彼此，因为它们驻留在同一命名空间中。
根本原因是使用Docker的一种网络模型：–***=container 能够让同一个Pod内的多个docker容器相互通信。
container模式指定新创建的Docker容器和已经存在的一个容器共享一个网络命名空间，也就是说新创建的Docker容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。
在k8s中每个Pod容器有一个pause容器，它拥有独立的网络命名空间，在Pod内启动Docker容器时候使用 –***=container就可以让当前Docker容器加入到Pod容器拥有的网络命名空间（pause容器）。
同一Node上的不同Pod之间进行通信
从 Pod 的角度来看，它存在于自己的以太网命名空间中。不同的Pod存在于不同的网络命名空间里。
但是可以使用Linux虚拟以太网设备或由两个虚拟接口组成的veth对 将两个网络命名空间进行连接 。要连接 Pod 命名空间，我们可以将 veth 对的一侧分配给根网络命名空间，将另一侧分配给 Pod 的网络命名空间。然后使用网桥把两个虚拟网络组成为一个以太网。如下图所示：
在上面这个网络模型下，Pod之间是如何通信的呢？
- Pod 1 向其自己的以太网设备发送数据包eth0，该设备可作为 Pod 的默认设备。对于 Pod 1，eth0通过虚拟以太网设备连接到根命名空间veth0
- 网桥cbr0配置有veth0连接到它的网段。一旦数据包到达网桥，网桥就会使用 ARP 协议解析将数据包发送到的正确网段
- 当数据包到达虚拟设备veth1时，它会直接转发到 Pod 2 的命名空间以及该命名空间内的设备eth0
不同Node上的Pod之间进行通信
同样会用到虚拟接口和网桥。
- 数据包首先通过 Pod 1 的以太网设备发送，该设备与根命名空间 中的虚拟以太网设备配对。最终，数据包到达根命名空间的网桥
- ARP 将在网桥处失败，因为没有设备连接到具有数据包正确 MAC 地址的网桥。发生故障时，网桥将数据包从默认路由（根命名空间的eth0设备）发送出去。此时，路由离开节点并进入网络
- 我们现在假设网络可以根据分配给节点 的 CIDR 块将数据包路由到正确的节点。数据包进入目标节点（在 VM 2 上）的根命名空间eth0，并通过网桥路由到正确的虚拟以太网设备
- 最后，路由通过驻留在 Pod 4 命名空间内的虚拟以太网设备对完成
一般来说，每个节点都知道如何将数据包传递到在其内运行的 Pod。一旦数据包到达目标节点，数据包的流动方式与在同一节点上的 Pod 之间路由流量的方式相同。
Service
我们要知道，Pod的IP地址不持久，会随着扩展或缩小、应用程序崩溃或节点重启而出现和消失。哪怕重启一个Pod，它的IP也可能和前一次不一样。
所以Kuber***es 里使用Service来管理一组 Pod 的状态，允许我们跟踪一组随时间动态变化的 Pod 的IP 地址。Service充当 Pod 的抽象，并将单个虚拟 IP 地址分配给一组 Pod 的IP 地址。
任何发送到服务虚拟 IP 的流量都将被路由到与该虚拟 IP 关联的 Pod 集。这允许与 Service 关联的 Pod 集随时更改 ，只要虚拟IP不改，客户端就感觉不到Pod的变化。
创建新的 Kuber***es Service时，系统会创建一个新的虚拟 IP（也称为集群 IP）。集群内的任何位置，寻址到虚拟 IP 的流量都将负载均衡到与Service关联的一组Pod。实际上，Kuber***es 会自动创建并维护一个分布式集群内负载均衡器，该均衡器将流量分配到Service关联的健康 Pod。
参考
https://sookocheff.***/post/kuber***es/understanding-kuber***es-***working-model/
https://kuber***es.io/zh-***/docs/concepts/services-***working/
