测验：cgroup

用--memory=256m --cpus=0.5启动的容器中，free -m显示为64228MB，nproc显示为32，最准确的解释是什么？

• 没有任何限制，所以你必须再次步行。
• cgroup 强制执行限制，但不覆盖/proc的主机值
• free 和 nproc 不适用于本机容器
• 内存限制包括交换，因此该值看起来很大。

当我将 Go 中制作的服务限制为 0.5 个核心时，响应时间只会增加，并且 CPU 使用率很低。首先要检查什么并采取行动？

• 提高容器的内存限制
• 通过将副本数量加倍来分担负载
• 降低memory.high以加速内存恢复并观察。
• 通过查看cpu.stat的 nr_throttled/nr_periods 比率来指定GOMAXPROCS

memory.high和memory.max有什么区别？

• 如果超过 high，则立即终止 OOM，如果超过 max，则仅保留警告。
• 如果超过high，会有恢复压力和分配延迟，但不会死，如果超过max，就会被OOM Kill。
• 两者相同，只是 v1/v2 名称不同
• high 适用于 CPU，max 适用于内存

为什么 Kubernetes 中当节点内存不足时，BestEffort Pod 首先死亡？

• 这是因为每个 QoS 类别的 OOM 分数设置为Guaranteed -997 / Burstable 2~999 / BestEffort 1000，并且内核 OOM Killer 按此顺序选择。
• 这是因为调度程序被编码为监视节点内存并首先驱逐 BestEffort pod。
• 因为 BestEffort pod 没有在 cgroup 中注册。
• BestEffort 的内存限制为 0，并且总是会超出。

cgroup 这个名字的正确来源是什么？

• 它是集群组的缩写，起源于 Kubernetes。
• 对照组的缩写。它在 2007 年内核合并期间被重命名，以避免与术语“容器”混淆。
• 核心组的缩写。它从CPU核心分配开始。
• 它是容器组的缩写，由 Docker 引入。

容器以退出代码 137 结束。确定是 OOM Kill 还是人为发送的 SIGKILL 的最合适方法是什么？

• 检查应用程序日志中剩余的异常堆栈跟踪以及终止前的行。
• 如果退出代码为137，则始终是OOM，因此无需区分。
• 将重启策略更改为始终，看看它是否能够重现。
• 检查运行时的State.OOMKilled字段和内核日志中的Memory cgroup out of memory行。