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-appcilium出现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-appcilium \ --sort-by.status.containerStatuses[0].restartCount NAME READY STATUS RESTARTS AGE cilium-813gf 0/1 CrashLoopBackOff 2 44sRESTARTS 计数最高、状态为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 或 AArch64Linux 内核 5.10或等价内核例如 RHEL 8.10 上的 4.18内核需启用CONFIG_BPFy、CONFIG_NET_CLS_ACTy、CONFIG_NET_SCH_INGRESSy、CONFIG_DEBUG_INFO_BTFy等 eBPF 相关配置项发行版内核通常已启用默认使用 VXLAN 隧道跨节点通信时还需要CONFIG_VXLANy等选项。如果失败 Pod 在问题发生后已经因 liveness 失败被重启过一次当前容器的日志可能已经不含崩溃现场此时要取上一轮容器的日志kubectl -n kube-system logs --timestamps -p cilium-pod名以上示例命令中的cilium-pod名需替换为kubectl -n kube-system get pods -l k8s-appcilium返回的实际 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或Failure1/1 connected表示可到达的 etcd 端点数Kubernetes/Cilium是否为OkController 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 statusetcd 模式下的 Quorum 检查Cilium 可以运行在 CRD 模式或 kvstore/etcd 模式。etcd 模式下 kvstore 是集群健康的关键组件。Cilium 会在后台周期性检查 etcd 健康并采取行动检查间隔随集群规模增大而变长文档给出两种会导致 Agent 被判不健康、从而被 liveness/readiness 探针失败并重启的情形所有 etcd 端点均不可达cilium-dbg status报告 failureKubernetes liveness 与 readiness 探针失败Cilium 会被重启quorum 连续失败达到阈值Cilium operator 会持续向心跳键cilium/.heartbeat写入所有 Agent 监听该键若心跳键未及时更新quorum 检查判失败连续 3 次及以上失败后 Cilium 被判为不健康。cilium-dbg status中两种状态的示例文档示例# quorum 失败但尚未达到阈值 KVStore: Ok etcd: 1/1 connected, lease-ID29c6732d5d580cb5, lock lease-ID29c6732d5d580cb7, has-quorum2m2.778966915s since last heartbeat update has been received, consecutive-errors1: 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-appcilium 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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-appcilium出现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-appcilium \ --sort-by.status.containerStatuses[0].restartCount NAME READY STATUS RESTARTS AGE cilium-813gf 0/1 CrashLoopBackOff 2 44sRESTARTS 计数最高、状态为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 或 AArch64Linux 内核 5.10或等价内核例如 RHEL 8.10 上的 4.18内核需启用CONFIG_BPFy、CONFIG_NET_CLS_ACTy、CONFIG_NET_SCH_INGRESSy、CONFIG_DEBUG_INFO_BTFy等 eBPF 相关配置项发行版内核通常已启用默认使用 VXLAN 隧道跨节点通信时还需要CONFIG_VXLANy等选项。如果失败 Pod 在问题发生后已经因 liveness 失败被重启过一次当前容器的日志可能已经不含崩溃现场此时要取上一轮容器的日志kubectl -n kube-system logs --timestamps -p cilium-pod名以上示例命令中的cilium-pod名需替换为kubectl -n kube-system get pods -l k8s-appcilium返回的实际 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或Failure1/1 connected表示可到达的 etcd 端点数Kubernetes/Cilium是否为OkController 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 statusetcd 模式下的 Quorum 检查Cilium 可以运行在 CRD 模式或 kvstore/etcd 模式。etcd 模式下 kvstore 是集群健康的关键组件。Cilium 会在后台周期性检查 etcd 健康并采取行动检查间隔随集群规模增大而变长文档给出两种会导致 Agent 被判不健康、从而被 liveness/readiness 探针失败并重启的情形所有 etcd 端点均不可达cilium-dbg status报告 failureKubernetes liveness 与 readiness 探针失败Cilium 会被重启quorum 连续失败达到阈值Cilium operator 会持续向心跳键cilium/.heartbeat写入所有 Agent 监听该键若心跳键未及时更新quorum 检查判失败连续 3 次及以上失败后 Cilium 被判为不健康。cilium-dbg status中两种状态的示例文档示例# quorum 失败但尚未达到阈值 KVStore: Ok etcd: 1/1 connected, lease-ID29c6732d5d580cb5, lock lease-ID29c6732d5d580cb7, has-quorum2m2.778966915s since last heartbeat update has been received, consecutive-errors1: 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-appcilium 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
