7.1 KiB
tags, create time
| tags | 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）进行扩缩容吗？如何做到？"请给出完整回答，包括必要的组件链和技术路径。
答题框架提示:
- 明确回答能否
- 解释 Custom Metrics API 的工作原理
- 列出关键组件及其职责
- 结合实际场景举例
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| 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：参考答案要点：
- 明确回答：可以。HPA 不仅支持 CPU/内存指标，还支持自定义业务指标。
- Custom Metrics API：HPA 通过 Kubernetes Custom Metrics API 获取任意指标值，不限于 K8s 原生指标。
- 关键组件链：Prometheus adapter（或 custom-metrics-adapter）负责将 Prometheus 中的数据暴露给 Custom Metrics API。流程：App 暴露 /metrics → Prometheus scrape → adapter 查询 Prometheus → HPA 读取指标 → 计算目标副本数。
- 实际例子：根据 Kafka consumer lag 扩缩容——当 lag > 阈值时 HPA 增加 Pod 数加快消费；lag < 阈值时缩容节省资源。也可以根据 QPS、错误率等业务指标触发。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。