IEEE TSUSC'23:基于网络接口使用流量的容器会话级别流量预测

VSole2023-05-04 09:43:28

0基于容器提供云原生服务可以提高云计算的弹性,成为现今的主流方式。在一个容器内,可以同时存在多个不同服务的通信会话,对这些会话分别进行预测在细粒度的系统管理中具有重要意义。然而,这是一个棘手的任务,因为会话流量通常都是不可见的,我们唯一能得到的是代表了所有共存会话总流量的容器网络接口使用流量。在本文中,我们提出了一种基于机器学习的会话级流量预测框架X-Rayer,从容器的网络接口使用流量中预测各个容器内部的会话流量。X-Rayer首先通过融合滑动窗口和集成经验模态分解算法的循环神经网络,准确预测未来的接口使用流量,然后利用卷积神经网络和门控循环单元组成的ConvGRU对会话级流量进行估计。同时,X-Rayer通过注意力机制提取了容器网络的时空相关性,并提高了会话流量预测的准确率。大量的实验表明,X-Rayer与最先进的方法相比提供了更为准确的结果,其在容器接口使用流量预测中将平均RMSE分别降低33.25%和33.71%,并在会话级流量估计中分别降低了18.05%、27.04%、21.91%和16.43%。

该成果“Container Session Level Traffic Prediction from Network Interface Usage”发表在IEEE TSUSC 2023,是实验室分布式系统组在容器流量预测领域的研究成果。

  • 论文链接:https://ieeexplore.ieee.org/document/10071951

背景与动机

容器作为一种轻量级虚拟化技术,如今已被广泛应用在各领域中,并展现出了其在提升性能和降低成本方面的优势。亚马逊、谷歌等许多公司均已实现了其各自基于容器的虚拟化环境。然而,容器只能提供应用程序级别的抽象,而无法提供强大的硬件隔离和细粒度资源管理。Docker等主流的容器产品通常允许用户通过命令或接口进行资源监控,以网络流量为例,通过使用docker stats命令,我们可以获取容器网络接口使用流量作为总通信流量的统计信息。另一方面,一个容器内可以同时存在多个服务和许多不同的通信会话。具体而言,在云原生应用中,根据预定义的服务语义,服务流量会通过不同的容器进行传递。因此,对于每个容器,可能会存在与其他不同容器的多个会话。与容器接口使用流量不同,会话级别的流量是不可见的,无法通过现有的系统命令轻松监测。

这种不可见的会话流量给容器管理带来了很多麻烦,甚至可能成为运营商的噩梦。例如,当两个容器之间存在多个会话时,我们无法知道每个会话中发生的具体情况,这使恶意或攻击性流量可以在看起来正常的容器接口使用下完美地隐藏,带来了严重的安全风险。此外,由于容器的弱隔离特性和复杂的网络模式,容器内的多个服务间可能会经历激烈的带宽竞争,进而影响服务的公平性并造成性能下降。

通过预测会话流量,我们不仅可以避免带宽竞争,还可以制定容器部署或资源分配的优化策略,以达到更好的服务公平性和系统性能。为了解决会话流量不可见的问题,我们可以重新构建容器系统或劫持服务源代码。例如,现有工作通过集成Istio框架或以旁路方式不断劫持会话流量,实现了可见性。然而,Istio框架相当沉重且应用范围有限,而流量劫持需要向服务中植入新代码,并在每个容器中维护一个消耗额外资源的守护进程。总之,这两种方法均不容易实现,并且会产生极高的开销。

因此,我们有动力设计一种非植入式、轻量级的容器会话级流量监控解决方案。其中,“非植入式”意味着它不需要更改容器现有架构或劫持服务源代码,可以在容器外部以可接受的开销进行预测。通过分析现有的技术,我们试图利用运行时的容器网络接口使用流量来预测不可见的会话流量。实际上,网络流量预测已经得到广泛研究,但由于以下两个挑战,这些研究无法直接应用在容器会话级流量预测中:

(1)一对多:现有的工作都高度依赖于运行时统计的流量时间序列,以预测完全相同链路上的未来流量,即从多维特征到一维标签。然而,我们的会话级流量预测问题必须基于单个容器接口使用的运行时统计数据预测多个会话流量,即从一维特征到多维标签。

(2)时间变化:容器会话流量随着服务需求的变化呈现高度动态和时变的特征。因此,即使是相同的接口使用值,其会话流量也可能截然不同。换而言之,除了大标签维度之外,一个接口使用流量特征可能会与多组会话流量标签配对。如何在不同的时间段准确估计相同接口使用流量特征下的会话流量,这无法通过现有的一对一特征—标签配对方案解决。

为了解决上述两个挑战,我们设计并实现了一个名为X-Rayer的会话级流量预测框架。与现有的会造成容器重组开销和额外安全风险的劫持会话流量信息方案不同, X-Rayer框架提出了一种EEMD-GRU+AttConvGRU网络,用于在总容器接口使用流量和会话级流量之间建立桥梁,从而实现基于容器接口使用的会话级流量预测,其无需植入任何旁路设备以劫持运行时会话流量或修改容器源代码。

设计与实现

典型的基于容器的服务系统主要由多个相互连接的容器组成,每个容器提供不同的功能。一个容器可以通过从上游服务接收数据包,对其进行处理并通过服务之间的逻辑会话将其发送到下游服务来维持多个会话,所有会话流量都将计入容器界面使用的一部分进行统计。通过测试研究发现,容器接口使用流量呈现一定的周期性变化特征,这意味着可以通过历史样本和运行时接口流量来预测未来的流量总趋势,并进一步进行会话流量的估计。同时,会话流量除了与接口使用流量一样具有时间相关性外,还具有空间相关性,换而言之,即使接口使用值相同,上一时隙不同的会话流量也会产生下一时隙不同的会话流量,并且其也受到容器网络中上游和下游容器中会话的影响。这些发现可以辅助解决上述提到的“一对多”和“时间变化”会话流量预测挑战,提高预测的准确率。

在本文中,我们设计了轻量级、非植入性的X-Rayer框架,基于运行时容器接口使用流量来预测会话级流量,实现其可见性。为了建立接口使用流量和会话流量之间的桥梁,X-Rayer首先必须基于当前接口使用值来预测未来的接口使用流量,然后通过预测的接口使用流量估计未来的会话流量。换句话说,接口使用预测是会话级流量估计的基础。因此,X-Rayer包括两个模块:接口使用预测器和会话流量估计器,如图1所示。

图1 X-Rayer架构图

接口使用预测器由三个部分组成:(1)集合经验模态分解(EEMD),用于分析和划分接口使用流量序列为多个频率,以更好地捕捉时间特征;(2)滑动窗口,来增强时间序列使用的短期依赖性;(3)GRU网络,来学习接口使用流量变化趋势和进行预测,在有限的数据集下可以获得更高的精度。而会话流量估计器由以下组成:(1)基于ConvGRU的编码器,用于编码和捕捉接口使用和会话流量的特征;(2)变换注意力层,用于确定不同时间段和不同会话的时间空间相关权重;(3)带有SoftMax激活函数的解码器,用于估计相应的会话流量。

X-Rayer框架的工作流程主要包括4个步骤:(1)通过使用docker stats命令并在一段时间内植入一个守护进程会话,获取容器接口使用流量序列和相应的会话流量序列,并将其记录为历史数据集以用于模型训练。(2)将容器接口使用流量序列集发送到预测器模块进行训练。首先,将流量序列通过EEMD划分为不同的模态特征子序列;接着,将每个子序列在经过滑动窗口处理后送入GRU网络训练,以获得每个子序列的预测结果;最后,将各结果相加以获取容器接口使用流量的预测值。在训练过程中,将预测的接口使用值与真实值进行比较,并相应地更新预测器模块。(3)基于预测的接口使用流量估计会话级流量。构建一个包含接口使用预测值的时空矩阵,将其输入估计器模块,依次经过基于ConvGRU的编码器、变换注意力机制和ConvGRU解码器,最后通过输出层SoftMax对各个会话的流量进行估计。在训练过程中,会进一步将估计的流量与真实值进行比较,以更新估计器模块。(4)当两个关键模块训练完毕后,我们移除守护进程会话,并运行docker stats命令以监视获取不同时间段的一批运行时接口使用情况。基于此数据集,可以预测未来的接口使用流量和会话级流量。

为了验证X-Rayer框架的有效性,分别在不同的场景下对接口使用预测器和会话流量估计器的性能进行了实验。我们从DockerHub中拉取了20个常用的容器组成网络,每个容器支持2-5个服务。并且根据IBM Docker Registry Trace数据集初始化服务请求速率。该实验基于Kubernetes框架,并运行docker stats命令在52天内获取接口数据。在接口使用预测实验中,滑动窗口大小设置为15,每个GRU网络包括含有15个神经元的输入层,3个含有60个神经元的隐藏层,和1个神经元的输出层,初始学习率为0.001,共训练100次。实验将X-Rayer框架的预测器与ARIMA,SVR,TarjGRU和FC-LSTM这4种算法进行对比,结果如图2所示。与最先进的TarjGRU,FC-LSTM相比,X-Rayer预测值的RMSE分别降低了33.71%和33.25%。在会话流量估计器实验中,ConvGRU网络包括一个15个神经元的输入层,5个含有60个神经元的隐藏层,以及一个使用SoftMax激活函数的输出层,初始学习率为0.01,共训练100次。实验将X-Rayer框架的估计器与FC-LSTM,GRU,ConvLSTM和TarjGRU这4种算法进行对比,结果如图3所示,X-Rayer估计值的RMSE分别降低了18.05%,27.04%,21.91%,和16.43%。

图2 不同接口使用预测算法的性能比较

图3 不同会话流量估计算法的性能比较

详细内容请参见:

Lin Gu, Honghao Xu, Ziyuan Li, Zirui Chen, Hai Jin, “Container Session Level Traffic Prediction from Network Interface Usage,”in IEEE Transactions on Sustainable Computing (TSUSC), pp.1-12, 2023, doi: 10.1109/TSUSC.2023.3252595.

流量容器技术
本作品采用《CC 协议》,转载必须注明作者和本文链接
最近测容器安全,才发现部署的容器云平台和容器应用几乎在裸奔,每个镜像和容器都有各种各样的漏洞,平台本身也不少问题,真是不测不知道,一测吓一跳。容器本身就是弱安全的,容易带来越权逃逸等问题,同时容器应用研发人员对容器技术又缺乏了解,缺乏相应的安全意识和安全知识,这就带来了比较严重的潜在的安全问题。
本文介绍了在集群中利用危险的RBAC配置提权至集群管理员的案例,并总结了同类的技术和方法和对应的防御思路
声明 本文为笔者对实际容器安全事件的归纳,仅代表个人观点。 文末为容器安全事件排查与响应思维导图。 引子 定位初始入侵位置 首先要确认入侵是否发生在容器内,或者说只在容器内。 场景:zabbix告警一个进程占用非常高,像是挖矿程序/DOS了。 但是查看进程的PPID却发现是systemd,这种情况大概率是容器相关了。 首先获取程序PID,然后查看对应进程的进程树是否父进程为contai
当前,以数字经济为代表的新经济成为经济增长新引擎,数据作为核心生产要素成为了基础战略资源,数据安全的基础保障作用也日益凸显。伴随而来的数据安全风险与日俱增,数据泄露、数据滥用等安全事件频发,为个人隐私、企业商业秘密、国家重要数据等带来了严重的安全隐患。近年来,国家对数据安全与个人信息保护进行了前瞻性战略部署,开展了系统性的顶层设计。《中华人民共和国数据安全法》于2021年9月1日正式施行,《中华人
与云原生技术红利相伴而来的是安全威胁和风险。近年来,在云原生蓬勃发展的产业背景下,新的安全漏洞、安全事件同样层出不穷。随着越来越多重要业务云原生化,安全已经成为业务落地的必要保障条件。有哪些因素会让云原生环境变得不安全?怎样保障云原生安全?《云原生安全: 攻防实践与体系构建》希望能够给出一个答案。本文为《云原生安全: 攻防实践与体系构建》一书的精华解读,重点介绍云原生环境下的攻防对抗。本书已在京东
随着云计算技术的成熟与发展,越来越多企业加速“上云”进程,云原生应用也日益普及并开始承载企业核心生产系统。 近日,腾讯安全云鼎实验室「安全大讲堂」邀请中国信通院云大所云计算部副主任陈屹力,以“云原生安全发展现状与趋势分析”为主题,围绕产业历史沿革进行前瞻性的技术及行业趋势分享,重点探讨了当前云原生环境下主要的安全威胁、云原生安全防护体系建设以及云原生未来的发展趋势。
勒索即服务大行其道,威胁横移时间减少67%
从云原生计算环境等主要领域深入分析了安全风险的来源,介绍了典型开源安全工具,提出业内首个云原生应用保护平台模型,并分层对模型中的安全能力进行了详细介绍
数据访问控制的未来
2022-07-04 04:47:28
原生控制>数据代理>数据边车
VSole
网络安全专家