From b9572cee3e7e15220f6ea5622002699d3c4c0098 Mon Sep 17 00:00:00 2001 From: wonder Date: Sun, 5 Jul 2026 09:53:43 +0800 Subject: [PATCH] vault backup: 2026-07-05 09:53:43 --- .../xinfra-preview/k8s-rke2-fundamentals.md | 20 +- .../core-objects-quiz.md | 197 ++++++++++++++++++ 2 files changed, 208 insertions(+), 9 deletions(-) create mode 100644 technical/xinfra-preview/k8s-rke2-fundamentals/core-objects-quiz.md diff --git a/technical/xinfra-preview/k8s-rke2-fundamentals.md b/technical/xinfra-preview/k8s-rke2-fundamentals.md index d623e0e..aa1770b 100644 --- a/technical/xinfra-preview/k8s-rke2-fundamentals.md +++ b/technical/xinfra-preview/k8s-rke2-fundamentals.md @@ -25,15 +25,15 @@ graph TD PvcRef[PVC ref by Pod] --> Pod ``` -| 对象 | 职责 | 类比 | -|------|------|------| -| **Node** | 运行 Pod 的物理机或虚拟机 | 服务器 | -| **Pod** | 一个或多个容器的打包体 | 应用实例 | -| **Deployment** | 管理 Pod 的副本数、滚动更新策略 | 发布控制器 | -| **Service** | 为一组 Pod 提供稳定的访问入口（负载均衡） | 反向代理 | -| **Namespace** | 逻辑隔离的资源分组 | 多租户文件夹 | -| **ConfigMap / Secret** | 将配置注入 Pod（非敏感/敏感数据分离） | .env 文件 | -| **Ingress** | 七层路由，HTTP/HTTPS 域名到 Service 的映射 | Nginx 规则 | +| 对象 | 职责 | 类比 | +| ---------------------- | ------------------------------- | -------- | +| **Node** | 运行 Pod 的物理机或虚拟机 | 服务器 | +| **Pod** | 一个或多个容器的打包体 | 应用实例 | +| **Deployment** | 管理 Pod 的副本数、滚动更新策略 | 发布控制器 | +| **Service** | 为一组 Pod 提供稳定的访问入口（负载均衡） | 反向代理 | +| **Namespace** | 逻辑隔离的资源分组 | 多租户文件夹 | +| **ConfigMap / Secret** | 将配置注入 Pod（非敏感/敏感数据分离） | .env 文件 | +| **Ingress** | 七层路由，HTTP/HTTPS 域名到 Service 的映射 | Nginx 规则 | ### RKE2 vs 原生 K8s @@ -294,6 +294,8 @@ kubectl patch deployment/ -p '{"spec":{"template":{"spec":{"containers":[{ > [!tip] `-A` 标志 = `--all-namespaces`，当你不确定资源在哪个 namespace 时非常有用。但正式脚本中不建议滥用，容易造成误操作。 +详见 [[k8s-rke2-fundamentals/core-objects-quiz]] — 覆盖 Pod 生命周期、Service 类型、探针机制等核心考点的 10 道选择题自测。 + --- ## 常见陷阱与最佳实践 diff --git a/technical/xinfra-preview/k8s-rke2-fundamentals/core-objects-quiz.md b/technical/xinfra-preview/k8s-rke2-fundamentals/core-objects-quiz.md new file mode 100644 index 0000000..cbeb0de --- /dev/null +++ b/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