---
tags: [arch/cicd, kubernetes, rolling-update, canary-deployment, hpa, vpa, prometheus, grafana]
create time: 2026-08-08 18:00
update time: 2026-08-08 18:00
---

# K8s 发布与可观测性体系

## 概述

Kubernetes 是现代 CI/CD 体系的编排核心，提供从滚动发布、灰度策略到自动扩缩容的完整能力链。配合 Prometheus + Grafana + 日志采集组件，构成生产级别的可观测性基础设施。本文系统梳理这些组件的设计原理与协作方式。

## 核心原理

### 整体架构概览

```mermaid
graph TD
    subgraph UserTraffic["用户流量"]
        U[用户请求] --> INGRESS[Nginx Ingress Controller]
    end

    subgraph K8sCluster["K8s 集群"]
        SUBNAME["Service Name: user-service"] --> EP[Endpoint: pod IPs]
        EP --> P1[Pod A: v2.3.1]
        EP --> P2[Pod B: v2.3.1]
        EP --> P3[Pod C: v2.4.0-new]

        DEPLOY[Deployment] -->|管理| P1
        DEPLOY -->|管理| P2
        DEPLOY -->|管理| P3

        HPA[Horizontal Pod Autoscaler] -->|扩缩容指令| DEPLOY

        sub kubeSystem["kube-system 组件"]
            APISERVER[API Server]
            ETCD[(etcd)]
            CONTROLLER[M-controller Manager]
            SCHEDULER[Scheduler]
        end

        P1 -->|心跳 / metrics| PROMETHEUS[Prometheus TSDB]
        P2 -->|心跳 / metrics| PROMETHEUS
        P3 -->|心跳 / metrics| PROMETHEUS
        P1 -.->Fluentd --> ES[ES / Loki]
        P2 -.->Fluentd --> ES
        P3 -.->Fluentd --> ES
    end

    sub GrafanaUI["可视化层"]
        GRAFANA[Grafana Dashboard] -->|查询| PROMETHEUS
        GRAFANA -->|告警规则| ALERTMANAGER[Alertmanager]
    end

    INGRESS --> SUBNAME
```

### RollingUpdate 策略详解

K8s Deployment 默认使用 `RollingUpdate` 策略，通过两个参数控制滚动速度：

| 参数 | 默认值 | 含义 | 影响 |
|------|-------|------|------|
| maxSurge | 25% | 更新过程中允许超出目标副本数的最大数量 | 控制新 Pod 先启动的数量 |
| maxUnavailable | 25% | 更新过程中允许不可用的最大副本数 | 控制旧 Pod 被终止的速度 |

**两种典型配置对比：**

| 配置 | 行为 | 适用场景 |
|------|-----|---------|
| maxSurge=1, maxUnavailable=0 | 逐台升级，零停机 | 对可用性要求极高的生产环境 |
| maxSurge=25%, maxUnavailable=25% | 批量快速滚动 | 测试环境或无需保持全量的场景 |

以 3 副本升级为 4 副本为例（maxSurge=1, maxUnavailable=0）：

```mermaid
gantt
    title RollingUpdate 过程 (3 -> 4 pods, surge=1)
    dateFormat YYYY-MM-DD
    axisFormat %H:%M

    section Pod Group
    old-1              :done,    1,  2026-08-08T00:00, 2026-08-08T00:05
    old-2              :done,    1,  2026-08-08T00:00, 2026-08-08T00:05
    old-3              :done,    1,  2026-08-08T00:00, 2026-08-08T00:05
    new-1 (surge +1)   :active,  2026-08-08T00:01, 2026-08-08T00:05
    old-3 terminate    :crit,    2026-08-08T00:06, 2026-08-08T00:07
    new-2 (surge +1)   :active,  2026-08-08T00:07, 2026-08-08T00:11
    old-2 terminate    :crit,    2026-08-08T00:12, 2026-08-08T00:13
    new-3 (surge +1)   :active,  2026-08-08T00:13, 2026-08-08T00:17
    old-1 terminate    :crit,    2026-08-08T00:18, 2026-08-08T00:19
    new-4              :active,  2026-08-08T00:19, 2026-08-08T00:23
```

