259 lines
11 KiB
Markdown
259 lines
11 KiB
Markdown
|
---
|
|||
|
|
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 会误判当前副本数从而做出错误的扩缩容决策。
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
|
|||
|
|
- [[负载均衡算法]]
|
|||
|
|
- [[限流熔断降级]]
|