使用 NGINX、Opsani 和 Prometheus 将云中的 Kubernetes 成本降低 70%

“这是一场完美风暴”可能是一句常用语，但在云计算成本失控的情况下，这句话很有用。 多种因素相互叠加，催生出这场完美风暴：

1. 部署工作负载的人不是支付工作负载的人
2. 可以很容易地按需和以编程方式使用基础设施
3. 易于访问的代码存储库可以“借用”其他人编写的现有代码的功能
4. CI/CD 管道和 SRE 实践可帮助开发人员快速集成和部署代码

综上所述，我们面临的情况是，开发人员会利用现有的代码块快速部署新功能，而这些代码块通常没有经过简化，也没有针对新应用的用途进行优化。由于上市时间至关重要，优化被搁置一旁（非常靠后）。 如果未优化的代码影响了性能，那么只需调用 API 即可配置更强大的基础架构。 问题解决了！

使问题更加复杂的是，编写代码的人和支付账单的人在思维方式和组织结构方面的分歧。 随着企业云成本的增加，CFO感到紧张。 但那些导致云计算费用上涨的开发人员却因其快速的产品交付而获得了回报，同时却对他们被激励去创造的下游财务问题一无所知。

为了解决这个问题，F5 NGINX 和Opsani合作推出了一种优化解决方案，使F5 NGINX Ingress Controller用户可以从现有部署中获得更多好处。 当Opsani Servo 容器部署到KubeNest工作负载中时，NGINX Ingress Controller 成为一种优化解决方案，它利用 Prometheus 收集速率、错误和持续时间 (RED) 指标。 Opsani 利用其自主优化功能（由机器学习提供支持）不断优化基础设施，以确保消耗适量的资源，从而实现更高的性能和更低的成本。

使用云优化来降低成本

NGINX 用户已经熟悉降低云成本的最基本方法：使用轻量级工具，在提供闪电般快速的性能的同时减少延迟。 当然，在 Kubernetes 的世界中，简单而强大的工具是成功部署的先决条件。 在这篇博客中，我们将解释如何利用三种工具同时降低成本并提高性能：

• NGINX Ingress Controller - 基于F5 NGINX Plus 的Ingress 控制器，其性能远远优于其他基于 NGINX 的 Ingress 控制器，因为它可以动态调整以适应后端端点的变化，而无需事件处理程序或配置重新加载。
• Opsani – 一种独特的持续优化即服务 (COaaS) 解决方案，可以将 CO 添加到您的 CI/CD 管道中，使您能够快速交付代码并以尽可能低的成本优化该代码以获得最佳性能。
• Prometheus——一个流行的监控和警报开源项目。 借助NGINX Plus Prometheus 模块，基于 NGINXPlus 的 NGINX Ingress Controller 可以将数百个指标导出到 Prometheus 服务器。

基于 NGINX Plus的 NGINX Ingress Controller 版本最强大的用例之一是它能够通过实时监控（通过NGINX Plus 仪表板）和历史数据（通过 Prometheus）提高 Kubernetes 中的可见性。 此外，作为工作负载的前端，NGINX Ingress Controller 可以收集速率、错误和持续时间 (RED) 指标并将它们（通过 Prometheus）提供给 Opsani。 Opsani 使用机器学习将指标与当前部署的基础设施关联起来，并建议优化 NGINX Ingress Controller、您的应用程序或整个技术堆栈的更改。 您甚至可以配置 Opsani 来提醒您有关 NGINX Ingress Controller 设置的延迟和性能阈值。

数字概览——我们的优化测试结果

让我们看一个示例，了解使用 Opsani 和 Prometheus 部署基于 NGINX Plus 的NGINX Ingress Controller 可以预期的结果。 如屏幕截图所示，Opsani摘要页面报告了一段时间内的流量（每秒请求数或 RPS），并突出显示了与基线设置相比其优化的优势 - 这里，每小时实例成本节省了 70%， P50 响应时间提高了 5%。

我们想知道这些结果与最著名的 Ingress 控制器之一——由 Kubernetes 社区在 GitHub kubernetes/ingress-nginx repo 中维护的基于 NGINX 开源的 Ingress 控制器相比如何。 （按照既定的NGINX 惯例，在本博客的其余部分，我们将其称为“社区 Ingress 控制器”。 基于 NGINX Plus 版本的 NGINX Ingress Controller 由 NGINX 工程团队在 GitHub nginxinc/kubernetes-ingress repo 中维护，以及基于 NGINX 开源的姊妹 NGINX Ingress Controller。)

我们在三种拓扑中测试了两个 Ingress 控制器的性能：

