---
tags: [test/review, architecture, arch/cicd]
create time: 2026-08-09 12:00
---

# K8s 发布与可观测性体系 — 测试题

## 概述
本测试覆盖 RollingUpdate 策略详解、蓝绿部署 vs Canary 发布、HPA/VPA 自动扩缩容、Prometheus 指标采集链路、Grafana Dashboard 数据源以及日志收集方案。共 10 道题目（6 选择 + 3 填空 + 1 简答）。

---

## 一、选择题（6道，由浅入深）

> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景

### Q1（基础）— 考察定义层面

K8s Deployment 的 RollingUpdate 策略中，`maxUnavailable=0` 和 `maxSurge=1` 的含义是：

A. 更新期间最多有 0 个新 Pod 同时运行
B. 逐台升级，保证零停机——每次只启动 1 个新 Pod，旧 Pod 终止后再启动下一个
C. 所有 Pod 同时替换，然后检查是否可用
D. 先删除全部旧 Pod 再创建新 Pod

### Q2（基础）→ 

Canary 发布相比蓝绿部署的主要优势是什么？

A. 回滚速度更快
B. 资源消耗更低
C. 风险最低——只有小部分用户先体验新版本
D. 实现复杂度更低

### Q3（进阶）— 核心原理

HPA（Horizontal Pod Autoscaler）扩容的基本计算公式是：

A. `targetReplicas = currentReplicas * desiredMetricValue / currentMetricValue`
B. `targetReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)`
C. `targetReplicas = currentReplicas + (currentMetricValue - desiredMetricValue)`
D. `targetReplicas = floor(currentReplicas * 2)`

### Q4（进阶）— 比较/辨析

以下关于 Prometheus Pull 模式的说法哪个是正确的？

A. Push 模式下失联的服务会立即被标记为 down
B. Pull 模式下失联的 service 会自动被忽略（不再收到数据即标记为 down）
C. Prometheus 不支持自定义业务指标
D. Prometheus 的采集间隔是实时的，没有延迟

### Q5（深入）— 场景推理

某秒杀系统需要在流量洪峰到来前自动扩容。以下方案最合理的是：

A. 完全依赖 HPA，等 CPU 使用率上升后触发扩容
B. 提前设置 minReplicas >= 预期峰值的 80%，配合 HPA 动态调整上限
C. 使用 VPA Auto 模式代替 HPA
D. 手动扩容并在活动结束后手动缩容

### Q6（深入）— 源码级/边界场景

关于 Prometheus 的四种核心指标类型，以下匹配哪个是错误的？

A. Counter — 单调递增计数器，适合画 Rate 曲线
B. Gauge — 可上可下的仪表值，如活跃连接数
C. Histogram — 分桶统计，自动生成 count + sum + bucket
D. Summary — 服务端计算分位数（P50/P99），客户端不做计算

---

## 二、填空题（3道）

### F1 — 填空1

K8s 中新 Pod 必须通过 _____ Probe 才会被加入 Service 的 Endpoint 列表。如果失败，即使新 Pod 已 Running 也不会接收流量。livenessProbe 用于检测进程存活并可能触发重启；而 _____ Probe 用于决定"这个 Pod 是否可以接受流量"。

> **提示**: 两个空填同一种类型的探针名称。

### F2 — 填空2

Fluentd/Filebeat DaemonSet 采集日志后的两种典型存储方案：**ELK 栈**建立_____索引（搜索能力强但存储成本高）；**Loki**不建立全文索引，只索引_____（Labels），存储成本极低。

> **提示**: ELK 的核心搜索机制和 Loki 的区别。

### F3 — 填空3

VPA（Vertical Pod Autoscaler）的 Offline 模式行为是_____——只推荐建议值而不直接应用，人工审核后手动调整。这种模式适合_____阶段。

> **提示**: 原文 VPA 表格中的描述。

---

## 三、简答题（1道）

### S1

面试官问："HPA 能基于自定义业务指标（如 Kafka 消费 lag、QPS）进行扩缩容吗？如何做到？"请给出完整回答，包括必要的组件链和技术路径。

> **答题框架提示**:
> 1. 明确回答能否
> 2. 解释 Custom Metrics API 的工作原理
> 3. 列出关键组件及其职责
> 4. 结合实际场景举例

---

## 参考答案与解析

### 选择题答案

| 题号 | 正确答案 | 解析 |
|------|---------|------|
| Q1 | B | maxSurge=1 表示更新过程中允许超出目标副本数 1 个，maxUnavailable=0 表示不允许任何不可用实例。逐台升级确保零停机，但速度慢。生产环境高可用场景推荐此配置。 |
| Q2 | C | Canary 只有少量流量进入新版本（如 10%），大部分用户还在稳定版。这样风险最低——有问题也只影响一小部分用户。蓝绿需要双倍资源，且一旦切到新版本就是全部流量都有问题。 |
| Q3 | B | `ceil(current * current_metric / desired_metric)`。例如当前 5 副本，CPU 91%，目标 70% → ceil(5 × 91 / 70) = ceil(6.5) = 7。注意分子是当前值、分母是目标值。 |
| Q4 | B | A 错：Push 模式下挂了停止发数据但采集器不知道不存在了；C 错：通过 Custom Metrics API + adapter 可以读任意业务指标；D 错：采集间隔 15~60 秒，有分钟级延迟。 |
| Q5 | B | HPA 不是实时的（依赖 metrics-server 15~60 秒采样），等 CPU 上升再扩容已经来不及。minReplicas 预热的做法可以应对已知高峰。VPA 不适合因为它是垂直扩缩（改资源配额需重建 Pod），不能快速应对流量变化。 |
| Q6 | D | D 错误——Summary 的分位数计算在**客户端**完成（SDK 内部算 P50/P99），服务器端不做计算但有额外开销。Histogram 是在服务器端做分桶统计。原文原话：Summary = 客户端计算分位数。 |

### 填空题答案

| 题号 | 答案 | 解析 |
|------|------|------|
| F1 | `readiness`；`readiness` | Readiness Probe 决定 Pod 是否能接收流量（加入 Endpoint）。livenessProbe 检测进程是否存活。二者职责不同：Ready = 可服务，Live = 没挂。 |
| F2 | `全文`；`Labels` | ELK 对每个字段建 inverted index 支持全文检索，但 JSON 结构化索引非常占空间。Loki 只对 Labels 建索引，查询时先用 label 过滤再检索内容，存储成本低几个数量级。 |
| F3 | `只推荐不应用`；`微服务刚上线` | 刚上线阶段运维难以精确预估资源需求，可以让 VPA 学习实际使用模式后给出最优建议。Offline 模式不会自动修改 Pod Spec，避免误配导致业务中断。 |

### 简答题参考答案

S1：**参考答案要点**：
1. **明确回答**：可以。HPA 不仅支持 CPU/内存指标，还支持自定义业务指标。
2. **Custom Metrics API**：HPA 通过 Kubernetes Custom Metrics API 获取任意指标值，不限于 K8s 原生指标。
3. **关键组件链**：Prometheus adapter（或 custom-metrics-adapter）负责将 Prometheus 中的数据暴露给 Custom Metrics API。流程：App 暴露 /metrics → Prometheus scrape → adapter 查询 Prometheus → HPA 读取指标 → 计算目标副本数。
4. **实际例子**：根据 Kafka consumer lag 扩缩容——当 lag > 阈值时 HPA 增加 Pod 数加快消费；lag < 阈值时缩容节省资源。也可以根据 QPS、错误率等业务指标触发。

**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。

## 关联笔记
- [[负载均衡算法]]
- [[限流熔断降级]]