Kubernetes Pod 刪除操作源碼解析
比如現在我有一個更新策略為 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 操作后看到的狀態來進行跟蹤，上面的格式化結果是通過代碼 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/printers/internalversion/printers.go#L88-L102 實現的，如下所示：
對于 Pod 的輸出結果是通過 printPod 函數獲取的，代碼位于：https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/printers/internalversion/printers.go#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
接收到刪除請求的處理器位于代碼 https://github.com/kubernetes/kubernetes/blob/v1.22.8/staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go#L986，如下所示：
在 BeforeDelete 函數中判斷是否需要優雅刪除，判斷的標準是 DeletionGracePeriodSeconds 值是否為 0，不為零則認為是優雅刪除，apiserver 不會立即將這個對象從 etcd 中刪除，否則直接刪除。對于 Pod 而言，默認 DeletionGracePeriodSeconds 為 30 秒，因此這里不會被立刻刪除掉，而是將 DeletionTimestamp 設置為當前時間，DeletionGracePeriodSeconds 設置為默認值 30 秒。代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/staging/src/k8s.io/apiserver/pkg/registry/rest/delete.go#L93-L159，在該函數中會設置 DeletionTimestamp 的值，如下所示：
上面的代碼驗證了當執行刪除操作的時候，apiserver 會先設置 Pod 的 DeletionTimestamp 屬性為當前時間加上優雅刪除寬限時長的時間點，設置了該屬性后，我們客戶端格式化過后看到的就是 Terminating 狀態了。
優雅刪除
由于 Pod 中涉及到其他很多資源，比如 sandbox 容器、volume 卷等等，在刪除后都需要進行回收，而刪除 Pod 最終也是去刪除對應的容器，這個就需要 Pod 所在節點的 kubelet 來完成清理了。kubelet 首先同樣會一直 watch 我們的 Pod，當 Pod 的刪除時間更新后，自然就會接收到事件，然后進行相應的清理工作。
kubelet 對 Pod 的處理主要在 syncLoop 函數中，會去調用和事件相關的處理函數 syncLoopIteration，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kubelet.go#L2040-L2079 中，如下所示：
當執行刪除操作的時候，apiserver 首先會更新 Pod 中的 DeletionTimestamp 屬性，這個改變對于 kubelet 來說屬于更新操作，所以會對應 kubetypes.UPDATE 操作，會調用 HandlePodUpdates 函數進行更新。
在 HandlePodUpdates 中會調用 dispatchWork 將 Pod 刪除分配給具體的 worker 處理，podWorker 是具體的執行者，也就是每次 Pod 需要更新都會發送給 podWorker。
dispatchWork 方法會調用 UpdatePod 函數對 Pod 進行刪除，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/pod_workers.go#L540-L765，在該函數中會通過一個 channel 傳遞 Pod 信息，在一個 goroutine 中調用 managePodLoop 函數進行處理，該函數中會調用 syncTerminatingPod/syncPod 方法來進行刪除操作。
最終都會調用 killPod 函數去執行刪除 Pod：
killPod 函數中會調用容器運行時去停止該 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 方法中首先調用函數 killContainersWithSyncResult 殺掉所有運行的容器，然后刪除 Pod 的 sandbox。
在該函數中，利用多個 goroutine 來對 Pod 中的每一個容器進行刪除，刪除容器的方法是 killContainer，在該函數中首先會執行 pre-stop 這個 hooks(如果存在的話)，然后才停止容器，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/kuberuntime/kuberuntime_container.go#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 方法進行處理，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/status/status_manager.go#L149-L181，如下所示：
在該方法中會判斷 Pod 是否已經優雅停止了，代碼位于 https://github.com/kubernetes/kubernetes/blob/v1.22.8/pkg/kubelet/status/status_manager.go#L583-L652，如下所示：
比如會判斷是否還有容器在運行、volumes 是否還沒有清理、pod cgroup 還沒清空等等，如果 canBeDeleted 返回 true，則表示 pod 已經優雅的停止了，那么這個時候就可以向 apiserver 發送 Delete 請求，再次刪除 Pod 了。
不過這一次的設置的 GracePeriodSeconds 為 0，表示要強制刪除 Pod 了，到這里 apiserver 會再次收到 DELETE 請求，與第一次不同的是，這次是強制刪除 Pod，會去 etcd 中刪除 Pod 對象了。
這個時候 kubelet 會接受到 REMOVE 的事件，調用 HandlePodRemoves 函數去進行處理：
首先會去調用 deletePod 函數去停掉關聯的 pod worker，然后還會調用 probeManager 去移除 Pod 相關的探針 prober worker，到這里就表示 Pod 徹底從節點上刪除了。
