Java容器的GC是否会耗尽Kubernetes底层节点的全部CPU资源？

首先明确：这种场景下容器内的Java进程完全可能出现相同的GC频繁占满CPU的情况，甚至更容易导致整个Kubernetes节点不可用。

• 未配置CPU、内存的requests与limits的Pod，Kubernetes不会为其生成对应的cgroup资源限制规则，容器进程默认可以占用节点全部可分配的CPU、内存资源，没有任何内核层面的资源隔离约束。
• 节点已超额部署的前提下，本身节点剩余可用内存远低于物理机总内存：如果使用的是8u191之前版本的JDK，JVM默认会识别节点物理机内存而非容器分配的资源，默认堆内存配置为物理机内存的1/4，远高于节点实际剩余可用内存；哪怕是高版本JDK，因为没有配置内存limit，JVM也会尽可能申请内存，最终很快触发堆内存不足，导致GC频繁执行。
• 常用的Parallel GC、G1 GC等默认都是多线程执行模式，Full GC触发时会占用所有可用的CPU核心，且因为没有配置CPU limits，GC占用的CPU不会被限流，会持续抢占节点上kubelet、containerd等核心组件的CPU资源。当核心组件无法获得足够CPU响应心跳、调度请求时，Kubernetes控制面会判定节点为NotReady状态，最终节点完全不可用。

进入异常容器执行jstat -gcutil <java_pid> 1000，如果输出中FGC（Full GC次数）每秒持续增长，且FGCT（Full GC总耗时）占比超过运行时间的80%，即可确认是GC内存不足导致的CPU占满问题。

• 所有业务Pod必须配置合理的CPU、内存requests与limits，强制开启cgroup资源隔离，避免单个业务Pod抢占节点全部资源
• 升级JDK到8u191及以上版本，默认开启cgroup资源感知能力，低版本需额外添加JVM启动参数-XX:+UseCGroupMemoryLimitForHeap
• 配置kubelet的--kube-reserved和--system-reserved参数，预留至少1核CPU、2G内存给节点核心组件，避免业务资源耗尽导致节点失联

内容的提问来源于stack exchange，提问作者Dominic1432