Kubernetes

变更管理在 SRE 中的定位 Google SRE 总结的一条铁律：大约 70% 的线上故障由变更直接引发。无论是代码部署、配置修改、基础设施调整还是依赖升级，每一次变更都在向系统注入不确定性。因此，变更管理不是流程上的繁文缛节，而是 SRE 可靠性工程的第一道防线。 变更管理的核心目标可以归纳为三点： 降低爆炸半径——变更出了问题，影响面应尽可能小。 缩短发现问题的时间——变更后若出现异常，必须能在分钟级甚至秒级感知。 具备快速回滚能力——发现问题后，能在最短时间内恢复到上一个已知正常状态。 实现这三个目标的关键技术手段就是灰度发布与快速回滚。下面逐一展开。 金丝雀发布原理与实现 核心思想 “金丝雀"一词源自矿工带金丝雀下井探测有毒气体的做法。在软件发布中，金丝雀发布指的是：先将新版本部署到极小比例的实例上，引入少量真实流量进行验证，确认无异常后再逐步扩大流量比例，直至全量切换。 与全量发布相比，金丝雀发布的本质区别在于引入了流量比例控制和指标门控两个机制，使发布过程变成一个可控的、可观测的渐进过程。 流量比例控制 典型的金丝雀发布流量推进序列： 5% → 10% → 25% → 50% → 100% 每个阶段之间设置观察窗口（如 5-10 分钟），期间持续采集关键指标。只有当指标满足预设的健康标准时，才推进到下一阶段；否则自动暂停甚至回滚。 指标门控 指标门控是金丝雀发布的"大脑”。通常关注以下几类指标： 指标类别 示例 门控逻辑 错误率 HTTP 5xx 比例 金丝雀错误率 > 基线 1.5x → 自动回滚 延迟 P99 / P95 响应时间 金丝雀 P99 > 基线 + 50ms → 暂停推进 业务指标 下单成功率、支付成功率 成功率下降 > 2% → 自动回滚 资源指标 CPU、内存、连接数 资源使用率异常飙升 → 告警暂停 关键原则：门控指标必须从用户视角出发，而非仅看基础设施指标。一个 CPU 正常但 P99 翻倍的系统，仍然应该触发回滚。...

为什么需要 Helm 裸用 kubectl apply -f 管理 K8s 应用，在规模小时够用，但随着环境增多（dev/staging/prod）和服务增长，问题立刻暴露： 配置硬编码：每个环境一份 YAML，镜像 tag、副本数、资源限制全写死，改一个值要改十个文件 无版本管理：升级回滚靠手动记录，不知道上次部署了什么版本 无法复用：部署 Redis 和部署 MySQL 写两套完全不同的 YAML，无法模板化 Helm 是 K8s 的包管理器，把一组 K8s 资源打包成 Chart，通过 values.yaml 参数化配置，实现一份模板、多环境部署、版本化升级和一键回滚。 本文参考 Helm 官方文档 Helm Chart 目录结构 my-web-app/ ├── Chart.yaml # Chart 元信息（名称、版本、描述） ├── values.yaml # 默认配置值 ├── values-prod.yaml # 生产环境覆盖配置 ├── charts/ # 依赖的子 Chart ├── templates/ # K8s 资源模板 │ ├── _helpers.tpl # 命名模板（可复用的模板片段） │ ├── deployment.yaml # Deployment │ ├── service....

可靠性工程：不只是"不出故障" 可靠性工程的目标不是追求零故障——那既不现实也不经济。真正的目标是：在故障不可避免的前提下，让系统具备快速发现、自动恢复、持续学习的能力。 Google SRE 提出的核心公式： MTTR << MTBF / (MTBF + MTTR) × (1 - SLO) 这个公式揭示了一个关键事实：当故障间隔（MTBF）远大于修复时间（MTTR）时，系统的可用性自然趋近于 SLO 目标。因此，可靠性工程的发力方向是双重的——延长无故障时间（提升 MTBF）和缩短故障恢复时间（降低 MTTR）。 可靠性层级模型 参考 CMMI 能力成熟度模型的思想，可靠性工程同样存在层级递进关系。从低到高分为五个层级： 层级 特征 典型表现 L1 被动响应 故障发生后人工处理 告警轰炸 → 人工排查 → 手动恢复 L2 监控覆盖 关键指标可观测 仪表盘完备，告警有阈值，但恢复仍靠人 L3 自动化恢复 常见故障自动处理 健康检查自动重启、HPA 自动扩容 L4 主动预防 提前发现风险 压测、容量规划、混沌工程主动注入故障 L5 自愈系统 闭环自适应 故障自动感知 → 诊断 → 恢复 → 学习 大部分团队的真实水平在 L2 到 L3 之间。从 L3 到 L4 的跨越是最关键的——它意味着从"等故障来"转变为"主动找故障"。L5 自愈是理想态，也是持续演进的方向。 层级跃迁的关键 L1 → L2：建设可观测性体系（指标、日志、链路追踪）。 L2 → L3：引入自动化恢复机制（Kubernetes 健康检查、HPA、自动故障转移）。 L3 → L4：引入混沌工程，主动验证系统的弹性。 L4 → L5：建设自愈闭环，将人工经验沉淀为自动化策略。 每一层级的跨越都需要对应的技术投入和组织能力建设，不能跳级。...

