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中的网络模型比较多，咱们来看个对比图，方便小伙伴们记忆理解。

看完三件事❤️

​ 若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙： ​

1. 点赞，转发，有大家的 『点赞和评论』，才是我创造的动力。
2. 关注公众号 『 阿风的架构笔记 』，不按期分享原创知识。
3. 同时能够期待后续文章ing🚀
4. 关注后回复【666】扫码便可获取架构进阶学习资料包