当用户向 Kubernetes 提交了一个创建 deployment 的请求后,Kubernetes 从接收请求直至创建对应的 pod 运行这整个过程中都发生了什么呢?
成都创新互联专注于玉屏网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供玉屏营销型网站建设,玉屏网站制作、玉屏网页设计、玉屏网站官网定制、小程序定制开发服务,打造玉屏网络公司原创品牌,更为您提供玉屏网站排名全网营销落地服务。
在搞清楚从 deployment 提交到 pod 运行整个过程之前,我们有先来看看 Kubernetes 的集群架构:
上图与下图相同:
如图所示,k8s 集群分为 control plane 控制平面和 node 节点。
control plane 控制平面(也称之为主节点)主要包含以下组件:
node 节点,专门部署用户的应用程序(与控制平面隔离,避免影响到 k8s 的核心组件),主要包含以下组件:
从 Deployment 到 Pod 的整个过程如下图所示:
请求发送到 kube-api-server,然后会进行认证、鉴权、变更、校验等一系列过程,最后将 deployment 的数据持久化存储至 etcd。
在这个过程我们可以通过 mutation admission 的 webhook 自主地对资源对象进行任意的变更,比如注入 sidecar 等等。
controller manager 组件针对不同的资源对象有不同的处理部分。
针对 Deployment,由于其并不直接管理 Pod,而是 Deployment 管理 ReplicaSet,ReplicaSet 再管理 Pod:
因此其中涉及到 controller manager 中的两个部分:
(1) 先是 deployment controller 监听到 deployment 的创建事件,然后进行相关的处理,最后创建 replicaset。
(2) 然后 replicaset controller 监听到 replicaset 的创建事件,进行相关处理后,最后创建 pod。
scheduler 接受到 pod 需要调度的事件后,进行一系列调度逻辑处理,最后选择一个合适的 node 节点,将 pod 绑定到这个节点上(所谓的节点调度在这里只是修改 pod 数据,对其中的 nodeName 进行赋值)。
具体的调度算法比较复杂,涉及强制性调度、亲和与反亲和、污点和容忍、以及硬件资源计算、优先级等等,本文不做展开。
调度完成后,pod 被绑定的 node 节点上的 kubelet 同样通过 kube-api-server 会接受到相应的事件,然后 kubelet 会进行 pod 的创建。
在这个过程中 kubelet 会分别调用 CRI、CNI、CSI:
所谓的接口其实只是定义了通信的规范或者标准(使用的是 grpc 协议),具体的实现则是交给了插件。
至此,Kubernetes 从创建 deployment 到 pod 运行的全过程就是这样了。
分享题目:Kubernetes从提交deployment到pod运行的全过程
文章出自:http://www.shufengxianlan.com/qtweb/news38/190688.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联