前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >k8s 自身原理 4

k8s 自身原理 4

作者头像
阿兵云原生
发布2023-09-01 08:49:34
1470
发布2023-09-01 08:49:34
举报
文章被收录于专栏:golang云原生new

前面咱们分享了 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

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

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

代码语言:javascript
复制
[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

首先是各种控制器会监听 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 会涉及哪些组件了吧!

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-08-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 阿兵云原生 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 从控制器到 pod 运行,是如何达成的?
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档