控制面健康端点怎么看
接口服务暴露了三个健康端点：一个综合结果，一个反映进程是否存活，一个反映能否对外提供服务。排查控制面问题时应先看就绪端点，加上详细输出后每一项检查会标注结果与失败原因，比笼统的整体结果有用得多，也省去逐项猜测的时间。
基本信息
| 适用平台 | Kubernetes 1.20+，接口服务自带端点 |
|---|---|
| 访问方式 | 通过命令行读取原始接口路径 |
| 三个端点 | 综合、存活、就绪 |
| 详细输出 | 加参数后逐项列出检查结果 |
| 典型检查项 | 数据后端连通性、准入组件、存储可用性 |
典型使用场景
- 控制面异常时快速判断问题出在哪个检查项
- 发布或升级后确认接口服务是否真正可用
- 负载均衡健康检查策略设计
- 排查命令行全部超时的原因
- 例行巡检时作为控制面自检入口
检查命令
检查命令
kubectl get --raw /healthz # 综合结果
kubectl get --raw '/readyz?verbose' # 就绪，逐项列出检查
kubectl get --raw '/livez?verbose' | head -20 # 存活检查
kubectl get --raw /readyz # 只看整体结论
kubectl -n kube-system get pods | grep apiserver # 副本与重启情况端点与用途
| 端点 | 回答什么问题 | 何时使用 |
|---|---|---|
| 综合端点 | 整体是否健康 | 快速判断 |
| 存活端点 | 进程是否还活着 | 判断是否需要重启进程 |
| 就绪端点 | 能否对外提供服务 | 排查业务请求失败 |
| 详细输出 | 每一项检查的结果 | 定位具体失败原因 |
详细输出里的单个失败项就足以指明方向：数据后端连接失败与准入组件异常的处理方式完全不同，不必等整体结论。
不同版本的检查项集合略有差异，看到不认识的检查项时，以官方文档对应版本的说明为准，不要凭经验判断其含义。
命令行全部超时不一定代表集群故障。本机网络、配置指向错误或凭据过期都会产生一致的表现，先确认访问路径再判断控制面。