我有一些两难选择什么应该是正确的请求和限制设置为一个吊舱在Openshift.一些数据：
1.在启动期间，应用需要至少600毫科雷才能够在150秒内完成准备就绪检查。
1.在启动之后，对于应用保持在空闲状态，200毫科瑞应该是足够的。
所以我从文档中了解到：
CPU请求
Pod中的每个容器都可以指定它在节点上请求的CPU量。调度程序使用CPU请求来查找适合容器的节点。CPU请求表示容器可以使用的最小CPU量，但如果没有CPU争用，它可以使用节点上的所有可用CPU。如果节点上存在CPU争用，CPU请求提供系统上所有容器的相对权重，以确定容器可以使用多少CPU时间。在节点上，CPU请求Map到内核CFS共享以强制执行此行为。
注意到调度器会参考请求CPU在节点上进行分配，一旦分配就是保证资源。另一方面，我可能会分配额外的CPU，因为6亿可能只在启动时需要。
那我应该去
resources:
limits:
cpu: 1
requests:
cpu: 600m保证资源或
resources:
limits:
cpu: 1
requests:
cpu: 200m为了更好地节省CPU
1条答案
按热度按时间iszxjhcz1#
我想你还没有得到 * 请求与限制 * 的想法，我建议你在做决定之前看一下文档。
在一个简单的解释中，
请求是指虚拟分配给容器的资源量，这是一种保证，您可以在需要时使用它，并不意味着它只保留给容器。也就是说，如果您请求200mb的RAM，但只使用100mb，当其他容器消耗完所有请求的内存时，其他100mb将被“借用”。当你的集装箱需要它时，它会被“收回”。
限制是简单的术语，是指在由于消耗过多资源而关闭容器之前，容器可以消耗多少资源（请求+从其他容器借用）。
1.如果Container超出其内存***限制***，则它 * 很可能 * 被终止。
1.如果Container超出其内存***request***，则 * 很可能 * 在 * 节点耗尽内存 * 时驱逐其Pod。
简而言之，限制是绝对值，它应等于或高于请求，良好做法是避免所有容器的限制都高于请求，只有在某些工作负载可能需要时才这样做，这是因为大多数容器会消耗更多资源（即：存储器），突然POD将开始以不可预测的方式被从节点逐出，这使得情况比对每个POD具有固定限制的情况更糟。
在docker docs中还有一篇关于资源限制的文章。
调度规则对于CPU和内存是相同的，K8将仅在节点具有足够的CPU和内存可分配以容纳pod内的container请求的所有资源时才向节点分配POD。
execution规则稍有不同：
内存是节点中的有限资源，容量是绝对限制，容器消耗的内存不能超过节点的容量。
另一方面，CPU是以CPU时间来衡量的，当你保留CPU容量时，你是在告诉一个容器可以使用多少CPU时间，如果容器需要的时间比请求的多，它可以被节流并进入执行队列，直到其他容器消耗完分配给它们的时间或完成它们的工作。但不太可能因为消耗太多CPU而终止该容器。当其他容器没有使用分配给它们的全部CPU时间时，该容器将能够使用更多CPU。主要问题是当容器使用的CPU多于分配的CPU时，限制将降低应用程序的性能，并且在某个点可能停止正常工作。2如果不提供限制，容器将开始影响节点中的其他资源。
关于要使用的值，没有正确的值或正确的公式，每个应用需要不同的方法，只有多次测量才能找到正确的值，我给予你的建议是确定最小值和最大值并在中间的某个地方进行调整，然后保持监控，看看它的表现如何，如果你觉得浪费或缺乏资源，你可以减少或增加到一个最佳值。2如果服务是至关重要的，从较高的值开始，然后再减少。
对于准备就绪检查，您不应将其用作指定这些值的参数，您可以使用探头中的
initialDelaySeconds参数延迟准备就绪，以便为启动POD容器给予额外的时间。PS：我引用术语“借用”和“要求归还”是因为容器实际上并不是从另一个容器借用，一般来说，节点有一个内存池，并在容器需要时将内存块给予给容器，因此从技术上讲，内存不是从容器借用，而是从池借用。