水平扩展，尤其是自动扩展，是许多应用程序面临的共同挑战，无论其架构方法（单体或微服务）和部署环境（云或本地）如何。今天的云提供商提供了丰富的选项和工具来满足这一关键需求，即能够根据指定的规则以有效的方式向上或向下扩展服务实例，以便： 

• 避免不可用

• 保证服务质量 

• 优化资源利用率

• 避免不必要的费用

许多开箱即用的解决方案都依赖 Kubernetes 并提供各种级别的抽象，以使此过程尽可能顺利。然而，在很多情况下，我们并不真正需要或负担不起所有这些云产品即服务，或者我们需要在本地运营我们自己的数据中心。正如上一篇文章“看，妈妈！没有 Pod！ ”中所述，HashiCorp Nomad是一种简单而灵活的部署工具，能够管理运行在本地、云或混合环境中的容器和非容器化应用程序。最近，Nomad 通过 Nomad Autoscaler Agent 提供了自动缩放功能。如Nomad Autoscaler Overview中所述，支持以下策略：

水平应用程序自动缩放：这是自动控制应用程序实例数量以具有足够的工作吞吐量以满足服务级别协议 (SLA) 的过程。

Horizontal Cluster Autoscaling：  从集群中添加或删除 Nomad 客户端以确保为计划的应用程序提供适当数量的集群资源的过程 

动态应用程序大小调整：企业功能，使组织能够使用 Nomad 的大小调整建议来优化应用程序的资源消耗

在本文中，我们将深入研究横向应用程序自动缩放用例。更具体地说，我们将：

1. 使用 HashiCorp 的 IaC 工具Terraform在 Google Cloud 的计算引擎虚拟机上启动一个最小的 Nomad/Consul 集群。

2. 通过 Nomad 部署以下组件：Autoscaler Agent、HAProxy Load Balancer、Prometheus 服务器、Spring Native 应用程序和Redis独立服务器，应用程序将其用作内存数据存储。

3. 针对 Spring 应用程序生成一些负载，以触发自动缩放过程并观察整个系统的行为。

先决条件 

为了能够运行您需要的一切：

• 创建一个新的 Google Cloud 帐户或登录现有帐户

• 创建一个新的谷歌云项目（指南在这里）

• 下载Google Cloud 命令行界面 (gcloud CLI)并将其安装到您的开发机器

• 下载并安装HashiCorp Packer

• 下载并安装Terraform

然后您需要克隆以下 GitHub 存储库：

• Terraform Google Nomad：包含用于在 GCP 上配置 Nomad/Consul 集群的 Terraform 脚本。这实际上是 HashiCorp* 的一个分支，应用了以下调整：

• 更新了 Ubuntu、Nomad 和 Consul 版本

• 在每个配置的 VM 上安装 Docker 守护程序的附加项

• Nomad 配置更改以启用遥测并将指标导出到 Prometheus

• 对 Terraform .tf 文件的最小更改以避免最新版本的 Terraform CLI 出现错误

• Spring Boot Yaus包含用于演示的示例 Spring Boot 本机应用程序的源代码、用于其部署的 Nomad 作业文件以及用于负载测试的 JMeter 测试计划

*旁注：选择特定的叉子是因为在撰写本文时熟悉它。我们鼓励您还检查最近的nomad/terraform GitHub 存储库，特别是如果您需要运行 Nomad/Consul 集群 localhost 或使用另一个 Cloud Provider。 另一种选择是使用 Caravan 开源工具。请记住，如果您有兴趣使用 Vagrant 在本地 Windows 机器上运行集群，则需要禁用 Hyper-V 功能，这可能会对 Docker 桌面造成副作用。 

启动一个 Nomad/Consul 共存集群

建立一个谷歌形象

打开您的 gcloud CLI 并通过执行以下命令对您的帐户进行身份验证：

gcloud auth application-default login

在 gcloud CLI 中，将目录更改为 ` terraform-google-nomad/examples/nomad-consul-image` 文件夹。然后执行：

packer build nomad-consul.json

这将需要一些时间，当构建完成时，它将输出生成的新 Google Image 的名称，例如“ nomad-consul-ubuntu18-2022-11-11-110511”。这实际上是一个 Ubuntu 镜像，安装了 Nomad & Consul 客户端/服务器二进制文件和 Docker。为下一步保留图像名称。

自定义 Terraform 输入变量 

从 gcloud CLI 中，返回到 ` terraform-google-nomad` 根目录并编辑variables.tf文件以指定： 

• 将启动所有资源的 GCP 项目的名称

• 您希望配置 VM 的 GCP 区域和区域

• 集群的大小（服务器和客户端的数量）

• 为每个节点类型运行的计算实例的机器类型

• Nomad/Consul Server 集群的命名空间

• Nomad 客户端集群的命名空间

• 用于启动 Nomad/Consul Server 集群中每个节点的 Google Image

• 用于启动 Nomad 客户端集群中每个节点的 Google Image

对nomad_consul_server_source_image和都使用相同的 Google 图像标识符nomad_client_source_image。基于现有设置，Terraform 配置将负责在客户端或服务器模式下自动执行 Nomad 和 Consul。完成后，保存并退出编辑器。

规划和部署基础设施

现在，您可以从克隆项目的同一个根文件夹执行：

terraform init

然后你可以运行：

terraform plan

如果计划看起来不错，请运行：

terraform apply

该过程完成后，您可以查看从 Google Cloud Console 提供的 VM 实例。它应该如下所示：

