目錄

引言

一、List-Watch機制概述

（一）基本概念

（二）工作機制

1.List操作

2.Watch操作

（三）數據流向

1.按模塊劃分

2.按整體總結

二、Pod生命周期

（一）生命周期

1.創建

2.調度

3.初始化容器啟動

4.鏡像拉取

5.容器創建與運行

6.健康檢查與就緒檢測

7.重啟策略

8.清理

9.終止

（二）生命周期狀態

1.Pending

2.Running

3.Succeeded

4.Failed

5.Unknown

---

引言

在Kubernetes（K8s）這個龐大的分布式系統中，資源的實時更新和響應對于維持集群的穩定性和高效性至關重要。而List-Watch機制正是Kubernetes實現這一目標的核心手段。本文將詳細介紹Kubernetes中的List-Watch機制，與容器的生命周期。包括其工作原理、應用場景以及性能優化等方面。

一、List-Watch機制概述

（一）基本概念

List-Watch是Kubernetes API Server提供的一種資源監控機制。它允許客戶端通過API Server獲取資源對象的列表（List），并通過建立長連接（Watch）來實時監控資源對象的變化。當資源對象發生創建、更新或刪除等操作時，API Server會向訂閱了相關資源的客戶端發送事件通知，實現資源的實時同步和響應

（二）工作機制

List-Watch機制的工作原理可以簡單概括為以下兩個步驟

1.List操作

客戶端向Kubernetes API Server發送List請求，指定要獲取的資源類型和篩選條件。API Server根據請求返回符合條件的資源對象列表。客戶端可以根據這個列表來初始化自己的狀態或進行其他操作。

2.Watch操作

客戶端在獲取到資源對象列表后，可以繼續向API Server發送Watch請求，建立與API Server的長連接。API Server會持續監控指定資源的變化，并將變化事件以流的形式發送給客戶端。客戶端可以解析這些事件通知，并觸發相應的處理邏輯。

（三）數據流向

1.按模塊劃分

初始化階段：Kubernetes的各種組件（如Controller Manager、Scheduler、kubelet等）在啟動時，會與APIServer建立連接，并初始化List-Watch機制。

List操作：組件向APIServer發送List請求，獲取當前集群中指定資源類型的所有資源對象列表。例如，Controller Manager可能會請求獲取所有Pod的列表。APIServer處理List請求，查詢etcd存儲系統，并將結果返回給組件。

Watch操作：組件向APIServer發送Watch請求，建立一個長連接，用于監聽指定資源類型的變化。APIServer處理Watch請求，并在內部與etcd建立Watch連接，以監聽etcd中對應資源的變化。

事件觸發：當etcd中的資源發生變化（如Pod的創建、更新或刪除）時，etcd會發送一個事件通知給APIServer。APIServer接收到事件通知后，會將事件封裝成HTTP響應，并通過之前建立的長連接發送給對應的組件。

組件處理：組件接收到APIServer發送的事件通知后，會解析通知中的信息，并根據事件的類型（如ADD、UPDATE、DELETE）執行相應的操作。例如，如果Controller Manager接收到Pod被創建的事件，它可能會觸發相應的控制器邏輯，如ReplicaSet控制器會根據Pod的創建來調整副本集的狀態。

數據同步：通過List-Watch機制，Kubernetes的各個組件能夠實時感知集群中資源的變化，并據此進行相應的操作，從而保持數據的同步和一致性。

2.按整體總結

1）這里有三個 List-Watch，分別是 Controller Manager（運行在 Master），Scheduler（運行在 Master），kubelet（運行在 Node）。 它們在進程已啟動就會監聽（Watch）APIServer 發出來的事件

2）用戶通過 kubectl 或其他 API 客戶端提交請求給 APIServer 來建立一個 Pod 對象副本。

3）APIServer將Pod對象的元數據信息存入ETCD當中，待存儲完畢后，APIServer會將確認信息返回給客戶端，同時ETCD會將創建Pod副本的事件發送給APIServer

4）由于Controller-Manager 一直在監聽（Watch，通過https的6443端口）APIServer 中的事件。此時 APIServer 接受到了Create（創建Pod副本）事件，又會發送給Controller Manager

5）Controller Manager 在接到 Create 事件以后，調用其中的 Replication Controller 來保證 Node 上面需要創建的副本數量。一旦副本數量少于 RC 中定義的數量，RC 會自動創建副本。總之它是保證副本數量的 Controller（PS：擴容縮容的擔當）

6）在Controller-Manager創建Pod副本以后，APIServer會在ETCD中記錄這個Pod的詳細信息。例如Pod的副本數，Container的內容是什么