概述 Kubernetes 每年发布三个版本，每个版本的支持周期约为 14 个月。这意味着生产集群大约每 6-12 个月就需要进行一次版本升级。集群升级是 K8s 运维中最敏感的操作之一——既要紧跟社区获得安全补丁和新特性，又要确保升级过程中业务零中断、零故障。 我将从版本策略制定、升级前准备、升级执行流程、蓝绿/金丝雀策略、回滚机制到生产环境实战，系统性地讲解 Kubernetes 集群升级的完整方法论。 一、Kubernetes 版本策略 1.1 版本发布节奏 Kubernetes 每年发布三个小版本（约每 15 周一个），版本号的命名规则经历了从北欧神话地名到主题词的演变： 版本 代号 发布时间（约） 关键特性 v1.30 Uwubernetes 2024-04 结构化认证配置 v1.31 Ichigo 2024-08 AppArmor GA、动态资源分配 v1.32 Penelope 2024-12 用户命名空间 Beta v1.33 Patricia 2025-04 Sidecar Containers GA v1.34 衔尾蛇 2025-08 Kubelet 凭证提供者 v1.35 Timbernetes 2025-12 Pod 资源就地更新 GA、Gang 调度 v1.36 Haru 2026-04 User Namespaces GA、CEL 准入策略 v1.37 — 2026-08（预期） — 参考：Kubernetes Release History...

概述 传统的可靠性保障思路是"尽量不出故障"——加监控、加告警、加冗余。但这种被动防御有一个根本缺陷：你不知道系统在故障发生时的真实表现，直到故障真正发生。 混沌工程反其道而行之：主动、可控地注入故障，在故障变成事故之前发现系统的弱点。 它不是搞破坏，而是一种科学的实验方法——提出假设（“系统应该能承受某节点故障”），设计实验（杀掉一个节点），验证假设（服务是否仍然正常），发现弱点（如果服务异常了）。 Netflix 的 Chaos Monkey 开创了这一领域，如今混沌工程已经成为 SRE 体系的重要组成部分。从原理、实验设计、爆炸半径控制、Kubernetes 实战到常态化实践，详细梳理如何把混沌工程从"概念"落地为"日常实践"。 关于混沌工程的原则，可参考 Principles of Chaos Engineering 和 Chaos Engineering Book。 一、混沌工程的原理 核心思想 混沌工程的核心思想是： 在正常流量期间，通过有意注入故障来验证系统的弹性，从而在故障变成事故之前发现并修复弱点。 这与传统的测试有本质区别： 维度 传统测试 混沌工程 目标 验证"代码是否正确" 验证"系统是否能承受故障" 环境 测试环境 生产环境（或接近生产的预发环境） 故障来源 预定义的测试用例 真实模拟的故障场景 发现时机 开发阶段 运行阶段 关注点 功能正确性 系统弹性 为什么要在生产环境做 混沌工程最反直觉的一点是"在生产环境注入故障"。为什么不 在测试环境做？ 测试环境无法复制生产的复杂性：生产环境的流量模式、数据量、网络拓扑、依赖关系与测试环境完全不同 测试环境的故障不会造成真实影响：没有压力，就不会暴露在压力下才出现的问题 只有在生产环境才能验证完整的恢复链路：告警是否触发？On-Call 是否响应？自动恢复是否生效？ 当然，直接在生产环境做混沌实验需要严格的控制——这正是"爆炸半径控制"要解决的问题。 混沌工程的四条原则 根据 Principles of Chaos Engineering，混沌工程遵循以下原则： 围绕稳态行为定义"正常"：先定义系统的正常状态（SLI/SLO），再注入故障看是否偏离 假设稳态在对照组和实验组中都保持：一部分流量/节点不注入故障（对照组），一部分注入（实验组），对比差异 在真实环境中实验：生产环境或接近生产的环境 自动化持续运行：不是一次性实验，而是持续自动化运行 混沌工程的收益 chaos_engineering_benefits: direct_benefits: - "提前发现系统弱点和单点故障" - "验证告警和恢复机制是否有效" - "提升团队对故障的响应能力" - "验证架构设计假设是否成立" indirect_benefits: - "建立团队对系统弹性的信心" - "驱动架构改进（从'看起来能扛'到'验证过能扛'）" - "减少真实故障的 MTTR（因为已经演练过类似场景）" - "培养'故障不可避免'的工程文化" 二、从 Chaos Monkey 说起 Netflix 的混沌工程演进 Netflix 是混沌工程的开创者，其演进路径值得参考：...

