198 lines
7.1 KiB
Markdown
198 lines
7.1 KiB
Markdown
---
|
||
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
|