企业官网建设流程全解析

半夜两点收到告警，节点CPU跑到100%持续了十五分钟，紧跟着内存告警，两个Pod被OOMKilled。我登录集群一看，同一个节点上堆了十几个没有设置任何资源限制的Pod，另一个节点却闲得发呆。这种“旱的旱死涝的涝死”，是我接手Kubernetes之后遇到最多的问题。后来我把Pod的requests、limits、QoS、ResourceQuota完整梳理了一遍，资源争抢和浪费才算真正被堵住。这篇文章不是单纯列举API参数，而是从实际故障出发，把Pod资源管理的设计逻辑、配置方法和排查套路一次性讲透，适合正在管理K8s集群的运维、开发和SRE同学参考。

1. 先理解Pod资源管理到底解决什么问题

1.1 为什么CPU和内存会成为事故导火索

Kubernetes里的Pod是最小的调度单位，容器只在Pod内部运行。如果你不去声明这个Pod“至少要多少资源、最多能用多少资源”，调度器就只能靠猜，运行时也只能靠底层Linux cgroup的默认行为兜底。兜不住的后果很典型：某个业务突发流量上来，容器疯狂消耗CPU，把节点上其他容器的CPU时间挤占掉；或者某个容器的内存像漏水一样上涨，触发了系统OOM，结果被杀的往往是别的无辜进程。

我遇到过最典型的场景是：业务方说“我只要一个Pod，镜像不大，启动很快”，然后直接kubectl run，什么资源参数都没写。开发本地测试没问题，一上生产，多个服务挤在一个节点上，监控里CPU使用率变成锯齿状，接口耗时忽高忽低。原因很简单，一个Pod吃满CPU之后，Linux CFS调度器是按权重分配CPU时间片的，没设置CPU limits的容器权重很高，大量请求进来会抢占其他容器的CPU份额。这不是Pod“坏”了，而是资源边界没有定义好。

资源管理的本质是给每个Pod划定边界：调度时按声明值“预留”资源，运行时按限制值“约束”资源。边界清晰了，节点上的所有Pod才不会互相争抢，也不会因为某个Pod的异常把所有资源吃掉。

1.2 requests和limits：一对容易混淆的数字

Kubernetes里最核心的两个参数是requests和limits。这两个词看起来简单，但很多人用反了。

• requests是给调度器看的，表示这个Pod启动时“至少需要预留多少资源”。调度器选择一个节点时，会看节点上所有Pod的requests总和，加上新Pod的requests，不能超过节点的可分配资源。可以理解成订酒店时先付定金，把房间锁住。
• limits是给kubelet和cgroup看的，表示这个Pod最多能使用多少资源。超过CPU limit会发生CPU Throttling，超过内存limit会被OOMKilled。这相当于酒店房间的入住上限，超过会被赶出去。

这里有个关键点：CPU是可压缩资源，内存是不可压缩资源。CPU超限的表现是变慢，进程还在；内存超限就危险了，直接杀掉容器。所以内存的limits一定要重点盯。

四个组合逻辑如下：

生产环境里，我建议对核心业务把requests和limits设置成相同值，也就是Guaranteed QoS。这样调度器能精确知道每个Pod的资源占用，运行时也不会因为某个Pod超过requests但低于limits造成节点超卖失控。如果觉得100%限制太浪费，可以在非核心服务上放宽limits，比如requests给200m CPU，limits给500m，让它可以短暂突发，但也要承担资源紧张时被驱逐的风险。

2. 从调度到运行：避免“争抢”的机制与参数

2.1 QoS等级：资源紧张时谁先出局

Kubernetes会自动根据Pod的requests和limits设置，把Pod划分到三个QoS等级：Guaranteed、Burstable、BestEffort。这个等级不是我之前理解的“服务优先级”，而是节点资源不足时，kubelet选择驱逐哪些Pod的依据。

当节点内存使用超过阈值，kubelet会开始驱逐Pod，顺序是：BestEffort优先驱逐，其次是Burstable中超过requests的Pod，最后才动Guaranteed Pod。只有在极端情况下，比如Guaranteed Pod自己也超过limits，才会被杀掉。这个设计很符合直觉：没有声明资源需求的Pod，就要承担资源不确定性带来的后果。

所以你的关键业务一定要做成Guaranteed。哪怕你只把内存和CPU的requests与limits设置成一样的值，就能享受这个保护。不要迷信PriorityClass，QoS等级是资源层面的第一道保险，两者不是一回事。

