vault backup: 2026-07-05 09:53:43

technical/xinfra-preview/k8s-rke2-fundamentals.md

@@ -26,7 +26,7 @@ graph TD
 ```
 
 | 对象                     | 职责                              | 类比       |
-|------|------|------|
+| ---------------------- | ------------------------------- | -------- |
 | **Node**               | 运行 Pod 的物理机或虚拟机                 | 服务器      |
 | **Pod**                | 一个或多个容器的打包体                     | 应用实例     |
 | **Deployment**         | 管理 Pod 的副本数、滚动更新策略              | 发布控制器    |
@@ -294,6 +294,8 @@ kubectl patch deployment/<name> -p '{"spec":{"template":{"spec":{"containers":[{
 
 > [!tip] `-A` 标志 = `--all-namespaces`，当你不确定资源在哪个 namespace 时非常有用。但正式脚本中不建议滥用，容易造成误操作。
 
+详见 [[k8s-rke2-fundamentals/core-objects-quiz]] — 覆盖 Pod 生命周期、Service 类型、探针机制等核心考点的 10 道选择题自测。
+
 ---
 
 ## 常见陷阱与最佳实践

technical/xinfra-preview/k8s-rke2-fundamentals/core-objects-quiz.md

@@ -0,0 +1,197 @@
+---
+tags: [k8s, quiz]
+create time: 2026-07-05 13:00
+---
+
+# K8s 核心对象关系 — 自测题库
+
+## Q1：K8s 中最小的部署单元是什么？
+
+- A. Container（容器）
+- B. Pod
+- C. Node（节点）
+- D. Deployment（部署）
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> Pod 是 K8s 最小的部署单元。一个 Pod 可以包含一个或多个容器，这些容器共享网络和存储，通常被当作一个整体来调度和管理。
+>
+> > [!tip] 类比
+> > Node ≈ 服务器，Pod ≈ 应用实例，Deployment ≈ 发布控制器。
+
+---
+
+## Q2：Node、Pod、Container 之间的关系是什么？
+
+- A. 一个 Container 运行在一个 Node 上，Pod 只是一个概念标签
+- B. 一个 Node 上可以运行多个 Pod，一个 Pod 内可以包含多个 Container
+- C. 一个 Pod 可以跨多个 Node 运行
+- D. Node 和 Pod 是一一对应的关系，一台 Node 只能跑一个 Pod
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> 一台物理机或虚拟机（Node）上通过资源隔离运行多个 Pod；一个 Pod 内的多个 Container 共享网络命名空间和存储卷，适合"主业务 + Sidecar"模式（比如 app + 日志采集代理放在同一个 Pod）。
+>
+> > [!quote] 一句话记忆
+> > Node 承载 Pod，Pod 封装 Container。
+
+---
+
+## Q3：Deployment 的主要作用是什么？
+
+- A. 直接创建和运行动态容器
+- B. 为一组 Pod 提供稳定的外部访问地址
+- C. 管理 Pod 的副本数以及更新策略（如滚动更新）
+- D. 为集群中的节点分配 CPU 和内存资源
+
+> [!example]- 答案与解析
+> **答案：C**
+>
+> Deployment 声明"想要几个副本、用什么镜像版本"，负责管理 Pod 的生命周期。最实用的功能是**滚动更新**——逐步用新版本的 Pod 替换旧版本，期间服务不会中断。
+
+---
+
+## Q4：Pod 重启后 IP 会变吗？为什么需要 Service？
+
+- A. Pod IP 不变，Service 的作用是做数据加密
+- B. Pod IP 会变，Service 为一组 Pod 提供稳定的访问入口和负载均衡
+- C. Pod IP 不变，但只能通过 Service 访问 Pod
+- D. Pod 没有 IP 地址，只能靠 Service 通信
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> Pod 是不固定的——它可能因为调度、扩缩容、故障重启而换到另一台 Node 上，IP 也会跟着变。**Service 就是用来屏蔽这种不稳定性**，给你一个稳定的 IP（ClusterIP），由 K8s 自动把流量转发给当前健康的 Pod。
+>
+> > [!tip] 核心逻辑
+> > Pod IP = 会变的临时地址 → Service = 不变的稳定门面。
+
+---
+
+## Q5：以下哪种 Service Type 只允许集群内部访问，不对外暴露？
+
+- A. NodePort
+- B. LoadBalancer
+- C. ClusterIP
+- D. Ingress
+
+> [!example]- 答案与解析
+> **答案：C**
+>
+> | 类型 | 可达范围 | 典型场景 |
+> |------|---------|---------|
+> | **ClusterIP** | 仅集群内部 | 服务间调用，默认值 |
+> | **NodePort** | 外部可以通过 `节点IP:端口` 访问 | 开发测试 |
+> | **LoadBalancer** | 云厂商自动分配公网 IP | 云上生产 |
+>
+> Service 选哪个类型取决于"谁能访问它"，ClusterIP 是最安全的选择——仅限内网使用。
+
+---
+
+## Q6：Namespace 的作用是什么？
+
+- A. 为 Pod 分配独立的物理资源
+- B. 将集群资源在逻辑上划分为多个独立区域
+- C. 限制每个 Namespace 只能运行一个 Pod
+- D. 自动为 Pod 绑定公网 IP
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> Namespace 是一种**逻辑隔离**机制，让不同的团队或项目在同一套集群中互不干扰。同一 Namespace 内资源名不能重复，不同 Namespace 可以有同名资源。
+>
+> > [!tip] 类比
+> > 如果把集群比作一栋大楼，Namespace 就是不同的楼层/租户，各自有自己的文件夹。
+
+---
+
+## Q7：PVC 和 PV 的关系，最准确的描述是？
+
+- A. PVC 是给 Pod 看的，PV 是给运维看的
+- B. PVC 是用户的"存储申请单"，PV 是实际的存储空间，二者匹配后 Pod 就能使用
+- C. PV 先于 PVC 存在，且一个 PV 只能绑定一个 Pod
+- D. PVC 和 PV 之间没有任何关系，各自独立工作
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> - **PV** 是集群里一块真实的存储资源（类似硬盘）
+> - **PVC** 是用户向系统提出的存储需求（类似购物小票），声明需要多大空间、什么速度等级
+> - 当 PVC 和合适的 PV 匹配成功后，Pod 就可以像挂载磁盘一样使用它了
+>
+> > [!tip] 类比帮助理解
+> > PV = 仓库里的货，PVC = 你的订单，订单和货物对上号后你才能提货使用。
+
+---
+
+## Q8：ConfigMap 和 Secret 的共同作用是？
+
+- A. 管理 Pod 的网络配置
+- B. 管理 Pod 的副本数量
+- C. 将外部配置（非敏感/敏感数据）注入到 Pod 中
+- D. 监控 Pod 的运行状态
+
+> [!example]- 答案与解析
+> **答案：C**
+>
+> ConfigMap 和 Secret 都用于把外部信息传入容器，区别在于：
+> - **ConfigMap** —— 放普通配置（如环境变量、配置文件内容）
+> - **Secret** —— 放敏感数据（如数据库密码、API Token）
+>
+> 它们支持三种注入方式：环境变量、Volume 挂载文件、命令行参数。这样修改配置就不需要重新构建 Docker 镜像了。
+>
+> > [!note] 设计意图
+> > "配置与镜像分离"是云原生应用的核心原则之一。
+
+---
+
+## Q9：Ingress 相比 Service 多了什么能力？
+
+- A. Ingress 可以直接创建和销毁 Pod
+- B. Ingress 支持基于域名和路径的七层路由（如 api.example.com → 后端-A）
+- C. Ingress 可以为 Pod 分配更强大的 CPU 和内存
+- D. Ingress 不需要 Service 就可以把流量发给 Pod
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> Service 只能做四层转发（按端口），Ingress 在此基础上支持**七层路由**——可以根据域名（host）、URL 路径（path）将流量精确分发到不同的 Service：
+> ```
+> api.myapp.com   → API Service  (后端处理接口请求)
+> web.myapp.com   → Web Service  (前端页面)
+> api.myapp.com/v2 → V2 Service  (新版本接口)
+> ```
+>
+> > [!quote] 一句话总结
+> > Service 管"怎么找到一组 Pod"，Ingress 管"不同域名该去哪个 Service"。
+
+---
+
+## Q10：如果把整个 K8s 核心对象串起来，正确的依赖链路是？
+
+- A. Node → Deployment → Service → Container
+- B. Node → Pod → Container，Deployment 管理 Pod 副本，Service 为 Pod 提供稳定入口
+- C. Namespace → Container → Node → Deployment
+- D. PVC → Node → Deployment → Service
+
+> [!example]- 答案与解析
+> **答案：B**
+>
+> 完整链路回顾：
+> 1. **Node** 是底层的物理/虚拟机器
+> 2. **Pod** 运行在 Node 上，内部封装 **Container**（真正的代码执行者）
+> 3. **Deployment** 管理一堆 Pod，确保数量和应对更新
+> 4. **Service** 给这些 Pod 提供一个不变的访问入口
+> 5. （可选）**Ingress** 根据域名把流量分给不同的 Service
+>
+> > [!abstract] 核心记忆图
+> > Deployment 创建 Pod → Pod 跑在 Node 上 → Service 暴露 Pod → Ingress 引导流量到 Service
+>
+> > [!tip] 考试总结
+> > 记住这四个关系就够：
+> > - Deployment **管** Pod
+> > - Pod **装** Container
+> > - Service **指** Pod
+> > - Ingress **导** 流量到 Service