第一章：Kubernetes架构总览

1. 为什么要了解架构？

想想自己需要管理一座城市——需要知道市长办公室在哪（控制面）、交警怎么指挥交通（调度器）、负责节点（节点代理）。Kubernetes就是管理"容器化应用"这座城市的操作系统。

如果不理解架构，就不知道一个命令下去会发生什么。

1. Kubernetes 的前身:Google Borg

脱胎于Google内部运行了超过15年的管理集群-——Borg。

四大核心组件

• BorgMaster 集群大脑。负责状态管理和决策。【市长角色】

• Scheduler 智能调度器，决定任务跑在哪台机器。【交警指挥中心】

• Borglet 节点代理，管理容器生命周期。【每栋物业】

• Borgcfg 声明式配置工具。【城市规划蓝图】

关键设计思想：BorgMaster 使用Paxos协议保证一致性——即使部分节点故障，集群状态也不会丢失。这个思想直接传承给了Kubernetes.

---

1. Kubernetes架构总览

设计哲学：决策集中，任务分布。

---

1. 控制面组件详解

控制面是集群的大脑，负责全局决策与事件响应。

kube-apiserver——集群的唯一入口

• 所有组件之间的通信都通过它

• 所有kuberctl命令最终都达它

• 负责认证、鉴权、准入控制。

API Server 集群的前台接待，所有访客必须先经过它。

etcd——集群的记忆

• 分布式键值存储，存储集群的所有数据。

• 高可用、强一致性。

• 如果etcd挂了，集群就失忆了。

Etcd 是集群的数据库，丢了它失去整个集群的状态。

kube—scheduler 调度员

• 监听新创建的Pod

• 根据资源需求、亲和性、污点性等条件，选择最合适的节点。

新来的住户（Pod）该住在哪栋大楼（Node），调度员说了算。

kube-controller-manager——循环控制执行者

• 包含多个控制器（Deployment、ReplicaSet、Node等）

• 每个控制器通过控制循环不断对齐"期望状态"和“实际状态”。

要三个副本，它就一直盯着，少了就加，多了就减少。

1. 节点组件详解

每个工作节点上必须运行以下组件：

• Kubelet ——节点管家

    确保Pod中的容器正常运行。

    向API Server汇报节点状态。

• kube-proxy ——网络规则管理者

维护节点上的网络规则（iptables/IPVS）

实现Service的负载均衡。

• 容器运行时—— 实际干活的

    负载运行容器

    常见选择：containerd 、cri-o

---

1. API与对象模型

什么是Kubernetes对象？

对象是集群中的实体，描述你想要什么。比如：

我想要运行3个nginx副本——>Deloyment 对象

我想要暴露一个服务———> Server对象

我想存储配置信息——>ConfigMap 对象

核心该概念：spec与status 参数状态

每个对象都有两个关键字：spec 声明我想要什么，期望状态；status 观测实际状态。

控制器持续将实际状态向期望状态对齐，并同步更新 status 反映真实情况。

对象标识：每个对象由三样东西确定：

• Name (用户定义名称)

• UID （系统自动生成）

• Namespace (命名空间范围)

标签范围（Label）与 选择器（Selector）

标签是附加在对象上的键值，是Kubernetes组织资源核心机制：

metadata: labels: app: nginx env: production tier: frontend

选择器通过标签筛选对象：

kubectl get pods -l app=nginx,env=production

---

1. 命名空间（Namespace）

命名空间在单个集群内实现虚拟隔离，适合多个租户场景。

kubernetes默认的四个命名空间：

Defalut 默认命名空间，未指定时资源在此。

• Kube-system ：系统组件（API Server、调度器。

• Kube-public ：所有用户可读的公共资源。

• Kube-node-lease ：节点心跳数据。

---

1. 对象所有权与垃圾回收

对象之间可以有父子关系（通过ownerReference字段）。删除父对象时，可以选择三种策略：

• 前台删除：先删除子对象，再删父对象。

• 后台删除：先删除父对象，再删子对象。

• 孤立删除：只删除父对象，子对象保留。

比如：删除一个Deployment 时，默认会级联删除它创建的ReplicaSet和Pod.

---

1. API Server 请求处理流程。

当你执行·kubectl apply -f deploy.yaml·时，请求经过以下步骤：

客户端请求 │ ▼ ① 认证（Authentication）—— 你是谁？ │ ▼ ② 鉴权（Authorization）—— 你有权限吗？ │ ▼ ③ 准入控制（Admission Control）—— 要不要修改/拒绝？ │ ▼ ④ 校验（Validation）—— 格式合法吗？ │ ▼ ⑤ 存储（Persist）—— 写入 etcd

1. 扩展机制

Kubernetes 设计之初就考虑了可扩展性：

• CRD :自定义资源类型

• Webhook ：拦截API请求做校验/修改

• 认证模块 : 新增认证方式

• 调度插件：自定义调度逻辑

• 网络插件：实现Pod网络

• 存储插件：对接存储系统

---

1. 日志监控

组件日志路径（Linux）

组件	路径
kube-apiserver	/var/log/kube-apiserver.log
kube-scheduler	/var/log/kube-scheduler.log
kube-controller-manager	/var/log/kube-controller-manager.log
kubelet	/var/log/kubelet.log
容器日志	/var/log/pods/<namespace>_<pod>_<uid>/<container>/

指标采集

所有组件通过 /metrics 端点暴露 Prometheus 格式指标，是监控集群健康的基础设施。

本章小结

你要记住的	核心要点
架构模式	控制面 + 工作节点，决策集中、任务分布
控制面四组件	API Server、etcd、Scheduler、Controller Manager
节点三组件	kubelet、kube-proxy、容器运行时
对象核心思想	spec（期望）→ 控制器 → status（实际）
API Server 流程	认证 → 鉴权 → 准入控制 → 校验 → 存储
扩展能力	CRD、Webhook、网络/存储/调度插件