跳到主要内容

如何扩展私有云基础设施：应对增长的策略

联系销售
免费试用

站内搜索

如何扩展私有云基础设施：应对增长的策略

从将代码提交到源代码控制到将其部署到云环境之间会发生很多事情。即使您从一个简单的应用程序开始，在构建基础架构时不考虑未来的可扩展性，也会在应用程序开始增长时导致各种问题。

部署后 Mendix 应用程序迁移到 Kubernetes 时，接收的流量可能会以不可预测的方式发生变化。如何让您的应用始终保持响应？

这就是扩展发挥作用的地方。您希望您的集群能够从容地处理负载，无论是流量高峰还是常规使用。 Mendix 私有云通过动态调整 Pod 数量来满足需求，从而实现这一点。在我们的 Connected 产品中，您可以从开发人员门户手动执行此操作，也可以直接在 Kubernetes 集群中启用 Horizo​​ntal Pod Autoscaler。很酷，对吧？

在本博客中，您将学习如何实现自动缩放 Mendix 基于特定于应用程序的自定义指标来监控应用程序。我们将使用 Horizo​​ntal Pod Autoscaler 和 Cluster Autoscaler 的组合。但等等，还有更多？是的，一个漂亮的 Grafana 仪表板 客制化 Mendix 让私有云能够实时可视化所有发生的一切！

Kubernetes 中的自动扩展——包括什么？

首先，让我们仔细看看 Kubernetes 中“自动缩放”一词的使用。在 Kubernetes 中，有几件事被称为“自动缩放”，包括：

Mendix 私有云支持上述所有内容，但它们都针对非常不同的用例并使用不同的概念和机制。

让我们探索有效扩展的策略。

扩展策略

如何针对给定需求获得最佳副本数量？如果能有一个数字指标来衡量您的应用当前的需求，那岂不是很棒？

对于扩展来说，合适的指标是表示应用程序当前负载的测量值。
以下是一些合适的扩展指标的示例：

  • 每个副本每秒接收的请求数。
  • 应用程序进程的 CPU 和/或内存使用情况。

（注：由于 Mendix 运行时基于 Java，它预先分配内存并且通常从不释放它，基于内存的指标不应用于自动缩放。）

这里的关键是找到一个最佳指标值（我们称之为 目标价值)，其中应用程序既没有过度使用，也没有利用不足。不幸的是，这说起来容易做起来难，因为每个应用程序的行为都不同。

例如，如果您指定 CPU 的最大使用率为 80%，则 HPA 控制器将在此副本集内所有 Pod 的平均使用率达到 80% 或更高时立即添加一个 Pod。这里的一个重要因素是您是否拥有 正确配置 pod 的资源请求和限制。我们的扩展策略应如下所示：

  • 如果观察值低于目标值（即应用程序利用率不足），则应减少副本数量，以便每个副本获得更高的利用率。这将导致指标值增加并更接近目标值。
  • 如果观察值高于目标值（即应用程序过度利用），则应增加副本数量，以便每个副本接收较小份额的总负载，从而导致度量值下降并更接近目标值。

资源请求和限制基础知识

Kubernetes 允许您指定单个 Pod 需要多少 CPU/RAM，以及如何限制给定 Pod 对这些资源的使用。在 Mendix 对于私有云，这可以通过我们的 开发者门户 或者，对于使用我们独立产品的客户，通过 编辑 MendixCR 目的。

资源请求和限制基础知识
Mendix 私有云 – 编辑资源请求和限制

内存单元

  • 内存单元通常以字节表示，但为了简单起见，Kubernetes 允许您使用更易于人类阅读的格式，例如兆字节 (MB) 或千兆字节 (GB)。
  • 您可以使用以下后缀来表示内存单元：
    • “Mi” 代表兆字节（2^20 字节）
    • “Gi” 代表吉比字节（2^30 字节）
    • “M” 代表兆字节
    • “G” 代表千兆字节

CPU单元

  • Kubernetes 中的 CPU 单元以“毫核”为单位，毫核是 CPU 核心的一小部分。
  • 1 个 CPU 核心相当于 1000 个毫核心。
  • 您可以使用“m”后缀来表示毫核，以指定 CPU 请求和限制。