• 拓扑 1 – 社区 Ingress 控制器，使用标准流程部署。 通过在应用pod 中的 sidecar 容器中添加与被测应用内联的 Envoy 代理来收集指标。

  

• 拓扑 2 – 基于 NGINX Plus 的 NGINX Ingress Controller，使用Helm部署。 使用与社区 Ingress Controller 相同的 Envoy 部署和配置来收集指标，以确保指标收集不会影响优化性能过程。

  

• 拓扑 3 – 基于 NGINX Plus 的 NGINX Ingress Controller，也使用 Helm 部署。 使用 Prometheus 收集指标。

  

该表总结了测试结果。 可以看到，NGINX Ingress Controller 相比社区 Ingress Controller 实现了更好的成本降低、CPU 优化、内存优化。 我们将其归功于 NGINX Ingress Controller 更高效的负载均衡。

P50 响应时间的结果表明 Prometheus 是收集指标的理想方式，因为它消除了 Envoy 边车机制所需的额外跳数。 Envoy 对社区 Ingress 控制器的 P50 响应时间没有影响，但实际上使用 NGINX Ingress 控制器会使延迟增加 4%。 相比之下，Prometheus 使用 NGINX Ingress Controller 将 P50 响应时间提高了 5%。

有关我们如何运行测试的信息，请参阅附录。

Opsani 如何优化 NGINX Ingress 控制器

即使在动态环境中负载平衡不佳，Opsani 也可以优化应用。 它还可以利用任何类型的指标输入，但是当输入来自收集网络指标的现有工具时，连接服务的优化会得到显著改善。 为此，我们使用一个简单的部署过程将 Opsani 与 NGINX Ingress Controller 集成。

在 NGINX 作为入口控制器的环境中 - 适用于当今的许多应用- 直接切换到使用基于 NGINX Plus 的NGINX 入口控制器可以提供更高效的负载平衡算法，而不会影响应用的功能。 第二个好处是，由 NGINX Ingress Controller 负载平衡的应用指标也变得可用。

唯一的额外要求是在优化命名空间下使用应用部署单个 Opsani pod。 基于 NGINX Plus 的NGINX Ingress Controller 的 Opsani 模板将指标端点指向 Ingress 服务，以捕获优化所需的特定于应用的指标。 通过处理三到四个高峰期的指标，Opsani 引擎仅需几个小时就能达到最佳优化水平。 到目前为止，我们已经实现峰值负载优化从30%到70%。

开始使用 Opsani 和 NGINX Ingress Controller

获取NGINX Ingress Controller和Opsani的免费试用版，然后前往我们的GitHub repo获取 NGINX Ingress Controller 和 Opsani 与 Prometheus 的脚本和配置文件。

附录： 测试方法

先决条件

• 基于NGINX Plus的NGINX Ingress Controller是作为容器构建的。
• Kubernetes 已配置，并且注册表访问密钥可用于提供对安全的私有 Docker 注册表的访问。
• 基于 NGINX Plus 的NGINX Ingress Controller 通过 Helm 部署到ingress命名空间。
• 配置一个NGINX VirtualServer资源来指向要优化的服务（通常默认为前端服务）。 请参阅我们的 GitHut 仓库中的frontend-virtualserver.yaml作为示例。

拓扑和配置

我们创建了三个 Opsani 实例。 对于拓扑 1 和 2 ，我们使用适用于所有 Opsani 帐户的标准 Opsani Dev 模板，并使用 NGINX Ingress Controller 简单地将应用置于前端并指向应用服务。

对于拓扑 3 ，我们使用相同的默认模板，并使用 GitHub repo 中opsani-manifests-nginx-plus.yaml中定义的 ConfigMap 修改 Servo 配置。 与标准模板一样，我们用适当的值替换 ConfigMap 中的以下变量：

• {{ NAMESPACE }} – 目标资源命名空间
• {{ DEPLOYMENT }} – 目标部署
• {{ CONTAINER }} – 目标应用容器名称

此外，我们根据应用部署公开的文档设置OPSANI_ACCOUNT_NAME ， OPSANI_APPLICATION_NAME和OPSANI_TOKEN 。

虽然 Opsani Dev 的默认ServoX包含一个 Prometheus 实例，但我们将 Prometheus 实例部署在与 NGINX Ingress Controller 相同的命名空间中，以减少对 ClusterRole 配置的需要。

我们还配置了一项服务，以允许 Servo pod 找到并查询正确的实例。 该工件在opsani-manifests-nginx-plus.yaml中涵盖。

一旦Bank of Anthos作为示例 Web应用运行并且 Ingress 得到验证，我们就会启动 Ingress Prometheus 实例。 最后，我们可以通过应用opsani-manifests-nginx-plus.yaml文件来启动 Opsani 优化。