Kubeedge Edged概述
Kubeedge Edged概述
Overview
EdgeD是管理節點生命周期的邊緣節點模塊。它可以幫助用戶在邊緣節點上部署容器化的工作負載或應用程序。這些工作負載可以執行任何操作,從簡單的遠程遙測數據操作到分析或ML推理等等。使用kubectl云端的命令行界面,用戶可以發出命令來啟動工作負載。
通過容器運行時接口Container Runtime Interface(CRI)支持幾種符合OCI的運行時runtimes。請參閱KubeEdge運行時配置,以獲取有關如何配置邊緣以利用其他運行時的更多信息。
有許多模塊協同工作以實現edged的功能。
EdgeD Overall
Fig 1: EdgeD Functionalities
Pod Management
它是pod添加,刪除和修改的句柄。它還使用pod status manager和pleg跟蹤pod的運行狀況。其主要工作如下:
? 接收并處理來自metamanager的pod添加/刪除/修改消息。
? 處理單獨的工作隊列以添加和刪除容器。
? 處理工作程序例程以檢查工作程序隊列以執行pod操作。
? 分別為配置映射和秘密保留單獨的緩存。
? 定期清理孤立的吊艙orphaned pods
Pod Addition Flow
Fig 2: Pod Addition Flow
Pod Deletion Flow
Fig 3: Pod Deletion Flow
Pod Updation Flow
Fig 4: Pod Updation Flow
Pod Lifecycle Event Generator生命周期事件生成器
該模塊有助于監視吊艙pod的邊緣狀態。每隔一秒鐘,通過使用活動性和就緒狀態的探測,會使用窗格狀態管理器為每個窗格更新信息。
PLEG Design
Fig 5: PLEG at EdgeD
CRI for edged
Container Runtime Interface (CRI) – a plugin interface which enables edged to use a wide variety of container runtimes like Docker, containerd, CRI-O, etc., without the need to recompile. For more on how to configure KubeEdge for container runtimes, see KubeEdge runtime configuration.
容器運行時接口Container Runtime Interface(CRI)–一個插件接口,使邊緣用戶無需重新編譯即可使用各種容器運行時runtimes,例如Docker,contained,CRI-O等。有關如何為容器運行時配置KubeEdge的更多信息,請參見KubeEdge運行時配置。
Why CRI for edged?
為了在以下情況中需要CRI支持邊緣化的多個容器運行時runtimes:
? 在無法運行現有Docker運行時的資源受限邊緣節點上支持輕量級容器運行時runtime。
? 在邊緣節點上支持多個容器運行時runtime,例如Docker,contained,CRI-O等。
稍后將考慮對具有暫停容器和IP的相應CNI的支持。
CRI Design
Fig 6: CRI at EdgeD
Secret Management
在邊緣,秘密是分開處理的。對于添加,刪除和修改之類的操作,有單獨的配置消息和接口集。使用這些接口,機密會在緩存存儲中更新。下面的流程圖說明了消息流。
Secret Message Handling
Fig 7: Secret Message Handling at EdgeD
Edged使用MetaClient模塊從MetaManager獲取機密。如果邊緣查詢尚未存儲在MetaManager中的新機密,則該請求將轉發到云。在發送包含機密的響應之前,MetaManager將其存儲在本地數據庫中。隨后將從數據庫檢索對同一密鑰的查詢,從而減少了等待時間。下面的流程圖顯示了如何從MetaManager和云中獲取機密。它還描述了機密如何存儲在MetaManager中。
Query Secret
Fig 8: Query Secret by EdgeD
Probe Management
探針管理分別創建兩個探針,以準備就緒和活動,以便吊艙監視容器。就緒探針可通過監視容器何時達到運行狀態來提供幫助。活動性探針可通過監視吊艙的健康狀況(指示吊艙處于打開還是關閉狀態)來提供幫助。如前所述,PLEG模塊使用其服務。
ConfigMap Management
在有邊緣的情況下,ConfigMap也被單獨處理。對于添加,刪除和修改之類的操作,有單獨的配置消息和接口集。使用這些接口,可以在緩存存儲中更新ConfigMap。下面的流程圖說明了消息流。
ConfigMap Message Handling
Fig 9: ConfigMap Message Handling at EdgeD
Edged使用MetaClient模塊從MetaManager獲取ConfigMap。如果邊緣查詢尚未存儲在MetaManager中的新ConfigMap,則該請求將轉發到云。在發送包含ConfigMap的響應之前,MetaManager將其存儲在本地數據庫中。隨后將從數據庫檢索對同一ConfigMap密鑰的查詢,從而減少了延遲。下面的流程圖顯示了如何從MetaManager和Cloud獲取ConfigMap。它還描述了ConfigMap如何存儲在MetaManager中。
Query Configmaps
Fig 10: Query Configmaps by EdgeD
Container GC
The container garbage collector is an edged routine which wakes up every minute, collecting and removing dead containers using the specified container gc policy. The policy for garbage collecting containers is determined by three variables, which can be user-defined:
容器垃圾收集器是一個邊緣例程,它每分鐘喚醒一次,使用指定的容器gc策略收集和刪除死容器。垃圾收集容器的策略由三個變量確定,可以由用戶定義:
? MinAge 是可以收集垃圾的最小年齡,零是無限制的。
? MaxPerPodContainer 是允許任何單個吊艙(UID,容器名稱)對具有的失效容器的最大數量,不超過零且沒有限制。
? MaxContainers是死容器總數的最大數量,無限制地小于零。通常,最舊的容器會先被移除。
Image GC
圖像垃圾收集器是一個邊緣程序,每5秒喚醒一次,并根據使用的策略收集有關磁盤使用情況的信息。垃圾收集圖像的策略考慮了兩個因素:HighThresholdPercent和LowThresholdPercent。磁盤使用率高于高閾值將觸發垃圾回收,垃圾收集將嘗試刪除未使用的映像,直到達到低閾值為止。首先刪除最近最少使用的圖像。
Status Manager
狀態管理器是一個獨立的邊緣例程,它每10秒收集一次pod狀態,并使用metaclient接口將該信息轉發到云。
Status Manager Flow
Fig 11: Status Manager Flow
Volume Management
卷管理器作為邊緣例程運行,該邊緣例程基于在邊緣節點上安排的容器,帶出要附加/安裝/卸載/分離哪些卷的信息。
在啟動Pod之前,將附加并安裝Pod規格中引用的所有指定卷,直到阻塞該流及其其它操作。
MetaClient
Metaclient是Metamanger for Edge的接口。它有助于從Metamanager或云中獲取ConfigMap和秘密詳細信息。它還向metamanger發送同步消息,節點狀態和pod狀態到云。
總結
以上是生活随笔為你收集整理的Kubeedge Edged概述的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 3D MinkowskiEngine稀疏
- 下一篇: CloudHub概述