还有一种情况是节点出现磁盘压力或文件系统压力，QoS驱逐顺序也是类似的。BestEffort Pod最容易因为ephemeral-storage超限被清理。如果你有一些离线任务Pod，能容忍不定时中断，那可以故意不做资源限制，让它变成BestEffort，这样节点空间紧张时会被优先腾退，反而保护了在线业务。这个用法可以作为一种“可牺牲队列”的设计思路。

2.2 调度器眼里不是“实际用量”而是“声明的requests”

调度器判断一个Pod能不能落到某个节点，用的不是节点当前的实际内存/CPU使用率，而是所有已分配Pod的requests总和。这个设计经常让新手困惑：明明节点监控显示内存用了不到50%，但新Pod就是调度不上去，事件里写Insufficient memory。

原因可能是节点上已有的多个Pod虽然实际使用量低，但它们的requests总和已经把节点内存接近填满了。比如有10个Pod，每个都声明了memory: 1Gi，但实际只用了100Mi，节点总内存是16Gi，那么新Pod想申请2Gi内存，调度器一算，已有requests总和10Gi + 新Pod 2Gi = 12Gi，看起来够，但还要考虑系统预留和驱逐阈值，剩下的额度可能就不够了。反之，如果这些Pod都没写requests，调度器会把节点看作非常空闲，导致大量Pod打上去，运行后实际使用暴涨，引发争抢。

理解这一点之后，你就会明白：合理设置requests，不只是在保护Pod自身，也是在帮助调度器做出正确决策。写requests时不要拍脑袋，要参考压测和监控数据的P95值。比如CPU平均使用300m，峰值500m，那么requests给500m、limits给1比较好，既有调度保证，也能容忍突发。

还有一点值得注意：调度器只处理节点维度，同一个节点上多个Pod之间如果存在亲和性、污点、拓扑分布约束，则还需要满足这些条件。资源充足不代表一定能调度成功，但资源不充足一定调度失败。

2.3 抢占机制与“no preemption victims found”

当集群里所有节点都无法容纳一个新的高优先级Pod时，调度器会尝试抢占。抢占的意思是：从低优先级Pod所在的节点上，挑一些Pod驱逐，腾出地方给高优先级Pod。这是Kubernetes默认开启的调度行为，前提是被抢占的Pod优先级低于当前Pod，且不会被PodDisruptionBudget（PDB）阻止。

我之前在处理一个线上问题时，看到Pod一直Pending，事件里出现no preemption victims found for incoming pod。这个报错字面意思是“没有找到可以被抢占的Pod”。说实话，很多人看到这个就慌了，以为是抢占功能坏了。其实不是。

出现这个报错一般有三种常见情况。第一种，集群里确实没有低优先级Pod，全都是相同优先级或者更高优先级的Pod，调度器不能抢占“同级别”的Pod。第二种，虽然存在低优先级Pod，但它们都受到PDB保护，无法被安全驱逐。第三种，低优先级Pod所在节点满足不了高优先级Pod的亲和性或污点容忍要求，即使把低优先级Pod赶走，高优先级Pod也进不去那个节点。这种情况下，调度器计算完会放弃，事件里就会留下这条消息。

要解决这类问题，不能只盯着抢占配置。正确思路是：看当前集群剩余资源，看低优先级Pod的分布，看PDB策略。如果集群真的没有资源，加节点或让业务缩容才是根本。PriorityClass不能凭空变出资源，它只能让高优先级Pod插队。

实践中，我给核心系统单独设置了高PriorityClass，给批量任务设置了默认PriorityClass，这样当批量任务占满节点时，核心系统仍然可以通过抢占获得资源。但一定要避免所有Pod都用高优先级，否则抢占调度器每次都扫描一遍，最后得出“无受害者”的结论，只会增加调度延迟。

3. 从单Pod到集群：避免“浪费”的规模化治理

3.1 ResourceQuota和LimitRange先上一道锁

单靠每个开发自觉写requests和limits，等于没管理。人总是会忘，迭代多了还会有人图省事写个很大的值然后常年占着资源。为了从集群层面避免浪费，我建议每个namespace都配置两个对象：ResourceQuota和LimitRange。

ResourceQuota用来限制整个namespace的累计资源。比如开发环境有10个服务，每个最多4Gi内存，你直接设置limits.memory总量50Gi，还能省出10Gi给临时任务。示例：

apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: "4" requests.memory: 8Gi limits.cpu: "8" limits.memory: 16Gi scopeSelector: matchExpressions: - key: podPriority operator: In values: - low-priority

这样设置代表dev这个命名空间里的普通Pod，累计requests不能超过4核8Gi，limits不能超过8核16Gi。如果某个Deployment的新版本要申请超过配额，API Server会直接拒绝，Kubernetes会把这个原因写进ReplicaSet的事件里。

