K8s工作流程詳解
在學習k8s工作流程之前，我們得再次認識一下上篇k8s架構與組件詳解中提到的kube-controller-manager一個k8s中許多控制器的進程的集合。
比如Deployment 控制器（DeploymentController）和 Job 控制器（JobController）是 Kubernetes 內置控制器的典型例子。在 Kubernetes 中，一個控制器至少追蹤一種類型的 Kubernetes 資源。這些 資源對象有一個代表期望狀態的 spec 欄位。 該資源的控制器負責所屬對象當前狀態接近期望狀態。
一、控制器與apiserver的交互
上面提到的這些資源的控制器是如何確保資源對象當前狀態接近於期望狀態？
當然是持續同步apiserver中（查詢etcd）資源對象的元數據，並不斷更新對象屬性。是這樣么？
當集群中有幾十上百萬個資源對象時，光控制器的http同步請求就夠apiserver喝一壺的，顯然不太棒。所以Kubernetes採用了一個叫Informer的機制。Informer 是 Client-go 中的一個核心工具包。
在這裡informer主要實現的作用如下：
-
更快地返回 List/Get 請求，減少對 Kubenetes API 的直接調用
使用 Informer 實例的 Lister() 方法， List/Get Kubernetes 中的 Object 時，Informer 不會去請求 Kubernetes API，而是直接查找快取在本地記憶體中的數據，依賴Etcd的List&Watch機制，客戶端及時獲知這些對象的狀態變化，然後更新本地快取，這樣就在客戶端為這些API對象維護了一份和Etcd資料庫中幾乎一致的數據，然後控制器等客戶端就可以直接訪問快取獲取對象的資訊，而不用去直接訪問apiserver。通過這種方式，Informer 既可以更快地返回結果，又能減少對 Kubernetes API 的直接調用。
-
可監聽事件並觸發回調函數
Informer 通過 Kubernetes Watch API 監聽某種 resource 下的所有事件。Watch API 本質上就是一種 APIServer 主動向客戶端推送 Kubernetes 資源修改、創建的一種機制。這樣我們就可以獲取到資源的變更，及時更新對象狀態。
關於k8s中 informer詳細可參考：kubenetes informer 詳解
通過上面我們知道了控制器是通過watch api監聽apiserver中資源對象的更新，下面我們進入正題：k8s工作流程。
二、k8s工作流程
我們來看通過deployment部署pod的常規流程：
-
kubectl向apiserver發送部署請求（例如使用 kubectl create -f deployment.yml）
-
apiserver將 Deployment 持久化到etcd；etcd與apiserver進行一次http通訊。
-
controller manager通過watch api監聽 apiserver ，deployment controller看到了一個新創建的deplayment對象更後，將其從隊列中拉出，根據deployment的描述創建一個ReplicaSet並將 ReplicaSet 對象返回apiserver並持久化回etcd。
以此類推，當replicaset控制器看到新創建的replicaset對象，將其從隊列中拉出，根據描述創建pod對象。
-
接著scheduler調度器看到未調度的pod對象，根據調度規則選擇一個可調度的節點，載入到pod描述中nodeName欄位，並將pod對象返回apiserver並寫入etcd。
-
kubelet在看到有pod對象中nodeName欄位屬於本節點，將其從隊列中拉出，通過容器運行時創建pod中描述的容器。
上面我們說到的deployment-replicaset-pod的關係如下：
希望小作文對你有些許幫助，如果內容有誤請指正。
您可以隨意轉載、修改、發布本文，無需經過本人同意。 沒什麼用的blog：iqsing.github.io
