我正在尝试了解时间表在某些情况下的行为方式/原因。有人能解释一下调度程序在这些情况下会做什么（以及为什么）吗？
假设我有一个 10GB 的内存盒
我有一个内存请求设置为 1G 的容器。我运行它的 10 个副本，我希望在同一个盒子上看到所有 10 个（在这种情况下，忽略任何 kube 系统样式的 pod）
现在假设我还将内存限制设置为 2G。怎么了？对我来说，这对调度器说“这个 pod 要求 1G，但可以增长到 2G”——调度器是否仍将所有 10 个放在同一个盒子上，知道它很可能不得不踢掉其中的一半？或者它会按照描述的限制分配 2G？
如果我不声明限制，那么我是否也正确地假设 pod 将增长直到节点耗尽内存然后杀死超过其请求资源的 pod？还是会假设某种默认值？
【问题讨论】：
标签： kubernetes
请求是需要在节点上专门提供给该 pod 以供调度。这是从可用资源计数中扣除的内容。限制就是限制。 pod 使用量将被限制为该值。
所以，如果你有 10G 的节点，并且想在上面安装 req: 1G, limit: 2G pod，你将能够容纳其中的 10 个，如果有足够的未使用内存，它们将能够突增到 2G 内存使用从其他人那里（即您请求 1G，但实际使用 700M，这为您提供了大约 3G 请求，但未使用的空间可用于 pod 爆破到 2G 限制。
【讨论】：
requests，那么只要资源稀缺并且必须得到它的东西需要，这个过程就可以得到一个OOMkilled。
@Radek 的解释当然是正确的。要回答您的后续问题，如果您确实声明了资源并且没有限制，documentation 解释了可用的方案： 如果节点可用，容器能够超出其请求内存。但不允许超过限制使用。所以这里有你的用例 -
如果容器分配的内存超过其限制，则 容器成为终止的候选者。如果容器 继续消耗超出其限制的内存，容器是 终止。如果终止的 Container 可以重新启动，则 kubelet 重新启动它，与任何其他类型的运行时故障一样。
如果没有限制：
为了完全掌握这个主题，我认为理解限制是为了防止爆发很重要，所以当你的容器在有限的时间内处于峰值时，你仍然会为你的其余部分保留可用资源组件，就不会发生严重的灾难。
我强烈建议尝试官方文档（CPU,Memory）中的一些用例，这样您就可以测试自己的场景并更好地理解它。例如，您可以使用 minikube 立即完成。
【讨论】：