Kubernetes 就像一个自动化的“分布式工厂”，而 Kubelet、etcd、Controller 分别是现场工人、仓库账本和车间主管。它们不止各司其职，还在不停地联动，一旦任何一个出问题，全场都会“卡壳”。
你可能常听说这些词：
- Kubelet 崩了，Pod 启不起来？
- etcd 慢了，集群全卡？
- Controller 失灵，副本数不对？
但它们到底谁负责干什么，怎么协同工作，怎么影响整个集群？这篇文章，带你用人话，一次讲透。
Kubernetes 架构就像一个自动化工厂
我们先换个角度，把 Kubernetes 想象成一个高效协作的“云上工厂”：
| K8s 组件 | 工厂角色 | 干的事 |
|---|---|---|
| etcd | 仓库 + 台账 | 所有货物状态、任务列表、库存信息都记在这 |
| Controller | 车间主管 | 一直在看“应该有几个机器在干活”，不对劲就立刻调人 |
| Kubelet | 一线工人 | 按图纸干活，安装软件、启动容器、上报进度 |
想想就明白了：你让一个工厂生产 10 台机器，Controller 发现只在运行 7 台，就立刻安排新的；Kubelet 会负责把机器装好。仓库（etcd）记录“现在到底有几台、什么状态”，大家都依赖这个账本来行动。
etcd：这个账本没了，集群就瘫了
etcd 是 Kubernetes 的唯一数据库，所有资源对象都存储在这里，比如：
- 你 apply 的 YAML 定义（Pod、Service、Deployment…）
- 当前所有节点、容器、网络、证书的状态
- 控制器的目标期望值
特点：
- 是一个轻量的分布式 KV 存储（使用 Raft 算法保证强一致性）
- 性能瓶颈多数出在磁盘 IO，建议配 NVMe
- 是集群级的“单点真实源”（Single Source of Truth）
备份建议：
etcdctl snapshot save /backup/etcd-$(date +%s).db
📌 注意：很多集群“突然卡死”，其实不是 K8s 崩了，是 etcd 慢了、写不进了、磁盘爆了。
Controller：最操心的“车间主管”
Controller（控制器）是 Kubernetes 控制面的核心逻辑引擎。
你给系统下达了一个“我要 5 个 Nginx 副本”的命令，其实是 Controller 在：
- 不停“观察”：现在到底有几个 Pod 正在运行？
- 发现少了，就调用 API Server 补上
- 多了，主动删掉
常见控制器：
- ReplicaSet Controller（管理副本）
- Deployment Controller（发布滚动更新）
- HPA Controller（按指标自动伸缩）
- Node Controller（判断节点挂了）
关键点：
- 控制器是“理想派”：只关心期望和实际有没有差别
- 实际部署动作不是它完成的，是 Kubelet 做的
- 每个控制器只关注一种资源对象，并以“控制循环”运行
🔧 诊断技巧：
kubectl get events # 看 Controller 有没有派单
kubectl describe deploy nginx-deploy # 看控制器下发情况
Kubelet：真正落地干活的“前线工人”
Kubelet 是运行在每个 Node 上的 Agent，它负责 Pod 的生命周期管理。
它是唯一“干实事”的人，比如：
- 看 API Server 发来的 Pod 定义
- 调用 containerd / Docker 拉镜像、创建容器
- 定期执行健康探针、挂载存储卷、配置网络
- 监控 Pod 状态并上报
Kubelet 不关心副本数、不关心调度，它的工作是：
- 收到任务
- 想尽办法“让它跑起来”
- 状态回报 API Server
🔍 排查技巧：
journalctl -u kubelet -f # 看 Kubelet 日志
crictl ps -a # 查看容器运行情况
常见故障如：
- 容器创建失败（镜像拉不下来、Volume 挂不稳）
- CNI 出错，Pod 卡在
ContainerCreating - Kubelet 无法上报状态，节点变成
NotReady
用一次 Pod 创建讲清三者如何配合
你执行了：
kubectl apply -f nginx-deploy.yaml
幕后发生了什么？
- API Server 收到请求，把 YAML 写进 etcd。
- ReplicaSet Controller 发现目标是运行 3 个 Pod。
- 它发现现在是 0，就新建了 3 个 Pod 对象 → 写入 etcd。
- Scheduler 出场，决定 Pod 分配在哪些节点。
- 各个 Node 的 Kubelet 发现自己被分配了任务 → 拉镜像 → 起容器。
- Kubelet 把“我起好了”这件事回报 API Server → API Server 写进 etcd。
- Controller 验证目标和实际一致，一切 OK。
一个闭环就这样完成了。
故障排查顺序：按角色来找错最省事
| 问题 | 先看谁 | 工具 |
|---|---|---|
| Pod 一直起不来 | Kubelet | describe pod 看事件 / journalctl |
| Deployment 更新没生效 | Controller | kubectl get events |
| 全集群卡顿 / 无法 get 资源 | etcd | etcdctl alarm list + iostat |
| 节点频繁 NotReady | Kubelet | 检查网络 / 心跳间隔设置 |
| 自定义资源没触发动作 | Controller | kubectl logs <controller-pod> |
总结：记住这 3 个核心角色的分工
| 组件 | 本质 | 类比 | 出问题的典型表现 |
|---|---|---|---|
| etcd | 存储系统 | 仓库台账 | 全局卡顿、状态混乱 |
| Controller | 控制逻辑 | 主管派单 | 副本数不符、自动扩容失败 |
| Kubelet | 执行器 | 工人干活 | Pod 卡壳、容器不启动 |
记住一句话： etcd 存信息，Controller 造理想，Kubelet 让它成真。
📌 写在最后
喜欢这种“把晦涩架构讲明白”的文章？欢迎 👍 收藏 + 分享给你的 DevOps 小伙伴，我们云端再见！
