kubernets之控制器之间的协作以及网络

一  创建一个deployment的时候整个kubernets集群的资源和事件的调用链

 

　　1.1  创建一个deployment的资源，在提交的时候，集群中的调度器，控制器以及node节点上kubelet就已经通过监听各自资源类型的变化，如图所示

                             

    • kubernets组件通过API服务器监听API对象

　　

　　1.2  观察本次创建资源的事件链

　　　　当你将deployment的yaml文件通过kubectl提交给API服务器的时候，实际上kubectl会对API服务器发起一个HTTP的post请求，API服务器对请求进行鉴权，认证，准入，最终效验，最后写入etcd存储中，并且将结果返回给API服务器，整个事件链如图所示

                        

  • 当客户端kubectl向API服务器发起创建一个deployment资源的时候
  • 集群里面所有监听了deployment资源的调度器会收到一个通知，其中在这里我们要说明的只是deployment同样也会收到通知
  • deployment调度器收到通知之后会去根据deployment的定义向API服务器发起创建RS
  • 彼时在集群中的RS控制器通过监听也收到了RS的创建，并创建了pod
  • 等待pod创建完成之后，调度器就会将其分配给工作节点，相应的工作节点通过订阅得知pod被调度自己的节点上
  • 于是kubelet会去拉取镜像，启动容器，并将结果反馈给API服务器

　1.3  观察集群事件

　　　控制平面以及kubelet在执行相关操作的时候都会向API服务器发送事件，发送事件是通过创建事件资源来实现的，每次使用kubectl describe来检查资源的时候就能看到相关的事件，也可以直接使用kubectl get events --watch

[root@node01 ~]# k get events --watch
NAME                       AGE
kubia-0.1659b586ea3d7158   0s
kubia-1.1659b586ec5d986a   0s
kubia-2.1659b586ed5fc952   0s
kubia.16591db959436c4c     0s
kubia-0.1659b58e5854386e   0s
kubia-0.1659b58e8bb8c852   0s
kubia-0.1659b58ee400e30f   0s

 

　　 了解运行中的pod都是些什么

　　　　查看下pod中的容器状况

[root@node01 Chapter10]# docker ps
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS               NAMES
9a96d4501bee        luksa/kubia-pet        "node app.js"            40 seconds ago      Up 39 seconds                           k8s_kubia_kubia-1_default_82c80622-5566-11eb-ae9a-5254002a5691_0
1733975abffb        k8s.gcr.io/pause:3.1   "/pause"                 44 seconds ago      Up 43 seconds                           k8s_POD_kubia-1_default_82c80622-5566-11eb-ae9a-5254002a5691_0
  • 从这里可以看到在一个容器起来之前就已经有了/pause容器起来
  • 这个容器看起来没有任何实质的作用，但是实际上还是有很大的意义的，它会将一个pod的所有容器组织在同一个命名空间里面
  • 实际上，这个基础容器的生命周期基本和pod保持一致，当pod里面的容器需要重启的时候，或者删除重新拉起的时候，需要和之前的容器在同一个命名空间里面，而这个基础容器使之成为可能，如果pod被删除，kubelet会重新去创建它，并包含基础容器以及该pod内部的所有容器

　　　　　　

　　1.4 了解pod中的网络

　　　　kubernetes自身并不提供任何的网络插件，而是通过集群管理员或者CNI来配置pod之间的网络，集群的要求是，所有pod都应该在一个扁平的网络环境里面互相通信，换句话就是说pod之间的通信不能够过NAT。

                                      

  • pod到pod之间通信没有使用NAT网络
  • 同样的pod到主机上面的网络也是没有过NAT的
  • 但是pod与外部服务通信的时候，就会使用NAT地址转换，由于pod使用的是似有地址，所有会转化为主机的地址

　　深入了解网络工作原理

　　每个pod里面都会有个pause容器，每个pod里面的网络接口以及都会被存储在这个基础容器里面

　　　　同一节点上pod之间如何通信

    • 每个节点上面都有都会有一个网络插件的网桥

    • 每个pod都有一个网卡对，一端在pod内部被改名为eth0，一端以vethxxx的形式到节点上

    • 同节点上面pod通信步骤是，podA的应用经由podA的网卡的eth0到节点端的一侧，之后到达网桥，再从网桥到达另一pod的node端，最后到另一个pod的容器的eth0进入容器应用

　　　　　　　　

　　　　不同的节点上面的node通信架构如图所示

                

　　　　   不同节点之间的pod通信需要一个三层网络，一般借助网络插件，将不同节点之间的网络打通，之后的流程就是单个节点之间的通信

posted @ 2021-01-13 11:50  伊铭(netease)  阅读(189)  评论(0)  编辑  收藏  举报