Kubernetes中的优雅关闭和零停机时间部署 _Kubernetes

在Kube.NETes中，创建和删除Pod是最常见的任务之一。
当你执行滚动更新、扩展部署、发布新版本、执行作业和定时作业等操作时，都会创建Pod 。
但是，在Pod被驱逐后，例如将节点标记为不可调度时，Pod也会被删除并重新创建。
如果这些Pod的性质是如此短暂，那么当一个Pod正在响应请求时，如果被告知关闭，会发生什么？在关闭之前，请求是否会完成？那么后续的请求呢？是否会被重定向到其他地方？
在讨论Pod被删除时会发生什么之前，有必要谈谈当Pod被创建时会发生什么。
假设你想在集群中创建以下Pod：
pod.yaml
apiVersion: v1kind: Podmetadata:name: my-podspec:contAIners:- name: webimage: Nginxports:- name: webcontainerPort: 80

你可以使用以下命令将YAML定义提交到集群中：
$ kubectl Apply -f pod.yaml

一旦你输入该命令，kubectl会将Pod定义提交给Kubernetes API 。
在数据库中保存集群的状态Pod的定义被API接收并进行检查，随后存储在数据库（etcd）中。
Pod也被添加到调度器的队列中。
调度器执行以下操作：
检查Pod的定义。
收集关于工作负载的详细信息，例如CPU和内存请求。
通过筛选器和判定的过程决定最适合运行该Pod的节点。
在此过程结束时：

Pod在etcd中被标记为已调度。
Pod被分配给一个节点。
Pod的状态被存储在etcd中。

然而，此时Pod仍然不存在。

当你使用kubectl apply -f命令提交一个Pod的YAML文件时，该YAML文件会被发送到Kubernetes API 。

文章插图
图片

API将Pod保存在数据库（etcd）中。

文章插图
图片
3. 调度器为该Pod分配了最适合的节点，Pod的状态变为Pending 。此时，Pod只存在于etcd中。

文章插图
图片
在控制平面中发生了前述任务，并且状态存储在数据库中。
**那么是谁在你的节点上创建Pod呢？
Kubelet-Kubernetes代理Kubelet 的任务是轮询控制平面以获取更新。
你可以想象kubelet不断地向主节点发出请求：“我负责管理工作节点1，是否有新的Pod需要我处理？”
当有一个Pod需要处理时，kubelet会创建它，在某种程度上是这样的。
kubelet并不是直接创建Pod 。相反，它将工作委托给其他三个组件：

容器运行时接口（CRI）：负责为Pod创建容器。
容器网络接口（CNI）：负责将容器连接到集群网络并分配IP地址。
容器存储接口（CSI）：负责在容器中挂载卷。

在大多数情况下，容器运行时接口（CRI）的工作类似于：
$ Docker run -d <my-container-image>

容器网络接口（CNI）更有趣，因为它负责以下任务：

为Pod生成有效的IP地址。
将容器连接到网络的其他部分。

正如你所想象的，连接容器到网络并分配有效的IP地址有多种方式（可以选择IPv4或IPv6，甚至可以分配多个IP地址）。
以Docker为例，它会创建虚拟以太网对并将其附加到一个桥接器上；而AWS-CNI会直接将Pod连接到虚拟私有云（VPC）的其余部分。
当容器网络接口完成其工作时，Pod将连接到网络的其余部分，并被分配一个有效的IP地址。
但是存在一个问题。
kubelet知道IP地址（因为它调用了容器网络接口），但控制平面不知道。
没有人告诉主节点Pod已被分配了IP地址，并且准备好接收流量。在控制平面的视角中，Pod仍在创建中。