kubernetes（K8s）学习笔记：第三期与第四期核心知识点学习自测与详解
本自测解析针对 Kubernetes 系列第三期（集群基础管理）和第四期（Pod 管理）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固集群运维与 Pod 管理技能。
第三期：集群基础管理（5 题）
题目一：节点维护流程（cordon / drain / uncordon）
题目 ：请完整描述 Kubernetes 节点维护的标准流程。需要执行哪些命令？各命令的作用是什么？如果 kubectl drain 命令卡住，可能的原因有哪些？
考查知识点
- 节点管理 ------ 第三期 §1.2
- cordon / drain / uncordon 命令详解
详细解答
标准维护流程（三步走）：
| 步骤 | 命令 | 作用 |
|---|---|---|
| 1. cordon | kubectl cordon <node> |
标记节点为不可调度，阻止新 Pod 调度到该节点 |
| 2. drain | kubectl drain <node> --ignore-daemonsets |
驱逐节点上所有 Pod（DaemonSet 除外），将其迁移到其他节点 |
| 3. 维护操作 | 在节点上执行实际维护（升级内核、更换硬件等） | --- |
| 4. uncordon | kubectl uncordon <node> |
恢复节点调度能力 |
drain 命令常用参数：
| 参数 | 作用 |
|---|---|
--ignore-daemonsets |
忽略 DaemonSet 管理的 Pod（必须加） |
--force |
强制驱逐无法正常终止的 Pod |
--delete-emptydir-data |
删除使用 emptyDir 的 Pod |
--grace-period=30 |
优雅终止宽限期（秒） |
drain 卡住的可能原因：
- PodDisruptionBudget（PDB）限制：Pod 设置了 PDB，阻止驱逐以保证最低可用副本数。
- 裸 Pod ：非控制器管理的 Pod（直接用
kubectl run创建的）无法被重新调度，需加--force或手动处理。 - PVC 限制：使用本地存储的 Pod 可能无法迁移。
- DaemonSet Pod 未忽略 ：未加
--ignore-daemonsets参数。 - 节点上 Pod 无法正常终止 ：容器进程卡死，超过
terminationGracePeriodSeconds。
完整命令示例：
bash
# 1. 标记节点不可调度
kubectl cordon worker31.whisky.cloud
# 2. 驱逐 Pod（忽略 DaemonSet）
kubectl drain worker31.whisky.cloud --ignore-daemonsets
# 3. 在节点上执行维护操作（如升级内核）
# ...
# 4. 恢复调度
kubectl uncordon worker31.whisky.cloud题目二：节点状态与 Conditions 解读
题目 ：kubectl get nodes 显示节点状态为 NotReady。请说明排查思路，包括需要查看哪些信息、各 Condition 的含义，以及常见原因。
考查知识点
- 节点状态与 Conditions ------ 第三期 §1.1
- 集群排错基础 ------ 第三期 §6
详细解答
排查步骤：
bash
# 1. 查看节点详细状态（Conditions 和 Events）
kubectl describe node worker31.whisky.cloud
# 2. 查看 kubelet 日志
journalctl -u kubelet -n 50
# 3. 检查 kubelet 服务状态
systemctl status kubelet各 Condition 含义：
| Condition | True 表示 | 影响 |
|---|---|---|
MemoryPressure |
内存压力大 | 节点可能驱逐 Pod |
DiskPressure |
磁盘空间不足 | 节点可能驱逐 Pod |
PIDPressure |
进程数过多 | 节点无法创建新进程 |
Ready |
节点就绪 | 正常接收 Pod |
NotReady 常见原因：
| 原因 | 排查方法 |
|---|---|
| kubelet 服务未运行或崩溃 | systemctl status kubelet |
| swap 未关闭 | free -h，swapoff -a |
| 容器运行时故障（containerd） | systemctl status containerd |
| 网络插件未部署或故障 | `kubectl get pods -n kube-system |
| 内核参数未配置 | sysctl net.bridge.bridge-nf-call-iptables |
| 磁盘空间满 | df -h |
| 证书过期 | kubeadm certs check-expiration |
排故原则 ：
kubectl describe node是首选排查命令，Events 部分通常能直接定位问题。
题目三：Namespace 资源隔离（ResourceQuota 与 LimitRange）
题目：请解释 Kubernetes 中 Namespace 的作用，并说明 ResourceQuota 和 LimitRange 的区别与使用场景。请分别给出 YAML 示例。
考查知识点
- Namespace 管理 ------ 第三期 §3
- ResourceQuota 与 LimitRange ------ 第三期 §3.4、§3.5
详细解答
Namespace 的作用：
- 将物理集群逻辑划分为多个虚拟集群
- 实现资源隔离和权限隔离
- 便于团队/项目/环境的资源管理
ResourceQuota vs LimitRange：
| 对比项 | ResourceQuota | LimitRange |
|---|---|---|
| 作用范围 | 整个 Namespace | 单个 Pod/容器 |
| 控制内容 | 总资源用量上限 | 单 Pod/容器资源默认值和范围 |
| 典型配置 | CPU/内存总量、PVC 数量、Pod 数量 | 单 Pod 最小/最大/默认 CPU/内存 |
| 使用场景 | 防止 Namespace 资源超限 | 防止单 Pod 资源无限使用 |
ResourceQuota YAML 示例：
yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
namespace: whisky
spec:
hard:
requests.cpu: "2"
requests.memory: "2Gi"
limits.cpu: "4"
limits.memory: "4Gi"
persistentvolumeclaims: "5"
pods: "10"LimitRange YAML 示例：
yaml
apiVersion: v1
kind: LimitRange
metadata:
name: limits
namespace: whisky
spec:
limits:
- max:
cpu: "1"
memory: "1Gi"
min:
cpu: "100m"
memory: "128Mi"
default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "200m"
memory: "256Mi"
type: Container补充：创建 ResourceQuota 后，Namespace 中的所有 Pod 都必须指定资源请求（requests）和限制（limits），否则创建 Pod 会失败。
题目四：多集群上下文切换
题目 ：用户需要管理两个 Kubernetes 集群（cluster1 和 cluster2）。请说明如何配置和切换集群上下文？kubectx 工具如何简化这一过程？
考查知识点
- 集群上下文切换 ------ 第三期 §5
- kubectx 工具 ------ 第三期 §5.5
详细解答
配置多集群 ：将两个集群的配置合并到 ~/.kube/config 文件，或通过多 KUBECONFIG 环境变量管理。
多集群配置示例：
yaml
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.1.8.30:6443
name: cluster1
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.1.8.150:6443
name: cluster2
contexts:
- context:
cluster: cluster1
namespace: default
user: cluster1-admin
name: cluster1-context
- context:
cluster: cluster2
namespace: default
user: cluster2-admin
name: cluster2-context
current-context: cluster1-context
kind: Config
users:
- name: cluster1-admin
user:
client-certificate-data: DATA+OMITTED
- name: cluster2-admin
user:
client-certificate-data: DATA+OMITTEDkubectl config 切换：
bash
# 查看集群列表
kubectl config get-clusters
# 查看上下文列表
kubectl config get-contexts
# 切换上下文
kubectl config use-context cluster2-contextkubectx 工具简化：
bash
# 列出所有上下文
kubectx
# 查看当前上下文
kubectx -c
# 切换上下文
kubectx cluster2-context
# 切换到上一个上下文
kubectx -补充 ：多 KUBECONFIG 环境变量方式：
export KUBECONFIG=/root/.kube/config:/root/cluster2.conf，然后用kubectl config view --flatten合并。
题目五：集群重建与证书更新
题目：Kubernetes 集群证书过期了怎么办？请说明如何检查证书过期时间以及如何更新证书。如果证书无法更新，如何重建集群？
考查知识点
- 集群删除与重建 ------ 第三期 §2
- 证书过期处理 ------ 第三期 §2.3
详细解答
检查证书过期时间：
bash
kubeadm certs check-expiration输出示例：
text
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf Jun 18, 2025 10:00 UTC 364d no
apiserver Jun 18, 2025 10:00 UTC 364d no
...更新证书：
bash
# 1. 更新所有证书
kubeadm certs renew all
# 2. 重启 kubelet
systemctl restart kubelet
# 3. 更新 kubeconfig（如果 admin.conf 过期）
kubectl config view --raw > /root/.kube/config证书无法更新时重建集群：
bash
# 1. 备份集群配置
kubectl get cm kubeadm-config -n kube-system -o yaml > kubeadm.yml
# 2. 删除所有 Worker 节点
kubectl drain worker31.whisky.cloud --ignore-daemonsets --force
kubectl drain worker32.whisky.cloud --ignore-daemonsets --force
kubectl delete node worker31.whisky.cloud worker32.whisky.cloud
kubeadm reset -f # 在 worker 节点执行
# 3. 删除 Master 节点
kubectl delete node master30.whisky.cloud
kubeadm reset -f
rm -fr .kube/
# 4. 使用备份配置重建集群
kubeadm init --config kubeadm.yml
mkdir -p $HOME/.kube
cp /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
# 5. 重新部署网络插件
kubectl apply -f calico.yaml
# 6. Worker 重新加入
kubeadm join ...补充：证书默认有效期 1 年，建议在生产环境中设置证书自动续期或定期检查。
第四期：Pod 管理（5 题）
题目六：Pod 与容器的关系及 Pod 状态
题目：Kubernetes 中 Pod 和容器的关系是什么？为什么 K8s 管理 Pod 而不是直接管理容器？请列举 Pod 的常见状态及含义。
考查知识点
- Pod 介绍 ------ 第四期 §1
- Pod 与容器辨析 ------ 第四期 §9
- Pod 生命周期与状态 ------ 第四期 §5
详细解答
Pod 与容器的关系：
| 维度 | 容器 | Pod |
|---|---|---|
| 本质 | 运行进程（运行时概念） | 容器的外壳 + 运行环境（K8s 概念） |
| K8s 调度单位 | ❌ 不是 | ✅ 是 |
| 多容器支持 | ❌ 不支持 | ✅ 天然支持 |
| 网络/存储共享 | ❌ 不能 | ✅ 内部容器可共享 |
为什么 K8s 管理 Pod 而不是容器：
- 容器太"原子"：K8s 需要一个能直接调度、有完整身份的对象------Pod。
- 支持多容器协同：业务容器 + Sidecar 容器（日志、监控、代理）需要共享网络和存储。
- 统一生命周期管理：以 Pod 为单位管理重启、自愈、滚动更新，语义清晰。
- 解耦底层容器运行时：Pod 屏蔽了 Docker、containerd、cri-o 等差异。
Pod 常见状态：
| 状态 | 含义 |
|---|---|
Pending |
Pod 已创建但尚未调度到节点 |
ContainerCreating |
正在拉取镜像、创建容器 |
Running |
Pod 正常运行 |
Completed |
容器进程正常退出（exit 0） |
Error |
容器进程错误退出（exit ≠ 0） |
CrashLoopBackOff |
反复崩溃，正在退避等待重启 |
ImagePullBackOff |
镜像拉取失败 |
Terminating |
正在被删除，优雅终止中 |
题目七：多容器 Pod 的使用场景与操作
题目：请说明多容器 Pod 的典型使用场景。Pod 中多个容器如何共享资源？请写出在多容器 Pod 中执行命令、复制文件到指定容器的命令格式。
考查知识点
- 多容器 Pod ------ 第四期 §3
- Pod 中执行命令和复制文件 ------ 第四期 §2.3、§2.4
详细解答
多容器 Pod 典型场景：
| 场景 | 说明 | 示例 |
|---|---|---|
| Sidecar 模式 | 辅助容器提供日志收集、监控、代理等功能 | Nginx + Filebeat |
| 数据同步 | 一个容器写数据，另一个容器读取或备份 | 主容器写日志，备份容器同步 |
| 初始化 | 使用 Init Container 完成初始化（特殊） | 数据库迁移、权限设置 |
| 代理/网关 | 代理容器处理网络通信 | Nginx + Envoy |
Pod 中多容器共享资源：
| 共享资源 | 说明 |
|---|---|
| 网络命名空间 | 所有容器共享同一个 IP 地址和端口空间，可通过 localhost 通信 |
| 存储卷 | 所有容器可挂载相同的 Volume，实现数据共享 |
| IPC 命名空间 | 容器之间可通过进程间通信交互 |
| 生命周期 | 同生共死，一起调度、一起销毁 |
多容器 Pod 操作命令：
bash
# 多容器 Pod 中执行命令（-c 指定容器）
kubectl exec bbs -c wordpress -- hostname
# 复制文件到指定容器
kubectl cp /etc/hosts bbs:/new-hosts -c wordpress
# 查看多容器 Pod 日志（默认显示第一个容器）
kubectl logs bbs
# 查看指定容器日志
kubectl logs bbs -c wordpress题目八：Init Container 的作用与场景
题目：什么是 Init Container？它与普通容器有何区别？请写出一个使用 Init Container 等待 Service 就绪的 YAML 示例。
考查知识点
- Init Container ------ 第四期 §7
- Init Container 使用场景
详细解答
Init Container 定义 ：在 Pod 中普通容器启动之前运行的特殊容器，用于执行初始化任务。
Init Container vs 普通容器：
| 对比项 | Init Container | 普通容器 |
|---|---|---|
| 执行顺序 | 按顺序依次执行 | 并行启动 |
| 前置条件 | 前一个 Init 成功才能执行下一个 | 无前置条件 |
| 成功要求 | 必须成功完成（exit 0） | 保持运行 |
| 重启策略 | 失败时根据 restartPolicy 重启 | 独立重启 |
| 就绪探针 | 不支持 | 支持 |
| 资源限制 | 独立设置 | 独立设置 |
使用场景：
- 等待依赖服务就绪（数据库、DNS 等）
- 等待固定时间后再启动业务容器
- 初始化 Volume 数据（克隆 Git 仓库、创建目录、设置权限）
- 执行数据库迁移
等待 Service 就绪的 Init Container 示例：
yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done; sleep 3;']
- name: init-mydb
image: busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done; sleep 3;']
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo The app is running! && sleep 3600']观察 Pod 状态变化 ：
Init:0/2 → Init:1/2 → PodInitializing → Running
题目九：restartPolicy 三种策略
题目 ：Kubernetes Pod 的 restartPolicy 有哪三种取值？请分别说明其行为，并给出适用场景。在多容器 Pod 中，重启策略如何生效？
考查知识点
- restartPolicy ------ 第四期 §6
- 多容器场景下的重启策略
详细解答
三种重启策略：
| 策略 | 行为 | 适用场景 |
|---|---|---|
Always |
无论容器成功还是失败，都重启 | 默认值，Web 服务等长期运行的应用 |
OnFailure |
只在容器失败（exit ≠ 0）时重启 | 批处理任务、Job |
Never |
从不重启 | 一次性任务、调试、数据迁移 |
多容器 Pod 中的重启策略：
restartPolicy针对 Pod 中所有容器，而不是单个容器- 只要有一个容器需要重启，整个 Pod 就会根据策略重新创建
验证实验：
yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
restartPolicy: Always
containers:
- name: busybox1
image: busybox
command: ['sh', '-c', 'echo Hello && sleep 5']
- name: busybox2
image: busybox
command: ['sh', '-c', 'echo Hello && sleep 5']Always：任一容器完成，Pod 就重启OnFailure：正常完成不重启，错误才重启Never：任何情况都不重启
题目十：静态 Pod 与 pause 容器
题目：什么是静态 Pod？Master 节点上的系统组件（kube-apiserver 等）是如何以静态 Pod 方式运行的？请解释 pause 容器的 3 个核心作用。
考查知识点
- 静态 Pod ------ 第四期 §8
- pause 容器 ------ 第四期 §9.3
详细解答
静态 Pod 定义：
- 由 kubelet 直接管理的 Pod，不通过 API Server
- kubelet 定期扫描
staticPodPath目录中的 YAML 文件，根据文件变动创建或删除 Pod
Master 组件静态 Pod：
bash
# 查看静态 Pod 目录
grep staticPodPath /var/lib/kubelet/config.yaml
staticPodPath: /etc/kubernetes/manifests
# 查看静态 Pod 文件
ls -1 /etc/kubernetes/manifests
etcd.yaml
kube-apiserver.yaml
kube-controller-manager.yaml
kube-scheduler.yaml静态 Pod vs 普通 Pod：
| 特性 | 静态 Pod | 普通 Pod |
|---|---|---|
| 管理者 | kubelet | API Server / 控制器 |
| 可通过 API 删除 | ❌ 会立即重建 | ✅ 直接删除 |
| 可用于系统组件 | ✅ 是 | ❌ 不适合 |
pause 容器的 3 个核心作用：
- 创建并持有 Pod 的 Linux Namespace
- Pod 中所有容器共享 Network、PID、IPC 命名空间
- 必须有一个容器来"持有"这些空间，pause 容器承担此角色
- 让 Pod 生命周期独立于业务容器
- 业务容器可以重启，pause 容器不重启
- Pod 的网络、IP、存储挂载始终保持不变
- 实现多容器共享网络
- 所有容器加入 pause 的 Network Namespace
- 共享同一个 IP，可以用
127.0.0.1互相访问 - 端口不能冲突
超形象比喻：
| 概念 | 比喻 |
|---|---|
| pause 容器 | 房东（先占好房子） |
| Pod | 房子（提供居住环境） |
| 业务容器 | 租客（住进房子干活） |
房东（pause）先占好房子（网络/命名空间），租客（业务容器）才能住进来。租客换了一波又一波，房子一直都在。
附：知识点对应总表
| 题号 | 主要考查知识点（对应笔记章节） |
|---|---|
| 1 | 第三期 §1.2 节点维护流程（cordon/drain/uncordon） |
| 2 | 第三期 §1.1 节点状态与 Conditions；§6 集群排错基础 |
| 3 | 第三期 §3.4-3.5 ResourceQuota 与 LimitRange |
| 4 | 第三期 §5 集群上下文切换；§5.5 kubectx 工具 |
| 5 | 第三期 §2 集群删除与重建；§2.3 证书过期处理 |
| 6 | 第四期 §1 Pod 介绍；§5 Pod 生命周期与状态；§9 Pod 与容器辨析 |
| 7 | 第四期 §3 多容器 Pod；§2.3-2.4 exec/cp 操作 |
| 8 | 第四期 §7 Init Container 概念与场景 |
| 9 | 第四期 §6 restartPolicy 三种策略 |
| 10 | 第四期 §8 静态 Pod；§9.3 pause 容器作用 |
学习建议：对于答错的题目，请回看第三期或第四期对应章节，并动手在集群环境中验证。集群运维和 Pod 管理是 Kubernetes 日常操作的基础，建议通过实际操作加深理解。
--- Compiled and Authored by Whisky --- June 25th, 2026