资源配额与 HPA
这一课你将能做到
- 在容器 spec 写出 CPU/内存的 requests 与 limits，并解释二者对「调度」与「运行」的不同影响
- 说出三级 QoS 的区别，了解 Namespace 级 ResourceQuota / LimitRange 的用途
- 读懂并创建一份 HPA（autoscaling/v2），解释它按什么指标、算什么公式扩缩副本
为什么要学
集群资源有限，不立规矩就是「丛林法则」：不写 requests，Scheduler 只能瞎猜这个 Pod 占多大，节点被塞爆后所有服务一起变慢；不写 limits，一个内存泄漏的进程能 OOM 掉整台机器上的邻居。流量高峰靠人肉改 replicas 太慢——HPA（Horizontal Pod Autoscaler） 按指标自动在 min/max 区间扩缩副本。
对本站：backend 是 JVM 应用，启动期和稳态内存差异大，requests/limits 写得太随意会频繁 OOMKilled；扩副本后每个实例都连 MySQL，HPA 的 max 要和数据库连接池一起算。这些都是面试真题（「requests 和 limits 区别」「HPA 原理」）。
先建立图像
requests：调度「预约」——节点剩余量 ≥ requests 才放得下；也是 HPA 利用率的分母
limits： 运行「天花板」——内存超限 → OOMKill；CPU 超限 → 被节流（变慢但不死）
HPA 决策循环（每 15 秒左右）：
采集指标（metrics-server） → 算期望副本 = ceil(当前副本 × 当前利用率/目标利用率)
→ 与上次决策对比（扩容防抖 0s、缩容稳定窗口默认 5 分钟）→ 调整 replicas
| 机制 | 作用范围 | 一句话 |
|---|
| requests / limits | 单容器 | 自己的份 |
| LimitRange | Namespace | 给没写资源的 Pod 发默认值/卡上下限 |
| ResourceQuota | Namespace | 全命名空间总量封顶 |
| HPA | Deployment 等 | 自动改副本数 |
| Cluster Autoscaler | 节点池 | 副本放不下就加机器（了解） |
跟着做
步骤 1：给 backend 容器加 requests/limits
在 deploy-backend.yaml 容器段追加：
resources:
requests:
cpu: "100m" # 0.1 核：调度预约
memory: "256Mi"
limits:
cpu: "500m" # 0.5 核：运行天花板
memory: "512Mi"
kubectl apply -f deploy-backend.yaml
kubectl describe pod -l app=backend | findstr /i "Requests Limits QoS"
（Linux/macOS 用 grep。）应看到资源字段与 QoS Class: Burstable。真 backend（JVM）的经验：启动期内存峰值明显高于稳态，limits 过紧会在启动时 OOMKilled——JVM 配 -XX:MaxRAMPercentage=75.0 让堆自适应容器限额，比手写 -Xmx 更贴合。
步骤 2：看真实用量（metrics-server）
minikube addons enable metrics-server
kubectl get pods -n kube-system -l k8s-app=metrics-server -w # 等 Running
kubectl top nodes
kubectl top pods
kubectl top 输出的是「实际用量」，和 requests（预约）、limits（上限）三个数字放在一起看，才敢谈调优。顺序：先观测 → 再定 requests/limits → 最后谈 HPA。
步骤 3：命名空间配额（ResourceQuota / LimitRange）
apiVersion: v1
kind: ResourceQuota
metadata:
name: coderoadmap-quota
namespace: default
spec:
hard:
requests.cpu: "2"
requests.memory: 4Gi
limits.cpu: "4"
limits.memory: 8Gi
pods: "20"
---
apiVersion: v1
kind: LimitRange
metadata:
name: coderoadmap-limits
spec:
limits:
- type: Container
default: # 没写 limits 的容器自动获得
cpu: "500m"
memory: "512Mi"
defaultRequest: # 没写 requests 的容器自动获得
cpu: "100m"
memory: "128Mi"
kubectl apply -f quota.yaml
kubectl get resourcequota
效果：本命名空间总申请量被封顶（防一个团队吃光集群）；漏写资源的容器自动带默认值。生产多团队集群这是标配，全靠自觉是不行的。
步骤 4：创建 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: backend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: backend
minReplicas: 2
maxReplicas: 6
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # 平均利用率（相对 requests）超 70% 就扩
behavior: # 可选：扩缩行为微调
scaleDown:
stabilizationWindowSeconds: 300
kubectl apply -f hpa-backend.yaml
kubectl get hpa backend-hpa
kubectl describe hpa backend-hpa
TARGETS 一开始可能显示 <unknown>/70%：指标管道还没就绪，等一分钟再试；一直 unknown 见卡点急救。
步骤 5：制造负载看扩缩
kubectl run load --rm -it --image=busybox:1.36 --restart=Never -- \
sh -c "while true; do wget -qO- http://backend >/dev/null 2>&1; done"
另开终端盯 kubectl get hpa -w 与 kubectl get pods -l app=backend。注意：nginx 占位镜像几乎不吃 CPU，扩缩可能不触发——这恰恰验证了「HPA 只看真实指标」，把 averageUtilization 临时调低或换个真吃 CPU 的负载即可看到 replicas 上升；Ctrl+C 停掉负载后，缩容要等稳定窗口（默认 5 分钟，上面已配 300s）。对本站的启示：扩副本会线性放大到 MySQL 的连接数，maxReplicas 要按「每副本连接池 × 副本数 ≤ 数据库上限」反推。
步骤 6：亲手见一次 OOMKilled
把上面临时改出一份「必死配置」：memory limit 压到 32Mi（nginx 可跑，换个想多要内存的负载即可，或直接把 busybox command 改成分配大数组）。观察：
kubectl get pods -w
kubectl describe pod <名字>
Status 显示 OOMKilled、重启次数上涨——这就是「内存 limit 是硬墙」。JVM 服务尤其要按步骤 1 的建议留足余量。
讲清楚要点
- requests 决定「能不能调度到节点」，limits 决定「跑起来后最多用多少」：前者影响放置与密度，后者影响运行时行为；两者语义完全不同，不可混写。
- 内存超 limit 必死（OOMKill），CPU 超 limit 只是被限速：所以内存要留余量、CPU 可适当紧——JVM 堆务必与内存 limit 自洽。
- HPA 的利用率分母是 requests：requests 虚高 → 利用率永远偏低 → 不扩；虚低 → 动不动就扩还挤兑资源。先校准 requests 再上 HPA。
- 扩容快、缩容慢是特性：扩容立即响应防过载，缩容有稳定窗口防抖动；
behavior 段可微调，别瞎砍默认值。
- ResourceQuota 管总量、LimitRange 管默认：多团队/多项目共享集群时防「吵闹邻居」，也强制 Pod 都带资源声明。
- HPA 只会自动改 replicas：它和手改 replicas 冲突时 HPA 赢（持续调谐会把你手改的值改回去）；上了 HPA 就别再手动 scale。
你可能会懵的地方
-
CPU limit 会让程序变慢吗？
会——超限时被节流（throttling），延迟抖动。经验：Web 服务常不设 CPU limit 只设 request（避免限速），内存 limit 必设（防拖垮节点）；团队规范优先。
-
只写 limits 不写 requests 行吗？
行为因配置而异（有的环境会把 request 默认等于 limit）。实践：核心服务两者都显式写清，别靠隐式规则。
-
为什么 HPA TARGETS 显示 unknown？
指标管道不通：metrics-server 没装好、Pod 没写 requests（Utilization 算不出百分比）、或刚创建还没采到数据。describe hpa 的 Conditions 会写明原因。
-
minikube 单机学 HPA 有意义吗？
有——对象字段、指标管道、扩缩窗口的概念全都能练；只是单机指标噪声大，别拿本地表现外推生产数值。
-
垂直扩容（加内存）怎么办？
那是 VPA（改容器规格）与 Cluster Autoscaler（加节点）的领域，与 HPA（加副本）互补。入门先精通 HPA，VPA 了解即可。
错法对照
| 错法 | 问题 | 正解 |
|---|
| 全员不写 requests | 调度无据可依，节点被塞爆 | 核心服务必写 requests |
| limits 盲目抄「2C4G 起步」 | 浪费资源、掩盖泄漏 | 用 top 观测后再定 |
| HPA 不设 maxReplicas | 高峰雪崩式扩容打爆下游 | 设上限并按 DB 连接数反推 |
| 无 metrics-server 硬上 HPA | 永远 unknown 不工作 | 先通指标管道 |
| JVM 忽略容器内存感知 | 启动期 OOMKilled | MaxRAMPercentage + 留足余量 |
卡点急救
kubectl top 报 Metrics API not available：metrics-server 未装或未就绪——minikube 用 addons enable metrics-server，等 Pod Running 再试；仍不通看其日志（常见是证书问题，按官方 FAQ 处理）。- Pod 反复重启，describe 显示 OOMKilled：内存 limit 过小或 JVM 堆未适配容器；上调 limit、配置 MaxRAMPercentage、必要时加 startupProbe 给慢启动留时间。
- HPA 一直
<unknown>/70%：确认 metrics-server 正常、目标 Deployment 的容器写了 requests（Utilization 需要）、等 1-2 分钟采集窗口；describe hpa 看 FailedGetResourceMetric 类事件。
面试常问
-
requests 和 limits 的区别？
requests 是调度依据：Scheduler 保证「节点可分配资源 ≥ 所有 Pod requests 之和」，它决定 Pod 放哪、密度多高，同时也是 HPA 利用率的分母；limits 是运行时上限：CPU 超限被 CFS 节流（变慢不死），内存超限触发 OOMKill（容器重启）。由两者组合产生三级 QoS：requests==limits 为 Guaranteed（最不容易被驱逐）、设了 request<limit 为 Burstable（大多数服务）、都没设为 BestEffort（资源紧张时最先被杀）。
-
HPA 的工作原理？
HPA 控制器周期性（默认 15 秒）从 metrics-server（自定义指标则从对应 API）采集指标，按公式「期望副本 = ceil(当前副本数 × 当前指标值 / 目标指标值)」计算，对 CPU 类 Utilization 指标以 requests 为分母；扩容立即生效、缩容要过稳定窗口（默认 5 分钟）防止抖动；最终修改 scaleTargetRef 对象（如 Deployment）的 replicas，再由其下层控制器完成 Pod 增删。前提：指标管道可用、目标容器声明了 requests。
-
线上出现频繁 OOMKill 怎么排查？
定位：describe pod 看 OOMKilled 与重启次数，top 对比实际用量与 limit。常见根因与处置：limit 明显低于应用真实峰值→上调并观察；JVM 未感知容器限额→加 MaxRAMPercentage；内存泄漏→堆 dump 定位修复；旁路问题（page cache 计入 cgroup）→留余量。原则：先观测再调参，不盲目加内存掩盖泄漏。
自测三问
- requests 和 limits 分别影响「调度」和「运行」的哪一步？
- 为什么 HPA 的 averageUtilization 必须和 requests 一起理解？
- backend 扩到 6 副本时，最先被压垮的通常是应用还是数据库？怎么预防？
小结一句话
先用 requests/limits 划清单容器边界、用 Quota/LimitRange 守住命名空间总量，再用 HPA 在安全区间内自动调副本——下一课补上「谁有权操作这些对象」的 RBAC 与安全基础。
延伸