k8s 自身原理 4

前面咱们分享了 mater 和 worker 节点里面都有哪些组件，他们又是各自主要负责的工作是什么，现在我们心里应该都有数了吧

master 节点：

etcd 存储资源配置，ApiServer 提供 RESTful Api 用于交互，scheduler 用于调度 pod，controller manager 控制器管理器

worker 节点：

kubelet 管理 节点上的所有组件和内容，kube-proxy，作为代理将数据给到 pod

从控制器到 pod 运行，是如何达成的？

那么今天来分享一下，这些组件都是如何高效配合协同作战的，我们可以从控制器作为切入点，来看看

前面我们说到 master 里面的组件是不会直接去创建和运行 pod 的，只会和 ApiServer 通信，那么我们来看看创建一个 控制器的资源，到最终 pod 运行，中间都会涉及哪些控制器，哪些资源，哪些动作

我们都知道，咱们在生产环境下面，是不会直接去创建 pod 资源的，而是通过 RC / RS 去管控 pod ，然后我们是否还记得 Deployment 资源是会去管控 RS 的，那么我们就用之前环境中一直有的 deploy 来演示一下效果吧

看一下环境中的 deploy

[图片上传失败...(image-375680-1691931655543)]

可以看到环境中是有 5 个 pod，我们进入 newkubia ，将副本数修改为 3 个，并且在另外一个窗口进入到 master 节点，开启事件监控 kubectl get events --watch

[图片上传失败...(image-28e132-1691931655543)]

在将 newkubia Deployment 从 5 个副本修改到 3 个副本的时候，我们可以看到此处的事件监控能够看到监控的信息

[图片上传失败...(image-b954f3-1691931655543)]

[xmt@VM-20-15-centos ~]$ kubectl get events --watch
LAST SEEN   TYPE     REASON              OBJECT                MESSAGE
0s          Normal   ScalingReplicaSet   deployment/newkubia   Scaled down replica set newkubia-85df599b7f to 3
0s          Normal   Killing             pod/newkubia-85df599b7f-zhwnw   Stopping container newkubia
0s          Normal   Killing             pod/newkubia-85df599b7f-jzjsn   Stopping container newkubia
0s          Normal   SuccessfulDelete    replicaset/newkubia-85df599b7f   Deleted pod: newkubia-85df599b7f-zhwnw
0s          Normal   SuccessfulDelete    replicaset/newkubia-85df599b7f   Deleted pod: newkubia-85df599b7f-jzjsn

咱可以在 REASON 字段处看到，经历的过程是 **ScalingReplicaSet -> Killing newkubia-85df599b7f-zhwnw -> Killing newkubia-85df599b7f-jzjsn -> SuccessfulDelete **

上述过程中，就会涉及到这些 控制器：

• Deployment 控制器
• ReplicaSet 控制器

还涉及 调度器，ApiServer 和 kubelet 和 docker

[图片上传失败...(image-36649b-1691931655543)]

首先是各种控制器会监听 ApiIServer 里面对应的资源，当我们修改 newkubia Deployment 清单的副本数时候，

• kubectl 会发 http 请求 POST 方法去请求 ApiServer，ApiServer 修改对应的 etcd 数据
• Deployment 控制器监控到 Deployment 资源有变动，则会去和 APiServer 交互修改 ReplicaSet 资源的副本数
• ReplicaSet 此时监听到 ApiServer 处的 ReplicaSet 资源有变动，则会 与 ApiServer 进行交互 去通知 相应的 pod 资源 进行需要进行更新
• 调度器 scheduler 同样也是监听到 ApiServer 中的 pod 资源有变动后，Scheduler 就会去和 ApiServer 交互 在相应节点上配置增删 pod
• 对应节点的 kubelet 监听到 ApiServer 中 pod 资源的变化，便会去通知自己节点的 docker，进行增加运行容器和删除容器的动作

通过上述简图和描述，相应到这里，xdm 对于修改一个 deployment 资源的副本数， k8s 中从控制器 到 实际的 pod 会涉及哪些组件了吧！

今天就到这里，学习所得，若有偏差，还请斧正

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

[图片上传失败...(image-5e25c5-1691931655543)]

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~