成为VIP
比如现在我有一个更新策略为 Recreate 的应用，然后执行删除命令，如下所示：
☸ ➜ kubectl get pods
NAME READY STATUS RESTARTS AGE
minio-875749785-sv5ns 1/1 Running 1 (2m52s ago) 42h
☸ ➜ kubectl delete pod minio-875749785-sv5ns
pod "minio-875749785-sv5ns" deleted
在删除之前在另外一个终端观察应用状态：
☸ ➜ kubectl get pods -w
NAME READY STATUS RESTARTS AGE
minio-875749785-sv5ns 1/1 Running 1 (2m46s ago) 42h
minio-875749785-sv5ns 1/1 Terminating 1 (2m57s ago) 42h
minio-875749785-h2j2b 0/1 Pending 0 0s
minio-875749785-h2j2b 0/1 Pending 0 0s
minio-875749785-h2j2b 0/1 ContainerCreating 0 0s
minio-875749785-sv5ns 0/1 Terminating 1 (2m59s ago) 42h
minio-875749785-sv5ns 0/1 Terminating 1 (2m59s ago) 42h
minio-875749785-sv5ns 0/1 Terminating 1 (2m59s ago) 42h
minio-875749785-h2j2b 0/1 Running 0 17s
minio-875749785-h2j2b 1/1 Running 0 30s
从上面的过程可以看到当我们执行 kubectl delete 命令后 Pod 变成了 Terminating 状态，然后才消失。接下来我们会从代码角度来介绍下删除 Pod 的整体流程。
这里我们以 v1.22.8 版本的 Kubernetes 为例进行说明，其他版本不保证代码完全一致，但是整体思路是一致的。
删除状态
我们可以根据 kubectl 操作后看到的状态来进行跟踪，上面的格式化结果是通过代码 #L88-L102 实现的，如下所示：
对于 Pod 的输出结果是通过 printPod 函数获取的，代码位于：#L756-L840，其中有一段代码提到了 Terminating 值，是在 pod.DeletionTimestamp != nil 的情况下变成该状态的，如下所示：
也就是说当执行删除操作的时候，会设置 Pod 的 DeletionTimestamp 属性，这个时候就会显示成 Terminating 状态。
当执行删除操作的时候，会向 apiserver 发送一次 DELETE 请求：
I0408 11:25:33.002155 42938 round_trippers.go:435] curl -v -XDELETE -H "Content-Type: application/json" -H "User-Agent: kubectl/v1.22.7 (darwin/amd64) kubernetes/b56e432" -H "Accept: application/json" 'https://192.168.0.111:6443/api/v1/namespaces/default/pods/minio-875749785-sv5ns'
I0408 11:25:33.037245 42938 round_trippers.go:454] DELETE https://192.168.0.111:6443/api/v1/namespaces/default/pods/minio-875749785-sv5ns 200 OK in 35 milliseconds
接收到删除请求的处理器位于代码 #L986，如下所示：
在 BeforeDelete 函数中判断是否需要优雅删除，判断的标准是 DeletionGracePeriodSeconds 值是否为 0，不为零则认为是优雅删除，apiserver 不会立即将这个对象从 etcd 中删除，否则直接删除。对于 Pod 而言，默认 DeletionGracePeriodSeconds 为 30 秒，因此这里不会被立刻删除掉，而是将 DeletionTimestamp 设置为当前时间，DeletionGracePeriodSeconds 设置为默认值 30 秒。代码位于 #L93-L159，在该函数中会设置 DeletionTimestamp 的值，如下所示：
上面的代码验证了当执行删除操作的时候，apiserver 会先设置 Pod 的 DeletionTimestamp 属性为当前时间加上优雅删除宽限时长的时间点，设置了该属性后，我们客户端格式化过后看到的就是 Terminating 状态了。
优雅删除
由于 Pod 中涉及到其他很多资源，比如 sandbox 容器、volume 卷等等，在删除后都需要进行回收，而删除 Pod 最终也是去删除对应的容器，这个就需要 Pod 所在节点的 kubelet 来完成清理了。kubelet 首先同样会一直 watch 我们的 Pod，当 Pod 的删除时间更新后，自然就会接收到事件，然后进行相应的清理工作。
kubelet 对 Pod 的处理主要在 syncLoop 函数中，会去调用和事件相关的处理函数 syncLoopIteration，代码位于 #L2040-L2079 中，如下所示：
当执行删除操作的时候，apiserver 首先会更新 Pod 中的 DeletionTimestamp 属性，这个改变对于 kubelet 来说属于更新操作，所以会对应 kubetypes.UPDATE 操作，会调用 HandlePodUpdates 函数进行更新。
在 HandlePodUpdates 中会调用 dispatchWork 将 Pod 删除分配给具体的 worker 处理，podWorker 是具体的执行者，也就是每次 Pod 需要更新都会发送给 podWorker。
dispatchWork 方法会调用 UpdatePod 函数对 Pod 进行删除，代码位于 #L540-L765，在该函数中会通过一个 channel 传递 Pod 信息，在一个 goroutine 中调用 managePodLoop 函数进行处理，该函数中会调用 syncTerminatingPod/syncPod 方法来进行删除操作。
最终都会调用 killPod 函数去执行删除 Pod：
killPod 函数中会调用容器运行时去停止该 Pod 中的容器，代码位于#L856-L868：
容器运行时的 KillPod 方法位于 #L969-L998，如下所示：
killPodWithSyncResult 方法中首先调用函数 killContainersWithSyncResult 杀掉所有运行的容器，然后删除 Pod 的 sandbox。
在该函数中，利用多个 goroutine 来对 Pod 中的每一个容器进行删除，删除容器的方法是 killContainer，在该函数中首先会执行 pre-stop 这个 hooks（如果存在的话），然后才停止容器，代码位于 #L660-L736。
首先获取优雅删除的宽限时间：
其中 TerminationGracePeriodSeconds 可以在资源清单文件中进行设置，默认为 30 秒，这个时间是，给 Pod 发出关闭指令后会给应用发送 SIGTERM 信号，程序只需要捕获 SIGTERM 信号并做相应处理即可。也就是 Pod 接收到 SIGTERM 信号后，应用能够优雅关闭的时间。该时间是由 apiserver 设置的，前面已经分析过。
如果配置了 pre-stop hook 并且还有足够的时间，则会执行该 hook，pre-stop 主要是为了业务在容器删除前前，能够优雅的停止，比如资源回收等操作：
最后才会真正去调用底层容器运行时来停止容器：
容器删掉后回到前面的 killPodWithSyncResult 函数中，接下来就会去调用运行时服务的 StopPodSandbox 函数停止 sandbox 容器，也就是 pause 容器。
// Stop all sandboxes belongs to same pod
for _, podSandbox := range runningPod.Sandboxes {
if err := m.runtimeService.StopPodSandbox(podSandbox.ID.ID); err != nil && !crierror.IsNotFound(err) {
killSandboxResult.Fail(kubecontainer.ErrKillPodSandbox, err.Error())
klog.ErrorS(nil, "Failed to stop sandbox", "podSandboxID", podSandbox.ID)
}
}
到这里 kubelet 就完成了对 Pod 的优雅删除，但是这并没有结束。
同步状态
对于优雅删除一开始在 apiserver 只是给 Pod 设置了 DeletionTimestamp 属性，然后 kubelet watch 来更新后去完成了 Pod 的优雅删除，但是现在服务端中还有 Pod 的记录，并没有真正去删除。
在 kubelet 启动的时候同时还去启动了一个 statusManager 的同步循环，该 Manager 是 kubelet pod 状态的真实来源，应该与最新的 v1.PodStatus 保持同步，它还将更新同步回 apiserver，也就是当优雅删除完成后我们还将通过该管理器将状态同步回 apiserver。
状态管理器在与 apiserver 进行状态同步的时候会去调用该管理器下面的 syncPod 方法进行处理，代码位于 #L149-L181，如下所示：
在该方法中会判断 Pod 是否已经优雅停止了，代码位于 #L583-L652，如下所示：
比如会判断是否还有容器在运行、volumes 是否还没有清理、pod cgroup 还没清空等等，如果 canBeDeleted 返回 truek8s删除pod，则表示 pod 已经优雅的停止了，那么这个时候就可以向 apiserver 发送 Delete 请求，再次删除 Pod 了。
不过这一次的设置的 GracePeriodSeconds 为 0，表示要强制删除 Pod 了，到这里 apiserver 会再次收到 DELETE 请求，与第一次不同的是k8s删除pod，这次是强制删除 Pod，会去 etcd 中删除 Pod 对象了。
这个时候 kubelet 会接受到 REMOVE 的事件，调用 HandlePodRemoves 函数去进行处理：
首先会去调用 deletePod 函数去停掉关联的 pod worker，然后还会调用 probeManager 去移除 Pod 相关的探针 prober worker，到这里就表示 Pod 彻底从节点上删除了。
限时特惠：本站每日持续更新海量展厅资源，一年会员只需29.9元，全站资源免费下载
站长微信：zhanting688
