examination/topics/interview-prep/k8s-observability/short_answer.json

{
  "topic": "k8s-observability",
  "type": "short_answer",
  "schema_version": "1.0.0",
  "generated": "2026-09-09T16:10:00+08:00",
  "questions": [
    {
      "id": "sa-001",
      "type": "short_answer",
      "difficulty": 3,
      "tags": [
        "kubernetes",
        "rolling-update",
        "blue-green",
        "canary",
        "deployment"
      ],
      "question": "请对比 Kubernetes 中 Rolling Update、Blue-Green 和 Canary 三种应用发布策略的核心机制、适用场景和主要优缺点。",
      "answer": "Rolling Update（滚动更新）：逐步用新版 Pod 替换旧版 Pod，通过 maxSurge 和 maxUnavailable 控制更新节奏。优点是无需额外资源、K8s 原生支持；缺点是回滚速度较慢，且在更新期间新旧版本共存可能产生兼容性问题。适用于大多数常规服务更新。\n\nBlue-Green（蓝绿部署）：同时维护两套完整环境（Blue 为当前版本，Green 为新版本），通过切换 Service selector 或 Ingress 流量一次性将所有流量切到新环境。优点是回滚极快（切回 Blue 即可）、部署原子性强；缺点是需要双倍资源，且切换瞬间可能产生短暂不一致。适用于对可用性要求极高且资源充足的核心服务。\n\nCanary（金丝雀发布）：先将少量流量（如 5%）导到新版本，观察监控指标无异常后逐步扩大比例，最终全量切换。优点是风险可控、可提前发现生产问题；缺点是实现复杂度高（需要 Service Mesh 或 Ingress 精细流量控制）、新旧版本长期共存需保证兼容。适用于大型服务或变更影响面广的场景。",
      "keywords": [
        "滚动更新",
        "maxSurge",
        "maxUnavailable",
        "蓝绿部署",
        "双倍资源",
        "金丝雀",
        "流量比例",
        "回滚",
        "Service Mesh"
      ],
      "scoring_rubric": "需完整对比三种策略的核心机制（各1分），正确说明适用场景（各0.5分），准确指出优缺点（各0.5分）。只提两种策略扣2分，缺少具体技术细节（如 maxSurge、Service selector 切换、流量比例控制）扣1分。",
      "explanation": "K8s 原生 Deployment 默认支持 Rolling Update，可通过 spec.strategy 配置 maxSurge（最大超出期望副本数）和 maxUnavailable（最大不可用副本数）来控制滚动节奏。Blue-Green 部署通常需要维护两个 Deployment 并通过切换 Service 的 selector 或使用 Argo Rollouts 等工具实现流量切换。Canary 发布在原生 K8s 中可通过 Deployment 副本数比例控制，更精细的方案需要借助 Istio 等 Service Mesh 或 Flagger 等 GitOps 工具。三种策略的选择取决于团队对风险的容忍度、资源预算和运维复杂度的权衡。",
      "source": null,
      "related": []
    },
    {
      "id": "sa-002",
      "type": "short_answer",
      "difficulty": 3,
      "tags": [
        "kubernetes",
        "HPA",
        "VPA",
        "pod",
        "deployment"
      ],
      "question": "请说明 Kubernetes 中 HPA（Horizontal Pod Autoscaler）的工作原理，并对比 HPA 与 VPA（Vertical Pod Autoscaler）的适用场景和限制。",
      "answer": "HPA 工作原理：HPA 通过周期性（默认 15 秒）查询 Metrics Server 或自定义 metrics API 获取指标（如 CPU 利用率、内存使用量或自定义指标），将当前指标值与用户设定的目标值进行比较，计算出期望副本数（desiredReplicas = ceil(currentReplicas × (currentMetricValue / desiredMetricValue))）。然后通过调整 Deployment/ReplicaSet 的 replicas 字段实现水平扩缩容。HPA 支持 stabilizationWindowSeconds 来防止抖动，也支持多指标和行为配置（Behavior）来精细控制扩缩策略。\n\nHPA vs VPA 对比：HPA 通过增减 Pod 副本数实现扩容，适用于无状态、可水平扩展的应用（如 Web 服务、API 网关）。VPA 通过调整单个 Pod 的 CPU request/limits 和内存 request/limits 实现垂直扩容，适用于有状态应用或无法水平扩展的场景（如单体数据库）。HPA 和 VPA 默认不能同时作用于同一资源（VPA 会驱逐 Pod 来应用新资源规格，与 HPA 冲突），但 VPA 可以仅设置 recommend 模式配合 HPA 使用。VPA 的缩容需要 Pod 重启，有一定影响；HPA 则可以更平滑地增减副本。",
      "keywords": [
        "HPA",
        "Metrics Server",
        "副本数",
        "目标值",
        "desiredReplicas",
        "VPA",
        "resource request",
        "水平扩展",
        "垂直扩展",
        "stabilizationWindow",
        "不能同时使用"
      ],
      "scoring_rubric": "HPA 工作原理描述正确（含指标获取、计算公式、执行动作）得3分。HPA 与 VPA 对比正确（适用场景各1分，限制/冲突1分）得3分。缺少具体计算公式扣1分，未提及 HPA 与 VPA 不能同时使用扣1分。",
      "explanation": "HPA 的核心是反馈控制循环（reconciliation loop）：采集指标 → 计算期望副本数 → 调整 replicas。计算公式为 desiredReplicas = ceil(currentReplicas × (currentMetric / desiredMetric))。例如当前 CPU 利用率 80%，目标 40%，则副本数翻倍。HPA 的 Behavior 配置允许分别设置扩容和缩容的策略（如 scaleUp 更激进、scaleDown 更保守）。VPA 通过 Admission Controller 在 Pod 创建时注入资源建议，或通过 Updater 驱逐 Pod 以应用新资源规格，这决定了它不能与 HPA 同时调节同一维度。在生产实践中，推荐用 HPA 处理流量波动，用 VPA 的 Auto Off 或 Recommendation 模式辅助设定合理的 resource request。",
      "source": null,
      "related": []
    },
    {
      "id": "sa-003",
      "type": "short_answer",
      "difficulty": 2,
      "tags": [
        "kubernetes",
        "liveness",
        "readiness",
        "pod",
        "startup"
      ],
      "question": "请说明 Kubernetes 中 Liveness Probe、Readiness Probe 和 Startup Probe 三种健康检查探针的区别、各自作用和典型使用场景。",
      "answer": "Liveness Probe（存活探针）：检测容器是否仍在正常运行。如果 Liveness Probe 失败，kubelet 会杀死容器并根据 restartPolicy 重启。适用于检测死锁、内存泄漏等导致进程假死但未退出的场景。例如：一个 Web 服务进程仍在监听端口但无法处理请求（死锁），Liveness Probe 检测到后触发重启。\n\nReadiness Probe（就绪探针）：检测容器是否准备好接收流量。如果 Readiness Probe 失败，K8s 会从 Service 的 Endpoints 中移除该 Pod，使其不再接收新请求，但不会重启容器。适用于容器需要较长启动时间加载数据、或临时不可用（如正在做数据同步）的场景。例如：数据库从库正在同步数据，Readiness Probe 返回失败，流量不会路由到该 Pod。\n\nStartup Probe（启动探针）：检测容器中的应用是否已成功启动。在 Startup Probe 成功之前，其他探针（Liveness/Readiness）都不会执行。适用于启动时间很长的应用（如大型 Java 应用加载 Spring 上下文），避免 Liveness Probe 在应用启动阶段误判导致反复重启。Startup Probe 成功后，由 Liveness/Readiness Probe 接管后续健康检查。",
      "keywords": [
        "Liveness Probe",
        "存活探针",
        "重启容器",
        "Readiness Probe",
        "就绪探针",
        "Endpoints",
        "流量摘除",
        "Startup Probe",
        "启动探针",
        "延迟执行"
      ],
      "scoring_rubric": "三种探针各2分：名称和作用描述正确1分，失败后果和使用场景正确1分。缺少任一探针扣2分。未说明 Startup Probe 与其他两种探针的执行顺序关系扣1分。",
      "explanation": "三种探针的设计体现了关注点分离原则：Liveness 关注「进程是否健康」，Readiness 关注「能否接流量」，Startup 关注「是否启动完成」。在实际配置中，Liveness 的 initialDelaySeconds 应设置得保守一些（避免应用还在初始化就被杀），而 Startup Probe 可以设置较大的 failureThreshold × periodSeconds 来给应用充足的启动时间。一个常见的最佳实践是：对于启动快的服务只配 Liveness + Readiness；对于启动慢的服务（如 Java Spring Boot）三者都配，并将 Startup Probe 的超时时间设为 Liveness Probe 初始延迟的数倍。",
      "source": null,
      "related": []
    },
    {
      "id": "sa-004",
      "type": "short_answer",
      "difficulty": 4,
      "tags": [
        "prometheus",
        "grafana",
        "loki",
        "kubernetes",
        "opentelemetry"
      ],
      "question": "请设计一个基于 Kubernetes 的完整可观测性体系，说明如何覆盖 Metrics、Logs、Traces 三大支柱，并阐述各组件的选型理由和数据流向。",
      "answer": "完整的可观测性体系需要覆盖三大支柱：\n\n**Metrics（指标）层：**\n- 采集：Prometheus（通过 ServiceMonitor/PodMonitor CRD 自动发现 K8s 中的服务并抓取指标）+ node-exporter（节点级指标）+ kube-state-metrics（K8s 对象状态指标）。\n- 存储：Prometheus 本地存储或 Thanos/Mimir 实现长期存储和高可用。\n- 展示：Grafana 作为统一可视化面板，通过 Prometheus 数据源查询和展示指标。\n\n**Logs（日志）层：**\n- 采集：Promtail 或 Alloy 以 DaemonSet 方式部署在每个节点，采集容器 stdout/stderr 日志（遵循 K8s 日志约定），也可通过 OpenTelemetry Collector 采集。\n- 存储与查询：Grafana Loki（标签索引 + 原始日志存储，不全文索引，成本低）。\n- 展示：Grafana 通过 Loki 数据源查询日志，支持日志与指标的关联跳转。\n\n**Traces（链路追踪）层：**\n- 采集：应用通过 OpenTelemetry SDK 埋点，导出 OTLP 格式 traces 到 OpenTelemetry Collector。\n- 处理与导出：OTel Collector 负责接收、处理（采样、批处理、属性注入）和导出，后端可选 Jaeger、Tempo 或 Zipkin。\n- 展示：Grafana Tempo（原生支持 TraceQL）或 Jaeger UI。\n\n**数据流向总结：**\n应用 → OTel SDK → OTel Collector → 各后端（Prometheus/Loki/Tempo）→ Grafana 统一展示。Prometheus 同时作为 OTel Collector 的 metrics 导出目标。\n\n**选型理由：** Grafana 全家栈（Prometheus + Loki + Tempo + Grafana）能实现三大支柱的无缝关联：在 Grafana 中可以从一个 metric 异常跳转到关联的 traces，再从 traces 跳转到对应 logs，形成完整的故障排查链路。",
      "keywords": [
        "Metrics",
        "Logs",
        "Traces",
        "Prometheus",
        "Loki",
        "Grafana",
        "OpenTelemetry",
        "OTel Collector",
        "ServiceMonitor",
        "Promtail",
        "Tempo",
        "OTLP",
        "三大支柱",
        "Grafana 全家栈"
      ],
      "scoring_rubric": "三大支柱各占2分（覆盖 Metrics/Logs/Traces 各层的组件选型和数据流），总计6分。每缺一个支柱扣2分。组件选型有合理解释得1分，数据流向描述清晰得1分。未提及 OTel Collector 作为统一入口扣1分，未说明 Grafana 统一展示扣1分。总分上限8分。",
      "explanation": "可观测性体系的核心挑战在于三大支柱的割裂——指标、日志、链路追踪通常由不同工具管理，排查问题时需要在多个系统间切换。Grafana 全家栈方案的优势在于统一的查询界面和原生的支柱间关联能力。OpenTelemetry 作为 CNCF 标准化项目，提供厂商无关的 SDK 和 Collector，避免了 vendor lock-in。在 K8s 环境中，Prometheus 的服务发现机制（基于 label 和 annotations）使其天然适配动态 Pod 环境。Loki 的设计哲学是「like Prometheus, but for logs」——只索引标签不索引全文，大幅降低存储成本。Tempo 则是分布式追踪后端，支持从日志中自动提取 trace ID 实现 logs-to-traces 关联。",
      "source": null,
      "related": []
    },
    {
      "id": "sa-005",
      "type": "short_answer",
      "difficulty": 3,
      "tags": [
        "opentelemetry",
        "kubernetes",
        "pod",
        "prometheus"
      ],
      "question": "请说明 OpenTelemetry 的架构组成、各组件职责，以及在 Kubernetes 环境中的典型数据流。",
      "answer": "OpenTelemetry（OTel）的架构由三个核心部分组成：\n\n**1. API & SDK：**\n- API：定义了 Traces、Metrics、Logs 的标准接口（如 Tracer、Meter、Logger），是应用埋点的抽象层。\n- SDK：API 的具体实现，负责数据的采集、处理（采样、批处理、过滤）和导出。应用通过 SDK 创建 spans、记录 metrics 和 logs。\n\n**2. OpenTelemetry Collector：**\n- 核心组件，部署为独立进程或 sidecar/daemonset，负责接收、处理和导出遥测数据。\n- 架构分为三个管道：Receiver（接收数据，如 OTLP receiver 接收 OTLP 格式）→ Processor（处理数据，如 batch、memory limiter、tail sampling、attributes 处理）→ Exporter（导出到后端，如 Prometheus exporter、Loki exporter、OTLP exporter 到 Jaeger/Tempo）。\n- 支持多种部署模式：sidecar（每个 Pod 一个 Collector）、DaemonSet（每个节点一个）、Deployment（集中式 Gateway）。\n\n**3. 协议与传播：**\n- OTLP（OpenTelemetry Protocol）：默认的传输协议，支持 gRPC 和 HTTP，用于 SDK → Collector 和 Collector → Backend 的数据传输。\n- W3C TraceContext：分布式追踪的上下文传播标准，通过 HTTP Header 传递 trace-id 和 span-id，实现跨服务的链路关联。\n\n**K8s 环境中的典型数据流：**\n应用 Pod 内嵌 OTel SDK（自动/手动埋点）→ 通过 OTLP 导出到同节点的 Collector（DaemonSet 模式）或 Pod sidecar → Collector 做批处理和采样 → 通过 OTLP Exporter 发送到集中式 Collector Gateway → Gateway 分发到各后端（Prometheus、Tempo、Loki）。对于 K8s 基础设施指标，OTel Collector 还可以通过 k8s_cluster receiver 自动采集集群级指标。",
      "keywords": [
        "OpenTelemetry",
        "API",
        "SDK",
        "OTel Collector",
        "Receiver",
        "Processor",
        "Exporter",
        "OTLP",
        "W3C TraceContext",
        "sidecar",
        "DaemonSet",
        "采样",
        "上下文传播"
      ],
      "scoring_rubric": "OTel 三大组成部分（API/SDK、Collector、协议）各1分，共3分。Collector 内部三管道（Receiver→Processor→Exporter）正确描述得1分。K8s 数据流描述正确（含部署模式）得2分。未提及 OTLP 协议扣1分，未提及 W3C TraceContext 扣1分。总分上限6分。",
      "explanation": "OpenTelemetry 是 CNCF 中仅次于 Kubernetes 的第二活跃项目，其设计目标是提供统一的可观测性数据采集标准，解决 vendor lock-in 问题。API 和 SDK 的分离使得应用代码只依赖轻量级 API，实际采集逻辑由 SDK 提供，方便替换。Collector 的管道架构（Receiver→Processor→Exporter）是其核心设计，通过 YAML 配置即可灵活组合。在 K8s 中推荐使用 OTel Operator 自动注入 SDK（通过 instrumentation annotation）和管理 Collector 实例。W3C TraceContext 传播机制确保了在微服务调用链中 trace-id 的一致性传递，这是实现分布式追踪的基础。",
      "source": null,
      "related": []
    }
  ]
}