内存单位是什么
内存支持两套单位体系：十进制以一千为进位，二进制以一零二四为进位。同一个字面量在两套体系下实际容量相差约百分之四点六，因此团队内应统一一种写法并在评审时检查。内存与 CPU 最大的差别在于不可压缩：容器超过自己的上限会被直接终止，而不是被限速。
为什么上限设置格外敏感
对 CPU 而言，上限不够只是变慢；对内存而言，上限不够就是被杀掉重启。加上许多运行时的内存占用不止堆内存这一块，还包括运行时自身与堆外分配，光按堆大小设置上限往往会周期性触发终止。因此内存上限通常要按实测峰值加合理余量来定。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，用于容器的资源请求与上限字段 |
|---|---|
| 两套体系 | 十进制与二进制，团队内需统一 |
| 换算关系 | 二进制体系下相邻单位相差一零二四 |
| 超出上限 | 容器被终止并重启，不属于限速 |
| 节点层面 | 节点内存紧张时按保障等级决定驱逐顺序 |
| 常见取值 | 小服务按百兆级，数据库与缓存按实际工作集 |
典型使用场景
- 服务规格声明：按实测稳态与峰值确定请求值与上限
- 缓存类服务：工作集随数据增长，需要定期复核上限
- 批量任务：按单批数据规模估算内存需求
- 排查周期重启：确认是否因上限过低被终止
- 节点容量规划：把请求值汇总，判断节点是否还有余量
- 成本优化：对比实际用量与请求值，缩紧过度预留
写法与核对
写法与核对
resources:
requests:
memory: 256Mi # 二进制体系，常用写法
limits:
memory: 512Mi # 超过即被终止，按实测峰值加余量
# 十进制体系的同名字面量容量略小，混用会造成临界负载踩线排查被终止
排查被终止
kubectl describe pod web-x | sed -n '/Last State/,+4p' # 看上一次终止原因
kubectl get pod web-x -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
kubectl top pod web-x --containers # 当前各容器用量
kubectl describe node node-1 | grep -A8 'Allocated resources'两套体系对照
| 体系 | 进位 | 使用建议 |
|---|---|---|
| 十进制 | 以一千为进位 | 与厂商标称容量一致，便于对外表述 |
| 二进制 | 以一零二四为进位 | 容器资源声明里的常见写法 |
| 混用风险 | 同名字面量差异约百分之四点六 | 临界负载容易出现不一致行为 |
内存上限低于应用真实工作集时容器会被反复终止，现象是重启计数持续增长，排查要结合上一次终止原因判断。
节点内存紧张时，系统会按保障等级与用量超出请求值的程度排序驱逐，请求值填得越准，被牺牲的顺序越靠后。