概述 Kubernetes 已成为云原生应用的标准运行平台，但其弹性与灵活性也带来了成本管理的巨大挑战。根据 Flexera 2024 云状态报告，企业平均有 32% 的云支出属于浪费，而 Kubernetes 集群的资源浪费尤为突出——一个缺乏治理的 K8s 集群，资源利用率往往低于 30%。 Kubernetes 成本优化不是一次性的配置调整，而是一个从资源治理、自动扩缩容、实例类型选择到 FinOps 文化建设的系统工程。从实际生产经验出发，给出一套可落地的 K8s 成本优化方法论。 Kubernetes 成本浪费的根源 资源配置的三大陷阱 在深入优化之前，必须先理解成本从哪里流失。K8s 的资源浪费主要来自三个层面： 浪费来源 表现 根因 影响占比 Requests 过高 节点 CPU/内存利用率低 开发按峰值而非实际需求配置 40-50% 无自动扩缩容 低峰期节点空跑 缺少 HPA/VPA/Cluster Autoscaler 20-30% 实例类型不当 全部使用按需实例 未利用 Spot/预留实例 15-25% 镜像冗余 大镜像拖慢部署、占用存储 缺少镜像优化和多阶段构建 5-10% 陷阱一：用峰值配置 Requests 这是最常见的浪费。开发团队为了保证服务"不出事"，倾向于把 Requests 设得很高。一个实际只需 200m CPU 的服务，Requests 被设为 1000m，导致节点只能调度少量 Pod，大量 CPU 资源闲置。 # 典型的过度配置 apiVersion: apps/v1 kind: Deployment metadata: name: api-service spec: template: spec: containers: - name: api resources: requests: cpu: "2000m" # 实际使用 200m，浪费 90% memory: "4Gi" # 实际使用 512Mi，浪费 87% limits: cpu: "4000m" memory: "8Gi" 陷阱二：缺少 LimitRange 和 ResourceQuota...

概述 当你的业务规模增长到单集群无法承载时，多集群就成为必然选择。可能的原因包括：单集群节点上限（5000 节点）、多地域部署、混合云策略、故障隔离、合规要求。但多集群带来的管理复杂度是指数级增长——应用如何跨集群部署、服务如何跨集群发现、配置如何同步、故障如何切换。 本文逐步梳理多集群的架构模式、主流管理工具对比，以及跨集群服务发现、CI/CD、容灾切换的实践方案。 本文基于 Kubernetes v1.30。多集群管理领域仍在快速演进，部分工具的成熟度需持续关注。 为什么需要多集群 单集群的瓶颈 瓶颈 说明 规模上限 K8s 单集群推荐上限 5000 节点、15 万 Pod、30 万容器 故障域 单集群 etcd 故障影响所有业务 升级风险 集群升级可能影响所有业务 多租户隔离 软隔离不如硬隔离 地域延迟 跨地域不能用一个集群 合规要求 数据不能跨地域/跨境 多集群的典型场景 场景 架构 目标 多地域容灾 每地域一个集群，DNS 全局负载均衡 RTO < 5min 混合云 云上 + 自建机房 弹性 + 合规 开发/测试/生产隔离 每环境一个集群 安全隔离 多租户硬隔离 每租户独立集群 安全合规 边缘计算 中心集群 + 边缘集群 低延迟 多集群架构模式 模式一：Hub-Spoke（中心辐射） ┌─────────┐ │ Hub │ ← 管理集群 │ Cluster │ └────┬────┘ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Spoke1│ │Spoke2│ │Spoke3│ ← 工作集群 └──────┘ └──────┘ └──────┘ 中心集群负责管理配置、分发应用、收集状态。工作集群只运行业务负载。这是最常见的多集群管理模式。...

