Kubernetes核心组件分控制平面与工作节点协同工作，缺一不可；control plane含apiserver（唯一入口）、etcd（状态源）、scheduler（Pod分配）、controller-manager（状态调和）等，node侧含kubelet（容器执行）、kube-proxy（Service转发）、CNI（网络实现）及容器运行时。
Kubernetes 核心组件不是“装上就能跑”的黑盒，而是分角色协同工作的控制平面与工作节点集合；漏掉任一关键组件（比如 etcd 或 apiserver），集群就无法初始化或持续协调。
control plane 组件：谁在发号施令？
控制平面是集群的“大脑”，所有决策和状态管理都发生在这里。它不运行用户容器，只调度、校验、持久化状态。
-
apiserver是唯一入口：所有操作（kubectl、控制器、调度器）都必须通过它，它做认证、鉴权、校验，不直连etcd，而是作为代理 -
etcd是唯一真相源：存储所有集群状态（Pod、Service、ConfigMap 等），必须用奇数节点部署（如 3/5），崩溃超过半数节点即不可写 -
scheduler只做“分配”：监听未绑定 Pod，按资源请求、污点容忍、亲和性等规则选 Node，不执行也不监控运行结果 -
controller-manager是多个控制器的集合：包括replicationcontroller、nodecontroller、endpointcontroller，每个轮询 API 状态并调apiserver修正偏差 -
cloud-controller-manager（可选）：仅当运行在公有云时才启用，负责同步 LoadBalancer、Node 地址等云资源，避免核心组件耦合云厂商逻辑
node 组件：谁在真正干活？
工作节点是容器实际运行的地方，组件轻量但强依赖 control plane 指令，离线后只会维持现状，不会主动重调度。
-
kubelet是节点上的“管家”：确保 Pod 定义被准确落实（拉镜像、启容器、上报状态），定期向apiserver心跳，不处理跨节点逻辑 -
kube-proxy不是传统代理：它监听 Service 变更，在节点上维护iptables或ipvs规则，实现 ClusterIP 流量转发，不参与容器网络（那是 CNI 插件的事） - CNI 插件（如
calico、flannel）：由kubelet调用，负责分配 IP、配置网桥/路由，Kubernetes 本身不提供网络实现 - 容器运行时（
containerd或cri-o）：K8s 1.24+ 已移除 dockershim，kubelet通过 CRI（Container Runtime Interface）对接运行时，docker不再是默认选项
常见故障点：哪些组件挂了会立刻“断联”？
不是所有组件宕机表现一样——有些影响立即可见，有些延迟暴露，有些只影响新能力。
-
apiserver宕机 →kubectl全部报错Unable to connect to the server，所有新操作冻结，已有 Pod 继续运行但无法扩缩/重建 -
etcd不可用 →apiserver启动失败或反复 crash，日志出现context deadline exceeded，集群彻底失能 -
scheduler停止 → 新建 Pod 卡在Pending（kubectl get pods显示0/1 nodes available），已运行 Pod 不受影响 -
kubelet崩溃 → 该节点状态变NotReady，Pod 被标记为Unknown并触发驱逐（默认 5 分钟后），但不会自动迁移到其他节点（需靠控制器重建） -
kube-proxy异常 → Service 访问失败（尤其是 ClusterIP），curl http://my-svc超时，但 Pod IP 直连仍通
部署形态差异：二进制 vs 托管 vs kubeadm
组件存在形式取决于安装方式，但职责不变；混淆部署形态和组件职责是排障大忌。
- 二进制部署（如 Kubespray）：所有组件以独立进程运行，
systemctl status kube-apiserver可查，日志在/var/log/kubernetes/ - 托管服务（EKS/GKE/AKS）：control plane 完全隐藏，你只能看到
node组件（kubelet、containerd），etcd和apiserver不可见 -
kubeadm部署：control plane 组件跑在静态 Pod 中（位于/etc/kubernetes/manifests/），由kubelet自动拉起，删 manifest 就等于停组件 - 注意：
kubectl不是核心组件，只是客户端工具；它连不上 ≠ 集群坏了，可能只是网络或证书问题
组件之间没有“主从”之分，只有协作契约：比如 controller-manager 依赖 apiserver 的 watch 机制，而 apiserver 依赖 etcd 的原子写入。任何一个环节的 TLS 证书过期、网络策略拦截、资源耗尽，都会让整条链路静默中断——这比单个进程崩溃更难定位。
