前言
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…
发表回复