【.com快译】我第一天使用Kubernetes将我的应用程序容器化并部署到生产集群。我正在从单体应用程序迁移Buffer的最高吞吐量（和低风险）端点之一。这个端点造成越来越多的麻烦，偶尔会影响其他更高优先级的流量。在使用curl进行一些手动测试后，我们决定开始将流量转移到我们在Kubernetes上的新服务。在1%的负载下，一切看起来都很棒；然后高达10%，仍然很好；然后高达50%，突然服务开始进入崩溃循环。我的第一反应是将服务从4个副本增加到20个。这有点帮助，服务处理流量，但pod仍然陷入崩溃循环。在使用kubectldescribe进行一些调查后，我了解到Kubelet正在终止pod由于OOMKilled，即内存不足。我进行了更深入的研究，并意识到在从另一个部署复制粘贴YAML时，我设置了一些过于严格的内存限制。这段经历让我开始思考如何有效地设置请求和限制。1.请求与限制Kubernetes允许设置可配置的请求和资源限制，例如CPU、内存和本地临时存储（v1.12中的测试版功能）。CPU等资源是可压缩的，也就是说可以通过CPU管理策略来限制容器。内存等其他资源由Kubelet监控，并在超过限制时终止。使用不同的请求和限制配置，可以为每个工作负载实现不同的服务质量。1.限制限制是允许工作负载消耗的上限。超过请求的限制阈值将触发Kubelet终止pod。如果不设置限制，工作负载将消耗节点上的所有资源。如果运行多个工作负载没有限制，资源将在尽力而为的基础上分配。2.请求调度程序使用请求为工作负载分配资源。工作负载可以在没有Kubernetes干预的情况下使用所有请求的资源。如果没有设置限制并且超过了请求阈值，容器将被限制为只能使用请求的资源。如果设置了限制但未设置请求，则请求的资源将匹配请求的限制。3.服务质量有三种基本类型的服务质量(QoS)可以通过资源和约束来实现——最佳QoS配置取决于工作负载的要求。图14.有保证的QoS有保证的QoS可以仅通过设置限制来实现。这意味着容器可以使用调度程序为其配置的所有资源。对于受CPU限制和相对可预测的工作负载（例如Web服务器处理请求）来说，这是一个很好的QoS。图25.突发QoS突发QoS通过设置请求和限制（请求低于设置）来配置。这意味着容器保证使用配置请求的资源，并且如果在节点上可用，则可以使用全部配置的资源配额。这对于短暂使用资源或需要密集初始化过程的工作负载很有用。一个示例是构建Docker容器或运行未优化的JVM进程的容器的工作节点。图36.BestEffortQoSBestEffortQoS是通过既不设置请求也不设置限制来配置的。这意味着容器可以使用计算机上的任何可用资源。从调度程序的角度来看，这是最高优先级的任务，将在BurstQoS和GuaranteedQoS配置之前终止。这对于可中断的、低优先级的工作负载很有用，例如迭代运行的幂等优化过程。图42.设置请求和限制要设置合理的请求和限制，关键是要找到单个pod的断点。通过使用几种不同的负载测试方法，您可以在应用程序投入生产之前了解其不同的故障模式。几乎每个应用程序在被推到极限时都有自己的一组故障模式。要准备测试，请确保将副本数设置为1，并从一组保守的限制开始，例如：#limitsmightlooksomethinglikelikereplicas:1...cpu:100m#~1/10thofacorememory:50Mi#50Mebibytes请注意，限制是在这个过程中使用重要的是为了清楚地看到结果（当内存使用率很高时节流CPU和终止pod）。测试迭代完成后，一次更改一个资源限制（CPU或内存）。1、ramp-up测试ramp-up测试逐渐增加负载，直到服务不堪重负而失败或测试完成。图5.如果启动测试突然失败，则表明资源限制过于严格。当观察到性能突然变化时，将资源限制加倍并重复测试，直到测试成功完成。图6随着资源限制接近其最大值（至少对于Web样式的服务而言），性能趋于逐渐稳定地下降。图7如果负载增加时性能没有变化，则工作负载可能分配了太多资源。2.持续时间测试运行ramp-up测试并调整限制后，可以进行持续时间测试。持续时间测试包括在一段较长的时间内（至少10分钟，但越长越好）添加一致的负载，但刚好低于断点。图8此测试的目的是识别在短期启动测试期间无法发现的内存泄漏和隐藏的排队机制。如果在此阶段进行调整，它们应该很小（变化>105）。良好的结果将表明性能在测试期间保持稳定。图93.为测试阶段保留故障日志时，记录服务在失败时的执行情况至关重要。可以将故障模式添加到运行手册和文档中，这在解决生产环境中的问题时很有用。我们在测试时发现了一些观察到的故障模式：内存缓慢增加CPU卡在100%500s响应时间过长3.实用工具虽然可以使用ApacheBench等工具来增加负载，也可以使用cAdvisor等工具直观地显示资源利用率，但有些工具更适合设置资源限制。1.Loader.IOLoader.io是一个托管负载测试服务。它允许您配置启动测试和持续时间测试，在测试运行时可视化应用程序性能和负载，并快速启动和停止测试。存储测试结果历史记录，以便在资源限制发生变化时轻松比较结果。图102.KubescopeCLIKubescopeCLI是一种在Kubernetes（或本地）中运行并直接从Docker收集和可视化容器指标的工具。它使用诸如cAdvisor或其他集群指标收集服务之类的工具，每秒而不是每10-15秒收集一次指标。以10到15秒的间隔，您有足够的时间在测试期间错过瓶颈。使用cAdvisor，您必须为每个测试找到新的pod，因为Kubernetes会在超过资源限制时终止pod。KubescopeCLI通过直接从Docker收集指标（可以设置您自己的间隔）并使用正则表达式来选择和过滤您想要可视化的容器来解决这个问题。图11结论我有很多经验，只有当您知道它何时以及如何中断时，服务才可以投入生产。希望您能从我的错误中吸取教训，并使用其中一些方法在已部署环境中设置资源限制和请求。这将为您的系统增加弹性和可预测性，从而使客户满意，并希望您安心。原标题：OptimizingKubernetesresourceallocationinproduction，作者：HarrisonHarnisch
