云原生应用自动化监控与编排的框架

摘要

在云原生实现时代，监控和自动化编排在管理这些应用的生命周期中起着重要作用。目前有许多可用的监控工具能够监控这些实现，但它们缺乏与应用相关的指标，同时自动化编排仍处于初级阶段。本文提出了一种框架，该框架结合与应用相关的指标以及绝对和相对指标，利用机器学习主动执行自动化编排以实现可扩展性。

索引术语 —云原生，监控，编排，机器学习

I. 引言

云计算领域最新的技术趋势是，软件公司正从单体系统转向云原生基础设施。由于云计算基础设施的改进和发展，云原生应用正在急剧增加。云原生应用运行在基于容器的环境中，以前开发的应用被封装成在容器中作为微服务运行的服务，并在弹性基础设施上进行管理。[1]. [2],[3]预测自动化将是云基础设施的下一阶段，今年收入将增加17%。在各种报告中，制造业、医疗保健和电信等不同领域的云原生应用均有所上升。

云基础设施管理一直是一个挑战。在此基础上，对这些云原生应用进行编排已成为一个重要方面，因为编排能够支持资源控制、异常检测、可扩展性、调度等广泛的操作[7]。通常，这类操作由管理员根据其经验手动完成。

目前存在许多容器编排平台，如Kubernetes[8], 红帽 OpenShift[9], Docker Swarm[10], 亚马逊EKS[11]，但这些编排平台仍存在一些局限性。卡萨利基奥等人[7]指出了当前编排操作的一些局限性，例如缺乏性能模型、没有统一的指标收集与关联标准、编排策略有限等问题。

如今，有许多监控工具可供使用，例如 Datadog [12], Dynatrace [13], LogicMonitor [14], 等，它们可以监控 Kubernetes 集群中每个 Pod 的资源利用率。但这些工具缺乏对应用本身进行深入的监控，例如延迟、处理的请求数量、当前正在运行的进程数量等。此外，这些监控工具仅支持监控和在 Pod 出现问题时发出警报，而编排决策完全依赖于集群所有者手动管理，这种方式在管理上效率低下。目前行业中缺少能够综合考虑系统行为，并主动且高效地对系统执行必要操作的编排工具。

本文提出了一种新的架构框架，用于对运行在 Kubernetes 集群中的云原生应用进行监控和自动化编排。该框架从应用层面、Pod 层面和节点层面监控指标。在编排方面，我们采用机器学习算法，基于应用、Pod 资源和节点资源提供的指标来预测未来的资源利用率，以实现横向扩展性。此外，我们设计了编排算法，根据机器学习算法对资源的预测结果做出横向扩展决策。我们通过一个案例研究，在两个场景下运行虚拟化 IP 多媒体子系统会话初始协议（SIP）[15]，对系统进行了测试和评估。同时，我们将本工作与 Kubernetes 原生 Pod 自动扩缩器进行了比较。

本文的组织结构从第二节的背景与文献综述开始。在第三节中，我们提出了用于自动化监控和编排的架构，第五节展示了对本框架的评估，第六节对本文进行了总结。

II. 背景与文献综述

在当前编排自动化研究趋势中，有许多研究正在进行。本节讨论了其中一些研究和最新技术。

监控运行在容器中的云原生微服务非常重要，因为这些微服务通常被隐藏在物理机和虚拟机之下。因此，常规方法类似于 TOP [16], 任务管理器等工具。而监控系统则支持多种编排操作，如诊断系统、故障预防等。文献[17]中的作者实现了一款开源轻量级容器资源监控工具，用于监控 Pod 的资源，主要面向资源受限设备。[18]提出了一种监控工具，用于监控相互连接的容器网络流量，以测量网络性能。

指标是系统生成的数值，例如资源、运行中的进程、系统告警、应用延迟等。在[19]中，作者阐述了为容器编排选择合适指标的必要性。根据作者的观点，Kubernetes 集群提供两种类型的指标：绝对指标，即物理主机（节点）的资源利用率；相对指标，即容器（Pod）的资源消耗。除了绝对和相对指标外，还有来自应用本身的指标，我们称之为应用指标。在[20]中，作者提出了一种使用 TOSCA 自动监控 Kubernetes 的方法。

