Cilium Agent Pod 持续 CrashLoopBackOff 怎么排查

Cilium Agent Pod 持续 CrashLoopBackOff 怎么排查

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

在 Kubernetes 集群中部署 Cilium 后，kube-system命名空间下的 Cilium Agent Pod（标签k8s-app=cilium）出现CrashLoopBackOff状态、READY 一直停在0/1，是每个节点上的网络代理都无法工作的典型信号。官方文档明确指出：如果 Cilium 遇到自身无法恢复的问题，会通过cilium-dbg status上报失败状态，Kubernetes liveness 探针据此自动重启 Pod；因此 Pod 进入CrashLoopBackoff表示这是一个持续性故障，而不是一次性抖动。本文基于 Cilium 文档给出排查路径：定位失败 Pod → 读取日志判断根因 → 对照系统要求与 etcd 状态逐项核对 → 无法定位时收集诊断信息。

确认哪些 Cilium Pod 在失败

先检查 DaemonSet 是否所有实例都处于 ready 状态：

$ kubectl --namespace kube-system get ds NAME DESIRED CURRENT READY NODE-SELECTOR AGE cilium 1 1 0 <none> 3s

期望 1、READY 为 0（文档示例）说明有问题。接着按重启次数排序列出所有 Cilium Pod，快速找出反复重启的那个：

$ kubectl --namespace kube-system get pods --selector k8s-app=cilium \ --sort-by='.status.containerStatuses[0].restartCount' NAME READY STATUS RESTARTS AGE cilium-813gf 0/1 CrashLoopBackOff 2 44s

RESTARTS 计数最高、状态为CrashLoopBackOff的 Pod 就是要排查的对象。注意一个 Pod 对应一个节点，Pod 崩溃意味着该节点上的 Cilium Agent 没有正常运行。

读取日志定位启动失败原因

对上一节找到的失败 Pod（文档示例中 Pod 名为cilium-813gf，请替换为你集群中的实际 Pod 名），打印其日志：

$ kubectl --namespace kube-system logs cilium-813gf

文档给出的示例日志（注意：该示例来自早期版本，其中的内核阈值与当前版本要求不一致，仅用于说明日志形态）：

CRIT kernel version: NOT OK: minimal supported kernel version is >= 4.8

这类CRIT级别日志直接指明失败原因：所在节点的 Linux 内核不满足系统要求。当前版本的系统要求见 系统要求：

• 宿主机架构为 AMD64 或 AArch64；
• Linux 内核 >= 5.10，或等价内核（例如 RHEL 8.10 上的 4.18）；
• 内核需启用CONFIG_BPF=y、CONFIG_NET_CLS_ACT=y、CONFIG_NET_SCH_INGRESS=y、CONFIG_DEBUG_INFO_BTF=y等 eBPF 相关配置项（发行版内核通常已启用）；
• 默认使用 VXLAN 隧道跨节点通信时还需要CONFIG_VXLAN=y等选项。

如果失败 Pod 在问题发生后已经因 liveness 失败被重启过一次，当前容器的日志可能已经不含崩溃现场，此时要取上一轮容器的日志：

kubectl -n kube-system logs --timestamps -p <cilium-pod名>

（以上示例命令中的<cilium-pod名>需替换为kubectl -n kube-system get pods -l k8s-app=cilium返回的实际 Pod 名；--timestamps用于在日志行前加时间戳，-p表示取上一次容器实例的日志。）

在 Pod 内运行 cilium-dbg status 看组件状态

如果 Pod 短暂处于 Running 或容器仍在运行，可以进入该 Pod 执行cilium-dbg status获取该节点上 Agent 的详细状态与健康信息：

$ kubectl -n kube-system exec cilium-2hq5z -- cilium-dbg status KVStore: Ok etcd: 1/1 connected: http://demo-etcd-lab--a.etcd.tgraf.test1.lab.corp.isovalent.link:2379 - 3.2.5 (Leader) Kubernetes: Ok OK Cilium: Ok OK Cilium health daemon: Ok Controller Status: 14/14 healthy Proxy Status: OK, ip 10.2.0.172, port-range 10000-20000 Cluster health: 4/4 reachable (2018-06-16T09:49:58Z)

（以上为文档示例输出，实际值以你的集群为准。）需要关注的行：

• KVStore：显示 etcd 端点连接数、lease 与 quorum 状态。整体状态为OK或Failure；1/1 connected表示可到达的 etcd 端点数；
• Kubernetes/Cilium：是否为Ok；
• Controller Status与Proxy Status：控制器是否全部 healthy、L7 代理是否正常。

