本文件汇总本大纲中所有偏 Kubernetes/K3s、可观测性、CI/CD 与 Docker、注册中心 & 服务发现、网络协议（HTTP/SSE/WebSocket） 的内容，用于准备云原生与运维方向的面试问题。

---

1. Kubernetes 核心概念

对应原文第 3 章中 Kubernetes 相关小节。

1.1 Pod 生命周期与探针

• Pod 状态：

  • Pending：已被接收但容器尚未创建（镜像下载、卷挂载等）。
  • Running：已调度到节点且至少一个容器在运行/启动/重启。
  • Succeeded：所有容器成功终止且不会重启（典型 Job）。
  • Failed：所有容器终止且至少一个容器非 0 退出。
  • Unknown：无法获取状态（节点通信异常）。

• 探针：

  • Liveness Probe：判断容器是否“活着”，失败会被杀死并按策略重启。
  • Readiness Probe：判断是否就绪，失败会从 Service 的 Endpoints 中移除。
  • Startup Probe：为启动很慢的应用预留时间，在其成功前不会执行 Liveness/Readiness。

1.2 Service 与 Ingress（Traefik）

• Service 类型：

  • ClusterIP：集群内访问，提供稳定虚 IP。
  • NodePort：在每个节点暴露固定端口（一般 30000–32767）。
  • LoadBalancer：云厂商外部 LB，常用公网暴露方式。
  • ExternalName：将 Service 映射为外部 DNS 名称。

• Ingress & Ingress Controller：

  • Ingress 是 HTTP/HTTPS 入口规则的声明。
  • Traefik 作为 Ingress Controller：
    • 自动发现 Ingress 规则并动态配置路由。
    • 提供中间件（重定向、认证、限流、熔断等）。

1.3 配置管理与热更新

• ConfigMap：
  • 存放非敏感配置，可通过 env/volume/args 注入。
• Secret：
  • 存放敏感信息（密码、token、证书等），一般以 volume 挂载方式使用。
• 热更新：
  • volume 挂载方式下，文件内容更新会自动反映在容器内，可通过 inotify 触发应用重新加载。
  • 对不支持动态加载配置的应用可使用 Reloader 等控制器触发滚动更新。

1.4 弹性伸缩

• HPA（水平伸缩）：

  • 根据 CPU/内存或自定义指标自动调整 Pod 副本数。
  • 周期性计算：期望副本数 = ceil(当前副本数 * 当前指标 / 目标指标)。
  • 自定义指标需要配合 Prometheus Adapter 等组件。

• VPA（垂直伸缩）：

  • 根据历史使用情况推荐/调整 Pod 的 request/limit。
  • 通过驱逐旧 Pod + 新 Pod 生效推荐配置。

---

2. 可观测性体系

2.1 Prometheus 监控

• Exporter：
  • 使用 client_golang 暴露 Counter/Gauge/Histogram/Summary。
  • HTTP /metrics 接口由 promhttp.Handler() 提供。
• PromQL：
  • rate(counter[5m])、histogram_quantile(0.95, bucket)。
• Recording Rule：
  • 预计算复杂/高成本查询，提升实时查询性能。

2.2 Grafana 可视化与告警

• Dashboard 设计原则：清晰、层次分明、避免信息过载。
• 变量模板：通过变量实现可复用、可切换的 Dashboard。
• Alerting：
  • 告警规则（阈值 + 持续时间）。
  • 通知渠道（Email/Slack/Webhook/钉钉/企业微信）。

2.3 ELK 日志栈

• Filebeat：
  • 作为 Agent 采集日志，配置 inputs/output/processors。
• Logstash：
  • Pipeline = input + filter + output。
  • 常用 filter：grok、mutate、date、geoip。
• Elasticsearch ILM：
  • 索引生命周期阶段：Hot/Warm/Cold/Delete。
  • 按时间/大小/文档数自动迁移和删除。

2.4 链路追踪（Jaeger / SkyWalking）

• 基本概念：Trace、Span、TraceID。
• TraceID 传播：
  • HTTP 头（如 x-trace-id）、gRPC metadata、消息队列 header。
• 好处：跨服务调用路径可视化，快速定位慢调用与错误节点。

---

3. DevOps 与容器构建

3.1 CI/CD（GitLab CI / GitHub Actions）

• 典型流水线阶段：
  • Build → Test → Security Scan → Build Image → Deploy。
• GitLab CI：
  • .gitlab-ci.yml 定义 stage/job，按 stage 顺序执行、同一 stage 并行。
• GitHub Actions：
  • workflow/job/step/action 四层结构，由 push/pull_request 等事件触发。

