共计 3255 个字符，预计需要花费 9 分钟才能阅读完成。
前言
K8s 是一个弱小的平台，但它的网络比较复杂，波及很多概念，例如 Pod 网络，Service 网络，Cluster IPs，NodePort，LoadBalancer 和 Ingress 等等，这么多概念足以让老手望而却步。然而，只有深刻了解 K8s 网络，能力为了解和用好 K8s 打下坚实基础。为了帮忙大家了解，模拟 TCP/IP 协定栈，我把 K8s 的网络合成为四个形象层，从 0 到 3，除了第 0 层，每一层都是构建于前一层之上，如下图所示：
第 0 层 Node 节点网络比拟好了解，也就是保障 K8s 节点 (物理或虚拟机) 之间可能失常 IP 寻址和互通的网络，这个个别由底层 (私有云或数据中心) 网络基础设施反对。第 0 层咱们假设曾经存在，所以不开展。第 1 到 3 层网络，我将分三篇文章，别离进行分析，本文是第一篇 Pod 网络。
留神，本文旨在帮忙大家建设 K8s 网络的概念模型，而不是对底层技术的准确形容。理论咱们学技术以利用为主，重要的是疾速建设起直观易懂的概念模型，可能领导咱们失常利用即可，当然了解肯定的技术细节也是有帮忙的。另外，本文假设读者对根本的网络技术，ip 地址空间和容器技术等有肯定的理解。
Pod 网络概念模型
Pod 相当于是 K8s 云平台中的虚拟机，它是 K8s 的根本调度单位。所谓 Pod 网络，就是可能保障 K8s 集群中的所有 Pods(包含同一节点上的，也包含不同节点上的 Pods)，逻辑上看起来都在同一个平面网络内，可能互相做 IP 寻址和通信的网络，下图是 Pod 网络的简化概念模型：
Pod 网络构建于 Node 节点网络之上，它又是下层 Service 网络的根底。为了进一步了解 Pod 网络，我将对同一节点上的 Pod 之间的网络，以及不同节点上的 Pod 之间网络，别离进行分析。
同一节点上的 Pod 网络
后面提到，Pod 相当于是 K8s 云平台中的虚拟机，理论一个 Pod 中能够住一个或者多个 (大多数场景住一个) 利用容器，这些容器共享 Pod 的网络栈和其它资源如 Volume。那么什么是共享网络栈？同一节点上的 Pod 之间如何寻址和互通？我以下图样例来解释：
上图节点上展现了 Pod 网络所依赖的 3 个网络设备，eth0 是节点主机上的网卡，这个是反对该节点流量出入的设施，也是反对集群节点间 IP 寻址和互通的设施。docker0 是一个虚构网桥，能够简略了解为一个虚构交换机，它是反对该节点上的 Pod 之间进行 IP 寻址和互通的设施。veth0 则是 Pod1 的虚构网卡，是反对该 Pod 内容器互通和对外拜访的虚构设施。docker0 网桥和 veth0 网卡，都是 linux 反对和创立的虚构网络设备。
上图 Pod1 外部住了 3 个容器，它们都共享一个虚构网卡 veth0。外部的这些容器能够通过 localhost 互相拜访，然而它们不能在同一端口上同时开启服务，否则会有端口抵触，这就是共享网络栈的意思。Pod1 中还有一个比拟非凡的叫 pause 的容器，这个容器运行的惟一目标是为 Pod 建设共享的 veth0 网络接口。如果你 SSH 到 K8s 集群中一个有 Pod 运行的节点下来，而后运行 docker ps，能够看到通过 pause 命令运行的容器。
Pod 的 IP 是由 docker0 网桥调配的，例如上图 docker0 网桥的 IP 是 172.17.0.1，它给第一个 Pod1 调配 IP 为 172.17.0.2。如果该节点上再启一个 Pod2，那么相应的调配 IP 为 172.17.0.3，如果再启动 Pod 可顺次类推。因为这些 Pods 都连在同一个网桥上，在同一个网段内，它们能够进行 IP 寻址和互通，如下图所示：
从上图咱们能够看到，节点内 Pod 网络在 172.17.0.0/24 这个地址空间内，而节点主机在 10.100.0.0/24 这个地址空间内，也就是说 Pod 网络和节点网络不在同一个网络内，那么不同节点间的 Pod 该如何 IP 寻址和互通呢？下一节咱们来剖析这个问题。
不同节点间的 Pod 网络
当初假如咱们有两个节点主机，host1(10.100.0.2)和 host2(10.100.0.3)，它们在 10.100.0.0/24 这个地址空间内。host1 上有一个 PodX(172.17.0.2)，host2 上有一个 PodY(172.17.1.3)，Pod 网络在 172.17.0.0/16 这个地址空间内。留神，Pod 网络的地址，是由 K8s 对立治理和调配的，保障集群内 Pod 的 IP 地址惟一。咱们发现节点网络和 Pod 网络不在同一个网络地址空间内，那么 host1 上的 PodX 该如何与 host2 上的 PodY 进行互通？
实际上不同节点间的 Pod 网络互通，有很多技术实现计划，底层的技术细节也很简单。为了简化形容，我把这些计划大体分为两类，一类是路由计划，另外一类是笼罩 (Overlay) 网络计划。
如果底层的网络是你能够管制的，比如说企业外部自建的数据中心，并且你和运维团队的关系比拟好，能够采纳路由计划，如下图所示：
这个计划简略了解，就是通过路由设施为 K8s 集群的 Pod 网络独自划分网段，并配置路由器反对 Pod 网络的转发。例如上图中，对于指标为 172.17.1.0/24 这个范畴内的包，转发到 10.100.0.3 这个主机上，同样，对于指标为 172.17.0.0/24 这个范畴内的包，转发到 10.100.0.2 这个主机上。当主机的 eth0 接口接管到来自 Pod 网络的包，就会向内部网桥转发，这样不同节点间的 Pod 就能够互相 IP 寻址和通信。这种计划依赖于底层的网络设备，然而不引入额定性能开销。
如果底层的网络是你无法控制的，比如说私有云网络，或者企业的运维团队不反对路由计划，能够采纳笼罩 (Overlay) 网络计划，如下图所示：
所谓笼罩网络，就是在现有网络之上再建设一个虚构网络，实现技术有很多，例如 flannel/weavenet 等等，这些计划大都采纳隧道封包技术。简略了解，Pod 网络的数据包，在出节点之前，会先被封装成节点网络的数据包，当数据包达到指标节点，包内的 Pod 网络数据包会被解封进去，再转发给节点外部的 Pod 网络。这种计划对底层网络没有特地依赖，然而封包解包会引入额定性能开销。
CNI 简介
思考到 Pod 网络实现技术泛滥，为了简化集成，K8s 反对 CNI(Container Network Interface)规范，不同的 Pod 网络技术能够通过 CNI 插件模式和 K8s 进行集成。节点上的 Kubelet 通过 CNI 标准接口操作 Pod 网路，例如增加或删除网络接口等，它不须要关怀 Pod 网络的具体实现细节。
总结
K8s 的网络能够形象成四层网络，第 0 层节点网络，第 1 层 Pod 网络，第 2 层 Service 网络，第 3 层内部接入网络。除了第 0 层，每一层都构建于上一层之上。
一个节点内的 Pod 网络依赖于虚构网桥和虚构网卡等 linux 虚构设施，保障同一节点上的 Pod 之间能够失常 IP 寻址和互通。一个 Pod 内容器共享该 Pod 的网络栈，这个网络栈由 pause 容器创立。
不同节点间的 Pod 网络，能够采纳路由计划实现，也能够采纳笼罩网络计划。路由计划依赖于底层网络设备，但没有额定性能开销，笼罩网络计划不依赖于底层网络，但有额定封包解包开销。
CNI 是一个 Pod 网络集成规范，简化 K8s 和不同 Pod 网络实现技术的集成。
有了 Pod 网络，K8s 集群内的所有 Pods 在逻辑上都能够看作在一个平面网络内，能够失常 IP 寻址和互通。然而 Pod 仅仅是 K8s 云平台中的虚拟机形象，最终，咱们须要在 K8s 集群中运行的是利用或者说服务 (Service)，而一个 Service 背地个别由多个 Pods 组成集群，这时候就引入了服务发现(Service Discovery) 和负载平衡 (Load Balancing) 等问题，这是波波的下一篇《Kubernetes 网络三部曲～Service 网络》要分析的内容，敬请期待。
————————————————
版权申明：本文为 CSDN 博主「架构师波波」的原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接及本申明。
原文链接：https://blog.csdn.net/yang751…
