在生产中优化Kubernetes资源分配

我在Kubernetes的第一天涉及对应用程序进行docker化并将其部署到生产集群中。 我正在从单个应用程序中迁移Buffer的最高吞吐量（和低风险）端点之一。 这个特定的端点正在引起越来越大的痛苦，并偶尔会影响其他优先级更高的流量。

在使用curl进行了一些手动测试之后，我们决定开始将流量推向Kubernetes上的新服务。 在1％的情况下，一切看起来都不错，然后在10％的情况下仍然很棒，然后在50％的情况下，服务突然开始崩溃。 我的第一个React是将服务从四个副本扩展到20个。这有所帮助-服务正在处理流量，但pod仍然陷入崩溃循环。 通过使用kubectl describe进行的一些调查，我了解到Kubelet由于OOMKilled （即内存不足）而杀死了吊舱。 深入研究，我意识到当我从另一个部署复制并粘贴YAML时，我设置了一些过于严格的内存限制。 这段经历使我开始思考如何有效地设置请求和限制。

请求与限制

Kubernetes允许在CPU，内存和本地临时存储（v1.12中的beta功能）等资源上设置可配置的请求和限制。 CPU等资源是可压缩的，这意味着将使用CPU管理策略来限制容器。 Kubelet会监视其他资源（例如内存），并在超出限制时将其杀死。 使用请求和限制的不同配置，可以为每个工作负载实现不同的服务质量。

限度

要求

调度程序使用请求为工作负载分配资源。 工作负载可以使用所有请求的资源，而无需Kubernetes的干预。 如果未设置任何限制并且超过了请求阈值，那么容器将被调低到所请求的资源。 如果设置了限制并且未设置任何请求，则请求的资源与请求的限制匹配。

服务质量

资源和限制可以实现三种基本的服务质量（QoS）-最佳QoS配置取决于工作负载的需求。

保证的QoS

仅通过设置限制即可实现有保证的QoS。 这意味着容器可以使用调度程序已提供给它的所有资源。 对于受CPU约束且具有相对可预测的工作负载的工作负载（例如，处理请求的Web服务器），这是一个很好的QoS。

突发性QoS

通过同时设置请求和限制（请求低于限制）来配置可突发QoS。 这意味着容器可以保证达到配置的请求的资源，并且如果给定节点上有可用的资源，则可以使用整个配置的资源限制。 这对于具有短暂资源利用周期或需要大量初始化过程的工作负载很有用。 一个示例是构建Docker容器的工作者或运行未优化的JVM进程的容器。

尽力而为QoS

通过不设置请求或限制来配置尽力而为QoS。 这意味着容器可以占用计算机上的所有可用资源。 从调度程序的角度来看，这是最低优先级的任务，在可突发且有保证的QoS配置之前将被杀死。 这对于可中断和低优先级的工作负载很有用，例如，迭代运行的幂等优化过程。

设定要求和限制

设定良好要求和限制的关键是找到单个吊舱的断点。 通过使用几种不同的负载测试技术，可以在应用程序投入生产之前了解其不同的故障模式。 当将每个应用程序推到极限时，几乎每个应用程序都会有自己的一套失败模式。

要准备测试，请确保将副本数设置为一个，并从一组保守的限制开始，例如：

   
   

    
    
 
     
     # limits might look something like 
     
     

replicas 
     
     :  1
     
     


     
     ... 
     
     

cpu 
     
     :  100m 
     
     # ~1/10th of a core 
     
     

memory 
     
     :  50Mi 
     
     # 50 Mebibytes 
    
    
   
   

请注意，在过程中使用限制很重要，以清楚地看到效果（内存高时限制CPU并杀死Pod）。 随着测试迭代的完成，一次更改一个资源限制（CPU或内存）。

斜坡测试

逐步测试会随着时间的推移增加负载，直到负载下的服务突然失败或测试完成。

如果加速测试突然失败，则很好地表明资源限制过于严格。 当观察到突然的变化时，将资源限制增加一倍，然后重复直到测试成功完成。

当资源限制接近最佳时（至少对于Web样式的服务而言），性能将随着时间的推移而降低。

如果随着负载的增加性能没有变化，则可能分配了过多的资源给工作负载。

持续时间测试

在运行了加速测试并调整了极限之后，该进行持续时间测试了。 持续时间测试会在断裂点以下的延长时间内（至少10分钟，但越长越好）施加一致的负载。

该测试的目的是识别内存泄漏和隐藏的排队机制，否则它们不会在短期加速测试中被捕获。 如果在此阶段进行调整，则调整幅度应该很小（变化幅度大于10％）。 良好的结果将表明性能在测试期间保持稳定。

保留失败日志

在进行测试阶段时，记录服务失败时的性能至关重要。 可以添加故障模式来运行帐簿和文档，这在分类生产中的问题时很有用。 我们在测试时发现了一些观察到的故障模式：

• 记忆慢慢增加
• CPU固定为100％
• 500秒
• 高响应时间
• 请求已删除
• 响应时间差异很大

请将它们放在下雨天，因为有一天它们可以为您或队友节省一整天的分诊。

有用的工具

虽然可以使用诸如Apache Bench之类的工具来施加负载，而可以使用cAdvisor等工具来可视化资源利用，但是某些工具更适合于设置资源限制。

加载器

Loader.io是托管的负载测试服务。 它允许您配置加速测试和持续时间测试，在测试运行时可视化应用程序性能和负载，并快速启动和停止测试。 存储了测试结果历史记录，因此可以轻松地比较结果，因为资源限制发生了变化。

Kubescope CLI

Kubescope CLI是一种在Kubernetes（或本地）中运行的工具，可直接从Docker（无耻的插件）收集并可视化容器指标。 它使用cAdvisor或其他集群指标收集服务每秒（而不是每10-15秒）收集指标。 每隔10到15秒，就会经过足够的时间，您可能会在测试过程中错过瓶颈。 使用cAdvisor时，每次测试都必须寻找新的Pod，因为在超出资源限制时Kubernetes会杀死它。 Kubescope CLI通过直接从Docker收集指标（您可以设置自己的间隔）并使用正则表达式来选择和过滤要可视化的容器来解决此问题。

结论

我发现很难知道服务何时以及如何中断，直到服务才准备就绪。 希望您能从我的错误中学习，并使用其中的一些技巧来设置资源限制和部署要求。 这将为您的系统增加弹性和可预测性，这将使您的客户满意，并有望帮助您获得更多的睡眠。

---

哈里森·哈尼施（Harrison Harnisch）将于12月10日至13日在西雅图举行的KubeCon + CloudNativeCon North America上 展示利用资源限制和负载测试 充分利用Kubernetes 。

翻译自: https://opensource.com/article/18/12/optimizing-kubernetes-resource-allocation-production