比如現(xiàn)在我有一個更新策略為 Recreate 的應(yīng)用，然后執(zhí)行刪除命令，如下所示：

? ? 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

在刪除之前在另外一個終端觀察應(yīng)用狀態(tài)：

? ? 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

從上面的過程可以看到當(dāng)我們執(zhí)行 kubectl delete 命令后 Pod 變成了 Terminating 狀態(tài)，然后才消失。接下來我們會從代碼角度來介紹下刪除 Pod 的整體流程。

這里我們以 v1.22.8 版本的 Kubernetes 為例進行說明，其他版本不保證代碼完全一致，但是整體思路是一致的。

刪除狀態(tài)

我們可以根據(jù) kubectl 操作后看到的狀態(tài)來進行跟蹤，上面的格式化結(jié)果是通過代碼 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/printers/internalversion/printers.go#L88-L102 實現(xiàn)的，如下所示：

對于 Pod 的輸出結(jié)果是通過 printPod 函數(shù)獲取的，代碼位于：https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/printers/internalversion/printers.go#L756-L840，其中有一段代碼提到了 Terminating 值，是在 pod.DeletionTimestamp != nil 的情況下變成該狀態(tài)的，如下所示：

也就是說當(dāng)執(zhí)行刪除操作的時候，會設(shè)置 Pod 的 DeletionTimestamp 屬性，這個時候就會顯示成 Terminating 狀態(tài)。

當(dāng)執(zhí)行刪除操作的時候，會向 apiserver 發(fā)送一次 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

接收到刪除請求的處理器位于代碼 https://github.com/kubernetes/kubernetes/blob/v1.22.8/staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go#L986，如下所示：

在 BeforeDelete 函數(shù)中判斷是否需要優(yōu)雅刪除，判斷的標(biāo)準(zhǔn)是 DeletionGracePeriodSeconds 值是否為 0，不為零則認(rèn)為是優(yōu)雅刪除，apiserver 不會立即將這個對象從 etcd 中刪除，否則直接刪除。對于 Pod 而言，默認(rèn) DeletionGracePeriodSeconds 為 30 秒，因此這里不會被立刻刪除掉，而是將 DeletionTimestamp 設(shè)置為當(dāng)前時間，DeletionGracePeriodSeconds 設(shè)置為默認(rèn)值 30 秒。代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/staging/src/k8s.io/apiserver/pkg/registry/rest/delete.go#L93-L159，在該函數(shù)中會設(shè)置 DeletionTimestamp 的值，如下所示：

上面的代碼驗證了當(dāng)執(zhí)行刪除操作的時候，apiserver 會先設(shè)置 Pod 的 DeletionTimestamp 屬性為當(dāng)前時間加上優(yōu)雅刪除寬限時長的時間點，設(shè)置了該屬性后，我們客戶端格式化過后看到的就是 Terminating 狀態(tài)了。

優(yōu)雅刪除

由于 Pod 中涉及到其他很多資源，比如 sandbox 容器、volume 卷等等，在刪除后都需要進行回收，而刪除 Pod 最終也是去刪除對應(yīng)的容器，這個就需要 Pod 所在節(jié)點的 kubelet 來完成清理了。kubelet 首先同樣會一直 watch 我們的 Pod，當(dāng) Pod 的刪除時間更新后，自然就會接收到事件，然后進行相應(yīng)的清理工作。

kubelet 對 Pod 的處理主要在 syncLoop 函數(shù)中，會去調(diào)用和事件相關(guān)的處理函數(shù) syncLoopIteration，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kubelet.go#L2040-L2079 中，如下所示：

當(dāng)執(zhí)行刪除操作的時候，apiserver 首先會更新 Pod 中的 DeletionTimestamp 屬性，這個改變對于 kubelet 來說屬于更新操作，所以會對應(yīng) kubetypes.UPDATE 操作，會調(diào)用 HandlePodUpdates 函數(shù)進行更新。

在 HandlePodUpdates 中會調(diào)用 dispatchWork 將 Pod 刪除分配給具體的 worker 處理，podWorker 是具體的執(zhí)行者，也就是每次 Pod 需要更新都會發(fā)送給 podWorker。

