我已经创build了一个部署，其中可以包含2到25个容器之间的任何地方，这些容器都在一个更大的单个逻辑工作单元上工作。 容器将会使用700MB-4GB的内存，我最初的方法是请求1G，限制4G。 在最坏的情况下（4GB的数量超过700MB），即使在其他地方有3％或400％的空闲资源可用时，也会使节点停机 （或者不会开始）。
看着一个或两个容器缓慢地爬上RAM和OOM的节点下来，而不是调度器采取容器closures和重新部署似乎是一个稳定的相当明显的关注。
通过几年的git辩论，文档和代码本身。 目前还不清楚在抽象的抽象层次上，调度程序甚至在启动时传播容器，或者如果有任何积极的步骤K8S一旦部署工作困扰。
如果一个ReplicaSet（我相信这是新的，改进的ReplicationController）只会重新生成容器，直到杀死主机，你必须创build硬盘最坏情况下的请求给每个pod。 对于我们作为部署运行的大部分工作，这会导致50％以上的内存浪费，以防万一 。
是不是在过度configuration的资源中存在一个我们正在试图解决的问题？
多年来，我使用了相当多的调度程序/资源pipe理器，并且不记得一个工作步骤 – 容器 – 无论类比如何都将被允许妥协主机本身，而不是被强制迁移或者直接标记没有资格进行排程
尽pipe文档告诫了这个想法，但是裸露的pod或者pid：1副本集似乎是保持工作分布的唯一方法（假设容器检查点和自杀经常足以使整个资源图片被重新考虑）。
我还应该提到，这是托pipe的Google容器引擎（v1.2.2），看起来像几页的标志可以启动K8S，不清楚这是一个固有的问题， 用户错误或只是如何configurationGCE K8S。 我真的希望在这一个用户错误。
基于Kubernetes松弛频道上一些相当有帮助的人回答我自己的问题。
– 由于容器的OOM操作，我对节点失败的体验很可能是由于资源pipe理器devise用于防止这种情况的次要影响。 build议的罪魁祸首实际上是I / O子系统变得超负荷的一点去稳定节点，经过一些测量，看起来很可能。
在GKE中，操作系统，Docker，K8S以及任何临时目录的pod请求都在一个非本地的100GB（默认情况下，我相信）是ext4文件系统。
大部分我们想要的荚都是要求和写入临时目录，而集体I / O压倒了系统，变成了没有响应的地步，在我们的例子中locking了操作系统本身。
– 一个初始的testing，在自己的ext4驱动器上设置自己的K8S，在自己的ZFS池中有docker和临时空间，并且相同的部署清单也有压力，但是不会使操作系统崩溃。
– 已经提出但尚未经过testing的解决方法是使用Jobs，并通过一些协调过程来pipe理它们之间的依赖关系，据推测这是因为这会将各个容器分散到整个群集中。 这可能会起作用，但是会让我觉得这是一个潜在的问题。
虽然我还没有测量为暂存空间分配持久性磁盘，但我们使用了emptyDir，我假设这也会减轻主磁盘上的负载，并且可能足以掩盖问题。
不幸的是，默认的GKE设置假设sda将能够处理操作系统，K8S日志，Docker和临时空间的整个负载，这显然必须适用于大多数人，因为我找不到像我们这样的另一个问题。
来自裸机，我希望避免一些低层次的细节让集群pipe理，但数据集和GKE至less让我倾向于把自己的集群打造出来。
希望这可以帮助那些工作负载适合Job模式或主要使用configuration磁盘的人。
我很惊讶任何最佳实践会有这么多的启动驱动器的预期，并将支持，因为即使是“常规”计算引擎似乎阻止这给定的默认启动驱动器的大小。