5分钟让你理解K8S必备架构概念,以及网络模型(下)

3,027 阅读7分钟

写在前面

在这用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】扫码即可获取架构进阶学习资料包