Cilium
Cilium
目录
组件概述
Cilium 和 Hubble 的部署由在集群中运行的以下组件组成：
Cilium
Agent 代理人
Cilium 代理 ( cilium-agent ) 在集群中的每个节点上运行。在较高级别上，代理通过 Kubernetes 或 API 接受配置，这些配置描述了网络、服务负载平衡、网络策略以及可见性和监控要求。
Cilium 代理侦听来自 Kubernetes 等编排系统的事件，以了解容器或工作负载何时启动和停止。它管理 Linux 内核用来控制这些容器进出的所有网络访问的 eBPF 程序。
Client (CLI) 客户端（命令行）
Cilium CLI 客户端 ( cilium ) 是一个与 Cilium 代理一起安装的命令行工具。它与在同一节点上运行的 Cilium 代理的 REST API 进行交互。 CLI 允许检查本地代理的状态和状况。它还提供了直接访问 eBPF 映射以验证其状态的工具。
此处描述的代理内 Cilium CLI 客户端不应与 用于在 Kubernetes 集群上快速安装、管理 Cilium 和进行故障排除的命令行工具 相混淆，后者也具有名称 cilium 。该工具通常安装在远离集群的地方，并使用 kubeconfig 信息通过 Kubernetes API 访问在集群上运行的 Cilium。
Operator
Cilium Operator 负责管理集群中的职责，逻辑上应该为整个集群处理一次，而不是为集群中的每个节点处理一次。 Cilium 运营商并不处于任何转发或网络策略决策的关键路径中。如果操作员暂时不可用，集群通常会继续运行。但是，根据配置的不同，操作员无法使用可能会导致：
- 如果 运营商 (IP Address Management, IPAM 需要分配新的 IP 地址，则 IP 地址管理 (IPAM) 会出现延迟，从而导致新工作负载的调度出现延迟
- 未能更新 kvstore 心跳密钥将导致代理声明 kvstore 不健康并重新启动。
CNI插件
当在节点上调度或终止 pod 时，Kubernetes 会调用 CNI 插件 ( cilium-cni )。它与节点的 Cilium API 交互，触发必要的数据路径配置，为 pod 提供网络、负载平衡和网络策略。
Hubble
服务器
Hubble 服务器在每个节点上运行，并从 Cilium 检索基于 eBPF 的可见性。它被嵌入到 Cilium 代理中以实现高性能和低开销。它提供 gRPC 服务来检索流和 Prometheus 指标。
Relay 中继
Relay ( hubble-relay ) 是一个独立组件，它了解所有正在运行的 Hubble 服务器，并通过连接到各自的 gRPC API 并提供代表集群中所有服务器的 API 来提供集群范围内的可见性。
Client (CLI) 客户端（命令行）
Hubble CLI ( hubble ) 是一个命令行工具，能够连接到 hubble-relay 的 gRPC API 或本地服务器来检索流事件。
图形用户界面 (GUI)
图形用户界面 ( hubble-ui ) 利用基于中继的可见性来提供图形服务依赖关系和连接图。
eBPF
eBPF 是一个 Linux 内核字节码解释器，最初是为了过滤网络数据包而引入的，例如tcpdump 和套接字过滤器。此后，它已通过附加数据结构（例如哈希表和数组）以及附加操作进行了扩展，以支持数据包修改、转发、封装等。内核内验证器可确保 eBPF 程序安全运行，并且 JIT 编译器可转换字节码CPU 架构特定指令以提高本机执行效率。 eBPF 程序可以在内核中的各个挂钩点运行，例如针对传入和传出数据包。
Cilium 能够探测 Linux 内核的可用功能，并在检测到更新的功能时自动使用它们。
有关内核版本的更多详细信息，请参阅：Linux 内核
Data Store
Cilium 需要数据存储来在代理之间传播状态。它支持以下数据存储：
Kubernetes CRDs（默认）
存储任何数据和传播状态的默认选择是使用 Kubernetes 自定义资源定义 (CRD)。 CRD 由 Kubernetes 为集群组件提供，以通过 Kubernetes 资源表示配置和状态。
Key-Value Store 键值存储
状态存储和传播的所有要求都可以通过 Cilium 默认配置中配置的 Kubernetes CRD 来满足。可以选择将键值存储用作优化，以提高集群的可扩展性，因为通过直接使用键值存储，更改通知和存储要求会更加高效。
目前支持的键值存储有：
可以直接利用 Kubernetes 的 etcd 集群，也可以维护专用的 etcd 集群。