wonder
0f68a64829
Deploy Examination / deploy (push) Successful in 10s
Subtopics: - distributed-microservice: 45 questions (分布式微服务架构) - message-queue: 45 questions (消息队列) - k8s-observability: 45 questions (K8s与可观测性) - go-java-concurrency: 45 questions (Go/Java并发模型) - database-advanced: 35 questions (数据库进阶) - ai-engineering: 35 questions (AI工程实践) Question types: single_choice, true_false, fill_blank, short_answer, code_reading
161 lines
9.3 KiB
JSON
161 lines
9.3 KiB
JSON
{
|
||
"topic": "k8s-observability",
|
||
"type": "true_false",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-09T16:10:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "tf-001",
|
||
"type": "true_false",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"kubernetes",
|
||
"deployment",
|
||
"HPA"
|
||
],
|
||
"question": "HPA（Horizontal Pod Autoscaler）只能基于 CPU 使用率来自动扩缩 Pod 副本数，无法使用内存或其他自定义指标。",
|
||
"answer": false,
|
||
"explanation": "HPA 支持多种指标来源：默认的 CPU 和内存（通过 resource metrics）、自定义指标（custom metrics，如请求 QPS）、以及外部指标（external metrics，如 Kafka lag）。通过 metrics API 的扩展机制，HPA 几乎可以基于任何可量化的指标进行扩缩容。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-002",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"prometheus",
|
||
"grafana",
|
||
"opentelemetry"
|
||
],
|
||
"question": "OpenTelemetry 的 Collector 架构采用 Receiver → Processor → Pipeline → Exporter 的管道模型，且支持同时向多个后端（如 Prometheus、Jaeger、Loki）导出数据。",
|
||
"answer": true,
|
||
"explanation": "OpenTelemetry Collector 的核心设计就是可插拔的管道架构：Receiver 负责接收遥测数据（OTLP、Jaeger、Prometheus 等格式），Processor 负责处理（批处理、过滤、属性修改等），Exporter 负责将数据推送到一个或多个后端。一个 Collector 实例可以配置多个 Pipeline 和多个 Exporter，实现数据扇出（fan-out）。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-003",
|
||
"type": "true_false",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"kubernetes",
|
||
"liveness",
|
||
"readiness"
|
||
],
|
||
"question": "Kubernetes 的 Liveness Probe 负责判断 Pod 是否准备好接收流量，失败时会将 Pod 从 Service 的 Endpoints 中移除。",
|
||
"answer": false,
|
||
"explanation": "这是 Readiness Probe 的职责。Liveness Probe 用于检测容器是否仍然存活（如是否发生死锁），失败时 kubelet 会重启容器。Readiness Probe 才负责判断 Pod 是否就绪，失败时会从 Service 的 Endpoints 列表中摘除，使流量不再路由到该 Pod。两者职责不同，不可混淆。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-004",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"kubernetes",
|
||
"deployment",
|
||
"rolling-update",
|
||
"HPA",
|
||
"VPA"
|
||
],
|
||
"question": "在同一个 Deployment 上同时启用 HPA 和 VPA 是推荐的最佳实践，因为 HPA 负责副本数扩缩，VPA 负责单 Pod 资源调整，两者互补且无冲突。",
|
||
"answer": false,
|
||
"explanation": "HPA 和 VPA 同时作用于同一个 Deployment 时会产生冲突：HPA 根据资源使用率调整副本数，而 VPA 根据历史使用量调整 Pod 的 resource requests。当 VPA 提高 requests 时，HPA 感知到的使用率下降会触发缩容，形成振荡。社区推荐的模式是：HPA 使用自定义指标（如 QPS）而非 CPU/内存，让 VPA 只管资源配额。或者使用 VPA 的 Recommend 模式（仅给出建议，不自动修改）配合 HPA。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-005",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"kubernetes",
|
||
"pod",
|
||
"deployment"
|
||
],
|
||
"question": "在 Kubernetes 中，DaemonSet 类型的控制器可以像 Deployment 一样通过修改 spec.replicas 字段来手动调整副本数。",
|
||
"answer": false,
|
||
"explanation": "DaemonSet 的设计目标是在每个（或指定的）节点上运行且仅运行一个 Pod 副本，因此它没有 spec.replicas 字段。DaemonSet 的 Pod 数量由集群中的节点数量决定，无法手动指定副本数。这与 Deployment、StatefulSet 等支持 replicas 字段的控制器有本质区别。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-006",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"prometheus",
|
||
"grafana"
|
||
],
|
||
"question": "Prometheus 的 ServiceMonitor 资源直接指定 Pod 标签来发现抓取目标，因此即使没有创建 Service，只要 Pod 有正确标签就能被 Prometheus 自动抓取。",
|
||
"answer": false,
|
||
"explanation": "ServiceMonitor 是 Prometheus Operator 提供的 CRD，它的 spec.selector.matchLabels 匹配的是 Service 对象的标签，而非 Pod 的标签。匹配到的 Service 对应的 Endpoints（即背后的 Pod）才会被 Prometheus 抓取。因此，要让 Prometheus 通过 ServiceMonitor 抓取指标，必须先创建对应的 Service。如果想直接基于 Pod 标签抓取，应使用 PodMonitor 资源。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-007",
|
||
"type": "true_false",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"kubernetes",
|
||
"rolling-update",
|
||
"deployment"
|
||
],
|
||
"question": "Kubernetes Deployment 的 Rolling Update 策略中，maxSurge 和 maxUnavailable 这两个字段本质上是冗余的，因为其中一个参数就能完整控制滚动更新的行为。",
|
||
"answer": false,
|
||
"explanation": "maxSurge 和 maxUnavailable 控制的是滚动更新中两个不同维度：maxSurge 决定更新过程中最多可以比期望副本数多出多少 Pod（控制创建新 Pod 的速度），maxUnavailable 决定最多可以比期望副本数少多少 Pod（控制旧 Pod 被移除的速度）。两者共同约束更新过程中的可用容量。例如 maxSurge=25%、maxUnavailable=0 意味着必须先创建新 Pod 再销毁旧 Pod（零停机），而 maxSurge=0、maxUnavailable=25% 则先销毁旧 Pod 再创建新 Pod（有停机风险）。两者配合使用才能精确控制滚动更新的激进程度。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-008",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"opentelemetry",
|
||
"loki"
|
||
],
|
||
"question": "OpenTelemetry Collector 在处理日志数据时，可以通过 Loki Exporter 将日志直接推送到 Grafana Loki，但 Loki 的核心索引机制是基于全文检索（类似 Elasticsearch），因此 OTLP 格式的日志需要先经过全文索引处理才能被高效查询。",
|
||
"answer": false,
|
||
"explanation": "Loki 的核心设计理念是「只索引标签，不索引日志内容」（like Prometheus, but for logs）。它只对标签（labels）建立索引，日志内容本身以压缩块的形式存储，在查询时才进行流式 grep。这与 Elasticsearch 的全文检索索引方式完全不同。OTLP 格式的日志通过 Loki Exporter 推送时，Resource Attributes 和 Log Records 的 Attributes 会被映射为 Loki 的标签，日志体直接存储，无需全文索引。这也是 Loki 相比 ELK 在存储成本上更有优势的原因。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-009",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"kubernetes",
|
||
"pod",
|
||
"liveness",
|
||
"readiness"
|
||
],
|
||
"question": "为一个启动时间较长的应用（如大型 Java Spring Boot 服务）配置 Liveness Probe 时，应设置较短的 initialDelaySeconds（如 5 秒），以便尽早发现并重启不健康的容器。",
|
||
"answer": false,
|
||
"explanation": "对于启动时间较长的应用，initialDelaySeconds 设置过短会导致 Liveness Probe 在应用尚未完成初始化时就开始探测，kubelet 会误判容器不健康并反复重启，形成「重启风暴」。正确的做法是：(1) 使用 Startup Probe（K8s 1.18+）给应用充足的启动时间，Startup Probe 成功后 Liveness 和 Readiness Probe 才开始工作；(2) 如果不用 Startup Probe，应将 Liveness Probe 的 initialDelaySeconds 设置为大于应用的最长启动时间。另外，Liveness Probe 的超时时间和失败阈值也应留有余量，避免应用在 GC 或高负载时被误杀。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "tf-010",
|
||
"type": "true_false",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"kubernetes",
|
||
"canary",
|
||
"blue-green",
|
||
"service",
|
||
"ingress"
|
||
],
|
||
"question": "在 Kubernetes 中实现 Canary 部署时，必须依赖 Istio 或 Linkerd 等服务网格才能按权重分流流量到新版本；仅使用原生的 Service 和 Ingress 资源无法实现流量的按比例分割。",
|
||
"answer": false,
|
||
"explanation": "虽然服务网格（Istio VirtualService、Linkerd TrafficSplit）提供了精细的流量管理能力，但原生 K8s 也能实现 Canary 分流：(1) 通过创建两个 Service（stable 和 canary）指向不同版本的 Deployment，配合 Ingress 的 annotations（如 Nginx Ingress 的 canary-weight annotation `nginx.ingress.kubernetes.io/canary-weight: 20`）实现按权重分流；(2) 使用 Deployment 的 Rolling Update 配合 minReadySeconds 和 progressDeadlineSeconds，让新旧版本 Pod 共存一段时间，Service 的 round-robin 负载均衡自然将部分流量导向新版本。原生方案虽然不如服务网格灵活，但对简单场景已经够用。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |