备考助手
🎯 学习目标
- 理解控制平面组件
- 掌握工作节点组件
- 了解集群通信机制
📌 核心知识点
kube-apiserveretcd 数据存储kube-schedulerkube-controller-managerkubelet 和 kube-proxy
Kubernetes 集群架构
📋 本章概览
| 主题 | 考试权重 | 重要程度 |
|---|---|---|
| Control Plane 组件 | ★★★★★ | 必考 |
| Worker Node 组件 | ★★★★★ | 必考 |
| etcd 备份与恢复 | ★★★★★ | 高频考点 |
| 集群升级 | ★★★★☆ | 重要 |
| kubeadm 操作 | ★★★★☆ | 重要 |
💡 考试占比：集群架构、安装和配置占 CKA 考试的 25%
🎯 学习目标
学完这一章，你应该能够：
- 从零理解 Kubernetes 集群架构 —— 每个组件是什么、为什么需要它
- 掌握 Control Plane（控制平面） 四大组件的职责和工作原理
- 掌握 Worker Node（工作节点） 三大组件的职责
- 熟练执行 etcd 备份和恢复（实操高频考题）
- 独立完成集群版本升级（drain → upgrade → uncordon 流程）
- 管理集群节点（添加、维护、标签）
📝 学习建议
通俗理解： 一个 Kubernetes 集群就像一家大型物流公司。
想象你运营一家快递公司，每天要处理成千上万个包裹（容器化应用）：
-
总部（Control Plane / Master Node） —— 做决策的地方
- 前台接待（kube-apiserver）：所有指令（"发这个包裹"、"查这个订单"）都要经过前台，前台验证你的身份、检查权限，然后转交给对应部门
- 档案室（etcd）：记录公司所有运营数据 —— 哪些包裹在哪个仓库、哪些司机在路上、哪条线路在维修。如果档案室丢了数据，整个公司就瘫痪
- 调度中心（kube-scheduler）：看哪个仓库有空位、哪条线路不堵车，决定"这个包裹送去哪个仓库处理"
- 监控部门（kube-controller-manager）：不断巡查 —— "仓库 A 的包裹够不够？不够就再调一批""司机 B 是不是掉线了？是就派替补"
-
各地仓库（Worker Nodes） —— 干活的地方
- 仓库主管（kubelet）：接收总部指令，确保包裹被正确处理。定时向总部报告"我这里一切正常"
- 路由员（kube-proxy）：让外部用户能找到包裹 —— "你要的快递在仓库 B 的 3 号货架"
- 传送带（Container Runtime）：实际搬运包裹的机器（containerd）
为什么第一章学架构？
CKA 考试中大量题目是排查故障。如果你不理解每个组件的作用和它们之间的关系，就无法判断"哪个组件出了问题"。比如：
- Pod 无法被调度 → 可能是 Scheduler 出了问题
- kubectl 命令无响应 → 可能是 API Server 挂了
- 集群数据丢失 → 可能是 etcd 损坏
- 节点上 Pod 没有运行 → 可能是 kubelet 停了
本章知识地图：
Kubernetes 集群架构
│
├── Control Plane（总部 = 做决策）
│ ├── kube-apiserver ─── 所有通信的入口（唯一接触 etcd 的）
│ ├── etcd ────────────── 集群的"大脑记忆"（所有状态数据）
│ ├── kube-scheduler ──── 决定 Pod 在哪个节点运行
│ ├── kube-controller-manager ── 持续巡检，保证"现实 = 期望"
│ └── cloud-controller-manager ── 对接云厂商 API（可选）
│
├── Worker Node（仓库 = 干活）
│ ├── kubelet ────────── 节点代理，确保容器运行
│ ├── kube-proxy ──────── 网络规则，Service → Pod 转发
│ └── Container Runtime ── 运行容器（containerd）
│
├── etcd 备份与恢复（高频考题）
│ ├── snapshot save ── 备份
│ └── snapshot restore ── 恢复
│
├── 集群升级（kubeadm）
│ ├── 先 Master 后 Worker
│ └── drain → upgrade → uncordon
│
└── 节点管理
├── cordon / drain / uncordon
└── 标签与注解
📚 官方文档：Kubernetes Components
Kubernetes 架构概览
先看一张全景图
图解说明：
- 这张图在讲什么：Kubernetes 集群的所有核心组件以及它们之间的通信关系。
- 你应该先看哪里：先看上半部分的 Control Plane（控制平面），再看下半部分的 Node（工作节点），最后看它们之间通过 API Server 连接。
- 考试怎么考：给你一个故障现象，让你判断是哪个组件出了问题。理解这张图就是排错的基础。
📖 图片来源：Kubernetes 官方文档 - CC BY 4.0
图解说明：
- 这张图在讲什么：Control Plane 和 Worker Node 的内部组件及其通信路径。
- 你应该先看哪里：注意所有组件都通过 kube-apiserver 通信（星型拓扑），etcd 只和 API Server 直接交互。
- 最易混淆：很多人以为 Scheduler 或 Controller Manager 可以直接读写 etcd —— 不行！所有组件都必须经过 API Server。
📖 图片来源：Kubernetes 官方文档 - CC BY 4.0
集群整体架构
┌─────────────────────────────────────────────────────────────────────────────┐
│ Kubernetes Cluster │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ Control Plane (Master Node) │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ ┌────────────┐ │ │
│ │ │ kube-api- │ │ etcd │ │ kube- │ │ kube- │ │ │
│ │ │ server │ │ │ │ scheduler │ │ controller │ │ │
│ │ │ │ │ (数据存储) │ │ │ │ -manager │ │ │
│ │ │ (API 网关) │◄─┤ │ │ (调度决策) │ │ (控制循环) │ │ │
│ │ └──────┬──────┘ └─────────────┘ └──────────────┘ └────────────┘ │ │
│ │ │ │ │
│ └─────────┼──────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ API 通信 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Worker Nodes │ │
│ │ │ │
│ │ ┌─────────────────────────┐ ┌─────────────────────────┐ │ │
│ │ │ Worker Node 1 │ │ Worker Node 2 │ │ │
│ │ │ ┌────────┐ ┌────────┐ │ │ ┌────────┐ ┌────────┐ │ │ │
│ │ │ │kubelet │ │kube- │ │ │ │kubelet │ │kube- │ │ │ │
│ │ │ │ │ │proxy │ │ │ │ │ │proxy │ │ │ │
│ │ │ └────────┘ └────────┘ │ │ └────────┘ └────────┘ │ │ │
│ │ │ ┌────────────────────┐ │ │ ┌────────────────────┐ │ │ │
│ │ │ │ Container Runtime │ │ │ │ Container Runtime │ │ │ │
│ │ │ │ (containerd) │ │ │ │ (containerd) │ │ │ │
│ │ │ └────────────────────┘ │ │ └────────────────────┘ │ │ │
│ │ │ ┌─────┐ ┌─────┐ │ │ ┌─────┐ ┌─────┐ │ │ │
│ │ │ │ Pod │ │ Pod │ ... │ │ │ Pod │ │ Pod │ ... │ │ │
│ │ │ └─────┘ └─────┘ │ │ └─────┘ └─────┘ │ │ │
│ │ └─────────────────────────┘ └─────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
组件通信流程
通俗理解： 下面这张流程图展示了你执行一条 kubectl create 命令后，请求在集群内部是怎么流转的。
用户请求 → kubectl → API Server → etcd (存储状态)
│
├──→ Scheduler (调度 Pod)
│
├──→ Controller Manager (控制循环)
│
└──→ kubelet (节点代理) → Container Runtime → Pod
完整举例 —— 你执行 kubectl run nginx --image=nginx 后发生了什么：
kubectl把请求发给 API Server- API Server 做认证（你是谁？）→ 授权（你能不能创建 Pod？）→ 准入控制（Pod 配置合规吗？）
- API Server 把 Pod 对象写入 etcd（此时 Pod 状态是 Pending，还没有分配节点）
- Scheduler 发现有一个没分配节点的 Pod → 选一个合适的 Node → 告诉 API Server "这个 Pod 应该去 Node-2"
- API Server 更新 etcd 中的 Pod 信息（添加 nodeName: node-2）
- Node-2 上的 kubelet 发现自己被分配了一个新 Pod → 告诉 Container Runtime 拉镜像、启动容器
- 容器启动后，kubelet 向 API Server 报告 "Pod 状态: Running"
💡 排错思路：如果 Pod 一直 Pending → 检查 Scheduler。如果 Pod 分配到了节点但不 Running → 检查 kubelet 和 Container Runtime。
Control Plane 组件
Control Plane 是集群的"大脑"，负责做决策。在生产环境中通常部署 3 个 Master 节点实现高可用。
kube-apiserver
术语：kube-apiserver
- 一句话解释：集群的中央枢纽，所有组件（Scheduler、Controller Manager、kubelet、kubectl）都通过它通信。它是唯一直接读写 etcd 的组件。
- 形象比喻：像公司的前台接待 + 安保。所有人进公司都要经过前台，前台验证你的工牌（认证）、检查你能进哪些楼层（授权）、记录你的来访（审计），然后才放行。
- 考试怎么考：API Server 挂了 → kubectl 完全无法使用 → 整个集群"失联"（但已经在运行的 Pod 不会立即停止）。
- 最易混淆：API Server 挂了 ≠ 所有 Pod 都停了。已经在运行的容器会继续运行，只是你无法管理它们了。
主要职责：
- 处理所有 REST API 请求（kubectl 的每一条命令最终都是 API 调用）
- 认证、授权和准入控制
- 与 etcd 通信（唯一直接访问 etcd 的组件）
- 验证和配置 API 对象
# 检查 API Server 状态
kubectl get componentstatuses
# 查看 API Server Pod
kubectl get pods -n kube-system | grep apiserver
# 查看 API Server 配置（考试常用 — 找端口、证书路径等）
cat /etc/kubernetes/manifests/kube-apiserver.yaml
API Server 请求处理流程（三道关卡）：
客户端请求
│
▼
┌─────────────┐
│ 认证 │ 验证用户身份 (证书、Token、Basic Auth)
│ Authentication│ → "你是谁？"
└─────┬───────┘
│
▼
┌─────────────┐
│ 授权 │ 检查用户权限 (RBAC、ABAC、Webhook)
│ Authorization│ → "你能不能做这个操作？"
└─────┬───────┘
│
▼
┌─────────────┐
│ 准入控制 │ 修改/验证请求 (Admission Controllers)
│ Admission │ → "这个请求合规吗？需要修改吗？"
└─────┬───────┘
│
▼
┌─────────────┐
│ 持久化 │ 存储到 etcd
│ Persistence │ → "记录下来"
└─────────────┘
为什么要三道关卡？
- 认证：防止匿名用户乱操作（"你是谁"）
- 授权：防止越权操作，开发者不能删生产环境（"你能做什么"）
- 准入控制：强制执行策略，如"所有 Pod 必须设资源限制"（"你的请求合规吗"）
⚠️ 考试排错：如果
kubectl返回connection refused，说明 API Server 没有运行。先检查/etc/kubernetes/manifests/kube-apiserver.yaml有没有语法错误，再看 kubelet 日志journalctl -u kubelet | grep apiserver。
etcd
术语：etcd
- 一句话解释：分布式键值数据库，存储集群的所有状态数据 —— Pod 在哪里、Service 怎么配的、Secret 内容是什么，全部保存在 etcd 里。
- 形象比喻：像公司的核心档案室。公司的所有合同、员工信息、财务记录都在这里。如果档案室被烧了（etcd 数据丢失），公司就不知道自己有多少员工、有多少订单了 —— 集群会完全失忆。
- 考试怎么考：etcd 备份与恢复是 CKA 最高频的实操题之一。几乎每次考试都会考到。
- 最易混淆：etcd 不直接对外服务，只有 API Server 能读写它。其他组件想获取集群状态，必须问 API Server。
为什么 etcd 这么重要？
Kubernetes 的所有"状态"都存在 etcd 里。如果 etcd 丢了数据：
- 你的 Deployment 定义没了 → Pod 不知道自己该有几个副本
- Service 配置没了 → 网络路由全断
- Secret 没了 → 应用拿不到数据库密码
- 简单说，没有 etcd，Kubernetes 就是一堆不知道该干啥的容器
etcd 的关键特性：
| 特性 | 含义 | 为什么重要 |
|---|---|---|
| 高可用（Raft 协议） | 多副本同步，少数节点挂了不丢数据 | 生产环境部署 3 或 5 个 etcd 节点 |
| 强一致性 | 读到的数据一定是最新的 | 避免两个 Scheduler 同时调度同一个 Pod |
| Watch 机制 | 数据变化时主动通知 | Scheduler 能实时发现"有新 Pod 需要调度" |
| 键值存储 | 用路径（/registry/pods/default/nginx）存数据 | 结构清晰，查询快速 |
数据存储结构（理解即可，考试不直接考）：
/registry
├── /pods
│ └── /default
│ └── /nginx-pod
├── /deployments
│ └── /default
│ └── /nginx-deployment
├── /services
│ └── /default
│ └── /nginx-service
├── /secrets
├── /configmaps
└── /nodes
常用 etcd 命令（考试必须熟练）：
# 检查 etcd 健康状态
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
# 查看 etcd 成员
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
member list
# 查看 etcd 中的所有键
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get / --prefix --keys-only
💡 考试技巧：etcd 命令的三个证书参数（
--cacert、--cert、--key）路径可以在/etc/kubernetes/manifests/etcd.yaml里找到。考试时先cat这个文件，复制证书路径。
kube-scheduler
术语：kube-scheduler
- 一句话解释：负责决定新创建的 Pod 应该被放到哪个 Node 上运行。它不负责启动 Pod（那是 kubelet 的事），只负责"选位置"。
- 形象比喻：像大学的课程排课系统。有个新课需要安排教室 → 排课系统检查哪些教室空着、座位够不够、有没有投影仪 → 选一个最合适的教室。但排课系统不负责把桌椅搬进去（那是后勤的事）。
- 考试怎么考：Pod 一直 Pending 状态 → 可能是 Scheduler 无法找到合适的节点（资源不够、Taint 没有 Toleration、NodeSelector 不匹配等）。
- 最易混淆：Scheduler 只做"选节点"的决策，不负责在节点上启动 Pod。启动 Pod 是 kubelet 的工作。
调度过程（两阶段 — 必须理解）：
新 Pod 创建（没有 nodeName）
│
▼
┌─────────────────────────────────────┐
│ 过滤阶段 (Filtering) │
│ 排除所有不满足条件的节点 │
│ • 资源是否充足？(CPU/Memory) │
│ • 节点是否有 Taint？Pod 有没有 │
│ 对应的 Toleration？ │
│ • 是否满足 NodeSelector？ │
│ • 是否满足 Node Affinity？ │
│ • 端口是否冲突？ │
└─────────────────┬───────────────────┘
│
▼ 候选节点列表（可能有多个）
┌─────────────────────────────────────┐
│ 打分阶段 (Scoring) │
│ 对候选节点进行评分，选最优的 │
│ • 资源均衡性（分散负载） │
│ • Pod 亲和性/反亲和性 │
│ • 镜像本地性（已有镜像的优先） │
│ • 自定义优先级 │
└─────────────────┬───────────────────┘
│
▼
选择最高分节点 → 绑定 Pod
通俗总结： 过滤 = "谁能干" → 打分 = "谁最合适" → 绑定 = "就你了"
调度考虑因素（考试高频）：
| 因素 | 描述 | 示例 |
|---|---|---|
| 资源需求 | CPU 和内存请求/限制 | requests: cpu: 500m |
| 节点选择器 | 标签匹配 | nodeSelector: env: prod |
| 亲和性 | Node/Pod Affinity | requiredDuringScheduling |
| 污点容忍度 | Taints/Tolerations | tolerations: key=value |
| 端口冲突 | 检查端口可用性 | hostPort: 80 |
⚠️ 排错要点：Pod 一直 Pending +
kubectl describe pod显示no nodes available to schedule→ 检查是不是所有节点都被 Taint 了但 Pod 没有对应的 Toleration，或者所有节点资源不足。
kube-controller-manager
术语：kube-controller-manager
- 一句话解释：运行多个控制器的进程，每个控制器都在做同一件事 —— 不断检查"当前状态是否等于期望状态"，如果不等，就采取行动修复。
- 形象比喻：像一组自动巡检员。有一个专门数人头的（"应该有 3 个副本，现在只有 2 个，赶紧再启动一个"），有一个专门检查设备的（"节点 B 失联了，把上面的 Pod 迁走"），有一个专门检查排班的（"这个 Job 完成了，清理掉"）。
- 考试怎么考：Deployment 设了 replicas: 3 但只有 2 个 Pod 在运行 → Controller Manager 应该自动创建第 3 个。如果没有 → 检查 Controller Manager 是否正常。
- 最易混淆：Controller Manager 是一个进程，但里面跑了很多个不同的控制器，每个控制器负责不同的资源类型。
控制器循环（核心概念 — Reconciliation Loop）：
┌──────────────────────────────────────┐
│ │
▼ │
┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ 观察 │───▶│ 比较 │───▶│ 行动 │──┘
│ Observe │ │ Compare │ │ Act │
└─────────┘ └─────────┘ └─────────┘
当前状态 与期望状态 采取纠正
进行比较 行动
为什么这个循环如此重要？
这就是 Kubernetes "声明式"管理的核心思想：你告诉 Kubernetes "我要 3 个 nginx Pod"（期望状态），Controller 会持续确保实际运行的就是 3 个。少了它加，多了它删，挂了它替换。你不需要手动干预。
主要控制器（了解各自职责）：
| 控制器 | 职责 | 例子 |
|---|---|---|
| Node Controller | 监控节点状态，处理节点故障 | 节点失联 5 分钟后驱逐 Pod |
| Replication Controller | 维护 Pod 副本数量 | 保持 3 个副本 |
| Deployment Controller | 管理 Deployment 滚动更新 | 逐步替换旧版 Pod |
| Endpoints Controller | 填充 Endpoints 对象 | Service 对应哪些 Pod IP |
| Service Account Controller | 创建默认 ServiceAccount 和 Token | 每个 Namespace 自动创建 |
| Job Controller | 管理 Job 对象 | 任务完成后标记 |
| Namespace Controller | 管理 Namespace 生命周期 | 删除 Namespace 时清理资源 |
cloud-controller-manager
与云提供商 API 交互的可选组件。
通俗理解： 如果你在 AWS/GCP/Azure 上运行 Kubernetes，有些资源（如 Load Balancer、云盘、云网络）需要调用云厂商的 API 来管理。cloud-controller-manager 就是 Kubernetes 和云厂商之间的"翻译官"。
职责：
- 管理云负载均衡器（创建 Service type: LoadBalancer 时）
- 管理云存储卷（创建 PV 时）
- 管理云网络路由
- 管理节点（云实例的生命周期）
💡 如果你用的是自建集群（不在云上），就不需要这个组件。
Worker Node 组件
Worker Node 是"干活"的地方。每个 Worker Node 上运行三个核心组件。
kubelet
术语：kubelet
- 一句话解释：运行在每个节点上的代理，负责接收 API Server 的指令，确保 Pod 里的容器按要求运行，并定期向 API Server 汇报状态。
- 形象比喻：像每个分公司的经理。总部（API Server）说"在你那里开一个新项目组（Pod）"，经理就安排人手（容器）开始工作，并定期向总部报告"项目进展正常"或"有人离职了（容器崩溃了）"。
- 考试怎么考：节点状态 NotReady → 首先检查 kubelet 是否在运行。Pod 在某个节点上无法启动 → 检查该节点的 kubelet 日志。
- 最易混淆：kubelet 不是 Pod。它是一个 systemd 服务，直接运行在节点的操作系统上，不是通过 Kubernetes 管理的。
主要职责：
- 接收 PodSpec 并确保容器运行
- 向 API Server 报告节点和 Pod 状态
- 执行容器健康检查（Liveness / Readiness / Startup Probe）
- 管理容器生命周期
# 查看 kubelet 状态（节点排错第一步！）
systemctl status kubelet
# 查看 kubelet 日志（排错核心命令）
journalctl -u kubelet -f
# 查看 kubelet 配置
cat /var/lib/kubelet/config.yaml
# 重启 kubelet
systemctl restart kubelet
kubelet 工作流程：
API Server
│
│ PodSpec（"在你这里运行这个 Pod"）
▼
┌─────────────────────────────────────────┐
│ kubelet │
│ ┌─────────────────────────────────┐ │
│ │ Pod Lifecycle Manager │ │
│ │ • 创建 Pod 沙箱（网络命名空间） │ │
│ │ • 启动容器 │ │
│ │ • 执行健康检查 │ │
│ │ • 向 API Server 报告状态 │ │
│ └─────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ Container Runtime Interface │ │
│ │ (CRI) │ │
│ └─────────────────────────────────┘ │
└────────────────┬────────────────────────┘
│
▼
Container Runtime
(containerd/CRI-O)
⚠️ 考试高频排错：
kubectl get nodes显示某节点 NotReady → SSH 到该节点 →systemctl status kubelet→ 如果 kubelet 停了就systemctl start kubelet→ 再检查日志看具体原因。
kube-proxy
术语：kube-proxy
- 一句话解释：运行在每个节点上的网络代理，维护节点上的网络规则，使得 Service 可以正确地把流量转发到对应的 Pod。
- 形象比喻：像每个仓库的快递分拣员。有人寄快递到"前端服务"（Service），分拣员查路由表，知道"前端服务"对应仓库里的 3 个货架（Pod），就把快递送到其中一个。
- 考试怎么考：Service 创建了但无法访问 Pod → 检查 kube-proxy 是否正常运行。
- 最易混淆：kube-proxy 不是一个真正的"代理"，它不转发流量本身。它是通过维护 iptables/ipvs 规则来告诉 Linux 内核如何转发。
代理模式：
| 模式 | 描述 | 特点 |
|---|---|---|
| iptables | 默认模式 | 使用 iptables 规则转发，适合中等规模 |
| ipvs | 高性能模式 | 更好的扩展性和性能，适合大规模集群 |
| userspace | 传统模式 | 已弃用，不用管 |
# 查看 kube-proxy 模式
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
# 查看 iptables 规则（了解 Service 如何转发）
iptables -t nat -L KUBE-SERVICES
# 查看 ipvs 规则（如使用 ipvs 模式）
ipvsadm -Ln
Container Runtime
术语：Container Runtime
- 一句话解释：真正运行容器的底层软件。kubelet 告诉它"拉这个镜像、启动这个容器"，它就执行。
- 形象比喻：如果 kubelet 是经理，Container Runtime 就是实际干活的工人。经理下指令，工人搬砖。
支持的运行时（考试必记）：
| 运行时 | 状态 | 说明 |
|---|---|---|
| containerd | ✅ 推荐 | 行业标准，轻量级，CKA 考试环境默认使用 |
| CRI-O | ✅ 支持 | 专为 Kubernetes 设计 |
| Docker | ❌ 已弃用 | Kubernetes 1.24 版本后不再支持 dockershim |
⚠️ 重要：虽然 Docker 不再直接支持，但 Docker 构建的镜像仍然可以在 containerd 上运行。"不支持 Docker" 是指不支持 Docker 作为运行时，不影响 Docker 镜像。
# 查看 containerd 状态
systemctl status containerd
# 使用 crictl 命令（CRI 工具，替代 docker 命令）
crictl ps # 查看运行中的容器
crictl images # 查看镜像
crictl pods # 查看 Pod
🔥 etcd 备份与恢复（高频考点）
为什么这是最高频考题？
因为 etcd 是集群的"大脑记忆"。在真实生产环境中，如果你不定期备份 etcd，一旦集群出严重故障（比如 etcd 数据损坏），你就会丢失所有配置 —— Deployment、Service、Secret 全部没了。CKA 考试几乎每次都会考 etcd 备份或恢复。
etcd 备份
考试场景： "请将 etcd 快照保存到 /backup/etcd-snapshot.db"
# 第一步：查看 etcd 配置，找到证书路径
cat /etc/kubernetes/manifests/etcd.yaml
# 找到 --cert-file, --key-file, --trusted-ca-file 对应的路径
# 第二步：执行备份
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 第三步：验证备份
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table
备份输出示例：
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 5b123abc | 150234 | 1543 | 4.2 MB |
+----------+----------+------------+------------+
etcd 恢复
考试场景： "请从快照 /backup/etcd-snapshot.db 恢复 etcd 数据"
恢复流程的核心思路： 停 API Server → 恢复数据到新目录 → 修改 etcd 配置指向新目录 → 重启。
# 1. 停止 kube-apiserver（移动 manifest 文件使其停止）
mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/
# 2. 恢复 etcd 数据到新目录
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-restored \
--initial-cluster=master=https://192.168.1.100:2380 \
--initial-advertise-peer-urls=https://192.168.1.100:2380 \
--name=master
# 3. 更新 etcd 配置使用新数据目录
# 编辑 /etc/kubernetes/manifests/etcd.yaml
# 把 --data-dir 改为 /var/lib/etcd-restored
# 同时更新对应的 volumes 和 volumeMounts 路径
# 4. 恢复 kube-apiserver
mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/
# 5. 等待集群恢复，验证
kubectl get nodes
kubectl get pods -A
🎯 考试技巧：etcd 备份恢复速查
考试中 etcd 备份恢复的关键步骤：
1. 先找到证书路径
→ cat /etc/kubernetes/manifests/etcd.yaml
2. 备份时三个证书参数一个不能少
--cacert (CA 证书)
--cert (服务器证书)
--key (服务器密钥)
3. 恢复时必须指定新的 --data-dir
→ 不要覆盖原目录！
4. 恢复后记得修改 etcd.yaml 的 data-dir 路径
→ volumes 和 volumeMounts 都要改
5. 如果忘记设 ETCDCTL_API=3 → 命令会报错
→ 这是最常见的低级错误！
集群升级（kubeadm）
为什么不能一次性升级所有节点？
因为 Kubernetes 遵循向后兼容一个版本的规则。比如 Control Plane 是 1.28，Worker 可以是 1.27 或 1.28，但不能是 1.26。所以升级顺序是：先升 Master，再逐个升 Worker —— 确保 Control Plane 始终是最新的。
为什么升级前要 drain？
drain 是"排空节点" —— 把节点上的 Pod 先迁移到其他节点上，然后再升级这个节点。如果不 drain 就直接升级，正在运行的 Pod 会被中断，用户请求会失败。
升级流程
┌─────────────────────────────────────────────────────────────────┐
│ Kubernetes 集群升级流程 │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────┴─────────────────┐
▼ ▼
┌───────────────┐ ┌───────────────┐
│ 1️⃣ 升级 Master │ │ 2️⃣ 升级 Worker │
│ 节点（先） │ │ 节点（后） │
└───────┬───────┘ └───────┬───────┘
│ │
▼ ▼
1. 升级 kubeadm 1. 排空节点 (drain)
2. kubeadm upgrade plan 2. 升级 kubeadm
3. kubeadm upgrade apply 3. kubeadm upgrade node
4. 升级 kubelet & kubectl 4. 升级 kubelet & kubectl
5. 重启 kubelet 5. 重启 kubelet
6. 恢复节点 (uncordon)
升级 Master 节点
# 1. 排空 Master 节点
kubectl drain master --ignore-daemonsets --delete-emptydir-data
# 2. 升级 kubeadm
apt update
apt install -y kubeadm=1.28.0-00
# 3. 验证升级计划（查看可以升级到哪个版本）
kubeadm upgrade plan
# 4. 执行升级
kubeadm upgrade apply v1.28.0
# 5. 升级 kubelet 和 kubectl
apt install -y kubelet=1.28.0-00 kubectl=1.28.0-00
# 6. 重启 kubelet
systemctl daemon-reload
systemctl restart kubelet
# 7. 恢复节点
kubectl uncordon master
升级 Worker 节点
# 1. 在 Master 上排空 Worker（Worker 上的 Pod 会被迁移到其他节点）
kubectl drain worker1 --ignore-daemonsets --delete-emptydir-data
# 2. 在 Worker 上升级 kubeadm
apt update
apt install -y kubeadm=1.28.0-00
# 3. 升级节点配置（注意：Worker 用 upgrade node，不是 upgrade apply）
kubeadm upgrade node
# 4. 升级 kubelet 和 kubectl
apt install -y kubelet=1.28.0-00 kubectl=1.28.0-00
# 5. 重启 kubelet
systemctl daemon-reload
systemctl restart kubelet
# 6. 在 Master 上恢复节点（重新允许调度 Pod）
kubectl uncordon worker1
⚠️ 考试注意：Master 用
kubeadm upgrade apply，Worker 用kubeadm upgrade node—— 别搞反了！
节点管理
添加新节点
# 在 Master 上生成 join token
kubeadm token create --print-join-command
# 输出类似：
# kubeadm join 192.168.1.100:6443 --token abc123.xyz \
# --discovery-token-ca-cert-hash sha256:...
# 在新节点上执行 join 命令
kubeadm join 192.168.1.100:6443 --token abc123.xyz \
--discovery-token-ca-cert-hash sha256:...
节点维护（cordon / drain / uncordon）
这三个命令的关系需要理解清楚：
| 命令 | 作用 | 现有 Pod | 新 Pod |
|---|---|---|---|
cordon | 标记不可调度 | 继续运行 | 不会再分配到这个节点 |
drain | 排空节点 | 驱逐到其他节点 | 不会再分配 |
uncordon | 恢复可调度 | 不影响 | 可以分配到这个节点 |
# 标记节点不可调度（但不驱逐现有 Pod）
kubectl cordon node1
# 排空节点（驱逐 Pod 并标记不可调度）
kubectl drain node1 --ignore-daemonsets --delete-emptydir-data
# 恢复节点可调度
kubectl uncordon node1
# 删除节点（从集群中移除）
kubectl delete node node1
💡
--ignore-daemonsets是什么？ DaemonSet 的 Pod 在每个节点上都有一份（如日志收集器），drain 时不需要驱逐它们，用这个参数忽略。--delete-emptydir-data表示允许删除使用 emptyDir 卷的 Pod 的临时数据。
节点标签和注解
# 添加标签（用于 NodeSelector 调度）
kubectl label nodes node1 env=production
kubectl label nodes node1 disktype=ssd
# 查看标签
kubectl get nodes --show-labels
# 删除标签
kubectl label nodes node1 env-
# 添加注解（元数据信息，不影响调度）
kubectl annotate nodes node1 description="Production node"
核心概念
Pod
术语：Pod
- 一句话解释：Kubernetes 中最小的可部署单元。一个 Pod 里可以有一个或多个容器，它们共享网络和存储。
- 形象比喻：Pod 就像一个"胶囊旅馆的房间"。房间里可以住一个人（单容器），也可以住两个好朋友（多容器 —— Sidecar 模式）。他们共用一个门（网络 IP）和一个衣柜（共享存储）。
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
resources:
requests: # 最少需要多少资源
memory: "64Mi"
cpu: "250m"
limits: # 最多允许用多少资源
memory: "128Mi"
cpu: "500m"
💡 requests vs limits：
requests是 Scheduler 做调度决策时用的（"这个节点剩余资源能不能满足 Pod 的 requests？"），limits是运行时的硬限制（超过 memory limit 会被 OOM Kill）。
Namespace
术语：Namespace
- 一句话解释：逻辑隔离机制，用于在同一个集群中隔离不同的项目/团队/环境。
- 形象比喻：像一栋办公楼的不同楼层。每层（Namespace）有自己的办公室和会议室（资源），楼层之间默认可以互通（除非你加了 NetworkPolicy）。
# 查看命名空间
kubectl get namespaces
# 创建命名空间
kubectl create namespace dev
# 在特定命名空间操作
kubectl get pods -n kube-system
kubectl get all -n dev
# 设置默认命名空间（避免每次都写 -n）
kubectl config set-context --current --namespace=dev
系统默认命名空间（必须知道）：
| 命名空间 | 用途 | 包含什么 |
|---|---|---|
| default | 默认命名空间 | 不指定 namespace 时资源都在这里 |
| kube-system | 系统组件 | API Server、Scheduler、Controller Manager、kube-proxy 等 |
| kube-public | 公共资源 | 集群信息，所有人可读 |
| kube-node-lease | 节点心跳 | 每个节点的 Lease 对象，用于检测节点是否存活 |
⚠️ 常见错误与误区
错误 1：混淆组件职责
| ❌ 错误认知 | ✅ 正确理解 |
|---|---|
| kubelet 调度 Pod | kubelet 只负责运行 Pod，调度由 Scheduler 负责 |
| etcd 直接与 kubelet 通信 | 只有 API Server 与 etcd 通信 |
| kube-proxy 运行在 Master | kube-proxy 运行在每个节点上（包括 Master） |
| API Server 挂了 Pod 就停 | 已运行的 Pod 继续运行，只是无法管理 |
| Scheduler 启动 Pod | Scheduler 只"选节点"，启动 Pod 是 kubelet 的事 |
错误 2：etcd 备份参数错误
# ❌ 错误：缺少证书参数（会报认证失败）
etcdctl snapshot save backup.db
# ❌ 错误：忘了设 ETCDCTL_API=3（默认是 API v2，命令不同）
etcdctl snapshot save backup.db --endpoints=...
# ✅ 正确：完整参数
ETCDCTL_API=3 etcdctl snapshot save backup.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
错误 3：升级顺序错误
❌ 错误顺序：先升级 Worker，再升级 Master
✅ 正确顺序：先升级 Master，再逐个升级 Worker
❌ 错误：升级时不排空节点（Pod 会被中断）
✅ 正确：升级前必须 drain 节点
❌ 错误：Worker 节点用 kubeadm upgrade apply
✅ 正确：Worker 用 kubeadm upgrade node，apply 只在 Master 上用
错误 4：kubelet 排错方向错误
# ❌ 错误：kubelet 是 Pod，用 kubectl 查
kubectl get pods kubelet -n kube-system # kubelet 不是 Pod！
# ✅ 正确：kubelet 是 systemd 服务
systemctl status kubelet
journalctl -u kubelet -f
📝 考试场景题
场景 1：API Server 无法启动
问题：kubectl 命令无响应，API Server 没有运行。
排查思路：API Server 是静态 Pod，由 kubelet 根据 manifest 文件启动。如果 manifest 有语法错误，kubelet 就无法启动它。
# 1. 检查静态 Pod 配置（最常见的原因：配置文件有错）
cat /etc/kubernetes/manifests/kube-apiserver.yaml
# 2. 检查 kubelet 日志（看 kubelet 为什么启动不了 API Server）
journalctl -u kubelet | grep apiserver
# 3. 常见原因：
# - 证书路径写错了
# - 端口被占用（其他进程占了 6443）
# - etcd 连接失败（etcd 也挂了）
# - YAML 配置文件语法错误（多了空格或少了缩进）
场景 2：节点状态 NotReady
问题：kubectl get nodes 显示某节点 NotReady 状态。
排查思路：NotReady 说明 kubelet 没有向 API Server 正常汇报心跳。可能是 kubelet 挂了、网络不通、或者 Container Runtime 有问题。
# 1. SSH 到问题节点
# 2. 检查 kubelet 状态（最常见原因：kubelet 没运行）
systemctl status kubelet
# 3. 如果 kubelet 没运行 → 启动它
systemctl start kubelet
# 4. 如果 kubelet 在运行但节点仍 NotReady → 看日志
journalctl -u kubelet -f
# 5. 检查 Container Runtime
systemctl status containerd
# 6. 检查网络插件是否正常
kubectl get pods -n kube-system | grep -E "calico|flannel|weave"
练习题
题目 1
哪个组件负责将 Pod 调度到节点上？
- A. kube-apiserver
- B. kube-scheduler
- C. kubelet
- D. etcd
答案：B
解析：kube-scheduler 负责监视新创建的 Pod，并为其选择合适的节点。kubelet 负责在节点上运行 Pod，但不负责调度决策。记住：Scheduler = "选位置"，kubelet = "在位置上干活"。
</details>题目 2
以下哪个组件直接与 etcd 通信？
- A. kubelet
- B. kube-proxy
- C. kube-apiserver
- D. kube-scheduler
答案：C
解析：只有 kube-apiserver 直接与 etcd 通信。所有其他组件都通过 API Server 间接访问集群状态。这是 Kubernetes 架构的一个核心设计原则 —— API Server 是集群的"唯一入口"。
</details>题目 3
执行 etcd 备份需要哪些证书参数？（选择所有正确的）
- A. --cacert
- B. --cert
- C. --key
- D. --token
答案：A, B, C
解析：etcd 备份需要三个证书参数：
--cacert：CA 证书（验证 etcd 服务器身份）--cert：客户端证书（证明你的身份）--key：客户端私钥（配合证书使用）
不需要 token 参数。记忆口诀："CA + 证书 + 密钥，三件套"。
</details>题目 4
升级 Kubernetes 集群时，正确的升级顺序是？
- A. 先 Worker 节点，后 Master 节点
- B. 先 Master 节点，后 Worker 节点
- C. 同时升级所有节点
- D. 只需升级 Master 节点
答案：B
解析：正确的升级顺序是先升级 Master（Control Plane）节点，再逐个升级 Worker 节点。这确保了集群控制平面始终是最新版本，能够管理可能运行旧版本的 Worker 节点。Kubernetes 支持 Control Plane 比 Worker 高一个小版本。
</details>题目 5（实操题）
创建 etcd 快照并保存到 /backup/etcd-snapshot.db。etcd 运行在 https://127.0.0.1:2379，证书位于 /etc/kubernetes/pki/etcd/ 目录。
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
验证：
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table
注意：如果考试没告诉你证书路径，先执行 cat /etc/kubernetes/manifests/etcd.yaml 查找。
🎯 考试技巧总结
考试开始时先执行
# 设置别名（节省打字时间）
alias k=kubectl
export do="--dry-run=client -o yaml"
# 快速查看集群状态
k get nodes # 节点状态
k get pods -n kube-system # 系统 Pod
k get cs # 组件状态（部分版本已弃用）
本章高频考点速查
| 考点 | 核心命令/配置 | 注意事项 |
|---|---|---|
| etcd 备份 | etcdctl snapshot save + 三证书 | 别忘了 ETCDCTL_API=3 |
| etcd 恢复 | etcdctl snapshot restore --data-dir | 恢复到新目录，修改 etcd.yaml |
| 集群升级 | drain → upgrade → uncordon | Master 用 apply，Worker 用 node |
| 节点管理 | cordon/drain/uncordon | drain 加 --ignore-daemonsets |
| 静态 Pod | /etc/kubernetes/manifests/ | API Server/etcd/Scheduler 都是静态 Pod |
| kubelet 排错 | systemctl status/restart kubelet | kubelet 不是 Pod，是 systemd 服务 |
时间分配建议
- etcd 备份恢复：8-10 分钟
- 集群升级：10-15 分钟
- 节点问题排查：5-8 分钟
本章小结
| 组件 | 位置 | 核心职责 | 比喻 |
|---|---|---|---|
| kube-apiserver | Master | API 网关，认证授权，唯一访问 etcd | 前台接待 + 安保 |
| etcd | Master | 所有状态数据存储 | 核心档案室 |
| kube-scheduler | Master | 决定 Pod 去哪个节点 | 排课系统 |
| kube-controller-manager | Master | 持续巡检，保证现实=期望 | 自动巡检员 |
| kubelet | Worker | 运行 Pod，汇报状态 | 分公司经理 |
| kube-proxy | Worker | 网络规则，Service 转发 | 快递分拣员 |
| Container Runtime | Worker | 实际运行容器 | 搬砖工人 |
核心记忆：
- 所有通信经过 API Server（星型拓扑）
- 只有 API Server 直接访问 etcd
- kubelet 是 systemd 服务，不是 Pod
- 升级顺序：先 Master 后 Worker
- etcd 备份 = 三证书参数 +
ETCDCTL_API=3