cilium 元件架構圖
Cilium
Agent
Cilium agent ( cilium-agent) 在叢集中的每個節點上執行。在較高階別上，代理透過 Kubernetes 或 API 接受配置，這些配置描述了網路、服務負載平衡、網路策略以及可觀測性和監控要求。Cilium agent 偵聽來自 Kubernetes 等編排系統的事件，以瞭解容器或工作負載何時啟動和停止。它管理 Linux 核心用來控制這些容器進出的所有網路訪問的 eBPF 程式。Client (CLI)
Cilium CLI 客戶端 ( cilium) 是與 Cilium agent 起安裝的命令列工具。它與在同一節點上執行的 Cilium agent 的 REST API 進行互動。CLI 允許檢查本地代理的狀態和狀況。它還提供了直接訪問 eBPF 對映以驗證其狀態的工具。Operator
Cilium Operator 負責管理叢集中的職責，邏輯上應該為整個叢集處理一次，而不是為叢集中的每個節點處理一次。Cilium 運營商並不處於任何轉發或網路策略決策的關鍵路徑中。如果Operator暫時不可用，叢集通常會繼續執行。但是，根據配置的不同，Operator可用性故障可能會導致：1. 如果運營商需要分配新的IP 地址，則 IP 地址管理 (IPAM) 會出現延遲，從而導致新工作負載的排程出現延遲。
2. 未能更新 kvstore 心跳金鑰將導致代理宣告 kvstore 不健康並重新啟動。CNI Plugin
當在節點上排程或終止 pod 時，Kubernetes 會呼叫 CNI 外掛 (cilium-cni)。它與節點的 Cilium API 互動，觸發必要的資料路徑配置，為 pod 提供網路、負載平衡和網路策略。Hubble
Server
Hubble 伺服器在每個節點上執行，並從 Cilium 檢索基於 eBPF 的可觀測性。它被嵌入到 Cilium agent中以實現高效能和低開銷。它提供 gRPC 服務來檢索流和 Prometheus 指標。Relay
Relay ( hubble-relay) 是一個獨立元件，它瞭解所有正在執行的 Hubble 伺服器，並透過連線到各自的 gRPC API 並提供代表叢集中所有伺服器的 API 來提供叢集範圍內的可觀測性。Client (CLI)
Hubble CLI (hubble) 是一個命令列工具，能夠連線到 hubble-relay 的 gRPC API 或本地伺服器來檢索流事件。Graphical UI (GUI)
圖形使用者介面 ( hubble-ui) 利用基於relay的可觀測性來提供圖形服務依賴關係和連線圖。eBPF
eBPF 是一個Linux 核心位元組碼直譯器，最初是為了過濾網路資料包而引入的，例如tcpdump 和socket 過濾器。此後，它已透過附加資料結構（例如雜湊表和陣列）以及附加操作進行了擴充套件，以支援資料包修改、轉發、封裝等。核心內驗證器可確保 eBPF 程式安全執行，並且 JIT 編譯器可轉換位元組碼CPU 架構特定指令以提高本機執行效率。eBPF 程式可以在核心中的各個掛鉤點執行，例如針對傳入和傳出資料包。Cilium 能夠探測 Linux 核心的可用功能，並在檢測到更新的功能時自動使用它們。Data Store
Cilium 需要資料儲存來在代理之間傳播狀態。它支援以下資料儲存：Kubernetes CRDs (Default)
儲存任何資料和傳播狀態的預設選擇是使用 Kubernetes 自定義資源定義 (CRD)。CRD 由 Kubernetes 為叢集元件提供，以透過 Kubernetes 資源表示配置和狀態。Key-Value Store
狀態儲存和傳播的所有要求都可以透過 Cilium 預設配置中配置的 Kubernetes CRD 來滿足。可以選擇將鍵值儲存用作最佳化，以提高叢集的可擴充套件性，因為透過直接使用鍵值儲存，更改通知和儲存要求會更加高效。目前支援的鍵值儲存有：etcd參考文件
https://docs.cilium.io/en/stable/overview/component-overview/