Kubernetes核心组件角色与交互全解析
·
一、核心组件角色定位（先明确 “谁干什么”）
| 组件 | 核心角色 | 所在节点 |
|---|---|---|
| kube-apiserver | 集群 “网关 + 统一入口”，所有组件通信的唯一桥梁，接收指令、存储集群状态到 ETCD | 控制平面（master） |
| kubelet | 节点 “执行者”，监听 apiserver 指令，管理本节点 Pod（启动 / 停止 / 健康检查） | 所有节点（master+worker） |
| kube-proxy | 节点 “网络代理”，实现 Service 网络功能（端口转发、负载均衡、服务发现） | 所有节点（master+worker） |
| Calico | 集群 “网络插件”，负责 Pod 跨节点通信、网络策略隔离，提供 Overlay/Underlay 网络 | 所有节点（master+worker） |
| ETCD | 集群 “数据库”，存储所有集群状态（Pod/Service/Deployment 等配置） | 控制平面（master） |
| kube-scheduler | 集群 “调度器”，根据 Pod 需求和节点资源情况，分配 Pod 到合适 worker 节点 | 控制平面（master） |
| kube-controller-manager | 集群 “控制器”，监控集群状态（如 Deployment 副本数），自动修复异常（重启 Pod） | 控制平面（master） |
二、核心组件交互流程图（分场景详解 “如何配合”）
场景 1：创建一个 Pod 并实现网络访问（完整流程）
场景 2：Pod 健康检查与自动修复（控制器 + kubelet 协作）
三、关键交互逻辑补充（理解 “为什么这么设计”）
- apiserver 的 “中枢作用”：所有组件不直接通信，均通过 apiserver 转发（如 kubelet 不直接找调度器，控制器不直接找 kubelet），保证集群安全和状态一致性。
- kubelet 的 “节点专属管理”：每个节点只有一个 kubelet，仅负责本节点的 Pod，不干涉其他节点，实现节点级隔离。
- kube-proxy 与 Calico 的 “网络分工”：
- kube-proxy 负责 “Service 层面” 的网络（端口映射、负载均衡）；
- Calico 负责 “Pod 层面” 的网络（IP 分配、跨节点路由、网络策略）；二者配合实现 “外部访问 Service→kube-proxy 转发→Calico 路由→Pod” 的完整网络链路。
- ETCD 的 “只读存储”：只有 apiserver 能读写 ETCD，其他组件通过 apiserver 获取 / 更新状态，避免数据冲突。
四、简化记忆口诀
- 入口看 apiserver，状态存在 ETCD；
- 调度找 scheduler，节点执行 kubelet；
- 网络代理 kube-proxy，跨节点通信靠 Calico；
- 异常修复控制器，组件通信不直接。
更多推荐
6
0- 0
已为社区贡献6条内容
所有评论(0)