如何有效控制需求，弹性和效率的无声杀手现在Kubernetes已经发展到企业级，组织正在寻求扩展他们的平台来支持更多的应用程序和更多的业务线。为了在规模上做到这一点，他们需要在多租户环境中支持这些应用程序和业务线，甚至现代的微服务应用程序也必须共享资源！对于我们医疗保健行业的一位客户来说尤其如此。两年前，他们投身于Kubernetes（特别是Red Hat OpenShift），现在是"平台优先"，这意味着所有新应用程序都是为云计算本地速度、灵活性和弹性而设计的；而现有的应用程序正逐渐为之重新架构。这些都是业务关键型应用程序，例如，利用大量数据和机器学习帮助临床医生更准确有效地诊断和治疗患者。作为一个平台优先的组织，该客户必须在Kubernetes上管理多个应用程序，并利用多租户。Kubernetes允许管理员通过请求和限制来管理共享资源，分配CPU和内存。限制可以过度使用，但请求是有保证的资源。换句话说，当容器中所有容器的请求之和能够满足一个节点时，Kubernetes才会调度一个容器pod。将应用程序装载到Kubernetes的企业通常在管理容器资源请求和限制方面采用某些最佳实践，请参阅此处。对于大多数组织（包括我们的客户）来说，从分配给平台的命名空间（或OpenShift中的"项目"）开始并应用资源配额。此配额限制了部署在此命名空间中的POD所允许的资源量，而请求则保证不同的LOB不会超出群集调配资源。使用配额时，向Kubernetes提交应用程序的用户需要提供资源请求，原因如下：保持一定水平的服务质量（QoS）。这对于CPU密集型应用程序尤其重要，在这些应用程序中，当节点发生拥塞时，cgroup运行时可以强制执行请求的CPU。保证最少的资源。在Kubernetes中，内存不能被过度分配或交换，因此许多Java服务使用请求来确保JVM可以获得最小数量的内存，以减少OOM的风险。使多租户环境中的资源管理和计划更容易。这是与命名空间中定义的资源配额一起实现的，为每个应用程序或LOB提供自己的资源。挑战：如今的多租户最佳实践在管理和限制弹性方面仍然很复杂围绕管理资源请求的最佳实践提供了一些可管理性，但在规模上，我们的客户仍然面临挑战。由于为服务指定的资源请求是估计值，因此群集很容易陷入以下情况：对资源的高估。很常见的情况是，估计的资源使用量明显高于实际使用量。可以理解的是，开发人员在资源使用需求上往往过于保守。他们经常请求具有大缓冲区的资源，这样他们的服务就不会受到影响。资源低估。这种情况下，实际的资源使用率高于请求的使用率，这可能会导致嘈杂的邻居问题，或者更糟的是过度使用的节点，在这种情况下，由于资源压力（对于不可压缩的资源，如内存），pod可能会被逐出。这种资源争用导致应用程序性能差，客户体验差。问题的症结在于，开发者只看到自己的服务，并对他们的服务负责。一个多租户集群将托管许多服务，每个服务都有自己的规范，这些服务没有考虑到一起运行的复合效应。即使100个服务都只超额分配了10%，集群或项目的总和需求将显示为"满"而不是。你不可能在这些节点上浪费更多的钱，结果是你不能在这些节点上浪费更多的钱这是一个非常困难的挑战。DevOps和SRE团队都对此感到担忧。当搜索数百个甚至只是50个运行在不同项目中的不同服务时，很难看到过度分配的影响以及优化的位置。DevOps和SRE都需要了解：服务分配过度项目/命名空间分配不足集群规模过小。 要求是弹性和效率的无声"杀手"。Turbonetic如何帮助您有效管理Kubernetes多租户在Turbonomic6.4中，我们介绍了Kubernetes集群中资源请求的发现。这使客户能够：可视化从pod到节点再到命名空间和集群的栈的所有级别上的资源请求量。可视化各级资源请求的历史趋势。在下面的UI屏幕截图中，Turbonic显示了顶级虚拟机（节点），在本例中按CPU请求排序（图1）。您还可以查看一段时间内CPU实际使用情况与CPU请求的比较，在本例中是过去2小时（图2）。图1。按CPU请求排序的顶级虚拟机。 图2。2小时内节点上的实际CPU使用率与CPU请求。但是集群级别的视图是不够的。由于资源是按命名空间分配的，因此您还需要查看每个命名空间的保证和实际利用率，这样可以更好地为每个LOB提供"自助服务"，以查看它们使用保留内容的效率。对于平台团队，它允许他们发现哪些项目正在耗尽资源，哪些项目没有资源（请参见图3中的单个名称空间示例）。对于那些正在填充的项目，您可以根据实际使用情况评估它是否已满，或者请求的数量超出了需要的数量，这可能是优化其中工作负载的一个机会。对于LOB或App团队，他们可以从查看命名空间利用率开始，深入查看其命名空间中的特定pod。图3。实际的CPU/Mem使用率与名称空间的CPU/Mem请求相比，用户可以看到部署在那里的pod的调整大小操作。最重要的是，Turbonomic可以确定是否有机会调整请求大小并整合节点上的资源（"移动"pods）以容纳更多的pod。注意图1中右边的"Actions"按钮。在集群层面上，TurboEnomics还将决定船上新服务或项目的可用容量。通过对请求与实际使用情况的可视化（图1和图2），客户可以快速看到分配的内容和正在使用的内容之间的差异。但当你在规模监控和仪表板操作是不够的。Turbonomics自动识别优化集群性能和效率的机会，您可以将其自动化！自动确保连续性能，同时最大限度地提高效率是涡轮经济的关键所在。这是自虚拟化时代以来我们一直在做的，那时应用程序首次开始在共享环境中运行。为了保证应用程序的实时性和完整性，需要对底层资源进行精确的分析。它生成可以而且应该自动化和/或集成到组织现有工作流中的特定操作，即：Move actions将pods从具有完全请求利用率的节点移动到请求利用率较低的节点。图4：Turbonic确定两个容器吊舱当前在节点上遇到拥塞，应该将其移动到一个有容量的节点上。请注意，在吊舱崩溃之前，Turbo确定了在何处和何时移动哪个吊舱，这是k8s编排器中的一个缺口！优化连续放置决策，以便请求利用率不会超过可分配的容量（也称为逐出区域！）。当请求与实际使用量相比被高估时，生成调整资源大小的请求。当所有现有节点因资源请求而拥塞时生成供应节点操作。图5:Turbonic确定集群需要另一个节点来支持它正在运行的应用程序。 有了涡轮力学的多对映体并不意味着你必须限制弹性限制和请求旨在使管理多租户更容易。他们在一定程度上做到了。但正如我所讨论的，由于人们在一天结束时都在做出分配决策，所以会出现一些挑战。他们不得不估算并增加缓冲区，因为他们不能全天候分析动态需求。它会使应用程序的性能处于风险之中，它可能会不必要地增加成本，并且会限制弹性，这就是为什么您在Kubernetes进行投资的原因。有了TurboEconomics软件连续自动地为您做出资源决策，您可以在不限制应用程序弹性的情况下实现多租户的基本好处。