[閱讀指南]
基于kubernetes 1.27 stage版本
為了方便閱讀,后續所有代碼均省略了錯誤處理及與關注邏輯無關的部分。
文章目錄
- 關于client-go
- Informer是什么
- 為什么需要informer
- Informer工作流程
- 后續分析計劃
關于client-go
client-go是kubernetes節點與服務端進行資源交互的客戶端庫,提供了非常多的功能與組件,用來與Kubernetes API 進行交互與操作。常見的功能有管理和同步kubernetes資源、管理本地kubernetes資源緩存、認證和授權等。
Informer是什么
Informer 是一種建立在client-上的資源同步和事件監聽的機制。它可以監控集群中的資源變化,并在資源發生變化時觸發事件通知。他用到了Informer 通過與 Kubernetes API Server 進行交互,獲取資源的最新狀態,再將這些狀態同步到本地緩存中。
為什么需要informer
當涉及大規模、高性能的系統時,直接與 API Server 通信可能會導致一些挑戰和性能問題,而 Informer 的引入可以有效地減少 API Server 的壓力,降低網絡開銷,實現響應式事件監聽,提高應用程序的性能和響應速度,以及處理資源同步和沖突問題。這使得系統更加高效、穩定和可靠。
舉個栗子。公司舉辦團建,如果通過私聊每個人來通知活動地點和活動,需要花費非常多的時間和精力。而將參與活動的人拉群并發一條公告,就能快速地同步團建信息了。informer就像是給clients拉了個群,將api-server的信息通過公告進行同步。
Informer工作流程
informer用到client-go的幾個關鍵組件
reflecter
負責監聽特定的kubernetes資源變化事件。informer
負責從delta FIFO隊列中取出資源變化事件,并進行緩存與索引的操作。indexer
負責管理存儲資源對象的索引。custom controller
根據資源變化實現本地節點的一些管理操作,本地的kubernetes應用可以通過實現controller監控服務端資源的變化。
下面的圖介紹了各個模塊之間是怎么交互和工作的。
根據這個關系圖,可以了解到客戶端的整個資源同步流程。簡單地看就是如下幾步,
- reflecter通過list/watch方法監聽kubernetes api的資源變化 ->
1
- reflecter將監聽到的資源變化對象添加到fifo隊列中 ->
2
- informer從隊列取出資源變化對象,并將取出的對象同步到本地緩存 ->
3,4,5
- 同步緩存時,也會將資源對象回調至custom handler ->
6
- custom handler將資源對象加入到workqueue中等待處理 ->
7
- work進程從workqueue中取出資源對象,再進行額外的處理操作 ->
8,9
后續分析計劃
后續將會按照這個同步流程的順序來詳細分析每個模塊的代碼和設計邏輯。
分析計劃:
- Informer
- Refletor
- Resync機制
- DeltaFIFO
- Indexer
- Informer
- stream list VS list