143 lines
7.1 KiB
Markdown
143 lines
7.1 KiB
Markdown
|
---
|
|||
|
|
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 个要点即可得满分；完全正确需覆盖全部要点。
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
- [[负载均衡算法]]
|
|||
|
|
- [[限流熔断降级]]
|