dispatchWork 方法會調(diào)用 UpdatePod 函數(shù)對 Pod 進行刪除，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/pod_workers.go#L540-L765，在該函數(shù)中會通過一個 channel 傳遞 Pod 信息，在一個 goroutine 中調(diào)用 managePodLoop 函數(shù)進行處理，該函數(shù)中會調(diào)用 syncTerminatingPod/syncPod 方法來進行刪除操作。

最終都會調(diào)用 killPod 函數(shù)去執(zhí)行刪除 Pod：

killPod 函數(shù)中會調(diào)用容器運行時去停止該 Pod 中的容器，代碼位于https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kubelet_pods.go#L856-L868：

容器運行時的 KillPod 方法位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L969-L998，如下所示：

killPodWithSyncResult 方法中首先調(diào)用函數(shù) killContainersWithSyncResult 殺掉所有運行的容器，然后刪除 Pod 的 sandbox。

在該函數(shù)中，利用多個 goroutine 來對 Pod 中的每一個容器進行刪除，刪除容器的方法是 killContainer，在該函數(shù)中首先會執(zhí)行 pre-stop 這個 hooks(如果存在的話)，然后才停止容器，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kuberuntime/kuberuntime_container.go#L660-L736。

首先獲取優(yōu)雅刪除的寬限時間：

其中 TerminationGracePeriodSeconds 可以在資源清單文件中進行設(shè)置，默認(rèn)為 30 秒，這個時間是，給 Pod 發(fā)出關(guān)閉指令后會給應(yīng)用發(fā)送 SIGTERM 信號，程序只需要捕獲 SIGTERM 信號并做相應(yīng)處理即可。也就是 Pod 接收到 SIGTERM 信號后，應(yīng)用能夠優(yōu)雅關(guān)閉的時間。該時間是由 apiserver 設(shè)置的，前面已經(jīng)分析過。

如果配置了 pre-stop hook 并且還有足夠的時間，則會執(zhí)行該 hook，pre-stop 主要是為了業(yè)務(wù)在容器刪除前前，能夠優(yōu)雅的停止，比如資源回收等操作：

最后才會真正去調(diào)用底層容器運行時來停止容器：

容器刪掉后回到前面的 killPodWithSyncResult 函數(shù)中，接下來就會去調(diào)用運行時服務(wù)的 StopPodSandbox 函數(shù)停止 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 的優(yōu)雅刪除，但是這并沒有結(jié)束。

同步狀態(tài)

對于優(yōu)雅刪除一開始在 apiserver 只是給 Pod 設(shè)置了 DeletionTimestamp 屬性，然后 kubelet watch 來更新后去完成了 Pod 的優(yōu)雅刪除，但是現(xiàn)在服務(wù)端中還有 Pod 的記錄，并沒有真正去刪除。

在 kubelet 啟動的時候同時還去啟動了一個 statusManager 的同步循環(huán)，該 Manager 是 kubelet pod 狀態(tài)的真實來源，應(yīng)該與最新的 v1.PodStatus 保持同步，它還將更新同步回 apiserver，也就是當(dāng)優(yōu)雅刪除完成后我們還將通過該管理器將狀態(tài)同步回 apiserver。

狀態(tài)管理器在與 apiserver 進行狀態(tài)同步的時候會去調(diào)用該管理器下面的 syncPod 方法進行處理，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/status/status_manager.go#L149-L181，如下所示：

在該方法中會判斷 Pod 是否已經(jīng)優(yōu)雅停止了，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/status/status_manager.go#L583-L652，如下所示：

比如會判斷是否還有容器在運行、volumes 是否還沒有清理、pod cgroup 還沒清空等等，如果 canBeDeleted 返回 true，則表示 pod 已經(jīng)優(yōu)雅的停止了，那么這個時候就可以向 apiserver 發(fā)送 Delete 請求，再次刪除 Pod 了。

不過這一次的設(shè)置的 GracePeriodSeconds 為 0，表示要強制刪除 Pod 了，到這里 apiserver 會再次收到 DELETE 請求，與第一次不同的是，這次是強制刪除 Pod，會去 etcd 中刪除 Pod 對象了。

這個時候 kubelet 會接受到 REMOVE 的事件，調(diào)用 HandlePodRemoves 函數(shù)去進行處理：

首先會去調(diào)用 deletePod 函數(shù)去停掉關(guān)聯(lián)的 pod worker，然后還會調(diào)用 probeManager 去移除 Pod 相關(guān)的探針 prober worker，到這里就表示 Pod 徹底從節(jié)點上刪除了。