企业官网建设流程全解析

Cilium Identity Management Mode：由 Cilium Operator 集中管理 Cilium Identity（CID）的配置、迁移与监控指南

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

导读

本文围绕 Cilium 的Identity Management Mode（身份管理模式）展开，讲解 Cilium Identity（CID）由默认的 Cilium Agent 管理模式切换到由 Cilium Operator 集中管理的方案。你将掌握三种模式（agent/operator/both）的语义、在 Helm 或cilium-configConfigMap 中的配置方法、Agent 与 Operator 之间无损迁移与安全降级的标准流程，以及 Operator 管理身份模式下的可观测性指标。本文同时结合仓库源码（如 operator/pkg/ciliumidentity/cell.go、operator/pkg/ciliumidentity/controller.go、pkg/option/config.go）与 identity-management-mode.rst 文档，为你提供从配置到排障的完整实践参考。

为什么需要集中管理 Cilium Identity

在 Cilium 中，每个工作负载（Pod）的身份由一组安全标签（security labels）决定，这些标签的集合被抽象为Cilium Identity（CID）。网络策略的匹配、可观测性数据的归属都以 CID 为核心，因此身份管理的质量直接影响网络策略的可靠性乃至集群的可扩展性。

默认情况下，CID 由各个Cilium Agent独立管理：每个节点上的 Agent 根据本地工作负载的标签自行创建身份。这种分布式的模式存在一个固有问题——CID 重复（CID duplication）：当多个 Agent 同时为相同的一组标签创建身份时，有可能产生多个语义相同、ID 不同的身份对象。

Cilium 支持将 CID 管理交给Cilium Operator，实现身份创建的集中化。集中管理的直接收益就是减少 CID 重复，这一点在集群中存在大量工作负载时尤为重要，因为：

• 集群中可分配的身份总数存在上限；
• eBPFPolicy Map 存在容量限制（详见 eBPF Maps 文档 中的bpf_map_limitations小节，例如 Policy Map 默认每 endpoint 上限为 16k 个“身份 + 端口 + 协议”组合）。

当身份由 Operator 统一分配时，相同标签集只对应一个全局身份，从而提升网络策略的可靠性和集群的可扩展性。

注意：与身份管理相关的标签（identity-relevant labels）可以通过 Cilium ConfigMap 配置（见 Limiting Identity-Relevant Labels）。如果由 Cilium Operator 管理身份，修改标签模式后必须同时重启 Operator 和 Agent，新的标签模式才会生效。

三种身份管理模式

从源码定义可以看出，Cilium 通过一个字符串配置项控制身份管理模式。三种取值在 pkg/option/config.go 中被定义为常量：

对应的配置键为identity-management-mode（源码注释原文："controls whether CiliumIdentities are managed by cilium-agent, cilium-operator, or both"）。该选项同时存在于 Agent 侧与 Operator 侧的配置中：

• 在 operator/pkg/ciliumidentity/cell.go 中，Operator 的 CID 控制器模块通过identity-management-modeflag 读取该配置，默认值即为agent；
• 在 pkg/identity/cache/cell/cell.go 中，Agent 侧的身份缓存模块同样监听该配置，判断是否跳过 Agent 自身对身份的管理职责。

从实现看，Operator 侧的 CID 控制器在 controller.go 中会根据该配置决定是否启用：仅当模式为operator或both且 Kubernetes clientset 可用、网络策略未被禁用时，控制器才会启动。控制器内部通过订阅CID、CES（CiliumEndpointSlice）、Pod、Namespace事件并执行调协（reconcile），将状态变更落实到集群中的 CID API 对象上。

在全新集群上启用 Operator 管理身份（Beta）

启用前请注意：由 Cilium Operator 管理身份目前是 Beta 功能（见 Documentation/beta.rst）。默认情况下由 Cilium Agent 管理 CID。

在全新集群上启用 Operator 管理身份，只需在安装时将模式设置为operator，两种方式任选其一：

方式一：Helm 安装时通过 values 指定

helm install cilium cilium/cilium --namespace kube-system \ --set identityManagementMode=operator

identityManagementMode是 Helm chart 中对应的 values 键。从 Documentation/helm-values.rst 的参考文档可见，其含义为 "Control whether CiliumIdentities are created by the agent (agent), the operator (operator) or both (both)"，默认值为"agent"，且文档明确注明 "Both" 只应用于在agent与operator之间迁移，Operator 管理身份为 beta 特性。