7）同樣的ETCD會將創建Pod的信息通過事件發送給APIServer

8）由于Scheduler在監聽（Watch）APIServer，APIServer會將Create事件發送到Scheduler，Scheduler接收到事件后，會根據預選與優選策略，為該事件選擇合適的node節點，

9）Scheduler 調度完畢以后會更新Pod的信息，此時的信息更加豐富了。除了知道Pod的副本數量，副本內容。還知道部署到哪個Node上面了。并將上面的Pod信息更新至API Server，

10）?APIServer更新至ETCD中，保存起來

11）ETCD將更新成功的事件發送給 APIServer，APIServer 也開始反映此 Pod 對象的調度結果

12）kubelet是在Node上面運行的進程，它也通過List-Watch的方式監聽（Watch，通過https的6443端口）APIServer發送的Pod更新的事件。kubelet會嘗試在當前節點上調用Docker啟動容器，并將Pod以及容器的結果狀態回送至APIServer，同時kubelet會負責Pod的整個生命周期

13）最后，APIServer將Pod狀態信息存入ETCD中。在ETCD確認寫入操作成功完成后，APIServer將確認信息發送至相關的kubelet，事件將通過它被接受

注釋：kubelet持續監控Pod狀態，當kubectl發送刪除、擴容、縮容等指令時，會將以上流程重復一遍，而后根據最新的情況，在node節點中調整部署資源

二、Pod生命周期

Pod的生命周期從創建開始，經歷一系列階段直至最終終止或被刪除。

（一）生命周期

1.創建

用戶通過創建一個新的Pod對象來請求Kubernetes調度器為Pod分配資源。

Kubernetes系統會賦予Pod一個唯一的ID（UID）。

2.調度

Pod被提交到集群后，調度器根據節點資源可用性和Pod的資源需求、親和性/反親和性規則等選擇合適的節點，并將Pod綁定到該節點上。

3.初始化容器啟動

若Pod定義中包含初始化容器（init containers），這些容器會在主容器啟動前按順序執行，用于設置運行主容器所需的條件或環境。

每個Init容器都必須在下一個Init容器啟動之前成功完成。

如果Pod的Init容器失敗，并且Pod的重啟策略（restartPolicy）值為“Always”，則kubelet會不斷地重啟該Init容器直到該容器成功為止。但如果Pod的重啟策略值為“Never”，則Kubernetes不會重新啟動Pod。

4.鏡像拉取

主容器對應的鏡像如果沒有在節點上，則kubelet負責從注冊表中拉取鏡像。

5.容器創建與運行

kubelet根據Pod Spec創建并啟動主容器。

容器狀態會經歷從Pending（等待中）到Running（運行中）的變化。

6.健康檢查與就緒檢測

在容器運行期間，kubelet可以配置并執行健康檢查（liveness probes）和就緒檢查（readiness probes）以確保容器正常工作。

Liveness Probe用于判斷容器是否存活，若失敗則可能重啟容器。

Readiness Probe用于決定容器是否準備好接收流量，只有當容器處于ready狀態時，Service才會將其添加到服務端點列表中。

7.重啟策略

根據Pod的重啟策略（Always、OnFailure或Never），kubelet會決定在容器退出時應采取何種行動。

8.清理

當Pod被刪除或者由于某種原因需要終止時，kubelet會按照預定義的優雅關閉策略通知容器停止服務，并等待一段時間讓容器完成任何必要的清理操作。

清理完成后，kubelet會真正刪除Pod及其相關的容器實例和其他資源。

9.終止

Pod完全從節點上移除。

此外，Pod生命周期中還包括容器啟動后鉤子（post-start hook）和停止前鉤子（pre-stop hook），這些鉤子允許在容器啟動后和停止前執行特定的操作。

（二）生命周期狀態

Pod的生命周期狀態主要包括

1.Pending

Pod已經被Kubernetes系統接受，但是有一個或多個容器鏡像尚未創建。

Pod等待被調度到一個節點上。可能涉及下載鏡像、分配IP地址、執行初始化容器等操作。

如果Pod一直處于等待中，可能是由于資源不足、調度問題或其他原因導致。

2.Running

Pod已經被調度至某節點，所有容器都已經被kubelet創建完成，且至少有一個容器處于啟動、重啟或運行過程中。

3.Succeeded

Pod中的所有容器都已成功完成并退出。

通常適用于一次性或批處理作業。

4.Failed

Pod中的一個或多個容器由于某種原因失敗。

這可能是由于容器的退出代碼非零、初始化容器失敗、依賴資源不可用等原因導致。

5.Unknown

由于某種原因，Pod的狀態無法確定。

這可能是由于與API服務器的通信問題或其他異常情況導致。