IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个平台持续发布Zui新文章，助你少走弯路。

在前面的文章中，我们为 Redis 配置了持久化存储，为 Flask 配置了健康检查和滚动geng新。我们的应用越来越“生产化”了。但还有一个关键问题没有解决：Pod 应该占用多少 CPU 和内存？Ru果某个 Pod 突然内存泄漏，会不会拖垮同一台节点上的其他 Pod？

这个问题不那么突出——一台机器上跑的服务数量有限，资源竞争不激烈。但在 K8s 集群中，一台节点可Neng同时运行几十个 Pod，资源的合理分配直接决定了集群的稳定性和调度效率。

Kubernetes 提供了两个核心参数来管理容器资源：Requests和 Limits。它们共同决定了 Pod 会被调度到哪个节点、运行时的资源使用上限，以及在资源紧张时 Pod 的“优先级”。今天我们就来彻底搞懂这套机制，并把它应用到贯穿案例的 Flask + Redis 应用中。

Requests 和 Limits 分别回答了两个不同的问题：

Requests“调度时我需要至少多少资源？” Scheduler 根据 Requests 为 Pod 选择节点——节点上所有 Pod 的 Requests 总和不Neng超过节点的总资源。这是调度的“准入线”。

Limits“运行时我Zui多Neng用多少资源？” 容器运行时的资源使用不Neng超过 Limits。CPU 超限会被限流，内存超限会被杀掉。这是运行的“天花板”。

用一个日常类比来理解：Requests 是你在餐厅预订的座位数量——餐厅只有在你预订的座位有空时才让你进。Limits 是你Neng点的菜的上限——你不Neng超过这个上限消费。你Ke以点菜少于预订座位数，但不Neng超过菜的上限。

K8s 主要管理两种资源：

CPU以“核”为单位。 CPU = 1 个物理/虚拟核心。Ke以用小数表示，如 0.5250m。m 后缀表示千分之一核——100m 是 0.1 核。这是 CPU Zui常用的计量单位。

内存以字节为单位。常见单位：MiGi。注意 M和 Mi 的区别——K8s 使用二进制单位 Mi/Gi。

  先说说Requests和Limits的区别吧！

Requests是基础,Limits是上限,两者共同决定Pod的命运!

为啥百度不收录我的文章？说实话,这个问题啊,哈哈,咱就是说,hen多因素吧,你得kankan是不是关键词密度不够,或者服务器响应太慢了...你得优化优化喽！

K8s 根据容器的 Requests 和 Limits 配置，自动为 Pod 分配一个 QoS等级,这个等级hen重要,它直接影响到当节点资源紧张时,哪些Pod会优先被“请出去”。

简单来说,QoS就是K8s对Pod的"VIP等级"划分!   三种 QoS 等级PK大法

containers: - name: besteffort-demo image: alpine command:

requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "256Mi"

Guaranteed:Requests = Limits → QoS = Guaranteed,不多不少刚刚好!

containers: - name: guaranteed-demo image: alpine command: resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "128Mi" cpu: "100m"

apiVersion: v1kind: LimitRangemetadata: name: default-limitsspec: limits: - type: Container defaultRequest:... max:... min:... apiVersion: v1kind: ResourceQuotametadata: name: team-quotaspec: hard: requests.cpu:"4" requests.memory:"20Gi" limits.cpu:"8" limits.memory:"40Gi"

ResourceQuota 就像团队预算,你得控制整个命名空间的资源使用总量,不然就GG！

想了解geng多还Ke以去各个平台搜索「IT策士」，一起升级 IT 思维 ！