例子

  • 100m 代表 100 毫核，也就是 0.1 个 CPU 核心。
  • 500m 代表 500 毫核，也就是 0.5 个 CPU 核心。

CPU 是一个绝对单位，也就是说，无论一个节点有多少个核心，1 个 CPU 都是一样的。

我们的 Mendix 应用程序部署配置了以下小尺寸模板值：

  • 100m 的 CPU 请求
  • 512Mi 的内存请求

Kubernetes 计算资源

模拟自动缩放

我们写这篇文章的目的是：

  • 模拟 Mendix 托管在 Kubernetes 集群中的应用程序。
  • 配置水平 Pod 自动缩放器来扩展 Mendix 实时中的应用程序副本 Mendix Kubernetes 环境运行于 Mendix 用于私有云连接模式。
  • 配置 Cluster Autoscaler 来扩展集群节点的数量，以分配新的副本 Mendix 应用程序。

在此示例环境中，我将托管我的 Mendix Azure AKS 中的群集。对于其他受支持的 Mx4PC 群集类型，请按照供应商推荐的方式配置 CA 功能。

有关如何部署 Mendix 应用程序，你可以查看本指南： https://docs.mendix.com/developerportal/deploy

在开始之前，最好先了解一些先决条件。您是否已经：

配置水平 Pod 自动扩缩器

让我们启用 HPA 并将指标设置为 80% CPU 使用率阈值：

# kubectl -n mendix-app autoscale mendixapp blogapp1-master --cpu-percent=80 --min=1 --max=3
horizontalpodautoscaler.autoscaling/blogapp1 autoscaled

配置集群自动扩缩器 (CA)

您可以启用 CA 从命令行 或 Azure 门户。在此示例中，我将最大节点数设置为 3：

扩展节点池

产生流量！

在下面的视频中，你可以在左上角看到我直接向 Mendix 通过在两分钟内发送 1000 个并发连接来应用。我使用 这个工具 在一个临时的吊舱内，但还有许多其他人可以做同样的事情！

Kubernetes 集群中的水平 Pod 自动缩放器视图

让我们探索一下相同序列在 Grafana 仪表板中的样子：

Grafana 仪表板中的水平 Pod 自动缩放器视图

一旦我们开始向 Mendix 应用中，我们观察到以下情况：

  1. CPU 使用率 blogapp1-master 应用范围从8米上升到100米以上（右上屏幕）。
  2. - 水平 Pod 自动缩放器 开始扩展 Pod。
  3. 又创建了两个 Pod。
  4. 其中一个 Pod 当前处于待处理状态，无法部署。现有节点中没有足够的空间来分配另一个 Pod。
  5. 几分钟后， 集群自动缩放器 确实触发并在集群中创建一个新节点（屏幕右下方）
  6. - 待审批 Pod 现已部署。

探索自动扩展前置时间

让我们总结一下所有内容是如何联系在一起的：

  1. 水平 Pod 自动缩放器反应时间。
  2. 集群自动缩放器的反应时间。
  3. 节点配置时间。
    • 然后，还有节点配置时间，这主要取决于云提供商。
    • 在 3 到 5 分钟内配置新的计算资源是很标准的。
  4. Mendix Pod 创建时间。
    • 开始 Mendix 运行时间通常不应超过 30 秒。
交期
交付周期自动缩放

在最坏的情况下，总延迟可能长达 7 分钟。还不错吧？然而， 在获得更多 pod 之前，您能否处理 7 分钟的突然激增的流量？

有没有什么方法可以调整自动缩放以减少缩放时间？

尝试调整一些默认值：

闭幕词

扩展和处理 Kubernetes 集群的增长乍一看似乎是一项艰巨的任务，但只要采取正确的策略并利用 Mendix 对于私有云，您已经做好了充分准备来驾驭这一激动人心的旅程。关键在于找到添加更多节点和优化现有节点之间的最佳平衡点。

最后再说一句——  Mendix 与应用程序容器密集型相比，应用程序往往相对数据库密集型，因此请确保（自动）扩展数据库。

快乐缩放！

选择你的语言