需要更细的 IPAM 状态、控制器明细和 Proxy 明细时，使用：

$ kubectl -n kube-system exec <cilium-pod名> -- cilium-dbg status --verbose

如果要在集群所有节点上批量执行cilium-dbg status，可以下载并运行仓库自带的 k8s-cilium-exec.sh 脚本（脚本会遍历所有 Cilium Pod 并执行你传入的命令，只读操作）：

$ ./k8s-cilium-exec.sh cilium-dbg status

etcd 模式下的 Quorum 检查

Cilium 可以运行在 CRD 模式或 kvstore/etcd 模式。etcd 模式下 kvstore 是集群健康的关键组件。Cilium 会在后台周期性检查 etcd 健康并采取行动（检查间隔随集群规模增大而变长），文档给出两种会导致 Agent 被判不健康、从而被 liveness/readiness 探针失败并重启的情形：

• 所有 etcd 端点均不可达：cilium-dbg status报告 failure，Kubernetes liveness 与 readiness 探针失败，Cilium 会被重启；
• quorum 连续失败达到阈值：Cilium operator 会持续向心跳键cilium/.heartbeat写入，所有 Agent 监听该键；若心跳键未及时更新，quorum 检查判失败，连续 3 次及以上失败后 Cilium 被判为不健康。

cilium-dbg status中两种状态的示例（文档示例）：

# quorum 失败但尚未达到阈值 KVStore: Ok etcd: 1/1 connected, lease-ID=29c6732d5d580cb5, lock lease-ID=29c6732d5d580cb7, has-quorum=2m2.778966915s since last heartbeat update has been received, consecutive-errors=1: https://192.168.60.11:2379 - 3.4.9 (Leader) # quorum 失败次数超过阈值 KVStore: Failure Err: quorum check failed 8 times in a row: 4m28.446600949s since last heartbeat update has been received

如果你使用 etcd 模式且 status 中出现KVStore: Failure，问题在 etcd 侧（如网络、quorum、心跳键更新），而不是 Cilium 配置本身。

无法定位时用 sysdump 收集完整诊断信息

当以上步骤仍不能定位原因时，在故障状态丢失前收集完整的日志与状态。安装 Cilium CLI 后执行cilium sysdump从 Kubernetes 集群收集排查信息：

$ cilium sysdump

默认情况下 sysdump 会尽量收集所有节点的全部日志。集群规模超过 20 个节点时，文档建议用以下选项控制收集范围（cilium sysdump --help可查看全部选项）：

• --node-list：只挑选少数节点，减少收集量；
• --logs-since-time：日志回溯到问题开始出现的时间点；
• --logs-limit-bytes：限制传给kubectl logs的日志文件大小。

文档推荐的优先级：优先用--node-list保留少数节点的历史全量，其次用--logs-since-time限定时间窗，最后才考虑--logs-limit-bytes。

不运行 Kubernetes 的单节点场景下，也可以在 Cilium Pod/容器内执行cilium-bugtool采集单节点调试信息（状态、版本、内核配置、日志、dmesg、ip a/ip link/ip r、iptables-save、cilium-dbg bpf * list等）。非 Kubernetes 环境可用cilium-dbg debuginfo打印 Markdown 格式的调试信息，例如cilium-dbg debuginfo -f debuginfo.md。

排查结束后的去向与验证

• 文档指出，Cilium 通过 GitHub issue 维护 FAQ 列表，先检索是否已有同类问题；
• 若仍无法定位，可以到 Cilium Slack 社区求助；
• 确认是 Cilium 缺陷时，提交 GitHub issue 并按上述方式附上系统 dump。

问题解决后，用与开头相同的命令验证恢复：

$ kubectl -n kube-system get pods -l k8s-app=cilium NAME READY STATUS RESTARTS AGE cilium-2hq5z 1/1 Running 0 4d

所有 Cilium Pod 均为Running、READY 为1/1且 RESTARTS 不再增长，说明 Agent 已在各节点恢复正常；此时可以再执行cilium-dbg status确认KVStore、Kubernetes、Cilium各项均为Ok。

需要注意的边界：CrashLoopBackOff只是现象，根因可能是内核版本/配置不满足系统要求、etcd 不可用或 quorum 失败、日志中暴露的其他CRIT错误等，排查时以实际日志和cilium-dbg status输出为准，不要跳过日志直接改配置。

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