Kubernetes

概述 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....

概述 容量规划是 SRE 的核心职责之一。Google SRE Book 将容量规划视为"前瞻性工作"，强调基于数据预测而非凭经验猜测。一个没有容量规划的团队，要么在高峰期被流量打垮，要么在低谷期浪费大量资源成本。 从指标采集、数据建模、Kubernetes 弹性扩容配置、陷阱规避四个层面，详细梳理容量规划的工程实践。 关于容量规划的系统方法论，可参考 Google SRE Book - Capacity Planning 中关于容量规划与级联故障的讨论。 一、容量规划的核心思想：基于数据而非猜测 容量规划的三个层次 当前容量评估：系统现在能扛多少？水位是多少？ 容量趋势预测：按当前增长趋势，什么时候需要扩容？ 弹性伸缩策略：面对突发流量，如何自动应对？ 容量规划的前提：可观测性 没有度量就没有管理。容量规划的基础是完善的监控体系，需要持续采集以下指标： 指标类别 具体指标 采集工具 CPU 使用率、负载（1m/5m/15m） node_exporter / cAdvisor 内存 使用量、可用量、OOM 次数 node_exporter / cAdvisor 网络 入站/出站带宽、连接数、丢包率 node_exporter 磁盘 I/O IOPS、读写延迟、队列深度 node_exporter 应用层 QPS、延迟分布、错误率 Prometheus / 自定义指标 中间件 连接池使用率、队列长度、缓存命中率 Exporter / 自定义指标 容量水位定义 不是所有指标都同等重要。需要定义关键资源的容量水位： # 容量水位定义示例 capacity_thresholds: cpu: warning: 60% # 60% 开始关注 critical: 80% # 80% 需要扩容 limit: 90% # 90% 紧急扩容 memory: warning: 70% critical: 85% limit: 95% disk_io: warning: 60% critical: 80% limit: 90% connection: warning: 60% # 连接池使用率 critical: 80% limit: 90% 关键原则：水位线不是拍脑袋定的，而是基于压测数据和历史故障分析得出的。如果你的应用在 CPU 85% 时开始出现延迟劣化，那么 warning 就应该设在 70% 以下。...

排查路径 kubectl get pods → 看状态 kubectl describe pod → 看 Events kubectl logs → 看日志 常见 Pod 状态 状态 含义 常见原因 Pending 未调度 资源不足、调度约束 CrashLoopBackOff 崩溃重启 应用异常、配置错误 ImagePullBackOff 镜像拉取失败 镜像不存在、认证失败 OOMKilled 内存溢出 内存限制过低 CrashLoopBackOff 排查 最常见故障，排查步骤： # 查看上次崩溃日志 kubectl logs <pod> --previous # 查看退出码 kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}' 退出码含义： 137：OOMKilled → 增加 resources.limits.memory 1：应用错误 → 查应用日志 126/127：命令不存在或权限问题 ImagePullBackOff 排查 kubectl describe pod <pod> | grep -A5 Events 常见原因：镜像名拼写错误、仓库需认证、网络不通。...

概述 Kubernetes 默认配置的安全性可以用一个词概括：开放。默认 ServiceAccount 拥有集群内几乎所有 API 的访问权限（取决于版本和 PSP 配置），Pod 以 root 用户运行，容器可以挂载宿主机文件系统，网络全通。这种"默认开放"的设计降低了上手门槛，但在生产环境中是巨大的安全隐患。 从 RBAC 权限模型、ServiceAccount 管理、Pod 安全标准、SecurityContext、网络策略到审计日志，详细梳理 K8s 安全加固的实践方法。 本文基于 Kubernetes v1.30。参考 Kubernetes 安全文档 RBAC 权限模型 RBAC 四个核心对象 对象 作用域 功能 Role 命名空间 定义命名空间内的权限 ClusterRole 集群 定义集群范围或命名空间内的权限 RoleBinding 命名空间 将 Role/ClusterRole 绑定到用户/组/SA ClusterRoleBinding 集群 将 ClusterRole 绑定到用户/组/SA 核心关系： 用户/组/ServiceAccount ──Binding──→ Role/ClusterRole ──包含──→ 权限规则 Role 与 ClusterRole # Role：命名空间级别的权限，只影响指定 namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: pod-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["configmaps"] verbs: ["get"] resourceNames: ["app-config"] # 限制只能访问特定 ConfigMap # ClusterRole：集群级别的权限 apiVersion: rbac....