概述 Kubernetes 集群的灾难恢复是运维中最容易被忽视的领域——直到灾难发生。etcd 损坏导致整个集群不可用、PV 数据误删无法恢复、集群升级失败无法回滚……这些场景没有备份就是灾难，有备份就是一次常规恢复。 详细梳理 K8s 灾难恢复的三个层次：etcd 备份恢复（集群元数据）、Velero 备份（K8s 资源）、PV 数据备份（持久化数据），以及跨集群恢复和恢复演练的实践。 本文基于 Kubernetes v1.30 和 Velero v1.14。参考 Kubernetes 灾难恢复文档 灾备基础概念 RTO 与 RPO 指标 全称 含义 目标 RTO Recovery Time Objective 恢复时间目标（多快恢复） < 30min RPO Recovery Point Objective 数据丢失目标（丢多少数据） < 5min 故障发生 恢复完成 |◄────── RTO ──────────►| | | |◄── RPO ──►| | | | | 最后一次备份 故障点 恢复点 备份层次 层次 备份对象 工具 RPO 恢复粒度 etcd 集群所有元数据 etcdctl snapshot 分钟级 整个集群 K8s 资源 Deployment/Service/ConfigMap 等 Velero 分钟级 命名空间/资源 PV 数据 持久化卷数据 Velero/Restic/Kasten 小时级 单个 PV 应用数据 数据库/对象存储 应用自身机制 秒级 应用级 灾备分类 类型 说明 适用场景 备份恢复 定期备份，故障时恢复 通用 活跃-备用 备集群 standby，故障切换 核心业务 活跃-活跃 多集群同时服务，故障切流 全球业务 混沌演练 模拟故障验证恢复能力 灾备成熟度 etcd 备份与恢复 为什么 etcd 备份最重要 etcd 是 K8s 的"大脑"——所有集群状态（Pod、Service、ConfigMap、Secret、Deployment 等）都存储在 etcd 中。etcd 损坏等于整个集群的数据丢失。没有 etcd 备份，其他备份都无意义。...

概述 自动扩缩容是 Kubernetes 最吸引人的能力之一——流量来了自动扩容，流量走了自动缩容，既保证服务质量又控制成本。但"自动"不等于"无脑"，配置不当的扩缩容可能导致：扩容不及时造成服务降级、缩容太激进中断长连接、抖动扩缩导致资源浪费。 K8s 的自动扩缩容体系包含三个层次： 层次 组件 扩缩维度 触发条件 Pod 水平扩缩 HPA Pod 副本数 CPU/内存/自定义指标 Pod 垂直扩缩 VPA Pod 资源配额 CPU/内存历史用量 节点扩缩 Cluster Autoscaler 节点数 Pending Pod 事件驱动 KEDA Pod 副本数 事件源（Kafka/Redis/…） 本文基于 Kubernetes v1.30。参考 Kubernetes 自动扩缩文档 HPA：水平 Pod 自动扩缩容 工作原理 HPA（Horizontal Pod Autoscaler）是一个控制循环，默认每 15 秒执行一次： 1. 从指标 API 获取 Pod 的当前指标值（CPU/内存/自定义） 2. 计算期望副本数 = ceil(当前副本数 * (当前指标值 / 目标指标值)) 3. 与当前副本数比较，决定扩容或缩容 4. 调用 Deployment/ReplicaSet 的 Scale API 修改副本数 核心公式：...

概述 Kubernetes Operator 是将人类运维知识编码为软件的范式。它通过 CRD（Custom Resource Definition）扩展 K8s API，通过 Controller 实现自动化运维逻辑。数据库集群管理、消息队列运维、证书轮转……这些原本需要 SRE 手动操作的工作，Operator 可以自动完成。 Operator 的核心思想是声明式 + 控制循环：用户声明期望状态（如"3 个 Redis 副本"），Controller 持续调整实际状态以趋近期望状态。理解这一模式，不仅能开发 Operator，更能深入理解 K8s 本身的设计哲学。 本文基于 Kubernetes v1.30、operator-sdk v1.37、kubebuilder v4.0。参考 Operator 模式文档 Operator 核心概念 CRD 与 Controller 的关系 用户创建 CR (Custom Resource) ──→ API Server 存储 ──→ Controller Watch ↓ Reconcile 循环 ↓ 比较期望状态 vs 实际状态 ↓ 创建/更新/删除资源 ↓ 更新 CR Status 声明式 vs 命令式 模式 示例 特点 命令式 “创建 3 个 Pod” 执行一次就结束，不关心后续状态 声明式 “保持 3 个 Pod 运行” 持续监控，自动修复偏差 Operator 是声明式的——用户声明 spec....