“完美风暴”（用来形容众多负面因素的偶然叠加形成的巨大灾难）一词可能听着很普通，但用来形容失控的云计算成本再合适不过了。几个因素相互叠加导致了这场“完美风暴”：
- 工作负载的部署者和购买者不是同一群体
- 基于编程自动化按需扩展的使用方式，很容易引起基础架构的超量使用
- 易于访问的代码仓库使得从他人编写的现有代码中“借用”功能变成可能
- CI/CD 流水线和 SRE 实践有助于开发人员快速集成和部署代码
以上条件叠加在一起，导致我们目前的状况是，开发人员更倾向于利用现有的代码块快速部署新功能，而这些代码块通常没有针对其在新应用中的用途进行简化或优化。由于上市时间是首要任务，他们将代码优化放在了后面考虑（非常靠后）。如果未经优化的代码影响了性能，仅需一个API调用，从而配置一个更强大的基础架构以缓解，问题就这样解决了！
造成问题的原因是，代码编写者和财务管理者思维方式和组织结构的不同。面对企业日益增加的云成本，首席财务官就像热锅上的蚂蚁急得团团转。然而，作为更为昂贵的云架构账单的“始作俑者”，开发人员因为快速交付产品而获得了奖励，往往忽视了下游财务问题。
为了解决这个问题，F5 NGINX 和 Opsani 联手打造了一种优化解决方案，让 NGINX Ingress Controller 用户从现有部署中获得更多优势。如果将 Opsani Servo 容器部署到 KubeNest 工作负载中，NGINX Ingress Controller 就可以利用 Prometheus 收集速率、错误和持续时间 (RED) 指标，从而得到进一步优化。Opsani 使用其自主优化功能（由机器学习提供支持）不断优化基础架构，以确保在提高性能的同时只消耗适量的资源，从而降低成本。
使用云优化降低成本
NGINX 用户已经熟悉了最基本的降低云成本的方法，通过使用增加极少时延却可交付极高性能的轻量级工具。当然，在 Kubernetes 的世界中，简单而强大的工具是成功部署的先决条件。本文解释了如何利用以下三个工具来降低成本并提高性能：
- 基于 NGINX Plus 的 NGINX Ingress Controller —— 它无需事件处理程序或重载配置，即可动态适应后端端点的变化，且其性能远超其他基于 NGINX 的 Ingress Controller。
- Opsani —— 一种独特的“持续优化即服务 (COaaS)”解决方案，它能够将 CO（持续优化） 添加到 CI/CD 流水线中，从而帮助您快速交付和优化代码，以尽可能低的成本提供最出色的性能。
- Prometheus —— 具备监控和告警功能的热门开源项目。借助 NGINX Plus Prometheus 模块，基于 NGINX Plus 的 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 Summary页报告了一段时间内的流量（每秒请求数 RPS），并突出显示了与基线设置相比优化所带来的优势（此处，每小时实例成本减少了 70%，P50 响应时间缩短了 5%）。
我们想知道，与最著名的 Ingress Controller 之一 —— 由 Kubernetes 社区维护的基于 NGINX 开源版的 Ingress Controller（在 GitHub kubernetes/ingress-nginx 仓库中）相比，结果将会如何。（根据 NGINX 的既定惯例，我们在后文称其为“社区版 Ingress Controller”。基于 NGINX Plus 的 NGINX Ingress Controller 由 NGINX 工程团队在 GitHub 的 nginxinc/kubernetes-ingress 仓库中维护，同一个仓库中还有它的姐妹版，即基于 NGINX 开源版的 Ingress Controller。）
我们使用三种拓扑测试了这两种 Ingress Controller 的性能：
-
拓扑 1 —— 社区版 Ingress Controller，使用 标准流程部署。通过在应用 pod 的 sidecar 容器内添加与被测应用内联的 Envoy 代理来收集指标。
-
拓扑 2 —— 基于 NGINX Plus 的 NGINX Ingress Controller，使用 Helm 部署。使用与社区版 Ingress Controller 相同的 Envoy 部署和配置收集指标，以确保指标的收集不会影响优化性能的过程。
-
拓扑 3 —— 基于 NGINX Plus 的 NGINX Ingress Controller，也使用 Helm 部署。使用 Prometheus 收集指标。
下表总结了测试的结果。可以看到，相比社区版 Ingress Controller，NGINX Ingress Controller 可实现更高的成本优化、CPU 优化和内存优化。这得益于 NGINX Ingress Controller 更高效的负载均衡功能。
P50 响应时间的测试结果表明，Prometheus 是理想的指标收集方式，因为它消除了 Envoy sidecar 机制所需的额外跃点。Envoy 对社区版 Ingress Controller 的 P50 响应时间没有影响，但实际上导致 NGINX Ingress Controller 的延迟增加了 4%。相反，Prometheus 将 NGINX Ingress Controller 的 P50 响应时间缩短了 5%。
| 拓扑 | 成本降低 (%) | P50 响应时间 (%) | CPU 优化 (%) | 内存优化 (%) |
|---|---|---|---|---|
| 1、搭配使用社区版 Ingress Controller 和 Envoy | 44 | 0 | 44 | 44 |
| 2、搭配使用 NGINX Ingress Controller 和 Envoy | 70 | 4 | 63 | 81 |
| 3、搭配使用 Ingress Controller 和 Prometheus | 70 | -5 | 63 | 81 |
有关详细的测试方法信息，请参阅下文“附录”一节。
Opsani 如何优化 NGINX Ingress Controller
即使应用是在动态环境中负载均衡情况不佳，Opsani 也可以对其进行优化。它还可以利用任何类型的输入指标，但是只有当这些输入信息是来自于收集网络指标的现有工具时，对于连接的服务才会得到明显的优化。为此，我们使用了一个简单的部署过程来集成 Opsani 与 NGINX Ingress Controller。
首先，在将 NGINX 用作 Ingress Controller（像如今许多应用那样）的环境中，直接换成使用基于 NGINX Plus 的 Ingress Controller，从而获得更有效的负载均衡算法且不会影响应用的功能。这样做的第二个好处是还可以获得由 NGINX Ingress Controller 实施负载均衡的应用的各项指标数据。
除此之外，需要做的就只是在需要优化的 namespace 下的应用中部署一个单独的 Opsani pod 即可。基于 NGINX Plus 的 NGINX Ingress Controller 的 Opsani 模板可以将指标的端点指向 Ingress 服务，以获取优化所需的特定应用指标。通过处理来自三到四个高峰期的指标，Opsani 引擎可在短短几小时内达到最佳优化水平。到目前为止，我们已经实现了从 30% 到 70% 的峰值负载优化。
立即试用 Opsani 和 NGINX Ingress Controller
申请 NGINX Ingress Controller 和 Opsani 免费试用版，然后前往我们的 GitHub 仓库 获取带 Prometheus 的 NGINX Ingress Controller 和 Opsani 的配置文件。
附录：测试方法
Prerequisites
- 将基于 NGINX Plus 的 NGINX Ingress Controller 构建成容器。
- 完成Kubernetes的集群部署，且具备容器私有仓库访问密钥以实现容器仓库的安全访问。
- 通过 Helm 将基于 NGINX Plus 的 NGINX Ingress Controller 部署到 ingress namespace。
- 将 NGINX VirtualServer resource 资源配置为指向要优化的服务（通常是默认的前端服务）。请参阅 Github 仓库中的 frontend-virtualserver.yaml。
拓扑和配置
我们创建了三个 Opsani 实例。对于 拓扑 1 和 2，我们使用适用于所有 Opsani 账户的标准 Opsani Dev 模板，简单地使用 NGINX Ingress Controller 的前端应用，并指向应用服务。
对于 拓扑 3, 我们使用相同的默认模板，并使用 GitHub 仓库中的 opsani-manifests-nginx-plus.yaml 中定义的 ConfigMap 修改 Servo 配置。与标准模板一样，我们为 ConfigMap 中的以下变量替换了适当的值：
{{ NAMESPACE }}—— 目标资源 namespace{{ DEPLOYMENT }}—— 目标部署{{ CONTAINER }}—— 目标应用容器名称
此外，我们根据应用部署时暴露的文档设置 OPSANI_ACCOUNT_NAME、OPSANI_APPLICATION_NAME 和 OPSANI_TOKEN。
虽然 Opsani Dev 默认的 ServoX 包含一个 Prometheus 实例，但我们将 Prometheus 实例部署在与 NGINX Ingress Controller 相同的namespace中，以减少对 ClusterRole 配置的需求。
我们还配置了一个服务，以允许 Servo pod 查找和查询正确的实例。该服务位于 opsani-manifests-nginx-plus.yaml。
Bank of Anthos 作为示例 Web 应用运行且 Ingress 验证完成后，我们启动 Ingress Prometheus 实例。最后，我们通过应用 opsani-manifests-nginx-plus.yaml 文件启动 Opsani 优化。
