资源管理

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

概述 在云原生和容器化技术全面普及的今天，Linux cgroup（控制组）作为资源隔离和限制的内核基石，其重要性不言而喻。从 Docker 容器的内存限制到 Kubernetes Pod 的 CPU Requests/Limits，底层都依赖 cgroup 机制。然而，cgroup v1 的多层级架构、控制器行为不一致、线程模型混乱等历史包袱，让运维人员在生产环境中频频踩坑。 cgroup v2 作为对 v1 的彻底重构，采用单一层级树（unified hierarchy）架构，从根本上解决了 v1 的设计缺陷。自 Linux 4.5 引入以来，经过多个内核版本的迭代完善，cgroup v2 在 5.x 内核上已趋于成熟稳定。Ubuntu 22.04+、RHEL 9+、Debian 12+ 等主流发行版已默认使用 cgroup v2，Docker 和 Kubernetes 也已全面支持。 我将从 cgroup v2 的架构原理出发，深入讲解核心控制器的工作机制，结合 systemd 集成、Docker 容器限制、Kubernetes 场景等实战配置，最后覆盖 v1 到 v2 的迁移策略，帮助你在生产环境中驾驭这一关键技术。 cgroup v1 vs v2：为什么要重构 v1 的核心痛点 cgroup v1 在设计之初，每个控制器可以独立挂载在不同的层级树上。这带来了灵活性，但也埋下了大量隐患： 问题维度 v1 表现 影响 多层级架构 每个控制器可挂载在独立的层级树 进程在不同控制器中可属于不同 cgroup，管理视图割裂 线程模型 进程的线程可分散到不同 cgroup 资源计量混乱，难以准确归因 控制器间协调 各控制器独立运作 无法做跨资源的统一策略（如 CPU 和内存的联动） 委派安全 子 cgroup 委派权限粗粒度 容器逃逸风险，安全边界模糊 接口一致性 不同控制器文件命名和语义不统一 运维认知负担高，脚本维护困难 v2 的设计哲学 cgroup v2 的核心设计原则是单一层级树（unified hierarchy）：整个系统只有一棵 cgroup 树，所有控制器挂载在同一棵树上。一个进程只属于一个 cgroup，该 cgroup 上可以同时启用 CPU、内存、IO 等多个控制器。...

Requests 与 Limits 的语义 Kubernetes 中每个容器可以配置 CPU 和 Memory 的 requests 与 limits。很多开发者分不清二者的区别，导致 Pod 频繁被驱逐或 OOMKilled。 apiVersion: v1 kind: Pod metadata: name: api-server spec: containers: - name: app image: myapp:latest resources: requests: cpu: "250m" # 0.25 核 memory: "256Mi" limits: cpu: "500m" # 0.5 核 memory: "512Mi" 核心区别 维度 Requests Limits 作用阶段 调度时 运行时 含义 Pod 需要的最小资源保证 Pod 能使用的最大资源上限 调度器行为 调度器根据 requests 判断节点是否有足够资源 调度器不关心 limits 运行时行为 cgroups 中的保障份额 CPU 被节流（throttle），Memory 触发 OOMKilled 是否可超卖 可以（节点上所有 Pod 的 limits 之和可超过节点容量） 不建议超卖 Memory 简单理解：...