etcd集群中healthy=false表示该成员节点通信异常或健康检查失败，需通过member list定位故障节点，再用endpoint status、服务状态、日志、磁盘、peer端口等分步排查具体原因。
当 etcd 集群执行 etcdctl member list 时出现 healthy=false，说明该成员节点当前无法被集群其他节点正常通信或自身健康检查失败，但不等于一定“完全挂了”——可能是网络不通、进程卡死、磁盘满、证书失效或端口被占等。需要分步排查定位具体是哪个节点异常以及原因。
看 member list 输出中的 healthy 字段和 clientURLs
运行命令：
etcdctl --endpoints=https://127.0.0.1:2379 member list -w table
重点关注两列：
-
HEALTHY：为
false的那一行，对应的就是疑似故障的成员； -
CLIENT_URLS：记录该成员对外暴露的客户端访问地址（如
https://10.10.10.21:2379），后续要单独连它做验证。
用 etcdctl endpoint status 检查每个节点真实状态
对 member list 中每个 CLIENT_URLS 单独发起探测（需带上正确证书）：
etcdctl --endpoints=https://10.10.10.21:2379 \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ endpoint status -w table
如果返回类似 Failed to get the status of endpoint 或超时，说明该节点确实不可达；若能返回表（含 Version、DB Size、IsLeader 等），说明它活着，healthy=false 可能是集群内其他节点与它通信失败（比如网络策略、防火墙、peer 通信端口 2380 不通）。
登录对应节点，检查本地 etcd 进程和服务状态
找到 CLIENT_URLS 对应的机器，执行：
-
systemctl is-active etcd—— 查是否 running； -
journalctl -u etcd -n 50 --no-pager—— 看最近错误日志（常见如context deadline exceeded、connection refused、permission denied、no space left on device）； -
netstat -tlnp | grep :2379—— 确认 etcd 是否真在监听； -
df -h /var/lib/etcd—— 检查数据目录磁盘是否已满（满会导致写失败，etcd 自动停止写入并降级）。
检查 peer 通信（2380 端口）是否通畅
healthy=false 常由集群内部 peer 连接中断导致（即使 client 端口通）。在其他正常节点上尝试 telnet 或 curl 到问题节点的 peer URL（一般形如 https://10.10.10.21:2380）：
curl -k https://10.10.10.21:2380/health
返回 {"health":"true"} 表示 peer 服务正常；若连接拒绝、超时或返回空/错误，则需查防火墙、安全组、SELinux、etcd 启动参数中 --initial-advertise-peer-urls 和 --listen-peer-urls 是否配置正确且可路由。