请注意，使用 nomad-server-* 机器的外部 IP，您应该能够分别访问 Nomad 和 Consul 管理HTTP://<nomad-server-external-ip>:4646界面HTTP://<nomad-server-external-ip>:8500。Terraform 已经处理了所有内部和外部网络和防火墙管道，以便集群能够正常运行并且易于访问，当然仅用于测试目的。

部署服务器和应用程序

现在我们已经启动并运行了 Nomad 和 Consul 集群，我们可以继续部署 Nomad Autoscaler Agent、Prometheus、HAProxy 和示例微服务及其所需的 Redis 服务器。 

导航到您的 Nomad 管理 UI，选择“运行作业”并在作业定义区域粘贴autoscaler.nomad作业的内容。选择“计划”，如果看起来没问题，请按“运行”。对haproxy.nomad和prometheus.nomad重复该过程。

请注意，在我们的 Nomad Job 文件中，我们使用了所谓的模板节。这是一种动态生成配置文件的强大方法，这些文件由环境变量、Consul 服务发现元数据、HashiCorp Vault 机密等填充。让我们看看它有何用处，尤其是对于 HAProxy 的配置。查看 haproxy.nomad 文件中的以下摘录：

纯文本1个

后端 http_back

2个

    平衡循环法

3个

    服务器模板 mywebapp 10 _demo-webapp._tcp.service.consul 解析器 consul resolve-opts allow-dup-ip resolve-prefer ipv4 检查

通过上述配置，HAProxy将能够通过Consul Service Registry动态发现它将负载平衡的应用程序实例（IP 和端口）。无需静态或手动更新配置，一切都由服务名称引用！很酷，对吧？ 

您可以通过运行redis.nomad和demo-webapp.nomad来完成部署。

到目前为止，从理论上讲，您应该已经启动并运行了所有内容，所以我们从 Nomad UI Jobs 列表视图中获得了一个概览：

以及 Consul UI 服务列表视图：

Nomad 自动缩放器基础知识

下图描绘了HashiCorp Nomad Autoscaling Tech Preview中最初描述的 Nomad Autoscaler 架构，重点关注水平应用程序扩展：

对于自动缩放应用程序，Nomad 提供了一个插件接口，通过它我们可以连接多个数据存储以获取指标。例如，如果使用 Prometheus 进行监控，我们可以轻松地将其与Prometheus插件集成，并使用 PromQL 表达式定义扩展策略。

让我们看一下来自 Spring 微服务 Nomad Job的缩放节：

JSON

scaling {       enabled = true       min     = 1       max     = 4        policy {         evaluation_interval = "2s"         cooldown            = "5s"          check "cpu_usage" {           source = "prometheus"           query  = "avg(nomad_client_allocs_cpu_total_percent{task='server'})"           strategy "target-value" {             target = 25           }         }       }     }

简而言之，我们声明如果运行此任务的节点的平均 CPU 负载达到 25%，我们希望 Nomad 扩展到我们应用程序的 4 个实例。有很多替代方案可以尝试，只要 Prometheus 中存在您感兴趣的指标！

生成负载并观察

是时候使用此处提供的示例 JMeter 测试计划生成一些流量了。需要用JMeter打开，在“HTTP Request”部分修改Server IP Address：

示例 Spring Boot 本机应用程序

示例应用程序是一个简化的“URL 缩短器”，并公开了 2 个可以通过 HA_Proxy 的外部 IP 和端口访问的端点。

特定应用程序是使用 Docker 映像中的 Cloud Native Buildpacks 构建的 Spring Boot 本机应用程序。 Spring Native支持使用GraalVM本机图像编译器将 Spring 应用程序编译为本机可执行文件。与 Java 虚拟机相比，使用本机映像具有关键优势，例如即时启动、即时峰值性能和减少内存消耗。因此，就自动缩放而言，我们肯定可以从所有这些优势中受益！

 完整的源代码和 Nomad 作业文件可在 GitHub 上的 Spring Boot 本机应用程序演示中获得（本文前面的链接）。

普罗米修斯用户界面

一旦流量开始激增，CPU 负载增加，您可以从 Prometheus UI 观察并确认：

Nomad 和 Consul 可观察性

同时，您还可以从 Nomad UI 跟踪 Nomad Autoscaler 代理日志：

确认 Nomad 开始启动更多应用程序实例，并遵守我们的扩展策略。查找 、 和可能的错误或警告之类的行target=nomad-target from=1 to=2 reason="scaling up because the factor is XXX"，target=nomad-target from=2 to=1 reason="scaling down because the factor is YYY"这些错误或警告可能表明您需要应用更复杂的调整。 

额外的实例由 HAProxy 负载均衡器动态发现并开始分担它们的负载。服务实例的数量、它们的 IP 和端口也可以在 Consul 管理 UI 中看到。 

撕毁它

一旦停止JMeter 负载测试，最终应用程序将缩小并保持单个实例运行。 

最后，您可以通过在 gcloud CLI 中执行以下命令来继续“销毁”临时 GCP 测试台：

terraform destroy

结束语

水平扩展是几乎所有解决方案的关键特征；因此，它的架构必须能够在需要时支持它。自动缩放并不总是强制性的，尤其是当我们处理非常可预测的工作负载时。在本指南中，我们介绍了 HashiCorp Nomad 的方法，将 Spring Boot 原生微服务作为扩展目标。

本文由本站原创或投稿者首发,转载请注明来源！

本文链接：http://www.ziti66.com/net/html/177.html