**关键约束：就绪探针（Readiness Probe）**
- 新 Pod 必须通过 Readiness Probe 才会被加入 Service 的 Endpoint 列表。
- 如果 Readiness 失败，即使新 Pod 已运行也不会接收流量。
- livenessProbe 用于检测进程是否存活并可能触发重启；readinessProbe 用于决定"这个 Pod 是否可以接受流量"。

### 蓝绿部署 vs Canary 发布

| 维度 | RollingUpdate | 蓝绿部署 | Canary 发布 |
|------|-------------|---------|------------|
| 资源消耗 | 低（增量替换） | 高（需要双倍实例） | 中（少量 Canary 实例） |
| 回滚速度 | 慢（需要滚动回去） | 秒级（切换流量即可） | 快（减少 Canary 流量比例） |
| 风险 | 低（渐进式） | 中高（全部切到新版本后才发现问题） | 最低（小部分用户先体验） |
| 复杂度 | 低（K8s 原生支持） | 中（需要外部 LB 管理） | 高（需要 Istio 或 Nginx 权重配置） |
| 适用团队 | 所有规模 | 大团队，有独立预发环境 | 有成熟 DevOps 能力的团队 |

Canary 发布的流量权重示例（基于 Istio VirtualService）：

```yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service-canary
spec:
  hosts: ["user-service.default.svc.cluster.local"]
  http:
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90     # 90% 流量走稳定版
    - destination:
        host: user-service
        subset: v2
      weight: 10     # 10% 流量进 Canary
```

### HPA — 水平自动扩缩容

HPA 基于指标监控动态调整 Pod 副本数：

```go
// HPA 核心指标类型
type MetricSourceType string

const (
    // CPU 利用率（容器内统计）
    ContainerCPU MetricSourceType = "ContainerResource"
    // 内存利用率
    ContainerMemory MetricSourceType = "ContainerResource"
    // Prometheus 自定义指标（外部指标）
    External MetricSourceType = "External"
    // Pods 级别指标（如并发连接数）
    Pods MetricSourceType = "Pods"
)
```

HPA 的计算公式：`targetReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))`

例如 CPU 目标 70%，当前平均 CPU 使用率 91%，当前 5 个副本：
`ceil(5 * 91 / 70) = ceil(6.5) = 7` → 扩容到 7 个副本。

> [!WARNING]
> HPA 不是实时的——它依赖 metrics-server 每 15~60 秒的采集间隔，扩容动作有分钟级延迟。对于需要即时响应的秒杀场景，应该提前设置 minReplicas >= 预期峰值的 80%。

### VPA — 垂直自动扩缩容

VPA 自动调整单个 Pod 的 CPU/Memory requests 和 limits：

| 模式 | 行为 | 说明 |
|------|-----|------|
| Offline | 只推荐不应用 | 人工审核后手动调整 |
| Initial | 在 Pod 创建时设置建议值 | 对新 Pod 生效 |
| Auto | 直接在运行时修改 Pod Spec | 会导致 Pod 被杀掉重建 |
| Recreate | 类似 Auto 但先删除旧的再创建 | 保证平滑过渡 |

VPA 的典型场景：微服务刚上线阶段，运维难以精确预估资源需求，可以让 VPA 学习实际使用模式后给出最优建议。

### Prometheus 指标采集链路

```mermaid
flowchart LR
    CLIENT_LIB["Client Library<br/>Go SDK / Java SDK / Python SDK"] -->|暴露 /metrics HTTP endpoint| APP_POD["App Pod"]
    APP_POD -->|HTTP GET /metrics| SCRAPE["Prometheus Scrape"]
    SCRAPE -->|写入| TSDB["TSDB: Thanos / VictoriaMetrics"]
    TSDB --> QUERY["PromQL Query Engine"]
    QUERY --> ALERT["Alert Rule Evaluation"]
    ALERT -->|告警触发| AM["Alertmanager"]
    AM -->|Webhook / 邮件 / 钉钉| NOTIFICATION["通知通道"]
```

