Kubernetes原始碼分析之Pod的刪除
我們通常使用kubectl命令刪除Pod，或者通過http協議直接呼叫apiserver暴露的介面去刪除Pod。所以，刪除Pod的起源肯定在apiserver這兒。
在之前分析kube-apiserver部分有分析到，kube-apiserver的http處理架構使用的是go-restful。其中，對於刪除，呼叫的自然是 DELETE 介面。方法如下（位於 kubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/install.go下的registerResourceHandlers方法 ）
restfulDeleteResource
restfulDeleteResource 繼續封裝handler，呼叫了
DeleteResource 方法。
DeleteResource 方法很長，但最終呼叫的還是
DELETE
方法，如下
DELETE 方法位於
staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go 下。在
DELETE 方法中，最主要的是
updateForGracefulDeletionAndFinalizers 方法，該方法的主要作用就是用來改變Pod的一些內部資訊，其實就是改變Pod的兩個欄位：
DeletionTimestamp 以及
DeletionGracePeriodSeconds ，呼叫的是
BeforeDelete
方法
通過比對工具也可以發現，主要的欄位改變如下
kubelet的任務
通過之前分析過kubelet的程式碼得知，kubelet一直在通過listwatch監聽apiserver的變化
在syncLoop之前呼叫了statusManager的start方法啟動statusManager。
start方法如下：
方法。在syncPod方法有下面一段程式碼
我們發現，kubelet又去呼叫了一次DELETE介面，這是為什麼呢？不是已經刪除了嗎？別急，這才是我們要分析的DELETE操作最核心的部分。
深層分析
我們知道，Pod的刪除如果不去強制刪除，則其實是一個優雅的刪除，也就是一個graceful的刪除。預設情況下，這個優雅的時間是30s，也就是 grace-period 的時間。在kube-apiserver的任務中，通過 updateForGracefulDeletionAndFinalizers 方法為Pod設定了 DeletionTimestamp 和 DeletionGracePeriodSeconds 兩個欄位，此時Pod定義為graceful的狀態。回到程式碼處，呼叫完 updateForGracefulDeletionAndFinalizers 方法後，下面有一個判斷的語句
很顯然，因為我們是優雅刪除，所以 deleteImmediately 欄位false，刪除到此結束。是不是與我們想象的完全不一樣？
沒錯，實際情況的確是這樣，每次刪除的時候，apiserver的處理邏輯到此就中斷了。接下來就要重新認識kubelet了。
Kubelet在呼叫apiserver的刪除介面的時候，提前會有一個判斷，呼叫鏈為canBeDeleted-->PodResourcesAreReclaimed 。在
PodResourcesAreReclaimed 方法內，主要的任務就是判斷Pod內的資源是否已經完全關閉和清理，包括
containers 、
processes 、
volumes 以及
cgroup sandbox
資源。
canBeDeleted 方法返回true，kubelet呼叫apiserver的delete介面再次刪除Pod。不過，與優雅刪除不同的是，這次呼叫，多了一個
deleteOptions
欄位
意思很好理解，就是設定grace-period欄位為0，表示這次是強制刪除Pod。因此，apiserver會再次收到DELETE的請求，繼續執行DELETE handler的流程。與第一次不同的時，這次是強制刪除Pod，所以會執行完整的過程，apiserver去etcd刪除最終的Pod資訊。
事件，完成Pod的最終清理工作。至此，Pod刪除流程結束。