K8s工作流程詳解

iqsing發表於2021-09-15
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主要實現的作用如下：

  1. 更快地返回 List/Get 請求，減少對 Kubenetes API 的直接呼叫

使用 Informer 例項的 Lister() 方法， List/Get Kubernetes 中的 Object 時，Informer 不會去請求 Kubernetes API，而是直接查詢快取在本地記憶體中的資料，依賴Etcd的List&Watch機制，客戶端及時獲知這些物件的狀態變化，然後更新本地快取，這樣就在客戶端為這些API物件維護了一份和Etcd資料庫中幾乎一致的資料，然後控制器等客戶端就可以直接訪問快取獲取物件的資訊，而不用去直接訪問apiserver。通過這種方式，Informer 既可以更快地返回結果，又能減少對 Kubernetes API 的直接呼叫。

  1. 可監聽事件並觸發回撥函式

Informer 通過 Kubernetes Watch API 監聽某種 resource 下的所有事件。Watch API 本質上就是一種 APIServer 主動向客戶端推送 Kubernetes 資源修改、建立的一種機制。這樣我們就可以獲取到資源的變更，及時更新物件狀態。

關於k8s中 informer詳細可參考：kubenetes informer 詳解

通過上面我們知道了控制器是通過watch api監聽apiserver中資源物件的更新，下面我們進入正題：k8s工作流程。

二、k8s工作流程

我們來看通過deployment部署pod的常規流程：

image-20210914114226232

  1. kubectl向apiserver傳送部署請求（例如使用 kubectl create -f deployment.yml）

  2. apiserver將 Deployment 持久化到etcd；etcd與apiserver進行一次http通訊。

  3. controller manager通過watch api監聽 apiserver ，deployment controller看到了一個新建立的deplayment物件更後，將其從佇列中拉出，根據deployment的描述建立一個ReplicaSet並將 ReplicaSet 物件返回apiserver並持久化回etcd。

    以此類推，當replicaset控制器看到新建立的replicaset物件，將其從佇列中拉出，根據描述建立pod物件。

  4. 接著scheduler排程器看到未排程的pod物件，根據排程規則選擇一個可排程的節點，載入到pod描述中nodeName欄位，並將pod物件返回apiserver並寫入etcd。

  5. kubelet在看到有pod物件中nodeName欄位屬於本節點，將其從佇列中拉出，通過容器執行時建立pod中描述的容器。

上面我們說到的deployment-replicaset-pod的關係如下：

Deploy-Replica-Pod

希望小作文對你有些許幫助，如果內容有誤請指正。

您可以隨意轉載、修改、釋出本文，無需經過本人同意。 沒什麼用的blog：iqsing.github.io

相關文章