我遇到的大多数已经运行集装箱化应用程序的客户都在处理管理其环境所需的多种资源的复杂性。我发现有两种挑战：在K8s中很难大规模地管理配置选项（利用率、配额、请求、限制）要理解k8中的变化对底层基础设施的影响是不可能的。（也就是说，如果我缩小我的请求，对服务于pod的物理主机有什么影响？）在这篇文章中，我将探讨每一个挑战。大规模管理K8s权衡在环境管理中，最常见的4个有限容量因素是：利用请求限制配额利用容器pod从其底层节点消耗内存和CPU。高利用率是导致性能问题的最常见原因之一，但在管理容量时往往会被忽略，因为人们希望围绕限制、配额和请求的最佳做法能够推动正确的利用率目标是在节点上达到持续有效的CPU/内存利用率。这充分利用了潜在资源，但仍保持了需求激增的空间。我经常听到的一个目标是利用率在70%左右。最终，这归结到你愿意承担的风险水平。不同的应用程序之间可能也会有所不同（您希望驱动节点的温度有多高？）。安全最大化节点资源利用率的涡轮经济最佳实践：在节点上连续放置pod可以最大限度地利用底层基础设施。由于并非所有容器都在同一时间需要所有资源，通过动态管理资源，您可以确保一旦pod需要资源，这些资源都是可用的。请求请求是容器的保证容量。请求与实际使用的内存无关。也就是说，一旦一个新的pod被调度，K8s就会检查可用的请求容量并相应地放置pod，而不管实际情况如何利用率。英寸换句话说，如果一个Pod被调度，并且没有节点有足够的请求容量，那么它将不会被放置。管理请求的经济最佳实践：对所有单个容器的正确尺寸要求将允许更多的吊舱安全地放置在环境中。连续放置pods有助于防止单个节点耗尽请求容量。限制限制决定了容器在运行时可以使用的最大CPU和内存量。节点可以在限制上过度提交（与请求相反）。i、 限制之和可以高于节点资源。通常，您对过度使用这些资源感兴趣。否则，你会给环境带来很大的浪费。然而，自然资源的过度使用总是会带来资源耗尽的风险，应谨慎管理。管理限制的涡轮经济最佳实践：在节点中连续放置pod可以将OOM错误的风险降至最低，因为实际内存超过了上的可分配内存节点。对吗根据实际需求的大小限制允许更严格的控制范围，从而实现可预测的性能和更安全地使用节点中的burstable空间。配额配额是K8s管理员限制单个团队使用的一种机制，因此它不会使用超过其公平份额的资源（无论是请求还是限制）。一旦一个项目达到其配额，该项目将不接受额外的pod。这与集群上的实际利用率或整个集群的可用容量完全不同。管理配额的最佳经济实践：对请求和限制的持续正确调整将避免项目超出配额。没有必要限制你的项目资源没有任何使用。了解完整的供应链显然，基础设施的利用是能力规划的一个主要功能。尤其是如果你是在内部运行。如果堆栈中有一个虚拟化层（hypervisor，如VMWare），则更是如此。归根结底，如果底层基础设施利用率很高，那么如何提高密度？用斯科蒂的话说，你不能改变物理定律。高CPU就绪队列会产生延迟，这可能会导致上面4层容器上的故障。要解释复杂性，请考虑以下场景：CPU等待时间（就绪队列）在物理ESX主机上累积->主机上的不同虚拟机开始出现延迟->其中一个受到严重影响的VM是一个K8s节点->该节点中的容器开始崩溃，无法及时重新调度。管理完整供应链的经济最佳实践：容量和性能必须在整个物理/虚拟堆栈上下进行整体管理。但还有一件事…同样，节点上吊舱的连续大小和放置是一个NP完全问题。此外，这些安置必须遵循多个约束条件。例如将主节点与不同的本地ESX主机分离，或在云中按比例分配地理位置策略。摘要微服务应用程序给性能和容量管理带来了显著的复杂性。为了在供应链上下多个资源的上下文中，系统应该能够持续地扩展、放置和配置您的资产，以实现系统的规模化运行。