Kubernetes源碼分析之Pod的刪除

本文主要梳理刪除Pod時，Pod的執行流程

kube-apiserver的任務

咱們一般使用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方法）

該方法最終的處理handler爲 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的變化

如圖，監聽到相應的變化以後，調用相應的處理邏輯。同時，kubelet還啓動了一個goroutine： statusManager

在syncLoop以前調用了statusManager的start方法啓動statusManager。
start方法以下：

主要的任務就是經過監聽事件的變化，調用 syncPod方法。在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信息。

kubelet接收到事件變化以後，轉化爲 REMOVE事件，完成Pod的最終清理工做。至此，Pod刪除流程結束。

總結

優雅刪除Pod時：
一、apiserver handler執行了兩次，第一次主要是修改Pod信息，設置DeletionTimestamp和DeletionGracePeriodSeconds信息，第二次去數據庫etcd刪除Pod信息；
二、kubelet經過檢測到Pod內的資源已經徹底釋放以後，觸發了第二次刪除事件，且是強制刪除Pod；
三、kubelet的DELETE操做其實監聽到的是Pod的更新事件，Pod刪除以後，執行的是REMOVE操做；
四、處理流程爲：客戶端請求刪除Pod-->apiserver更新Pod信息-->kubelet優雅釋放Pod資源-->kubelet請求刪除Pod-->apiserver刪除etcd中Pod信息-->kubelet完成最終Pod的資源清理。