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

{
  "topic": "k8s-observability",
  "type": "fill_blank",
  "schema_version": "1.0.0",
  "generated": "2026-09-09T16:10:00+08:00",
  "questions": [
    {
      "id": "fb-001",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "kubernetes",
        "pod",
        "deployment"
      ],
      "question": "在 Kubernetes 中，Deployment 通过 ______ 控制器来管理 Pod 的副本数量，确保指定数量的 Pod 始终处于运行状态。",
      "answer": [
        "ReplicaSet"
      ],
      "answer_rule": "any",
      "explanation": "Deployment 的底层是 ReplicaSet 控制器。Deployment 对象声明期望的 Pod 模板和副本数，ReplicaSet 负责实际维护 Pod 的生命周期，确保运行中的 Pod 数量与 spec.replicas 一致。当 Pod 意外终止时，ReplicaSet 会自动创建新 Pod 进行替换。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-002",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "kubernetes",
        "ingress",
        "service"
      ],
      "question": "Kubernetes 中，______ 是一种 API 对象，用于管理集群中 Service 的外部 HTTP/HTTPS 访问，提供基于名称的虚拟主机和基于路径的路由规则。",
      "answer": [
        "Ingress"
      ],
      "answer_rule": "any",
      "explanation": "Ingress 资源定义了从集群外部到内部 Service 的 HTTP/HTTPS 路由规则。它通常配合 Ingress Controller（如 Nginx Ingress Controller）工作，支持基于主机名和 URL 路径的流量转发。Ingress 可以配置 TLS 终止、重写规则等，是 Kubernetes 中暴露服务的标准方式之一。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-003",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "kubernetes",
        "rolling-update",
        "deployment"
      ],
      "question": "在 Kubernetes Rolling Update 策略中，maxSurge 控制更新过程中可以超出期望副本数的最大 Pod 数量，而 ______ 控制更新过程中可以处于不可用状态的最大 Pod 数量。",
      "answer": [
        "maxUnavailable"
      ],
      "answer_rule": "any",
      "explanation": "Rolling Update 策略通过两个关键参数控制发布节奏：maxSurge 决定可以额外创建多少个新 Pod（默认 25%），maxUnavailable 决定可以有多少个旧 Pod 被标记为不可用（默认 25%）。两者配合确保在更新过程中始终有足够数量的可用 Pod 服务流量，同时逐步用新版本替换旧版本。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-004",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "kubernetes",
        "configmap",
        "secret"
      ],
      "question": "在 Kubernetes 中，______ 资源用于存储敏感信息（如密码、令牌、证书），数据以 Base64 编码存储，但不提供加密功能，需配合 RBAC 进行访问控制。",
      "answer": [
        "Secret"
      ],
      "answer_rule": "any",
      "explanation": "Secret 是 Kubernetes 中专门用于管理敏感数据的资源对象。它以 Base64 编码存储数据（注意 Base64 是编码而非加密）。生产环境中建议结合 etcd 加密（EncryptionConfiguration）来保护 Secret 数据。Secret 可以通过环境变量或 Volume 挂载方式注入到 Pod 中。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-005",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "canary",
        "blue-green"
      ],
      "question": "在灰度发布策略中，Canary（金丝雀）发布是将新版本逐步推送给 ______ 的用户，观察其行为和指标，确认无误后再全量发布；而 Blue-Green（蓝绿）发布则维护两套完全相同的生产环境。",
      "answer": [
        "小部分",
        "少量",
        "一部分",
        "部分"
      ],
      "answer_rule": "any",
      "explanation": "Canary 发布的核心思想是风险控制：先将新版本部署给一小部分用户（如 5% 的流量），通过监控指标（错误率、延迟等）验证新版本的稳定性，然后逐步增加流量比例直到全量切换。相比 Blue-Green 的一次性切换，Canary 发布更加渐进，回滚成本更低，适合对稳定性要求极高的场景。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-006",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "HPA",
        "VPA",
        "KEDA"
      ],
      "question": "Kubernetes 的 HPA（Horizontal Pod Autoscaler）基于 CPU、内存等指标自动扩缩 Pod 的副本数量；______（Vertical Pod Autoscaler）则根据资源使用情况自动调整 Pod 的 CPU 和内存请求与限制。",
      "answer": [
        "VPA",
        "Vertical Pod Autoscaler"
      ],
      "answer_rule": "any",
      "explanation": "VPA 通过分析 Pod 的历史资源使用数据，自动调整容器的 resource requests 和 limits，实现「垂直」维度的资源优化。VPA 有三种模式：Off（仅建议）、Initial（仅在 Pod 创建时应用）、Auto（自动驱逐并重建 Pod 以应用新资源）。与 HPA 的水平扩缩不同，VPA 更适合无法水平扩展的应用（如单体数据库）。KEDA 则是基于事件驱动的高级自动伸缩器，支持更丰富的触发器。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-007",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "kubernetes",
        "liveness",
        "readiness"
      ],
      "question": "Kubernetes 中的存活探针（______ Probe）用于检测容器是否仍在运行，如果探针失败，kubelet 会重启该容器。",
      "answer": [
        "liveness",
        "Liveness"
      ],
      "answer_rule": "any",
      "explanation": "Liveness Probe 用于检测容器是否存活。如果 Liveness Probe 失败，kubelet 会认为容器处于不健康状态并执行重启操作。常见的探针方式包括 HTTP GET（检查端口是否返回 200）、TCP Socket（检查端口是否可达）、Exec（执行命令检查退出码）。Liveness Probe 适用于检测死锁、无限循环等无法自行恢复的故障场景。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-008",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "prometheus",
        "grafana"
      ],
      "question": "Prometheus 使用 ______ 查询语言（PromQL）来检索和聚合时间序列数据，例如通过 rate() 计算指标的变化速率。",
      "answer": [
        "PromQL",
        "Prometheus Query Language"
      ],
      "answer_rule": "any",
      "explanation": "PromQL 是 Prometheus 内置的函数式查询语言，支持选择器、聚合操作（sum、avg、max 等）、数学运算和内置函数（rate、histogram_quantile 等）。例如 rate(http_requests_total[5m]) 表示计算过去 5 分钟内 HTTP 请求的每秒增长率。PromQL 是使用 Prometheus 进行监控告警和数据可视化的基础。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-009",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "opentelemetry",
        "OTLP"
      ],
      "question": "OpenTelemetry 定义了 ______（OpenTelemetry Protocol）作为其默认的数据传输协议，用于统一传输 Traces、Metrics 和 Logs 三种遥测数据。",
      "answer": [
        "OTLP",
        "OpenTelemetry Protocol"
      ],
      "answer_rule": "any",
      "explanation": "OTLP 是 OpenTelemetry 原生的传输协议，支持 gRPC 和 HTTP/protobuf 两种传输方式。OTLP 的设计目标是统一 Traces（分布式追踪）、Metrics（指标）和 Logs（日志）的采集与传输格式，使应用只需集成一个 SDK 就能输出所有类型的遥测数据，再由 OTel Collector 进行统一处理、转换和导出到后端存储。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-010",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "loki",
        "opentelemetry",
        "grafana"
      ],
      "question": "在可观测性技术栈中，______ 是 Grafana 推出的日志聚合系统，它不建立全文索引，而是只索引日志的标签（labels），因此查询时需要先通过标签过滤再进行正则匹配。",
      "answer": [
        "Loki",
        "Grafana Loki"
      ],
      "answer_rule": "any",
      "explanation": "Loki 的设计理念是「像 Prometheus 一样索引标签」——它只为日志的元数据标签（如 app、env、namespace）建立索引，而不对日志内容建立全文索引。这种设计使得 Loki 的存储成本远低于 Elasticsearch（ELK 栈），但查询日志内容时需要先用标签缩小范围再进行 LogQL 正则匹配。Loki 与 Grafana 深度集成，可以在 Grafana 面板中直接查询和关联日志数据。",
      "source": null,
      "related": []
    }
  ]
}