kubernetes（K8s）学习笔记：第三期与第四期核心知识点学习自测与详解

AOwhisky2026-06-26 16:42

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 卡住的可能原因：

  1. PodDisruptionBudget（PDB）限制：Pod 设置了 PDB，阻止驱逐以保证最低可用副本数。
  2. 裸 Pod ：非控制器管理的 Pod（直接用 kubectl run 创建的）无法被重新调度，需加 --force 或手动处理。
  3. PVC 限制：使用本地存储的 Pod 可能无法迁移。
  4. DaemonSet Pod 未忽略 ：未加 --ignore-daemonsets 参数。
  5. 节点上 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+OMITTED

kubectl config 切换：

bash

复制代码 
# 查看集群列表
kubectl config get-clusters

# 查看上下文列表
kubectl config get-contexts

# 切换上下文
kubectl config use-context cluster2-context

kubectx 工具简化：

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 而不是容器：

  1. 容器太"原子"：K8s 需要一个能直接调度、有完整身份的对象------Pod。
  2. 支持多容器协同：业务容器 + Sidecar 容器（日志、监控、代理）需要共享网络和存储。
  3. 统一生命周期管理：以 Pod 为单位管理重启、自愈、滚动更新，语义清晰。
  4. 解耦底层容器运行时：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 重启 独立重启
就绪探针 不支持 支持
资源限制 独立设置 独立设置

使用场景：

  1. 等待依赖服务就绪（数据库、DNS 等）
  2. 等待固定时间后再启动业务容器
  3. 初始化 Volume 数据（克隆 Git 仓库、创建目录、设置权限）
  4. 执行数据库迁移

等待 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 个核心作用：

  1. 创建并持有 Pod 的 Linux Namespace
    • Pod 中所有容器共享 Network、PID、IPC 命名空间
    • 必须有一个容器来"持有"这些空间，pause 容器承担此角色
  2. 让 Pod 生命周期独立于业务容器
    • 业务容器可以重启，pause 容器不重启
    • Pod 的网络、IP、存储挂载始终保持不变
  3. 实现多容器共享网络
    • 所有容器加入 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

热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04【AI】2026 年具身智能模型和世界模型总结05飞书长连接_事件订阅（接收消息，审批任务状态变更）06Trae国际版与国内版深度测评：AI原生IDE的双生花07Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析08GitHub 镜像站点09【AI总结】2026年6月 主流国内外大模型总结102026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）