LimitRange的作用跟ResourceQuota互补，它是给单个Pod或容器设置默认值和边界。比如下面这个配置：

apiVersion: v1 kind: LimitRange metadata: name: dev-limitrange namespace: dev spec: limits: - max: cpu: "2" memory: 4Gi min: cpu: 50m memory: 64Mi default: cpu: 500m memory: 512Mi defaultRequest: cpu: 100m memory: 128Mi type: Container

有了LimitRange，只要Pod容器没有显式设置requests/limits，就会被自动填入默认值。这至少保证了“不写资源限制”的Pod不会变成BestEffort，失去了QoS保护。同时max和min能阻止有人把requests设成10核或者1B，这种没有意义的配置直接报错。

我实际使用中也会碰到开发来问：“为什么我创建Pod失败了，报错说exceeded quota？”这时通常是ResourceQuota已经在发挥作用，说明新的发布规格加起来的资源超过了该namespace上限。解决方式不是删掉配额，而是评估是否有必要扩容或者清理无人使用的旧版本。

3.2 2c4g的Pod能撑多少并发：估算与压测

“2c4g的Pod能支持多大并发”是群里面出现概率极高的问题。说实话，任何脱离业务模型给具体数字的回答都是拍脑袋。但我可以给一套可行的估算思路，避免你拿着机器规格去硬套。

首先明确并发量的含义。如果指“同时活跃的连接数”，这个数字往往比“同时正在处理的请求数”大得多，因为连接建立后可能长时间空闲。真正影响CPU和内存的是活跃请求数，也就是单位时间内正在处理中的请求数。常用的模型是Little's Law：L = λ × W。L是平均活跃请求数，λ是每秒进入的请求数（QPS），W是平均处理时长（秒）。

举个例子：假设一个请求平均响应时间50ms，也就是0.05秒，那么要支撑200 QPS，平均活跃请求数L = 200 × 0.05 = 10。也就是说同时只有10个请求在处理中。如果单请求CPU消耗是0.02核，那么这10个请求大概需要0.2核CPU。2核的Pod可以轻松承载这个量级。

内存估算也要分两部分看：基础常驻内存加每个请求的额外内存。一个Java服务，基础堆可能就要2Gi，再叠加连接池、缓存、GC开销，这时候4Gi内存可能只能支撑几十个并发请求。换成一个Go写的轻量服务，4Gi可能能支撑上千并发。所以正确的做法是：

1. 先用压测工具（wrk、hey、k6）打压力，观察kubectl top pod里的CPU和内存使用率。
2. 记录下不同并发下对应的CPU请求量和内存占用。
3. 以稳定运行时的P95 CPU和内存作为requests参考，以峰值的1.5倍到2倍作为limits参考。
4. 再根据“单副本能承受的最大QPS”反向推出副本数。

我看过太多人按“2c4g=500并发”去预估容量，结果线上一个Java应用在200并发就开始频繁Full GC。根本原因是每个请求的CPU消耗和内存开销完全不同。如果不想一开始就压测，可以先给一个宽松的承接值，上线后观测两周再逐步调整requests和limits，把资源“瘦身”。这个过程叫right-sizing，是避免浪费最有效的手段。

3.3 HPA扩缩容的正确姿势

很多团队把HPA当作“自动扩缩容”的银弹，但忽略了前置条件：Pod必须设置了requests，否则HPA算出来的“资源利用率”完全没有分母。HPA默认的算法是当前副本数 × 当前Pod实际使用量 / 当前Pod requests总和，如果Pod没写requests，HPA会因为无法计算而一直不触发扩容。

CPU-based HPA配置大概是：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: dev spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

这里averageUtilization: 70的意思是“所有副本的CPU平均使用率为requests的70%”。如果requests设置得太大，实际使用率很低，HPA永远不扩容；如果requests设置得太小，实际使用率容易打到100%，HPA会激进扩容。所以requests的值不能只是“预估够用”，还要配合业务模型。

内存HPA我一般建议谨慎开启。内存回收有滞后性，某些语言（比如Java）在GC前内存会持续保持高位，HPA看到持续高内存就会不断扩容，后面GC一触发内存又跌下来，导致副本数反复抖动。如果非要做内存HPA，可以把目标利用率设低一点，比如60%，并且配合冷却时间，降低震荡。

HPA真正解决的是“波动型业务”的浪费问题。稳定业务更适合用VPA或直接固定副本数，频繁扩缩容反而会增加创建Pod的调度延迟。记住一句话：先right-sizing，再谈扩缩容。

4. 实操与排障：把资源管理落到日常操作里

4.1 用Dashboard创建带资源规格的Pod

