K8s架构总览与组件职责表

最新推荐文章于 2026-08-17 23:56:37 发布

原创最新推荐文章于 2026-08-17 23:56:37 发布 · 468 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

云原生

Kubernetes 架构总览与组件职责表

一、整体架构

Kubernetes 采用 控制平面 + 工作节点 的分层架构。

┌─────────────────────────────────────────────────┐
│                  控制平面                        │
│  (大脑，负责决策和管理)                           │
│                                                  │
│  kube-apiserver  kube-scheduler  controller-mgr  │
│        │             │              │            │
│        └─────────────┴──────────────┘            │
│                      │                           │
│                    etcd                          │
│                 (数据库)                          │
└──────────────────────┬───────────────────────────┘
                       │
┌──────────────────────┴───────────────────────────┐
│                  工作节点                         │
│  (干活的，运行业务Pod)                             │
│                                                  │
│    kubelet    kube-proxy    容器运行时            │
│                                                  │
│  ┌──────────────────────────────────────────┐    │
│  │         Pods（业务容器）                  │    │
│  │  ┌───┐ ┌───┐ ┌───┐                      │    │
│  │  │Pod│ │Pod│ │Pod│                      │    │
│  │  └───┘ └───┘ └───┘                      │    │
│  └──────────────────────────────────────────┘    │
└──────────────────────────────────────────────────┘

二、为什么要分层架构？

职责分离：控制平面只管决策，工作节点只管运行，互不干扰
水平扩容：业务量增长时，只需增加工作节点，不用动控制平面
高可用：一个工作节点挂了，不影响其他节点和控制平面
解耦：开发团队专注应用（工作节点），运维团队专注集群（控制平面）
安全：控制平面不直接暴露，减少攻击面

三、控制平面组件（大脑）

组件	别名	核心职责	关键特性	打比方
kube-apiserver	API服务器	集群唯一入口，所有组件都通过它通信	唯一直接操作etcd的组件提供RESTful API 负责认证授权准入控制可水平扩展	公司前台/总机
etcd	分布式数据库	存储集群所有数据（配置、状态、元数据）	分布式键值存储（非关系型）强一致性（Raft协议）生产环境至少3节点（奇数）只有apiserver能直接读写	公司档案室
kube-scheduler	调度器	决定新Pod调度到哪个节点	过滤不符合条件的节点给剩余节点打分选分数最高的节点考虑资源/亲和性/污点等	公司行政/调度员
kube-controller-manager	控制器管理器	运行各种控制器，维护期望状态	Node Controller：监控节点 Deployment Controller：维护副本数 Endpoint Controller：维护Service-Pod关联声明式API，自动向期望状态靠拢	各部门经理

控制器的核心思想：声明式 API

你告诉K8s："我想要3个副本"
        ↓
控制器不断检查当前状态
        ↓
当前只有2个 → 自动创建1个
当前有4个 → 自动删除1个
        ↓
永远维持"期望状态"

声明式 vs 命令式：

命令式：告诉系统"怎么做"（一步一步命令）
声明式：告诉系统"我想要什么"（系统自己想办法）

四、工作节点组件（干活的）

组件	别名	核心职责	关键特性	打比方
kubelet	节点管家	本节点Pod的全生命周期管理	接收apiserver指令管理Pod创建/启动/停止监控Pod状态并上报不管理非K8s创建的容器	楼层楼管
kube-proxy	网络代理	维护节点网络规则，实现Service负载均衡	iptables模式（默认） IPVS模式（高性能）为Service分配虚拟IP 维护网络转发规则	前台转线
容器运行时	Container Runtime	真正运行容器	containerd（现在主流，K8s 1.24+默认） Docker（需cri-docker适配） CRI-O（轻量级）通过CRI标准接口对接	办公设备

CRI 接口

K8s不直接管理容器，通过 CRI（Container Runtime Interface）标准接口对接容器运行时。只要实现了CRI，都可以接入。

五、节点挂了会发生什么？（完整流程）

工作节点挂了
    ↓
kubelet 无法上报心跳
    ↓
apiserver 将节点标记为 NotReady
    ↓
Node Controller 检测到节点超时（默认5分钟）
    ↓
触发 Pod 驱逐机制
    ↓
将该节点上的 Pod 标记为 Terminating
    ↓
在其他健康节点上重建这些 Pod
    ↓
业务自动恢复 ✅

这就是 K8s 的自愈能力。

六、常用排查命令

场景	命令
查看节点状态	`kubectl get nodes`
查看节点详情	`kubectl describe node <node-name>`
查看组件状态	`kubectl get componentstatuses`
查看Pod分布	`kubectl get pods -o wide`
查看调度事件	`kubectl get events --sort-by=.metadata.creationTimestamp`

七、易混淆点澄清

kube-apiserver vs kubelet
- apiserver：控制平面的，集群入口，管理者
- kubelet：工作节点的，执行任务，执行者
Pod 健康检查 vs 节点健康检查
- Pod健康检查（Probe）：kubelet做的，检查单个容器
- 节点健康检查：Node Controller做的，检查整个节点
etcd 不是数据库吗？为什么不用MySQL？
- etcd是分布式键值存储，强一致，适合存配置和状态
- MySQL是关系型数据库，复杂但重，不适合K8s这种场景
- K8s只存元数据，不需要复杂查询，etcd更轻量高效