3. Cilium 控制面通信模型:Agent 与 API Server、Operator 及 gRPC 协议

Cilium 控制面由多个组件构成,它们之间的通信效率与安全性直接决定了整个数据面的转发性能与策略生效速度。本章深入拆解 Cilium Agent、Cilium Operator 与 Kubernetes API Server 之间的交互模型,并分析 gRPC 与 Protocol Buffers 在控制面通信中的核心作用。

3.1 控制面通信全景

Cilium 控制面采用“观察-决策-下发”的闭环模型。Agent 作为每个节点的控制面代理,负责监听 Kubernetes 资源变化、计算网络策略并下发 BPF 程序;Operator 则承担集群级别的协调任务,如 IPAM、CNI 配置、身份管理。

关键认知: Agent 与 API Server 之间是“事件驱动”的 List-Watch 模式;Agent 与 Operator 之间则通过 gRPC 流式通信实现身份与策略的同步。
Cilium 控制面通信架构 Cilium 控制面通信架构 Kubernetes API Server List-Watch / CRD 资源 Cilium Agent (Node-1) gRPC Server / BPF 下发 Cilium Agent (Node-N) gRPC Server / BPF 下发 Cilium Operator IPAM / 身份管理 / 策略协调 List-Watch gRPC 双向流 Agent 节点 Operator

3.2 Agent 与 Kubernetes API Server 交互

Cilium Agent 通过 client-go 库与 API Server 建立 List-Watch 连接,监听以下核心资源:

  • Pod / Node / Service:获取网络端点与拓扑信息。
  • NetworkPolicy:解析 Kubernetes 原生网络策略。
  • CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy:Cilium CRD 扩展策略。
  • CiliumEndpoint / CiliumIdentity:身份与端点映射。
性能要点: Agent 使用 Informer 机制,将 API Server 事件缓存到本地 DeltaFIFO 队列,再通过 WorkQueue 异步处理,避免阻塞 Watch 连接。

当 API Server 返回大量资源时(例如 5000+ 节点集群),Agent 必须控制 Watch 的 resourceVersion 与 timeoutSeconds,防止内存暴涨。Cilium 默认使用 --k8s-watch-queue-size=1024 与 --k8s-k8s-api-rate-limit=100qps 进行限流。

3.3 Agent 与 Operator 通信

Agent 与 Operator 之间的通信不经过 API Server,而是通过 gRPC 双向流 直接建立连接。主要交互场景包括:

通信场景 发起方 协议 数据内容
身份分配 Agent gRPC Stream 请求 Pod 对应的 Security Identity
策略同步 Operator gRPC Stream 下发全局策略变更通知
IPAM 分配 Agent gRPC Unary 请求 Pod IP 地址
健康检查 双向 gRPC Stream Keepalive / 探针
避坑指南: 在大规模集群中,Operator 可能成为 gRPC 连接瓶颈。建议将 Operator 副本数设置为 --operator-replicas=3,并开启 --enable-k8s-event-handover=false 避免事件重复处理。

3.4 gRPC 与 Protocol Buffers 在 Cilium 中的应用

Cilium 选择 gRPC 作为控制面通信的核心协议,主要基于以下优势:

  • 双向流式通信:支持 Server Push 模式,Operator 可主动向 Agent 推送策略变更。
  • Protocol Buffers 序列化:相比 JSON,PB 序列化体积减少 60%-80%,解析速度提升 5-10 倍。
  • HTTP/2 多路复用:单个 TCP 连接可承载多个 RPC 调用,减少连接建立开销。
  • 内置认证与拦截器:支持 mTLS、 认证、请求日志拦截器。

Cilium 中关键的 gRPC 服务定义位于 api/v1/ 目录下,核心 proto 文件包括:

// cilium/api/v1/observer/observer.proto
service Observer {
    rpc GetEvents(GetEventsRequest) returns (stream GetEventsResponse);
    rpc GetFlows(GetFlowsRequest) returns (stream Flow);
}

// cilium/api/v1/relay/relay.proto
service Relay {
    rpc StreamFlows(StreamFlowsRequest) returns (stream Flow);
}

Agent 与 Operator 之间的身份分配服务定义:

// cilium/api/v1/identity/identity.proto
service Identity {
    rpc Allocate(AllocateRequest) returns (AllocateResponse);
    rpc Release(ReleaseRequest) returns (ReleaseResponse);
    rpc Watch(WatchRequest) returns (stream IdentityChange);
}
gRPC 与 Protocol Buffers 消息流 gRPC 与 Protocol Buffers 消息流 Cilium Agent gRPC Client / Server Cilium Operator gRPC Server HTTP/2 双向流 Protocol Buffers 编码 mTLS 加密通道 序列化性能对比(模拟 1000 条策略) JSON: 约 1.2 MB / 解析 45ms PB: 约 0.3 MB / 解析 6ms 体积减少 75% | 解析速度提升 7.5x 数据来源:Cilium 社区基准测试 (K8s 1.28, 5000 endpoints)

3.5 通信安全加固

Cilium 控制面通信默认开启以下安全机制:

安全层 实现方式 配置参数
传输加密 gRPC over mTLS --tls-cert-file / --tls-key-file
身份认证 Kubernetes ServiceAccount --k8s-service-account-
请求鉴权 RBAC + CiliumClusterwidePolicy --enable-policy=always
审计日志 gRPC 拦截器 + hubble --hubble-listen-address=:4244
生产建议: 在非受信网络环境中,务必启用 mTLS 并设置 --grpc-server-keepalive-time=30s 与 --grpc-server-keepalive-timeout=10s,防止连接泄漏。

3.6 性能调优关键参数

针对控制面通信的性能调优,以下参数直接影响 Agent 与 API Server、Operator 的交互效率:

  • --k8s-watch-queue-size:增大可减少事件丢失,但会增加内存占用。推荐 1024-4096。
  • --k8s-k8s-api-rate-limit:控制 Agent 对 API Server 的请求速率。默认 100qps,大规模集群可提升至 300qps。
  • --operator-replicas:Operator 副本数,建议 >= 2。
  • --grpc-max-msg-size:gRPC 消息最大字节数,默认 4MB,策略较多时需提升至 16MB。
  • --bpf-map-dynamic-size-ratio:控制 BPF Map 大小,间接影响控制面事件处理速度。
调优口诀: Watch 队列不丢事件,gRPC 消息不超限,Operator 副本保高可用,API 限流防雪崩。