Linux cilium status / cilium-health 的集群健康检查清单

cilium status可快速判断集群核心组件是否存活，需在cilium pod内执行，重点检查cilium、operator、hubble三行状态，任一非ok或超时即表明节点网络/ebpf异常。

如何用 cilium status 快速判断集群是否“活着”

它不是万能诊断器，但能一眼揪出最致命的组件掉线——比如 cilium-agent 没起来、cilium-operator 崩了、或者 Hubble 服务不可达。cilium status 走的是本地 agent 的健康端点，不依赖 kubernetes API Server，所以即使控制面卡住，它也可能显示 OK；但反过来，如果它报错，基本说明节点网络栈或 eBPF 加载已出问题。

• 必须在任意一个 cilium Pod 内执行：kubectl -n kube-system exec -ti <cilium-pod-name> -- cilium status</cilium-pod-name>，直接在宿主机跑会失败（缺少 socket 和权限）
• 关键看三行：Cilium（agent）、Operator（controller）、Hubble（可观测性），任一不是 OK 都得立刻查日志
• 如果输出卡住或超时，大概率是 BPF map 初始化失败，常见于内核版本太低（5.4 以下）、SElinux 启用未配置、或 /sys/fs/bpf 挂载异常

cilium-health 是什么，为什么不能只靠它看“全集群”健康

cilium-health 是每个节点上独立运行的探测进程，专做节点间连通性打点：它会主动向其他所有节点的 cilium-health 端口（默认 4240）发 http GET /healthz，并记录延迟与成功率。但它不检查 Pod 网络、策略、DNS 或服务发现——只管“节点能不能 ping 通另一节点的健康端口”。

• 它默认只探测同集群内节点，跨 ClusterMesh 的健康状态要额外配置 cluster-mesh-health-check-interval
• 探测失败不等于业务不通：可能只是防火墙拦了 4240 端口，而实际流量走的是 eBPF redirect，完全绕过该端口
• 查看结果用：cilium-health status（在 Pod 内），或 kubectl -n kube-system get cep -o wide 看 cilium-health 对应的 endpoint 状态

连通性测试跑完全是 Connection refused 怎么办

官方 connectivity-check.yaml 里一堆 pod-to-b-intra-node-hostport 类型的测试失败，报 curl: (7) Failed to connect to echo-b-host-headless port 40000: Connection refused，这几乎从不意味着 Cilium 本身坏了，而是目标容器根本没监听那个端口，或者 readiness probe 没通过导致 kubelet 拒绝转发。

• 先确认测试 Pod 是否真在 Running + Ready：kubectl get pods -n cilium-test -o wide，注意 READY 列是不是 1/1
• 进失败 Pod 手动 curl：kubectl -n cilium-test exec -ti <failed-pod> -- curl -v http://echo-b-host-headless:40000</failed-pod>，看是 DNS 解析失败、连接超时，还是真被拒绝
• 如果是 HostPort 测试失败，检查节点是否开了 hostPort 支持（--enable-hostports 参数需开启，且 docker/containerd 配置允许）

真正有用的健康检查组合拳

单靠一个命令永远不够。生产环境要交叉验证三层：组件存活、节点连通、业务可达。漏掉任何一层，都可能线上炸锅还查不出原因。

• 组件层：cilium status + kubectl -n kube-system get ds,deploy -l io.cilium/app 确认副本数和就绪数一致
• 节点层：cilium-health status --verbose 查每个 peer 的 RTT 和失败次数；再配合 cilium endpoint list | grep -E "(not-ready|regenerating)" 找卡住的 endpoint
• 业务层：别只信 connectivity-check，自己写个最小化测试 Job，用 busybox 访问核心 Service（如 kubernetes.default.svc.cluster.local），并加 --resolve 强制走 CoreDNS

最容易被忽略的是：cilium-health 探测间隔默认 30 秒，但故障转移策略（比如 ClusterMesh failover）可能设成 10 秒超时——这意味着健康探测还没来得及上报失败，流量就已经切走了。调参必须对齐。