我创建了一个 Deployment，它可以包含 2 到 25 个容器，它们都在一个更大的单个逻辑工作单元的一个切片上工作。容器将使用 700MB-4GB 的峰值内存，我最初的方法是请求 1G，限制 4G。在最坏的情况下（4GB 多于 700MB），即使在其他地方有 3% 或 400% 的免费聚合资源可用，这也会导致节点停机（或不会安排开始）。
看着一个或两个容器在 RAM 中慢慢爬升并 OOM 节点关闭，而不是让调度程序将容器拔出并重新定位，这似乎是一个非常明显的稳定性问题。
经过多年的 git 辩论、文档和代码本身的挖掘。目前尚不清楚调度程序在抽象的哪个抽象级别上甚至在启动时传播容器，或者一旦部署工作，K8S 是否有任何主动步骤。
如果一个 ReplicaSet（我相信那是新的、改进的 ReplicationController）只会重新激活容器直到杀死主机，你必须在它的职权范围内创建对每个 pod 的最坏情况请求。对于我们作为部署运行的较大的作业，这会引入50% 以上的 RAM 浪费，因为“以防万一”过度配置。
保持过度配置的资源不是我们在这里试图解决的问题之一吗？
多年来，我使用了很多调度程序/资源管理器，并且不记得一个作业步骤 - 容器 - 无论是什么类比都会被允许损害主机本身，而不是被强制迁移或直接标记没有资格安排..
尽管文档告诫了这个想法，但裸 pod 或 1 pod:1 ReplicaSet似乎是保持工作分布式的唯一方法（假设容器检查点和自杀经常足以重新考虑整体资源图）。
我还应该提到，这是托管的 Google Container Engine (v1.2.2)，鉴于看起来有几页标志可以启动 K8S，不清楚这是一个固有问题、用户错误还是 GCE 的配置方式K8S。我真的希望这个用户错误。