如果你想在Web界面上快速创建一个带资源限制的新Pod，Kubernetes Dashboard是够用的。先进入目标namespace，点右上角+ CREATE，选择“从表单创建”。表单里有“资源请求”和“资源限制”区域，直接填CPU和内存值即可。但我更推荐切到“从YAML创建”，因为YAML模式可以一次性定义多个对象，比如Deployment加Service，避免表单字段不完整。

一个最常见的发布方式是这样的：

apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: dev spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: registry.example.com/web:latest ports: - containerPort: 8080 resources: requests: cpu: 500m memory: 512Mi limits: cpu: "2" memory: 1Gi restartPolicy: Always --- apiVersion: v1 kind: Service metadata: name: web namespace: dev spec: selector: app: web ports: - port: 80 targetPort: 8080 type: ClusterIP

在Dashboard的YAML编辑框里粘贴以上内容，点击Upload即可。注意左侧输入框会自动提示语法错误，资源字段的格式一定要正确：CPU可以用500m代表0.5核，内存可以用512Mi或1Gi。创建后如果Pod一直Pending，点开Deployment的状态，查看事件里有没有Insufficient cpu或FailedScheduling。如果看到这些，就说明当前namespace或节点资源配额不够，优先检查ResourceQuota，再检查节点余量。

用Dashboard创建裸Pod虽然可行，但我不推荐裸Pod。新服务发布应该用Deployment管理，这样有滚动更新、故障自愈和副本控制能力。裸Pod被删了不会自动重建，发布等于没有兜底。

4.2 多容器Pod的资源边界与启动失败影响

Kubernetes允许一个Pod里放多个容器，比如nginx加sidecar日志采集器。有人问“如果Pod里一个容器启动失败，会不会影响其他容器？”这个问题要分几个层面看。

第一是生命周期层面。Pod里的容器共享网络命名空间和存储卷，但kubelet会分别管理每个容器的生命周期。一个容器启动失败，不代表其他容器会被主动停止。如果失败容器持续CrashLoopBackOff，Pod会处于CrashLoopBackOff状态，但这个Pod里的另一个已经Running的容器仍然在运行。不过要注意，Pod的Ready状态是所有容器都满足就绪条件，如果失败容器没有进入Ready，Service的EndpointList里就不会包含这个Pod，外部流量不会打到它。所以从服务角度看，它确实“被影响了”。

第二是资源层面。多容器Pod的requests和limits是所有容器资源的累加。比如一个Pod有两个容器，一个声明cpu: 250m，一个声明cpu: 250m，那么整个Pod的request就是500m。调度器按500m来预留，运行时cgroup的QoS级别也按Pod粒度计算。如果一个容器内存超限，可能触发整个Pod的OOMKilled，甚至影响同Pod的其他容器。所以sidecar的资源请求不能“顺手填一个小值”，它会把Pod总资源顶高，导致调度紧张。

第三是启动顺序层面。如果你需要严格的启动顺序，比如主业务容器必须等初始化容器执行完再启动，那就用initContainer而不是指望普通容器的启动顺序。普通容器之间基本是并行启动的，没有内置依赖关系。热词里说的“一个容器没成功启动影响其它容器”，往往是sidecar中有文件锁、Unix socket或共享目录等待逻辑，导致主容器启动后找不到依赖而失败。这种问题最好的解决办法是：在业务容器里做就绪探测和重试逻辑，不要假设sidecar一定比自己快。

4.3 资源类问题排查速查表

我把日常遇到比较多的资源问题汇总成一张速查表，可以直接当排障手册用。

实际排障过程中，我最常用的命令是kubectl describe pod <pod-name>，里面包含了调度事件、容器状态、上次退出原因。几乎所有资源问题都能从这个命令里找到第一手线索。然后配合kubectl top nodes和kubectl top pods确认真实用量，就能定位到是requests不准确，还是limits太小，又或是配额问题。

还有一个细节容易被忽略：Pod被驱逐后的事件里可能没有明显错误，只是显示节点内存压力。这时要去看节点上的systemd日志，比如journalctl -u kubelet，里面会有EvictionManager的驱逐原因。有时候是节点本身有长时间运行的容器累积了页面缓存，导致nodefs或imagefs压力，不一定是Pod requests的问题。

最后再分享一个日常习惯：每次发布新服务，我都会要求带上资源字段，并且在一个测试namespace里配置LimitRange做默认值校验。上线后第一周每天看资源使用曲线，第二周根据曲线调整一次requests和limits。这个动作看似很小，但能把“争抢”和“浪费”这两个问题同时按下去。如果你也总是被资源问题折腾，建议从今天起给每个Deployment补上resources字段，再在namespace上卡一个ResourceQuota，后面你的告警邮件一定能安静不少。