K8s 资源限制计算器 - 推荐 requests/limits

核心概念

Requests

Requests 是 Kubernetes 中为容器指定的最低资源保障值。当调度器将 Pod 分配到节点时，会确保节点上所有 Pod 的 requests 总量不超过节点的可分配资源。例如，如果一个 Pod 的 CPU requests 设置为 500m（即 0.5 核），那么调度器会保证该 Pod 至少能获得 0.5 核的 CPU 时间。Requests 的值不会在运行时限制容器的资源使用，它仅作为调度依据和资源预留基准。合理设置 requests 是确保应用获得稳定资源保障的基础。

Limits

Limits 是 Kubernetes 中为容器指定的资源使用上限。当容器的实际资源使用量超过 limits 时，会触发相应的限制机制：CPU 超过 limits 时会被节流（throttling），即内核会限制容器的 CPU 时间片分配；内存超过 limits 时会被 OOM Killer 终止（OOMKilled），容器会收到 SIGKILL 信号并被强制重启。Limits 是防止应用失控影响其他服务的重要保护机制，但设置不当也会导致服务中断。

Requests vs Limits 的核心区别

Requests 是"保底值"，保证容器至少能获得这么多资源；Limits 是"上限值"，限制容器最多只能使用这么多资源。当节点资源紧张时，requests 决定了 Pod 的调度优先级和资源分配下限；limits 则在运行时生效，防止资源过度使用。requests 和 limits 之间的差值区间允许应用在资源充裕时获得额外资源，但在资源紧张时会被限制在 requests 水平。

QoS 等级

Kubernetes 根据 Pod 中所有容器的 requests 和 limits 配置自动划分 QoS（Quality of Service）等级：Guaranteed——所有容器的 CPU 和内存 requests 均等于对应的 limits，提供最高级别的资源保障；Burstable——至少有一个容器的 requests 小于 limits，在资源紧张时可能被回收；BestEffort——所有容器均未设置 requests 和 limits，在资源最紧张时最先被终止。QoS 等级决定了 Pod 在资源压力下的优先级和被驱逐的顺序。

CPU Throttling（CPU 节流）

CPU Throttling 是 Linux CFS（Completely Fair Scheduler）调度器在容器 CPU 使用量超过 limits 时采取的限制措施。当容器在某个调度周期内使用的 CPU 时间超过其分配的配额时，内核会暂停该容器的 CPU 执行，直到下一个调度周期开始。这会导致应用响应延迟增加，尤其对延迟敏感的在线服务影响显著。避免 CPU throttling 的关键是合理设置 CPU limits，或使用 CPU 突发机制。

OOMKilled

OOMKilled 是 Linux OOM Killer 在容器内存使用超过 limits 时采取的终止操作。内核会向容器进程发送 SIGKILL 信号，强制终止容器内的所有进程。Kubernetes 会根据 Pod 的重启策略（RestartPolicy）决定是否重启被 OOMKilled 的容器。频繁的 OOMKilled 不仅影响服务可用性，还可能导致数据丢失。避免 OOMKilled 的关键是准确估算应用的内存使用量并设置合理的内存 limits。

Workload Types（工作负载类型）

在本工具中，工作负载类型是指 Kubernetes 中常见的八种应用模式：Web 应用（提供页面渲染和静态资源）、API 服务（提供 RESTful 或 gRPC 接口）、数据库（MySQL/PostgreSQL/MongoDB 等）、缓存服务（Redis/Memcached 等）、消息队列（RabbitMQ/Kafka 等）、批处理任务（定时任务或一次性计算任务）、AI/ML 推理（模型推理和预测服务）、静态资源服务（CDN 源站或文件服务器）。不同类型具有不同的资源使用特征，需要差异化的配置策略。

Steady-State Memory（稳态内存）

稳态内存是指应用在正常负载下持续稳定占用的内存大小，通常在应用启动并完成预热后趋于稳定。它不同于峰值内存——峰值内存是应用在极端负载下可能达到的最高内存使用量。稳态内存是计算 memory requests 的重要依据，而峰值内存则影响 memory limits 的设定。在 Kubernetes 中，memory requests 通常设置为稳态内存的 1.2-1.5 倍，memory limits 设置为稳态内存的 1.5-2.0 倍。

QPS（Queries Per Second）

QPS 是每秒查询数的缩写，是衡量应用负载压力的核心指标。在 Web 和 API 服务场景中，QPS 直接反映了应用需要处理的并发请求量。QPS 与 CPU 资源需求呈正相关——更高的 QPS 通常意味着需要更多的 CPU 核心来处理请求。本工具将 QPS 作为 CPU 资源计算的关键输入，结合工作负载类型特征生成合理的 CPU 配置建议。

CPU Burst（CPU 突发）

CPU Burst 是指容器在短时间内使用超过其 CPU limits 配置的机制。在 Kubernetes 1.22+ 中，可以通过 CPUCFSQuotaPeriod 和 CPU CFS Quota 相关参数实现突发行为。启用 CPU 突发后，当容器在某个调度周期内未用完其 CPU 配额时，剩余配额会累积到后续周期，允许容器在需要时短暂使用更多 CPU。这对于有突发流量特征的应用（如定时任务、促销活动）非常有用。

Deployment YAML

Deployment YAML 是 Kubernetes Deployment 资源的声明式配置文件，采用 YAML 格式编写。Deployment 是 Kubernetes 中最常用的无状态应用管理资源，支持滚动更新、回滚和副本数管理。在 Deployment YAML 中，resources 字段用于指定每个容器的 CPU 和内存 requests/limits。本工具生成的 YAML 片段即为 Deployment 配置中 resources 部分的内容，可直接嵌入到完整的 Deployment 配置中使用。

Mi vs M vs Gi vs G

这些是 Kubernetes 中资源数量的单位后缀。Mi（Mebibyte）= 1024 KiB = 1048576 字节，Gi（Gibibyte）= 1024 MiB；M（Megabyte）= 1000 KB = 1000000 字节，G（Gigabyte）= 1000 MB。在 Kubernetes 中，内存通常使用二进制单位（Mi/Gi），而 CPU 使用小数或毫核（如 0.5、500m）。m 表示毫核，1000m = 1 核 CPU。正确理解这些单位对于配置资源配额至关重要。