编排使管理员能够执行不同的管理操作，如资源控制、集群中的故障调试、调度等。[7]解释了微服务环境生态系统中的自我优化和自我保护等不同编排操作。[21]讨论了编排问题与挑战。随后，作者提出了一种改进版 Kubernetes 水平 Pod 自动伸缩器，该方法使用绝对指标（节点）和相对（Pod）指标来决定自动伸缩[19]。[22]提出了一种基于机器学习的策略动态适应方法，用于容器化环境。[23]提出了一种基于计算机智能的方法，通过观察管理节点主机的异常行为来预测其可能的故障。[24]量化了资源利用率的影响以及各种请求的端到端尾部延迟的性能干扰。Al-Dhuraibi 等人[25]解释了如何在 Docker 容器中使用垂直弹性。[26]和[24]利用机器学习根据工作负载和 Pod 指标实现可扩展性。

表 I 展示了我们的工作与其他研究的比较，以及在这些实现基础上的附加价值。我们的实现考虑了所有不同类型的指标（相对、绝对和应用），以做出可扩展性的编排决策。

III. 架构

我们提出的架构如图1所示，该架构包含多个协同工作的模块，以实现自动化的监控和编排操作。此架构框架中的模块作为微服务运行在托管云原生应用的 Kubernetes 集群中。该框架监控运行云原生应用的集群，并根据云原生应用的行为做出扩容或缩容的编排决策。

框架中的每个模块独立工作，并具有特定功能。它们的功能如下：

• 监控模块 负责监控集群，并从节点、Pod 和应用层指标中收集指标。监控模块会频繁收集每个应用实例（副本）的指标，例如每两秒一次。各层面的不同类型指标包括：
• 节点级别指标包括副本所在节点的资源利用率，如 CPU、内存等。
• Pod 级别指标包括副本自身的资源利用率，如 CPU、内存、网络等。
• 应用指标包括与应用本身相关的特定数据，如正在处理的请求数量、请求延迟、副本处理延迟等。

监控模块聚合从应用、Pod 和节点收集的指标，然后将指标数据传输到执行器进行预测，同时传输到数据库进行存储。

• 数据库 用于存储从监控模块接收的指标。该数据库采用时序数据库格式来存储指标。当机器学习引擎请求数据集时，数据库会将数据转换为数据集。数据库获取该应用在一段时间内的指标，然后将该数据集发送给机器学习引擎。

• 机器学习引擎 是基于知识的，它定期从数据库中获取数据集，并为每个应用生成不同的资源预测模型。该机器学习引擎从数据集中选择一些特征，使用支持向量回归来构建模型。一旦模型生成，就会将其传递给执行器进行资源预测。

• 执行器 接收来自监控模块的每个副本的各项指标，并利用机器学习引擎生成的模型，预测每个指标数据未来的资源消耗。然后判断副本是否需要扩容或缩容。当需要扩容时，执行器检查预测的资源值是否高于该副本可用的资源量，若是，则向编排器发送该副本的部署名称和扩容命令。当需要缩容时，执行器检查资源利用率是否低于资源消耗的10%阈值，若是，则向编排器发送该副本的部署名称和缩容命令。

• 编排器 执行从执行器接收到的编排决策。一旦编排器收到编排决策，它将查询 Kubernetes 集群以获取副本的配置文件，然后根据扩容或缩容决策分别通过增加或减少副本数量来修改副本数。之后，它将更新推送到 Kubernetes 集群管理。

在我们的实现中，我们使用 Python 来部署每个模块，然后将其容器化，以便可以在 Kubernetes 集群中使用。为了监控 Kubernetes 集群，我们使用 Prometheus [29] 来监控节点、Pod 和应用指标。Scikit-learn [30] 因其丰富的机器学习算法而被采用。我们选择支持向量回归作为我们的机器学习算法，因为它允许利用多个特征对未来资源需求进行预测。

IV. 编排算法

算法1和2展示了编排算法，该算法可预测资源消耗的未来数值，并针对可扩展性做出编排决策，即增加或减少 SIP 服务器实例的 Pod 数量。

