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/
