3. Operator 角色解析：Cilium Operator 在集群中的职责、Endpoint 管理、Identity 同步、Node 监控

Cilium Operator 是 Cilium 控制面的核心组件之一，它运行在 Kubernetes 集群的 控制平面节点 上，负责管理集群级别的全局状态。与每个节点上运行的 Cilium Agent 不同，Operator 不处理数据平面的转发逻辑，而是专注于协调 Kubernetes 资源与 Cilium 内部状态的一致性。理解 Operator 的职责是进行容量调优的前提。

3.1 核心职责概览

Operator 的主要职责可以归纳为以下四个关键领域：

  • Endpoint 管理： 监控 Pod 的生命周期，创建、更新和删除 CiliumEndpoint (CEP) 资源。
  • Identity 同步： 为 Pod 分配和管理安全标识 (Security Identity)，并确保其与 Kubernetes 标签的一致性。
  • Node 监控： 监控集群节点的状态变化，管理节点间的隧道或路由配置。
  • 资源协调： 处理 CiliumNetworkPolicy (CNP) 和 CiliumClusterwideNetworkPolicy (CCNP) 的全局状态。
关键认知： Operator 是“大脑”，负责决策和状态管理；Agent 是“手脚”，负责执行数据平面的转发规则。Operator 的故障会导致新 Pod 无法获得 Identity 或网络策略无法生效，但不会影响已有连接的转发。
Cilium Operator 集群角色与交互图 Cilium Operator 集群角色与交互 Kubernetes API Server Cilium Operator Cilium Agent (Node-1) Cilium Agent (Node-2) Cilium Agent (Node-N) Watch / List 同步 Identity 下发 CNP Node 监控 说明： Operator 通过 Watch API 监听 Kubernetes 资源变化，处理后通过 CRD 或 gRPC 将结果同步给各节点的 Agent。

3.2 Endpoint 管理：Pod 生命周期的映射

当 Kubernetes 创建一个 Pod 时，Cilium Operator 会负责创建对应的 CiliumEndpoint (CEP) 自定义资源。CEP 是 Pod 在 Cilium 网络模型中的抽象，它记录了 Pod 的 IP 地址、安全标识 (Identity)、所属节点以及网络策略的生效状态。

阶段 Operator 行为 触发条件
Pod 创建 监听 Pod 事件，创建 CEP 对象，分配初始 Identity Pod 进入 Running 状态且 IP 已分配
Pod 更新 更新 CEP 中的标签、Identity 或网络策略状态 Pod 标签变更或关联的 CNP 更新
Pod 删除 删除对应的 CEP 对象，回收 Identity Pod 进入 Terminating 状态
CEP 同步 将 CEP 状态写回 Kubernetes API Server，供 Agent 读取 周期性或事件驱动
调优要点： 在大型集群中（>1000 个 Pod），CEP 对象的数量会急剧增加。Operator 需要处理大量的 Watch 事件和 API 写入操作。此时应关注 Operator 的 --cilium-endpoint-gc-interval 参数（默认 5 分钟），适当增大该值可以减少 API Server 的负载，但会延长已删除 Pod 的 CEP 残留时间。

3.3 Identity 同步：安全标识的生命周期

Identity 是 Cilium 安全策略的核心。每个 Pod 根据其标签组合被分配一个 24 位的数字标识。Operator 负责维护一个全局的 Identity 池，并确保 Identity 与标签组合的映射关系在整个集群中保持一致。

Identity 的分配流程如下：

  1. 标签提取： Operator 监听 Pod 或 Endpoint 的标签变化。
  2. 标签哈希： 将标签集合进行哈希计算，生成一个唯一的标识符。
  3. Identity 分配： 从全局池中查找或创建一个新的 Identity 对象（CRD: CiliumIdentity）。
  4. 同步到 Agent： 将 Identity 信息通过 gRPC 或共享的 KV Store（如 etcd）同步给所有相关的 Agent。
Identity 分配与同步流程 Identity 分配与同步流程 1. Pod 创建 2. 标签提取 3. Identity 分配 4. 写入 CRD 5. 同步 Identity 到所有 Agent 关键指标： Identity 的分配速度直接影响 Pod 启动延迟。在 Pod 频繁创建/删除的场景下，应监控 Operator 的 cilium_operator_identity_count 指标。 如果 Identity 池耗尽（最大 65535 个），新 Pod 将无法获得网络连通性。

3.4 Node 监控：集群拓扑的维护

Operator 负责监控集群中节点的加入、离开和状态变化。在基于 Overlay（如 VXLAN/Geneve） 或 Direct Routing 的网络模式下，Operator 需要维护节点间的隧道端点或路由信息。

Node 监控的主要职责包括：

  • 节点发现： 监听 Kubernetes Node 对象的创建和删除事件。
  • 隧道管理： 在 Overlay 模式下，为每个节点分配 VTEP IP 并维护隧道端点列表。
  • 路由同步： 在 Direct Routing 模式下，更新节点间的路由表或 BGP 配置。
  • 健康检查： 定期检查节点的可达性，标记异常节点。
容量风险： 当集群节点数量超过 500 时，Operator 的 Node 监控循环（默认 30 秒）可能会成为瓶颈。每次循环都需要遍历所有节点并更新状态，导致 CPU 和 API Server 负载上升。建议在大型集群中启用 --node-selector 来限制 Operator 监控的节点范围，或使用 --nodes-gc-interval 调整垃圾回收频率。

3.5 关键指标与监控

为了评估 Operator 的健康状况和性能，需要关注以下 Prometheus 指标：

指标名称 类型 说明 告警阈值建议
cilium_operator_identity_count Gauge 当前已分配的 Identity 总数 > 50000 告警
cilium_operator_identity_sync_duration_seconds Histogram Identity 同步到 Agent 的耗时 P99 > 5s 告警
cilium_operator_ces_sync_total Counter CiliumEndpointSlice 同步次数 速率突降告警
cilium_operator_node_events_total Counter 节点事件处理总数 速率突增告警
cilium_operator_process_cpu_seconds_total Counter Operator 进程 CPU 使用时间 持续 > 80% 核心数告警

3.6 高可用与 Leader Election

Cilium Operator 支持多副本部署以实现高可用。多个 Operator 实例之间通过 Leader Election 机制协调，确保同一时刻只有一个实例执行全局协调任务。

Leader Election 的实现细节：

  • 使用 Kubernetes 的 Lease 对象（位于 kube-system 命名空间）进行选举。
  • Leader 实例负责处理所有写操作（创建/更新 CRD）。
  • 非 Leader 实例处于热备状态，只进行读操作和健康检查。
  • 当 Leader 实例故障时，其他实例会在 Lease 过期后（默认 15 秒）自动接管。
最佳实践： 建议部署 2 个 Operator 副本，并设置 --leader-election-lease-duration=30s 和 --leader-election-renew-deadline=15s，以平衡故障切换速度和 API Server 负载。避免设置过短的 Lease 时间，否则频繁的续约操作会消耗不必要的资源。
← 上一章 📖 返回目录 下一章 →