算法1 是主要的算法，它以列表形式接收监控模块在该时间实例收集的指标。此算法的第一步是从指标列表中获取 SIP 请求的数量，并将其插入到 SIP 列表的末尾，该列表保存了之前二十个 SIP 请求的数量。然后它根据 SIPList 的数值，找出 Pod 正在处理的 SIP 请求的趋势，该趋势可能是增加、减少或稳定。之后，计算 SIP 请求的平均值，并将其添加到指标列表中。通过取 SIP 请求的平均值，消除了系统的异常峰值。最后，利用 SIPList 确定 SIPTrend，以判断流量是增加、减少还是稳定。根据 SIPTrend，相应地调整 SIP 请求的数量，如算法所示，然后调用算法2进行可扩展性决策。

算法2 根据对未来指标的预测来决定 Pod 的扩容或缩容。该算法需要指标列表以及由机器学习引擎生成的机器学习模型。在算法开始时，它利用机器学习模型和算法1提供的数值来预测资源的未来数值。根据预测结果，如果所需资源：
- 大于已分配资源时，它会增加 Pod 的数量；
- 低于下限阈值时，会减少 Pod 数量；
- 不大于已分配资源且不低于下限阈值时，不执行任何操作。

算法1 执行器

需要：指标列表
来自指标的 SIP ← SIP 请求
在 SIP 列表中插入 SIP
SIP 趋势 ← 获取 SIP 趋势(SIP 列表)
SIP ← 平均值(SIP 列表)

如果 SIPTrend = 增加 则
SIP ← SIP + 20
更新指标列表中的 SIP 请求 ← SIP
调用算法2 使用 MetricsList
否则如果 SIPTrend = 减少 则
SIP ← SIP + 10
更新指标列表中的 SIP 请求 ← SIP
调用算法2 并传入指标列表
else if SIP 趋势 = 稳定 then
否
结束如果

算法2 预测器

需要：指标列表, 资源模型, 最低限制
未来 Pod CPU ← 预测 Pod CPU(指标列表)
未来 Pod 内存 ← 预测 Pod 内存(指标列表)
未来 Node CPU ← 预测 Node CPU(指标列表)
未来 Node 内存 ← 预测 Node 内存(指标列表)
未来延迟 ← 预测延迟(指标列表)

如果 未来 Pod CPU > 已分配 Pod CPU 来自 指标列表 或 未来 Pod 内存 > 已分配 Pod 内存，则
向编排器发送 增加 Pod
否则 如果 未来 Node CPU > 已分配 Node CPU 来自 指标列表 或 未来 Node 内存 > 已分配 Node 内存，则
向编排器发送 增加 Pod
否则 如果 未来延迟 > 延迟限制，则
向编排器发送 增加 Pod
否则 如果 未来 Pod CPU < 最低 Pod CPU 限制，则
向编排器发送 减少 Pod
否则
不执行任何操作
结束 if

V. 实验与评估

为了测试我们提出的架构的性能，我们通过一个包含两个测试场景的案例研究对其实现进行了实验。在实验中，我们使用了在 Kubernetes 集群中运行的微服务。监控系统对系统进行监控，并主动做出编排决策。

A. 测试平台

为了测试我们提出的自动化监控和编排框架，我们使用了在 Kubernetes 集群中运行的爱立信专有的云原生 SIP 实现。

系统名称	CPU	RAM	运行系统	Kubernetes 版本
主节点	8 核	8 GB	Ubuntu 桌面版 18.04.4	1.18.2
从节点 1	4 核	4 GB	Ubuntu 最小安装版 18.04.1	1.17.0
从节点 2	4 核	6 GB	Ubuntu 最小安装版 18.04.1	1.17.0
从节点 3	4 核	4 GB	Ubuntu 最小安装版 18.04.1	1.17.0

在我们的集群中，有一个主节点和三个节点。配置的详细信息如表 II 所示。所有节点均运行在最小化的 Ubuntu 上，以减少系统开销以及操作系统本身的资源消耗。SIP 服务器接收来自流量生成器[31]的 SIP 流量，对其进行处理，并将响应返回给流量生成器。系统的指标收集间隔设置为 2 秒，Enforce 基于这些指标主动做出决策。用于编排决策的算法细节将在下一节中讨论，该算法针对我们的测试平台。

B. 实验

我们使用了会话初始化协议（SIP）的虚拟化版本实现，该协议由运行在 Kubernetes 微服务中的 IP 多媒体子系统 [15]托管。我们使用 SIP 交通生成器[31]来生成 siptraffic。对于 Kubernetes 集群，我们有三个节点和一个运行 Ubuntu 的主节点。

为了测试我们的框架，我们设计了两个场景，第一个场景如图2所示，展示了生成的流量，其中流量在30分钟内逐渐增加至峰值，然后再逐渐减少。第一个场景代表系统的正常运行，在前15分钟内，流量从每秒0个SIP请求逐渐增加到每秒150个SIP请求，并在接下来的15分钟内重复该过程。

在第二个场景（图3）中，系统出现了一些异常流量行为。在此场景中，流量在短时间内突然发生变化。如图 3 所示，在 04:05 时流量从 60 个 SIP 请求突然增加到 120 个 SIP 请求，并在 5 秒内回落至 70 个 SIP 请求。同样的增加和减少情况在 05:50、15:00、18:20 和 28:30 再次发生。在 08:00、09:00、13:50 和 22:50 时，流量大幅下降后又突然上升。通过此场景，我们能够观察监控和编排系统是否能够保持云原生应用的副本数量稳定，且不会立即改变副本数量。

通过讨论的两个场景，我们将我们的实现与原生 Kubernetes 水平 Pod 自动扩缩容（HPA）[27], 进行了比较，结果如图4和图5所示。

图4 显示了在第一个场景（图2）中，我们的实现与 Kubernetes HPA 的副本数量增减情况以及二者之间的比较。如图所示，两个系统都能根据系统负载和流量负载增加或减少副本数量。根据我们提出的架构，系统能够在达到最大资源利用率之前主动扩容，并缓慢减少副本数量。而 HPA 则是在系统达到阈值时才进行扩缩容。如图所示，在最高流量时，我们的实现比 HPA 实现具有更多的副本数量；然而，HPA 能够比我们的实现更快地减少副本数量。由于我们的算法会检查 SIP 请求的趋势，并据此缓慢做出减少副本数量的决策，这有助于系统在流量突然增加时保持稳定。

当我们把两种实现引入第二个场景（图3）时，可以更好进行比较。在图5中，我们的实现能够基于算法1预测流量负载的峰值和低谷，从而做出比 HPA 更好的编排决策。如图5所示，我们的实现根据 SIP 趋势做出决策，因此不会突然增加或减少副本。而基于阈值的 HPA 实现并未考虑请求趋势或资源趋势，仅根据当前资源负载来决定副本的扩容或缩容，这间接导致频繁创建或删除容器，最终给系统带来压力。这就是为什么在30分钟内，HPA 会频繁地多次增加或减少副本数量。如图所示，HPA 通过一个简单公式计算所需副本数，因而随着流量波动频繁伸缩；而我们的实现则保持副本数量稳定。

总之，当流量逐渐增加和减少时，该系统表现良好，但我们的实现能够预测未来的资源消耗，并在任何副本达到其阈值之前做出扩容决策。当系统出现流量负载的峰值和低谷时，HPA 无法维持系统稳定性，这最终会增加系统的延迟。

VI. 结论

在本文中，我们提出了一种能够利用机器学习来监控和编排云原生应用的架构。该架构旨在弥补现有研究工作的局限性。我们在云原生环境中实现了该架构，并以 vIMS 作为测试案例，通过两种场景进行了验证。本文讨论了编排算法，该算法能够在突发流量异常时保持系统稳定，并能够主动且高效地做出扩缩容编排决策，同时对系统资源的额外占用极少或无占用。我们还将所提出的架构与原生 Kubernetes 水平 Pod 自动扩缩器进行了对比评估。在未来的工作中，我们计划引入新的编排功能，如云原生应用的动态流量管理、调度和容错能力。