3.2 Dockerfile 最佳实践

• 多阶段构建：
  • 构建阶段使用完整构建镜像（如 golang:1.21）。
  • 运行阶段使用精简镜像（如 alpine），仅复制编译产物。
• 使用非 root 用户：
  • 通过 adduser/addgroup 创建业务用户，用 USER 指令降权。
• 安全扫描：
  • 使用 Trivy 等工具在 CI 中扫描镜像漏洞，发现高危漏洞时阻断流水线。

---

4. 注册中心与服务发现（K8s vs Nacos/Eureka）

这一节来自原文中“注册中心管理的是服务发现和服务注册。能不能用原生k8s替代”的问答整理。

4.1 K8s 如何实现服务注册与发现？

• 服务注册：
  • Pod 创建时带有标签（如 app=my-service）。
  • Service 的 selector 自动选中这些 Pod，其 IP 会写入 Endpoints。
• 服务发现：
  • CoreDNS 提供 my-service.namespace.svc.cluster.local 域名解析。
  • 也可以通过自动注入的环境变量访问 Service。
• 健康检查：
  • Readiness/Liveness Probe 与 Endpoints 结合，自动剔除异常实例。
• 负载均衡：
  • kube-proxy 通过 iptables/ipvs 实现 ClusterIP 级别的负载均衡。

一句话：“声明一个 Service，K8s 自动完成注册、发现、健康剔除与负载均衡。”

4.2 原生 K8s 替代传统注册中心的优缺点

• 优点：
  • 零额外成本，无需单独维护 Nacos/Eureka 集群。
  • 控制面高可用，集成度高。
  • Pod 弹性扩缩容时 Endpoints 秒级更新。
• 短板：
  • 跨集群/跨环境能力弱。
  • 服务元数据能力有限（权重、版本、灰度规则等）。
  • 配置中心不如 Nacos 一体化，需要 ConfigMap/Secret 自己拼装。
  • 控制台和治理能力（限流、熔断、灰度）需要 Service Mesh 补齐。

选型建议：

• 单集群、服务都在 K8s 内且治理需求不复杂：直接用 K8s Service。
• 多集群、多语言、复杂治理（灰度/权重路由）：K8s + Nacos 或上 Istio 等 Service Mesh。

---

5. 网络与协议：HTTP/1.1、HTTP/2、HTTP/3、SSE 与 WebSocket

本节来自原文中关于 HTTP 版本与 SSE/WebSocket 区别的问答，归档在运维与网络协议部分。

5.1 HTTP/1.1 vs HTTP/2 vs HTTP/3

• HTTP/1.1：
  • 基于 TCP + 文本协议。
  • Keep-Alive 复用连接，但请求串行，存在队头阻塞。
• HTTP/2：
  • 基于 TCP + 二进制分帧。
  • 单连接多路复用，应用层队头阻塞问题基本解决。
  • 头部压缩（HPACK）、服务器推送、流优先级。
  • 仍受 TCP 层队头阻塞影响（丢包影响同连接所有流）。
• HTTP/3：
  • 基于 QUIC（UDP），集成 TLS1.3。
  • 多路复用 + 无 TCP 队头阻塞。
  • 0-RTT/1-RTT 握手、连接迁移（网络切换不重连）。

面试金句：“HTTP/2 解决应用层队头阻塞，HTTP/3 解决 TCP 层队头阻塞。”

5.2 SSE（Server-Sent Events）与 WebSocket

• SSE：
  • 基于 HTTP 的单向推送，text/event-stream。
  • 浏览器原生 EventSource 支持，自动重连。
  • 适合服务器→客户端单向推送，如日志、行情、AI 流式输出。
• WebSocket：
  • 独立协议（ws/wss），通过 HTTP 升级握手。
  • 全双工双向通信，支持二进制帧。
  • 适合 IM、协同编辑、实时游戏等强交互场景。

选择建议：

• 只需要服务端推送：优先 SSE。
• 需要双向交互或二进制：选择 WebSocket。

---

6. 云原生场景常见组合题：日志 & 监控 & 部署

• 日志链路：应用 → Sidecar/Agent（Filebeat/Fluentd）→ Kafka/Logstash → Elasticsearch → Grafana/Kibana。
• 指标链路：应用 Exporter → Prometheus → Alertmanager → Grafana。
• 部署策略：
  • 使用 Deployment 做无状态应用滚动更新。
  • 使用 StatefulSet 管理有状态服务（ES/Kafka 等）。
  • 结合 HPA/VPA 与 PodDisruptionBudget 做高可用与弹性。