[TOC]  Cilium 和 Hubble 的部署由在集群中運行的以下組件組成： # Cilium ## Agent Cilium 代理（cilium-agent）在集群中的每個節點上運行。 在較高級別上，代理通過 Kubernetes 或 API 接受配置，這些配置描述了網絡、服務負載平衡、網絡策略以及可見性和監控要求。 Cilium 代理偵聽來自 Kubernetes 等編排系統的事件，以了解容器或工作負載何時啟動和停止。 它管理 Linux 內核用來控制這些容器進出的所有網絡訪問的 eBPF 程序。 ## Client (CLI) Cilium CLI 客戶端 (cilium) 是與 Cilium 代理一起安裝的命令行工具。 它與在同一節點上運行的 Cilium 代理的 REST API 進行交互。 CLI 允許檢查本地代理的狀態和狀況。 它還提供了直接訪問 eBPF 映射以驗證其狀態的工具。 >[info] 此處描述的代理內 Cilium CLI 客戶端不應與用于在 Kubernetes 集群上快速安裝、管理 Cilium 和進行故障排除的命令行工具混淆，后者也稱為 cilium。 該工具通常安裝在遠離集群的地方，并使用 kubeconfig 信息通過 Kubernetes API 訪問在集群上運行的 Cilium。 ## Operator Cilium Operator 負責管理集群中的職責，邏輯上應該為整個集群處理一次，而不是為集群中的每個節點處理一次。 Cilium 運營商并不處于任何轉發或網絡策略決策的關鍵路徑中。 如果 Operator 暫時不可用，集群通常會繼續運行。 但是，根據配置的不同，Operator 的可用性故障可能會導致： - 如果需要 Cilium Operator 分配新的 IP 地址，IP 地址管理 (IPAM) 會出現延遲，從而導致新工作負載的調度出現延遲 - 未能更新 kvstore 心跳密鑰將導致代理聲明 kvstore 不健康并重新啟動。 ## CNI Plugin 當 pod 在節點上調度或終止時，Kubernetes 會調用 CNI 插件 (cilium-cni)。 它與節點的 Cilium API 交互，觸發必要的數據路徑配置，為 pod 提供網絡、負載平衡和網絡策略。 # Hubble ## Server Hubble 服務器在每個節點上運行，并從 Cilium 檢索基于 eBPF 的可見性。 它被嵌入到 Cilium 代理中以實現高性能和低開銷。 它提供 gRPC 服務來檢索流和 Prometheus 指標。 ## Relay Relay (hubble-relay) 是一個獨立組件，它了解所有正在運行的 Hubble 服務器，并通過連接到各自的 gRPC API 并提供代表集群中所有服務器的 API 來提供集群范圍內的可見性。 ## Client (CLI) Hubble CLI (hubble) 是一個命令行工具，能夠連接到 hubble-relay 的 gRPC API 或本地服務器來檢索流事件。 ## Graphical UI (GUI) 圖形用戶界面 (hubble-ui) 利用基于中繼的可見性來提供圖形服務依賴關系和連接圖。 # eBPF eBPF 是一個 Linux 內核字節碼解釋器，最初是為了過濾網絡數據包而引入的，例如 tcpdump 和套接字過濾器。 此后，它已通過附加數據結構（例如哈希表和數組）以及附加操作進行了擴展，以支持數據包修改、轉發、封裝等。內核內驗證器可確保 eBPF 程序安全運行，并且 JIT 編譯器可轉換字節碼 CPU 架構特定指令以提高本機執行效率。 eBPF 程序可以在內核中的各個掛鉤點運行，例如針對傳入和傳出數據包。 Cilium 能夠探測 Linux 內核的可用功能，并在檢測到更新的功能時自動使用它們。 # Data Store Cilium 需要數據存儲來在代理之間傳播狀態。 它支持以下數據存儲： 1. Kubernetes CRDs (Default) 存儲任何數據和傳播狀態的默認選擇是使用 Kubernetes 自定義資源定義 (CRD)。 CRD 由 Kubernetes 為集群組件提供，以通過 Kubernetes 資源表示配置和狀態。 2. Key-Value Store 狀態存儲和傳播的所有要求都可以通過 Cilium 默認配置中配置的 Kubernetes CRD 來滿足。 可以選擇將鍵值存儲用作優化，以提高集群的可擴展性，因為通過直接使用鍵值存儲，更改通知和存儲要求會更加高效。 目前支持的鍵值存儲有：etcd > 可以直接利用 Kubernetes 的 etcd 集群，也可以維護專用的 etcd 集群。