当用户向 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 运行的全过程就是这样了。
本文链接：http://www.28at.com/showinfo-26-56594-0.htmlKubernetes 从提交 deployment 到 pod 运行的全过程
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 彻底搞懂 JS 类型转换
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