**核心概念：**
- **Counter**：单调递增计数器（如总请求数），适合画 Rate 曲线。
- **Gauge**：可上可下的仪表值（如活跃连接数）。
- **Histogram**：分桶统计（如请求延迟分布），自动生成 count + sum + bucket。
- **Summary**：客户端计算分位数（P50/P99），服务器端不做计算但有额外开销。

> [!TIP]
> 面试常考点：为什么 Prometheus 用 Pull 而不是 Push？因为 Prometheus 作为中心化的采集器天然知道所有 target 的地址，Pull 模式下失联的 service 会自动被忽略（不再收到数据即标记为 down）。如果是 Push 模式（如 StatsD），挂了的服务会停止发送数据但采集器不知道它们已经不存在了。

### Grafana Dashboard 模板来源

Grafana 本身不提供指标，它只是可视化层。主要数据来源：

| 数据源 | 采集内容 | 典型用途 |
|--------|---------|---------|
| cAdvisor | 容器级别的 CPU/内存/网络/Disk I/O | 容器资源监控 |
| kube-state-metrics | Pod/Node/Deployment/RS 的状态元数据 | K8s 资源健康度 |
| node-exporter | 宿主机硬件指标（CPU、内存、磁盘、网络） | 节点层面性能分析 |
| cadvisor+prometheus | 组合 cAdvisor 和 Prometheus 的指标导出 | 综合容器监控面板 |

### 日志收集方案

```mermaid
graph LR
    PODS["所有 Pod 的 stdout/stderr"] --> FLUENTD["Fluentd / Filebeat DaemonSet"]
    FLUENTD -->|"Filesystem tail"| LOG_FILES["文件日志"]
    FLUENTD --> ES_ELB["Elasticsearch Cluster"]
    FLUENTD --> LOKI["Loki"]
    ES_ELB --> KIBANA["Kibana"]
    LOKI --> GRAFANA["Grafana Log Panel"]
```

- **ELK 栈（Elasticsearch + Logstash/Filebeat + Kibana）**：功能最强大，支持全文搜索、聚合分析，但存储成本高（JSON 结构化索引非常占空间）。
- **Loki（Grafana 生态）**：不建立全文索引，只索引 Labels。查询时用 label 过滤后再检索日志内容，存储成本极低。适合与 Grafana 深度集成的场景。

> [!NOTE]
> 最佳实践：日志采集应该在 Pod 层面做 sidecar 注入（而非直接写文件），这样即使 Pod 崩溃也能收集到最后一段输出。

## 代码示例

Go 中使用 Prometheus Client Library 暴露自定义指标：

```go
import "github.com/prometheus/client_golang/prometheus"

var requestDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "http_request_duration_seconds",
        Help:    "HTTP request duration in seconds",
        Buckets: prometheus.DefBuckets,
    },
    []string{"method", "path"},
)

func init() {
    prometheus.MustRegister(requestDuration)
}
```

## 实践场景

**秋招高频问题：**

- "HPA 能基于自定义业务指标扩缩容吗？" — 可以。通过 Custom Metrics API + adapter（如 prometheus-adapter），HPA 可以从 Prometheus 读取任意业务指标。例如根据 QPS、错误率、或者 Kafka 消费 lag 来触发扩缩容。
- "为什么蓝绿部署要双倍资源？" — 蓝绿的本质是同时保留新旧两套完整环境，用负载均衡器切换流量。这保证了随时可以秒级回滚，代价就是付费双倍的生产实例。
- "Prometheus 在什么场景下不适合？" — 海量短生命周期任务（如 Serverless 函数，每分钟创销毁成千上万 Pod）。Prometheus 的拉取模型无法跟得上如此动态的变化。此时更适合用 Pushgateway 或改为 push-based 的方案。

> [!WARNING]
> K8s 的 Ready/NotReady 状态切换不会自动通知 HPA——只有当 Pod 处于 Running + Ready 时才计入副本基数。所以在 deployment.yaml 里一定要配好 readiness probe，否则 HPA 会误判当前副本数从而做出错误的扩缩容决策。

## 关联笔记

- [[负载均衡算法]]
- [[限流熔断降级]]