【Cilium / eBPF】Endpoint 与 Identity：数字身份、标签选择与生命周期
内容提要
本文介绍Cilium v1.20中Endpoint与Identity机制：Endpoint是节点上共享IP的网络实体，Identity是由安全相关标签导出的集群范围数字键，用于策略匹配。标签变更会触发身份重解析，产生init拒绝、新身份拒绝、旧身份放行三类短暂窗口。排障时应区分窗口类型，而非简单归咎于策略错误或系统不稳定。
延伸解读
身份与IP：策略匹配的稳定键
Cilium 将安全与编址分离，用标签导出的数字身份作为策略匹配的稳定键，而非 IP。这避免了 Pod 扩缩容时 IP 变化导致的规则重写风暴。理解这一点，排障时就不会误以为策略仍在匹配 Pod IP，而是关注身份是否一致。
三类变更窗口：拒绝与放行的短暂间隙
标签变更会触发身份重解析，产生三类窗口：init 拒绝（引导期身份未定）、新身份拒绝（策略未收敛）、旧身份放行（旧规则残留）。排障时应先判断属于哪类窗口，再决定是等待收敛、调整超时还是改变发布顺序，而非简单归咎于策略错误或系统不稳定。
标签基数：身份爆炸的隐患
并非所有标签都进入身份，只有安全相关标签才参与。若误将时间戳、构建号等元数据纳入，会导致身份数量激增，接近 Pod 数量，使身份模型退化为昂贵的 IP 策略。排障时若发现身份数远高于应用角色数，应优先检查标签基数。
Q&A
Cilium中Endpoint和Identity有什么区别？
Endpoint是节点上共享同一IP的一组应用容器（如一个Pod），Endpoint ID仅在单节点内唯一，用于本地管理；Identity是由安全相关标签导出的集群范围唯一数字ID，用于策略匹配，是BPF策略map中的稳定键。
Cilium为什么使用Identity而不是IP来匹配策略？
使用IP列表表达策略时，后端节点需维护所有前端IP，扩缩容会导致大量节点更新过滤器，且新Pod启动可能等待规则传播。Identity将安全与编址分离，同标签集合的Pod共享同一数字ID，新增同身份Pod时只需解析已有身份并更新本地缓存，避免规则风暴。
Cilium中reserved:init身份代表什么？
reserved:init（数字ID为5）表示身份尚未解析完成的引导阶段。当Endpoint创建时元数据不齐，会分配init身份。若策略未显式允许init，引导窗口内流量可能被拒绝，这是设计上的过渡态。
Cilium中标签变更会引发哪些短暂窗口？
标签变更会触发身份重解析，产生三类窗口：1）init拒绝窗口：新Endpoint在标签未齐时处于init身份，策略未允许则拒绝；2）新身份拒绝窗口：新Identity已生效但策略map未收敛，默认拒绝模型下丢弃流量；3）旧身份放行窗口：旧Identity的允许条目未清除，可能仍按旧关系放行。
Cilium中哪些标签会进入安全相关集合？
并非所有标签都进入身份，只有配置的有意义标签前缀（如k8s:）和agent配置的相关标签会进入。应把会改变信任边界的标签保留，排除仅用于运维检索的标签（如时间戳、构建号），否则会导致身份爆炸。
Cilium中Identity分配如何跨节点协调？
Cilium通过分布式键值存储（kvstore）或CRD模式进行原子操作：若未见过该标签集合则分配新ID，同标签集合的Pod共享同一数字身份，跨节点共享。具体模式由identity-allocation-mode配置决定。
Cilium中Identity模型相比IP策略有什么优缺点？
优点：扩缩容同角色Pod不迫使策略键空间按IP线性膨胀，backend节点不必为每个新IP改规则。缺点：依赖分配存储与缓存收敛，标签变更引入deny/allow窗口。IP策略心智模型简单，但Pod churn下规则更新放大。
