Kubernetes中CPU和内存的request决定调度与资源预留，limit控制运行时上限；CPU超limit被节流，内存超limit触发OOMKilled；需合理配比requests≤limits，并配合应用配置（如JVM堆大小）。
在 Kubernetes 中设置 CPU 和内存限制，不是加个参数就完事，关键得理解 request 和 limit 的区别，以及它们如何影响调度、运行和驱逐行为。
CPU 限制：别只设 limit，request 才决定能分到多少核
CPU 是可压缩资源，超限会被节流（throttled），但不会被杀。Kubernetes 调度器只看 requests.cpu 来决定把 Pod 放在哪台节点上——比如你设了 requests: 500m，那节点就得有至少 0.5 核空闲才可能调度成功。
-
limits.cpu控制容器最多能用多少 CPU 时间（例如1表示 1 个逻辑核的 100%） -
requests.cpu影响调度，也作为 CFS 配额的基准（如500m对应quota=50000, period=100000） - 不设 request，默认 request = limit；不设 limit，容器可无限抢占 CPU（不推荐）
内存限制：设错会 OOMKilled，request 和 limit 必须合理配比
内存是不可压缩资源。一旦容器使用内存超过 limits.memory，Linux OOM Killer 就会直接终止该容器（事件里显示 OOMKilled）。而 requests.memory 决定调度时是否预留足够内存，并影响节点内存压力下的驱逐顺序。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 建议
requests.memory≤limits.memory，且差值不宜过大（比如应用常驻内存 300Mi，可设 request=400Mi、limit=600Mi） - 避免
limits.memory过小（如 Java 应用没调 JVM 堆大小就设 limit=256Mi，大概率 OOM） - Node 内存不足时，Kubelet 按
(memory usage - memory request) / memory request算“超用比例”，优先驱逐超用高的 Pod
实战写法：在 Deployment 中正确配置
以下是一个带典型资源限制的容器定义片段：
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
- 这个 Pod 启动时，调度器确保节点有 ≥512Mi 内存 + ≥0.25 核 CPU 空闲
- 运行中，CPU 最多用满 0.5 核，内存超 1Gi 会被杀
- Java 应用建议显式传
-Xmx512m，让 JVM 堆上限匹配 memory request，避免堆外内存+堆内内存合计超限
验证和调试：三步快速确认是否生效
配置完别急着上线，用这几条命令验证：
-
kubectl describe pod <pod-name>—— 查Requests/Limits字段和 Events（有没有 Warning 或 OOMKilled） -
kubectl top pod <pod-name>—— 看实时 CPU/Mem 使用量（需 Metrics Server） -
kubectl exec -it <pod> -- cat /sys/fs/cgroup/cpu/cpu.stat—— 查 throttling 统计（nr_throttled> 0 说明 CPU 被限频了）
