5分钟让你理解K8S必备架构概念，以及网络模型（下）

写在前面

在这用XMind画了一张导图记录Redis的学习笔记和一些面试解析（源文件对部分节点有详细备注和参考资料，欢迎关注我的公众号：阿风的架构笔记后台发送【导图】拿下载链接，已经完善更新）：

前言

前两篇介绍了K8S的核心的概念，以及各自起到的作用，小伙伴们一定需要了解哦。今天来分享一下K8S核心的网络模型，这一块也是比较复杂的，但也是非常重要的。我们从最基本的点慢慢梳理。

Node网络

这个是最基础的网络，就是每个机器Node节点之间网络通信，也会整个K8S的基础网络，这个运维工程师会保证每个机器Node网络的互通。

上面的WorkNode虚机节点，通过IP+Port即可以实现网络互通，类似搭建了一个内部局域网环境。

Pod网络

K8S最小单位是Pod，每个WorkNode节点中会存在多个Pod，以及一个Pod会有多个容器，那他们的网络通讯模型是什么呢？

我们只需要保证各个Pod之间，都是能够互通的。如下图

我们先来看看在同一个Pod之间不同容器的互通原理。

同一个Pod不同容器之间的网络互通

上图中有eth0、docker0、veth0三种网络设备：

eth0：是代表node节点的网络设备， 即是node之间的互通是通过此设备。
docker0：虚拟网桥，可以理解为虚拟交换机。 此设备是用在同一个node中的不同pod之间互相通讯的。
veth0：是Pod内部的虚拟网卡。 它是Pod内不同容器之间互联的网络设备，它的IP地址是由docker0分配的。
在k8s中每个Pod中管理着一组Docker容器， 这些Docker容器会共享同一个网络命名空间
Pod中的每个Docker容器拥有与Pod相同的IP和port地址空间，并且由于他们在同一个网络命名空间，他们之间可以通过localhost相互访问。 什么机制让同一个Pod内的多个docker容器相互通信那？其实是使用Docker的一种网络模型：–net=container

container模式指定新创建的Docker容器和已经存在的一个容器共享一个网络命名空间，而不是和宿主机共享。新创建的Docker容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。

每个Pod容器中有一个系统提供的pause容器有独立的网络命名空间，在Pod内启动Docker容器时候使用 –net=container就可以让当前Docker容器加入到Pod容器拥有的网络命名空间 （pause容器）。

所以我们能够看到每个Pod中的pause容器是很重要的哦。

同一个Node节点不同Pod之间网络互通

上图就是同一个node启动多个Pod时，docker0又会给Pod2分配ip地址，因为Pod的IP都是由docker0分配的，docker0承担着虚拟网桥的作用，则同一个node的不同Pod之间的通讯即是通过docker0实现的。

比较细心的小伙伴们会发现，pod的ip地址空间是172.17.0.0/24；而node节点的ip地址空间是在10.100.0.0/24。

那么不同node节点之间的pod是如何互通的呢？

不同node之间的pod网络互通

上图阐述了不同的Node节点之间的Pod是互通需求，Node节点IP地址空间为10.100.0.0/24；Pod的IP地址是在172.17.0.0/16；pod的ip地址在整个K8S集群是唯一的，这个是由K8S保证的。 Node节点网络和Pod网络不在同一个网络空间，那2个Pod是如何互通的呢？

这个底层实现比较复杂，小伙伴们可以理解为是通过覆盖网络方式实现，即pod1给pod2时，先把数据包封装为所在node节点的网络数据包，然后到目标Node之后再解数据包，再到目标Pod。整个流程需要知道哪个Pod在哪个Node映射关系。

简单一点理解：Pod1与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机Node网卡是两个完全不同的ip网段，并且不同Node之间的通讯只能通过宿主机的物理网卡进行。

将Pod的ip和所在Node的ip关联起来，通过这个关联可以让Pod互相访问。

Service的ClusterIP网络模型

在我们之前文章介绍了一个服务是可以存在多个pod的，那么另一个服务请求此服务时，到底是请求到其中哪一个pod的呢？看下图

我们看到User服务启动了3个Pod，都有独立的PodIP；那我们黄色的pod怎么发现User服务的Pod呢？如果重启了User服务的Pod，ip会有变动怎么办？增加或减少Pod又怎么办？

K8S提供了ClusterIP网络模型解决了服务发现，黄色Pod不需要知道User服务到底有多少Pod以及Pod的Ip变化；黄色Pod访问User服务是通过User Service的ClusterIP进行的，ClusterIP会感知后端User服务的Pod变化。

ClusterIP也起到了负载均衡的作用，默认为随机算法。

注册发现

那ClusterIP的服务发现原理是什么呢？

看上图的服务注册以及发现，非常类似微服务的注册中心的服务注册/发现。在Pod实例化后会通过kubelet注册到K8S Master节点上面。注册的信息就是ServiceName和ClusterIP关系、ClusterIP和PodIP的关系。

kube-proxy和kube-dns会监听K8S Master上面的信息。kube-dns目的就是解析ServiceName到哪个ClusterIP。

消费者Pod访问某个ServiceName时，则通过注册信息找到对应的ClusterIP、然后再找到PodIP。

ClusterIP的访问核心是系统的Iptables、ipvs进行截获请求

外部流量接入

上面介绍了K8S内部，pod访问不同pod的方式，是通过ClusterIP方式的Service。

那外部网络如何连接K8S集群内部的Pod呢？上一篇文章中已经介绍了一种NodePort方式的Service。

定义了NodePort的Service，会在所有的Node节点上面创建这个NodePort，提供给外部访问。多个Node节点上面都有一个NodePort；那怎么实现负载均衡访问呢？

这个时候会要延伸出LoadBalancer这个组件了，一般做生产云端部署的时候会用到；需要一些费用的哦。开发测试环境只需要NodePort访问就行了

这个外部请求时，会通过Load Balancer选择一个Node节点上的NodePort进行访问。

Ingress

上面的NodePort和LoadBalancer针对的是某一个Service；但是我们业务中会有很多个这样的Service，如果每个Service都要去申请一个LoadBalancer，那么费用就太高了。

那能不能只要购买一个LoadBalancer就可以支持很多个Service呢？这个就是用到Ingress组件了。

上图中就能看出来，Ingress本质就是7层反向代理，做了个路由转发，类似网关路由转发；把不同的path转发到不同的Service。

实现Ingress的方式有很多，如：Nginx/Kong/Envoy/Zuul/SpringCloudGateway等

总结

K8S中的网络模型比较多，我们来看个对比图，方便小伙伴们记忆理解。

看完三件事️

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

点赞，转发，有你们的『点赞和评论』，才是我创造的动力。
关注公众号 『阿风的架构笔记』，不定期分享原创知识。
同时可以期待后续文章ing
关注后回复【666】扫码即可获取架构进阶学习资料包