组件定位
控制面负责集群的「决策与记录」：kube-apiserver 提供唯一的读写入口并做认证鉴权，etcd 保存全部集群状态，kube-scheduler 决定 Pod 落到哪个节点，kube-controller-manager 跑各类控制器循环；节点侧则由 kubelet 管 Pod 生命周期、kube-proxy 维护转发规则。适用平台是 Kubernetes。理解分工的意义在于：出问题时能迅速判断该看组件日志、节点日志，还是存储状态。
基本信息
| 适用平台 | Kubernetes，控制面与节点组件 |
|---|---|
| kubeadm 部署形态 | apiserver、scheduler、controller-manager、etcd 以静态 Pod 形式由 kubelet 拉起 |
| 访问入口 | 所有组件都通过 apiserver 读写集群状态，不直接改 etcd |
| 健康检查 | 各组件有健康端点，apiserver 常用 /healthz 与 /readyz |
典型使用场景
- 集群整体异常：先确认控制面组件是否都在运行，判断是全局还是局部问题
- 调度停止：Pod 一直 Pending 且无新事件，怀疑 scheduler 异常
- 权限与鉴权问题：确认 apiserver 日志里的认证失败原因
- 状态不一致：怀疑 etcd 健康或写入延迟
- 节点侧问题：kubelet 与 kube-proxy 异常影响单节点，与全局故障区分开
查看
查看
kubectl get pods -n kube-system # 控制面与系统组件总览
kubectl get --raw /healthz # apiserver 自身健康
kubectl get --raw /readyz?verbose # 逐项就绪检查
kubectl -n kube-system logs kube-scheduler-node1 --tail=50 # 静态 Pod 日志（名称含节点名）
kubectl -n kube-system logs kube-controller-manager-node1 --tail=50
kubectl get componentstatuses # 旧版本可用，新版本已弃用控制面组件
| 组件 | 职责 | 常见排查点 |
|---|---|---|
| kube-apiserver | API 入口与认证鉴权 | 健康端点、证书、请求延迟 |
| etcd | 集群数据存储 | 成员健康、磁盘与延迟、快照 |
| kube-scheduler | Pod 调度决策 | 调度失败事件、领导者选举 |
| kube-controller-manager | 各类控制器循环 | 控制器卡顿、选举与日志 |
| kubelet | 节点上的 Pod 生命周期 | 状态、日志、cgroup 与运行时 |
| kube-proxy | Service 转发规则 | iptables 或 IPVS 规则与模式 |
把 /healthz 当整体体检：它只反映 apiserver 自身，节点与调度问题要看别的检查点。
控制面组件多数以静态 Pod 运行，kubectl 删掉后 kubelet 会重建；排障时优先看日志与事件，而不是靠重启恢复。