【Cilium / eBPF】排障坐标系：丢包、policy deny、identity 漂移、Service 黑洞与加密失败
内容提要
本文介绍Cilium v1.20网络排障的五轴坐标系：通用丢包、策略拒绝、身份漂移、服务黑洞和加密失败。每轴按症状、排查顺序和禁忌操作展开，强调先分型再行动，避免盲目重启或改策略。通过Hubble、BPF map和状态检查定位根因，并保留最小证据包用于复盘。
延伸解读
先分型再动手：五轴排障的核心纪律
文章强调排障第一步不是直接重启或改策略，而是根据症状选择对应的轴。例如，超时无明确拒绝文案时，先查Hubble drop reason，再决定进入哪个轴。盲目重启会冲掉因果链，甚至放大问题。这种分诊思路适用于任何复杂系统，避免在未定位根因前做破坏性操作。
身份漂移：标签变更后的短暂窗口
轴三指出，标签或ServiceAccount变更后，identity重新分配存在传播窗口，期间可能短暂拒绝或误放行。这解释了为何策略YAML看似正确却偶发失败。排障时应对齐变更时间与失败窗口，并关注policy_implementation_delay指标，而非简单归因于网络抖动或DNS。
Service黑洞：先查EndpointSlice再动后端
轴四强调，Pod IP通但ClusterIP不通时，应先检查EndpointSlice是否为空或后端未Ready，再查看BPF LB映射。空后端导致黑洞是机制结果，不是DNS问题。在未确认EndpointSlice前重启后端或删除Service都是碰运气，可能掩盖真实原因。
加密失败：路径表比Policy denied更可靠
轴五指出，透明加密开启后跨节点失败而同节点成功，应检查encrypt status和路径表，确认是否应加密却未封装。某些组合下Hubble甚至看不到drop，此时依赖路径表而非等待Policy denied。永久关闭加密而不记录威胁模型变更，是危险的做法。
Q&A
Cilium 网络排障中，如何区分通用丢包和策略拒绝？
通用丢包通常表现为连接超时或 i/o timeout，且没有明确的策略拒绝证据；而策略拒绝在 Hubble 或 monitor 中会明确显示 Policy denied。排障时应先通过 Hubble 观察流量的 verdict 和 drop reason，根据 reason 进入对应轴。
Cilium 中 Policy deny 的常见原因有哪些？
常见原因包括：NetworkPolicy 或 CiliumNetworkPolicy 的 selector 未正确匹配源或目的 identity；policy map 压力过高导致策略行为异常；identity 漂移导致策略键不匹配；以及 L7 策略与 L3/L4 策略的修复面不同。
什么是 Cilium 中的 identity 漂移？如何排查？
Identity 漂移是指工作负载的标签或 ServiceAccount 变更后，安全身份重新分配，但其他节点尚未同步，导致短暂拒绝或误放行。排查时需对齐变更时间与失败窗口，检查 policy_implementation_delay 指标，并对比变更前后的 identity list。
Cilium Service 黑洞通常由什么原因导致？
Service 黑洞通常由后端为空或未就绪导致，例如 EndpointSlice 为空或后端 Pod 未 Ready。也可能是 BPF LB 映射未指向预期后端，或 kube-proxy 替代（KPR）与残留 iptables/IPVS 规则冲突。
Cilium 透明加密失败时，如何定位问题？
先检查 cilium-dbg encrypt status 确认密钥分发和链路状态，再对照官方 Transparent Encryption 文档检查路径表，确认哪些路径应加密但未加密，或不应加密却走了未封装路径。同时注意 WireGuard 和 IPsec 的失败表现不同，IPsec 还需检查 xfrm 状态。
Cilium 排障中，为什么不能一上来就重启所有 cilium DaemonSet？
因为重启会冲掉因果链，可能掩盖真正的根因，甚至将可恢复的 identity 同步抖动放大成双故障。应先按五轴分型，通过 status、Hubble、BPF map 等定位根因，再采取针对性措施。
Cilium 排障时，如何保留最小证据包？
保留事故时间窗与变更单、一则 Hubble 事件（含 identity 和 verdict/reason）或明确无 drop 事件的陈述、相关 cilium status / encrypt / bpf lb 摘录，以及选定的轴与否证记录。