方式二：修改cilium-configConfigMap

# kubectl edit cm -n kube-system cilium-config identity-management-mode: operator

从 Agent 管理模式迁移到 Operator 管理模式

为了避免对现有连接或工作负载管理造成中断，迁移必须分两步走，并且充分利用both这个中间过渡态：

1. 让 Operator 也参与身份管理：将identityManagementMode（Helm）或identity-management-mode（ConfigMap）设置为both，然后重启 Operator。此时 Agent 与 Operator 同时管理身份，不会出现身份管理空窗。

2. 将 Agent 切换为不再管理身份：在上述过渡状态稳定运行后，将模式改为operator，然后重启 Cilium Agent DaemonSet。此后身份管理完全由 Operator 承担。

# 步骤 1：Helm 方式切换为 both 并重启 Operator helm upgrade cilium cilium/cilium --namespace kube-system \ --set identityManagementMode=both # 步骤 2：切换为 operator 并重启 Agent DaemonSet helm upgrade cilium cilium/cilium --namespace kube-system \ --set identityManagementMode=operator kubectl rollout restart -n kube-system ds/cilium

重要提醒：过渡态（both）期间，只要 Agent 仍在创建身份，CID 重复问题就可能依然存在。该中间状态只应临时用于模式迁移，不应长期驻留。源码层面也印证了这一点——在both模式下，Agent 与 Operator 两侧的身份管理逻辑都会被启用（见 pkg/identity/cache/cell/cell.go 与 operator/pkg/ciliumidentity/controller.go）。

从 Operator 管理模式降级回 Agent 管理模式

安全降级同样需要先 Agent 后 Operator的顺序，与升级迁移顺序相反：

1. 先将 Agent 恢复为参与身份管理：将模式设置为both，重启 Cilium Agent DaemonSet，让 Agent 先接管身份管理职责。

2. 再让 Operator 退出身份管理：将模式改为agent，然后重启 Operator。此后身份管理完全回归由 Agent 负责。

# 步骤 1：切换为 both 并重启 Agent helm upgrade cilium cilium/cilium --namespace kube-system \ --set identityManagementMode=both kubectl rollout restart -n kube-system ds/cilium # 步骤 2：切换为 agent 并重启 Operator helm upgrade cilium cilium/cilium --namespace kube-system \ --set identityManagementMode=agent

身份管理模式相关指标

当身份由 Operator 管理时，CID 控制器的工作队列行为可以通过指标观测。相关指标定义在 Documentation/observability/metrics.rst 的 "Identity Management Mode" 小节：

这些指标来自 Operator 中 NewMetrics 注册的监控项，配合 Kubernetes 标准的 Pod/CID 事件流，可用于判断身份调协是否健康、是否存在积压或异常。

与身份相关标签配置的联动

Operator 集中管理身份后，身份相关标签（identity-relevant labels）的变更流程也会发生变化：

• 默认情况下，Cilium 将除默认排除列表之外的所有标签视为与身份相关。若不对其进行限制，时间戳、哈希值等高频变化的标签会导致每个 Pod 都被分配唯一身份，而不是整个服务共享一个身份，从而急剧消耗身份与策略映射资源（详见 identity-relevant-labels.rst）。
• 修改 ConfigMap 中的labels配置后：若由 Operator 管理身份，必须重启 Operator 和 Agent 双方；若仍由 Agent 管理身份，只需重启 Agent。

# 修改 ConfigMap 后，按身份管理模式重启相应组件 kubectl rollout restart -n kube-system ds/cilium kubectl rollout restart -n kube-system deploy/cilium-operator

注意：YAML 中的双反斜杠（\\.）是必须的——它用于转义 YAML 字符串中的反斜杠，使最终传给 Cilium 的正则表达式包含\.。同时，已有身份不会因新配置而改变；要让新标签模式作用于存量身份，需要重启对应工作负载所在节点上的 Cilium Pod，旧的未使用身份随后会被 Operator 的垃圾回收机制清理。

配置要点速查

所有配置既可通过 Helm values（identityManagementMode）设置，也可直接编辑cilium-configConfigMap（identity-management-mode）。在大型集群中，将身份管理集中到 Operator 可以有效减少 CID 重复、缓解身份总数与 eBPF Policy Map 容量压力，是提升网络策略可靠性与集群可扩展性的推荐做法。

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium