cilium status可快速判断集群核心组件是否存活，需在Cilium Pod内执行，重点检查Cilium、Operator、Hubble三行状态，任一非OK或超时即表明节点网络/eBPF异常。
如何用 cilium status 快速判断集群是否“活着”
它不是万能诊断器，但能一眼揪出最致命的组件掉线——比如 cilium-agent 没起来、cilium-operator 崩了、或者 Hubble 服务不可达。cilium status 走的是本地 agent 的健康端点，不依赖 Kubernetes API Server，所以即使控制面卡住，它也可能显示 OK；但反过来，如果它报错，基本说明节点网络栈或 eBPF 加载已出问题。
- 必须在任意一个
ciliumPod 内执行：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 秒超时——这意味着健康探测还没来得及上报失败，流量就已经切走了。调参必须对齐。
