CN115918139A - 网络切片的主动保证 - Google Patents
网络切片的主动保证 Download PDFInfo
- Publication number
- CN115918139A CN115918139A CN202180046468.2A CN202180046468A CN115918139A CN 115918139 A CN115918139 A CN 115918139A CN 202180046468 A CN202180046468 A CN 202180046468A CN 115918139 A CN115918139 A CN 115918139A
- Authority
- CN
- China
- Prior art keywords
- network
- test
- service
- kubernets
- agent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 claims abstract description 560
- 238000000034 method Methods 0.000 claims abstract description 117
- 230000000977 initiatory effect Effects 0.000 claims abstract description 15
- 230000004044 response Effects 0.000 claims description 38
- 238000012545 processing Methods 0.000 claims description 21
- 238000004088 simulation Methods 0.000 claims description 21
- 238000003860 storage Methods 0.000 claims description 19
- 230000009471 action Effects 0.000 claims description 6
- 230000001960 triggered effect Effects 0.000 claims description 4
- 230000008439 repair process Effects 0.000 claims description 3
- 239000003795 chemical substances by application Substances 0.000 description 334
- 238000012544 monitoring process Methods 0.000 description 113
- 239000008186 active pharmaceutical agent Substances 0.000 description 99
- 238000010586 diagram Methods 0.000 description 62
- 230000006870 function Effects 0.000 description 57
- 239000000306 component Substances 0.000 description 49
- 241000380131 Ammophila arenaria Species 0.000 description 41
- 238000007726 management method Methods 0.000 description 31
- 238000013024 troubleshooting Methods 0.000 description 26
- 238000012795 verification Methods 0.000 description 23
- 230000006855 networking Effects 0.000 description 20
- 238000004891 communication Methods 0.000 description 18
- 238000002474 experimental method Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 18
- 239000004744 fabric Substances 0.000 description 17
- 230000000739 chaotic effect Effects 0.000 description 16
- 230000000694 effects Effects 0.000 description 16
- 230000008859 change Effects 0.000 description 15
- 230000000875 corresponding effect Effects 0.000 description 15
- 230000008901 benefit Effects 0.000 description 10
- 238000013461 design Methods 0.000 description 10
- 238000004220 aggregation Methods 0.000 description 9
- 238000000275 quality assurance Methods 0.000 description 9
- 230000002776 aggregation Effects 0.000 description 8
- 238000012217 deletion Methods 0.000 description 8
- 230000037430 deletion Effects 0.000 description 8
- 238000002955 isolation Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 230000001413 cellular effect Effects 0.000 description 6
- 238000013500 data storage Methods 0.000 description 6
- 238000012384 transportation and delivery Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 3
- 210000004027 cell Anatomy 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000003863 physical function Effects 0.000 description 3
- 239000000523 sample Substances 0.000 description 3
- 238000000638 solvent extraction Methods 0.000 description 3
- 238000012369 In process control Methods 0.000 description 2
- 241000270295 Serpentes Species 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 238000003339 best practice Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 210000004544 dc2 Anatomy 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000007613 environmental effect Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000004190 ion pair chromatography Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000002156 mixing Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 101100536354 Drosophila melanogaster tant gene Proteins 0.000 description 1
- 239000000853 adhesive Substances 0.000 description 1
- 230000001070 adhesive effect Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000001771 impaired effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 229910052751 metal Inorganic materials 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 239000005022 packaging material Substances 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000005201 scrubbing Methods 0.000 description 1
- 231100000735 select agent Toxicity 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000007493 shaping process Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/06—Testing, supervising or monitoring using simulated traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0876—Aspects of the degree of configuration automation
- H04L41/0883—Semiautomatic configuration, e.g. proposals from system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
- H04L43/55—Testing of service level quality, e.g. simulating service usage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Automation & Control Theory (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种方法包括：由计算系统接收由网络中的第一虚拟化服务实现的、用于主动测试网络切片的声明性测试描述符；由计算系统并且从协调层接收与网络切片相关联的元数据；由计算系统并且基于声明性测试描述和元数据来确定用于测试网络切片的主动测试配置；以及根据主动测试配置启动主动测试，以及基于主动测试的结果来确定服务等级违规。
Description
本申请要求2021年9月30日提交的美国临时专利申请第63/261,943号的权益；并且本申请要求2020年11月16日提交的美国临时专利申请第63/114,444号的权益；每个申请的全部内容通过引用并入本文。
技术领域
本公开涉及监控由部署到网络内的虚拟化计算基础设施的虚拟执行元素(例如，虚拟机或容器)提供的服务。
背景技术
计算机网络已经变得无处不在，并且网络应用、网络连接设备和网络连接设备类型的数目迅速增长。此类设备现在包括计算机、智能电话、物联网(IoT)设备、汽车、医疗设备工厂设备等。终端用户联网设备通常无法直接访问公共网络，诸如互联网。相反，终端用户网络设备与接入网络建立网络连接，并且接入网络与连接到提供服务的一个或多个分组数据网络(PDN)的核心网络通信。目前有几种不同类型的接入网络在使用。示例包括作为第三代合作伙伴计划(3GPP)网络的接入网络的无线电接入网络(RAN)，诸如Wi-Fi或WiMAX网络的受信和不受信的非3GPP网络，以及诸如数字订户线(DSL)、无源光网络(PON)和有线网络的固定/有线网络。核心网络可以是诸如3G、4G/LTE或5G网络的移动服务提供方网络的网络。
在典型的云数据中心环境中，存在大量互连的服务器，这些服务器提供计算和/或存储能力以运行各种应用。例如，数据中心可以包括为订户(即数据中心的客户)托管应用和服务的设施。例如，数据中心可以托管所有基础设施设备，例如网络和存储系统、冗余电源和环境控制。在典型的数据中心中，存储系统和应用服务器的集群通过由一个或多个物理网络交换机和路由器提供的高速交换结构互连。更复杂的数据中心提供遍布世界各地的基础设施，其中订户支持设备位于各种物理托管设施中。
虚拟化数据中心正在成为现代信息技术(IT)基础设施的核心基础。具体地，现代数据中心已经广泛地利用了虚拟化环境，其中在物理计算设备的底层计算平台上部署和执行虚拟主机，本文也被称为虚拟执行元素，诸如虚拟机或容器。
数据中心内的虚拟化可以提供多个优势。一个优势是，虚拟化可以显著提高效率。随着每个物理中央处理单元(CPU)具有大量核心的多核微处理器架构的出现，底层物理计算设备(即服务器)已经变得越来越强大，虚拟化变得更容易和更高效。第二个优势是，虚拟化提供了对计算基础设施的重要控制。随着物理计算资源成为可替换资源，诸如在基于云的计算环境中，计算基础设施的供应和管理变得更容易。因此，企业信息技术(IT)员工通常更喜欢数据中心中的虚拟化计算集群，因为它们的管理优势以及虚拟化提供的效率和更高的投资回报(ROI)。
容器化是基于操作系统级虚拟化的虚拟化方案。容器是轻量级和可移植的执行元素，用于相互隔离并且与主机隔离的应用。因为容器没有紧密耦合到主机硬件计算环境，所以应用可以绑定到容器镜像，并且作为单个轻量级包在支持底层容器架构的任何主机或虚拟主机上执行。因此，容器解决了如何使软件在不同的计算环境中工作的问题。容器提供了从一个计算环境到另一计算环境(虚拟的或物理的)一致运行的承诺。
凭借容器本身的轻量级特性，单个主机通常可以支持比传统虚拟机(VM)多得多的容器实例。这些系统的特点是动态和短暂的，因为托管服务可以快速扩展或适应新的要求。容器寿命通常是短的，其可以比VM更高效地创建和移动，并且它们也可以作为逻辑组相关的元素来管理(对于某些协调平台，例如Kubernetes，有时称为“Pod”)。这些容器特性影响了对容器网络解决方案的要求：网络应当灵活并且可缩放。VM、容器和裸机服务器可能需要在相同的计算环境中共存，并且允许在不同的应用部署之间进行通信。容器网络还应当对如何与用于部署容器化应用的多种类型的协调平台一起工作是不可知的。
管理应用执行的部署和基础设施的计算基础设施可以涉及两个主要角色：(1)协调——用于跨主机集群自动化应用的部署、缩放和操作，以及提供计算基础设施，其可以包括以容器为中心的计算基础设施；以及(2)网络管理——用于在网络基础设施中创建虚拟网络，以允许在诸如容器或VM的虚拟执行环境中运行的应用之间以及在传统(例如，物理)环境上运行的应用之间进行分组化通信。软件定义的网络有助于网络管理。
发明内容
一般而言，描述了用于监控由虚拟执行元素提供的服务的技术。执行主动监控以提供主动保证。使用声明性测试描述符来配置主动监控。元数据由监控运营方从诸如Kubernetes平台的系统的协调层接收。例如，元数据与由虚拟执行元素提供的多个服务相关联，诸如Kubernetes服务。监控运营方使用声明性测试描述和元数据来确定主动测试配置。在一些示例中，基于主动测试配置来执行服务的主动监控，并且可以基于主动测试结果来确定服务的服务等级要求违规。
主动监控/测试指的是主动网络探测技术(例如，发送测试分组)，而不是被动监控，在被动监控中，监控网络业务本身而不发送分离的测试分组。主动测试配置包括发送主动探测以确定网络质量的测试代理。例如，测试代理可以部署为托管容器、虚拟机的Kubernetes pod，或部署为装置。监控运营方(例如，Kubernetes运营方)读取服务的标签，并且向协调监控的中央控制中心提供测试代理IP地址和标签、服务端点、模板名称和参数。然后，中央控制中心基于监控运营方提供的配置来将测试代理和服务实例化。在使用Kubernetes外部测试代理的情况下，使用标签/标记将测试代理绑定到服务。由于声明性测试描述符和元数据，当虚拟执行元素发生更新时，测试代理可以自动地和动态地更新测试配置。相比于诸如手动更新测试配置的其他方法，本文描述的技术提供了技术优势，在动态虚拟化环境中，手动更新测试配置在规模上变得不实际或不可行。
在本文描述的一些示例中，主动保证技术可以用于响应于网络切片被创建而自动设置和执行网络切片的主动监控。使用声明性测试描述符来配置主动监控。监控运营方从诸如Kubernetes平台的系统的协调层接收关于网络切片的元数据。监控运营方例如基于虚拟执行元素的标签来确定元数据与由虚拟执行元素提供的多个RAN元素模拟服务之间的关联。监控运营方使用声明性测试描述和元数据来确定主动测试配置。在一些示例使用中，主动测试配置可以包括用于使用模拟无线电接入网络的元素的虚拟执行元素在模拟环境中验证网络切片的供应。在利用仿真的UE和gNodeB验证网络切片之后，将网络切片用于移动网络。在一些示例中，基于主动测试配置来执行对网络切片操作的主动监控，并且可以基于主动测试结果来确定网络切片的服务等级要求违规。
在监控网络切片的情况下，通过在创建网络切片时自动启用对网络切片的主动监控，而不需要手动放置和删除用于出于测试目的模拟网络切片的RAN功能的虚拟执行元素，本文公开的技术可以提供相对于先前系统的技术优势。作为本公开中描述的技术的实际应用，监控运营方自动检测与正在创建的网络切片相关联的元数据，并且基于在元数据中发现的服务类型来连接用于测试和监控网络切片的适当虚拟执行元素(例如，Kubernetes资源实例)。
与监控运营方集成的应用可以提供对监控服务、认证服务、网络切片服务、资源管理服务的细粒度共同控制。因此，监控运营方可以与协调器集成，以提供测试和监控网络切片的平台，例如跨5G核心网络和RAN。网络切片、接入网络和核心网络的面向服务的视图及其主动保证监控协助软件定义网络(SDN)和网络功能虚拟化(NFV)，其允许在不同的底层网络基础设施之上实现灵活并且可缩放的网络服务。
在一个示例中，本公开描述了一种方法，该方法包括：由计算系统接收用于对虚拟化服务进行主动测试的声明性测试描述符；从协调层获取与虚拟化服务相关联的元数据，其中元数据指定由协调层管理的集群的命名空间内的虚拟化服务的唯一名称；由计算系统使用声明性测试描述符和元数据来确定针对虚拟化服务的实例的主动测试配置；以及根据主动测试配置来启动主动测试，并且基于主动测试的结果来确定虚拟化服务的实例的服务等级违规。
在一个示例中，本公开描述了一种计算系统，该计算系统包括耦合到存储器设备的处理电路，该处理电路被配置为：接收用于主动测试第一虚拟化服务的声明性测试描述符；从协调层获取与所请求的网络切片相关联的元数据，该网络切片由第一虚拟化服务实现，其中元数据指定由协调层管理的集群的命名空间内的第一虚拟化服务的唯一名称；基于声明性测试描述符和元数据，确定用于验证所请求的网络切片的主动测试配置，主动测试配置包括测试配置参数、测试代理的放置、以及被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素；根据主动测试配置，使用模拟元素在网络切片上启动主动测试；以及输出主动测试的结果是否指示网络切片满足服务等级要求的指示。
在另一示例中，本公开描述了一种方法，该方法包括：由计算系统接收用于对网络中的虚拟化服务进行主动测试的声明性测试描述符；从协调层获取与所请求的网络切片相关联的元数据，该网络切片由第一虚拟化服务实现；由计算系统并且基于声明性测试描述和元数据来确定用于验证所请求的网络切片的主动测试配置，主动测试配置包括测试配置参数、测试代理的放置、以及将被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素；根据主动测试配置，使用模拟元素在网络切片上启动主动测试；由计算系统确定主动测试的结果是否指示网络切片满足所要求的服务等级要求；以及输出主动测试的结果是否指示网络切片满足所要求的服务等级要求的指示。
在另一示例中，本公开描述了一种方法，该方法包括：由计算系统接收用于主动测试由网络中的第一虚拟化服务实现的网络切片的声明性测试描述符；由计算系统接收与网络切片相关联的元数据；由计算系统基于声明性测试描述和元数据来确定用于测试网络切片的主动测试配置；以及根据主动测试配置启动主动测试，并且基于主动测试的结果来确定服务等级违规。
本公开的一个或多个实施例的细节在附图和下面的描述中阐述。其他特征、目的和优势将从说明书和附图以及权利要求书中清楚。
附图说明
图1是示出可以在其中实现本文描述的技术的示例的示例计算基础设施8的框图。
图2是示出根据本公开中描述的技术的示例移动网络系统的框图。
图3是示出根据本公开中描述的技术的包括与Kubernetes平台集成的监控运营方的示例计算系统的框图。
图4是示出节点到节点连通场景的框图。
图5是示出节点到服务验证场景的框图。
图6是示出Pod到Pod连通场景的框图。
图7是示出入站验证场景的框图。
图8是示出故障排除Pod场景的框图。
图9是示出初始部署验证场景的框图。
图10是示出根据本公开中描述的技术的包括与Kubernetes平台集成的监控运营方的另一示例计算系统的框图。
图12是示出部署为PodK的代理及其与其他组件的交互的框图。
图13是示出部署为sidecar容器的代理及其与其他组件的交互的框图。
图14是示出监控器控制器在协调期间可以采取的决策的活动图的框图。
图15是示出测试控制器在协调期间可以采取的决策的活动图的框图。
图16是示出污染(“taint”)控制器在协调期间可以采取的决策的活动图的框图。
图17是示出Sidecar控制器基于注释而作出的决策的活动图的框图。
图18是示出根据本公开中描述的技术，用于节点到节点主动保证监控的示例配置和对应的用户界面显示的概念图。
图19是示出根据本公开中描述的技术，用于在不同节点上的测试代理之间创建主动保证监控的监控场景的示例配置和对应的用户界面显示的概念图。
图20是用于配置诸如UE的模拟无线电接入网络(RAN)元素的示例用户界面显示。
图21是示出根据本公开中描述的技术，用于添加可以由监控运营方用于网络切片测试的模拟UE和eNodeB的示例配置和对应的用户界面显示的概念图。
图22是示出根据本公开中描述的技术一个方面，使得监控运营方经由代理控制器(控制中心)利用所需的UE/eNodeB/gNodeB设置来配置测试代理以实现YAML输入的意图的示例YAML输入的概念图。
图23是示出根据本公开中描述的技术的一个方面，用于测试网络切片的示例系统的框图。
图24是示出根据本公开中描述的技术的一个方面，用于使用位于同一虚拟执行元素中的测试代理和模拟器来测试网络切片的示例系统的框图。
图25是示出根据本公开中描述的技术的一个方面，用于使用位于与模拟器不同的虚拟执行元素中的测试代理来测试网络切片的示例系统的框图。
图26至图28是示出根据本公开的一个或多个技术的计算系统的示例操作的流程图。
在整个说明书和附图中，相同的附图标记表示相同的元素。
具体实施方式
移动设备的数目不断增加，并且对电信网络基础设施提出了新的要求，电信网络基础设施正变得越来越关键。除其他外，用例还包括移动宽带、自动驾驶、大规模物联网(IoT)系统和内容交付网络(CDN)，并且必须考虑用于未来的基础设施。
5G基础设施是互连设备和服务的大规模网络的主要驱动因素中的一个因素。据设想，许多企业将在基础设施上运行其系统，从而允许它们将处理移动至更接近终端用户或设备。这将需要对可用资源和服务等级协议的保证——这将催生诸如5G网络切片的新概念，其允许在基础设施上运行的服务之间进行隔离。
电信设备生产商和运营方正在转向云本机方法，在这种方法中，他们在物理基础设施之上的云中为软件定义的容器化网络功能(CNF)和虚拟化网络功能(VNF)提供执行平台。此网络功能(NF)执行环境通过提供移动边缘计算带来了将内容处理放置在离消费者更近的位置的灵活性，但也将其他服务托管在距离消费者较远的云中，用于延迟可能不太重要的服务。
供应方的目标是采用云本机方法，其将Kubernetes(缩写为“Kubernetes”)合并为底层协调引擎和执行环境，用于在裸机上和更靠近边缘部署CNF。云本机计算基础(CNCF)产品组合中的Kubernetes容器协调系统和相关项目是可扩展的大型生态系统，允许许多组件遵循微服务架构而互操作在一起。Kubernetes通过消除VNF所需的虚拟化层，带来了更容易的生命周期管理和更少的开销。
具有隔离网络切片和边缘计算能力的这些云可能会受益于主动监控和测试，以确保在Kubernetes环境中作为CNF运行的设备与服务之间的功能和服务等级协议。在一些示例中，根据本公开的一个或多个技术，测试代理可以用作硬件和软件容器。测试代理可以产生业务来验证和监控网络功能。工具使用作为web应用托管的控制中心用户界面(UI)进行配置和部署。在一些示例中，该功能可以作为软件即服务(SaaS)和内部部署产品来提供。SaaS实例由运营方管理和托管，而内部部署产品可以托管在客户的硬件上。
本公开描述了用于在网络切片的上下文中将主动保证平台与Kubernetes生态系统集成的技术，用于主动测试模拟网络切片和/或主动监控部署的网络切片。本公开描述了如何能够将主动测试与具有Kubernetes带来的临时组件的动态集群环境配合使用。
图1是示出可以在其中实现本文描述的技术的示例的示例计算基础设施8的框图。一般而言，数据中心10为具有通过服务提供方网络7耦合到数据中心的一个或多个客户网络的客户站点11(示为“客户11”)提供应用和服务的操作环境。例如，数据中心10可以托管基础设施设备，诸如联网和存储系统、冗余电源和环境控制。服务提供方网络7耦合到公共网络15，公共网络15可以表示由其他提供方管理的一个或多个网络，并且因此可以形成大规模公共网络基础设施的部分，例如互联网。公共网络15可以表示例如局域网(LAN)、广域网(WAN)、互联网、虚拟LAN(VLAN)、企业LAN、第3层虚拟专用网(VPN)、由运营服务提供方网络7的服务提供方运营的网际协议(IP)内联网、企业IP网络或其某种组合。
尽管客户站点11和公共网络15主要被示出和描述为服务提供方网络7的边缘网络，但在一些示例中，客户站点11和公共网络15中的一个或多个可以是数据中心10或另一数据中心内的租户网络。例如，数据中心10可以托管多个租户(客户)，每个租户(客户)与一个或多个虚拟专用网(VPN)相关联，VPN中的每个VPN可以实现客户站点11中的一个客户站点。
服务提供方网络7向附接的客户站点11、数据中心10和公共网络15提供基于分组的连通。服务提供方网络7可以表示由服务提供方拥有和运营以互连多个网络的网络。服务提供方网络7可以实现多协议标签交换(MPLS)转发，并且在这种情况下可以被称为MPLS网络或MPLS主干。在一些情况下，服务提供方网络7表示提供来自一个或多个服务提供方的服务的多个互连的自治系统，例如互联网。
在一些示例中，数据中心10可以表示许多地理上分布的网络数据中心中的一个数据中心。如图1的示例所示，数据中心10可以是为客户提供网络服务的设施。服务提供方的客户可以是诸如企业和政府的集体实体或个人。例如，网络数据中心可能为多个企业和终端用户托管web服务。其他示例服务可以包括数据存储、虚拟专用网络、流量工程、文件服务、数据挖掘、科学计算或超级计算等。尽管被示出为服务提供方网络7的分离边缘网络，但是数据中心10的元素，诸如一个或多个物理网络功能(PNF)或虚拟化网络功能(VNF)，可以被包括在服务提供方网络7核心内。
在该示例中，数据中心10包括经由交换结构14互连的存储和/或计算服务器，交换结构14由一层或多层物理网络交换机和路由器提供，其中服务器12A至12X(本文称为“服务器12”)被描绘为耦合到架顶式交换机16A至16N。服务器12是计算设备，并且在本文也可以被称为“主机”或“主机设备”。尽管在图1中仅详细示出了耦合到TOR交换机16A的服务器12A，但是数据中心10可以包括耦合到数据中心10的其他TOR交换机16的许多附加服务器。
在所示的示例中，交换结构14包括互连的架顶式(TOR)(或其他“叶”)交换机16A至16N(统称为“TOR交换机16”)，其耦合到机箱(或“主干”或“核心”)交换机18A至18M(统称为“机箱交换机18”)的分布层。尽管未示出，但数据中心10还可以包括例如一个或多个非边缘交换机、路由器、集线器、网关、诸如防火墙的安全设备、入侵检测和/或入侵防御设备、服务器、计算机终端、膝上型计算机、打印机、数据库、诸如蜂窝电话或个人数字助理的无线移动设备、无线接入点、网桥、电缆调制解调器、应用加速器或其他网络设备。数据中心10还可以包括一个或多个物理网络功能(PNF)，诸如物理防火墙、负载均衡器、路由器、路由反射器、宽带网络网关(BNG)、演进的分组核心或其他蜂窝网络元素、以及其他PNF。
在该示例中，ToR交换机16和机箱交换机18向服务器12提供到IP结构20和服务提供方网络7的冗余(多宿)连接。机箱交换机18聚合业务流并且提供TOR交换机16之间的连接。ToR交换机16可以是提供第2层(MAC)和/或第3层(例如，IP)路由和/或交换功能的网络设备。ToR交换机16和机箱交换机18可以各自包括一个或多个处理器和存储器，并且可以执行一个或多个软件过程。机箱交换机18耦合到IP结构20，IP结构20可以执行第3层路由以通过服务提供方网络7在数据中心10和客户站点11之间路由网络业务。数据中心10的交换架构仅是示例。例如，其他交换架构可以具有更多或更少的交换层。
术语“分组流”、“业务流”或简称为“流”指的是源自特定源设备或端点并且发送到特定目的地设备或端点的分组集。单个分组流可以由5元组来标识：例如，<源网络地址，目的网络地址，源端口，目的地端口，协议>。该5元组通常标识接收到的分组对应的分组流。n元组是指从5元组中提取的任何n个项。例如，分组的2元组可以指分组的<源网络地址，目的网络地址>或<源网络地址，源端口>的组合。
服务器12可以各自表示计算服务器、交换机或存储服务器。例如，服务器12中的每个服务器可以表示被配置为根据本文描述的技术操作的计算设备，例如基于x86处理器的服务器。服务器12可以为NFV架构提供网络功能虚拟化基础设施(NFVI)。
服务器12中的任何服务器可以通过虚拟化服务器的资源来配置虚拟执行元素，以在服务器上执行的一个或多个过程(应用)之间提供隔离。“基于管理程序的”或“硬件等级的”或“平台的”虚拟化是指创建虚拟机，每个虚拟机都包括用于执行一个或多个过程的访客操作系统。一般而言，虚拟机提供用于在隔离的虚拟环境中执行应用的虚拟化/访客操作系统。因为虚拟机是从主机服务器的物理硬件虚拟化的，所以执行应用与主机的硬件和其他虚拟机两者都是隔离的。每个虚拟机可以配置有一个或多个虚拟网络接口，用于在对应的虚拟网络上通信。
虚拟网络是在物理网络之上实现的逻辑结构。虚拟网络可以用于取代基于VLAN的隔离，并且在例如数据中心10的虚拟化数据中心中提供多租户。每个租户或应用可以具有一个或多个虚拟网络。除非安全策略明确允许，否则每个虚拟网络可以与所有其他虚拟网络隔离。
使用数据中心10边缘路由器(图1中未示出)，可以将虚拟网络连接到物理多协议标签交换(MPLS)第3层虚拟专用网(L3VPN)和以太网虚拟专用网(EVPN)网络，并且在其上进行扩展。虚拟网络还可以用于实现网络功能虚拟化(NFV)和服务链接。
虚拟网络可以使用各种机制来实现。例如，每个虚拟网络可以被实现为虚拟局域网(VLAN)、虚拟专用网络(VPN)等。还可以使用两个网络来实现虚拟网络——由IP结构20和交换结构14组成的物理底层网络和虚拟覆盖网络。物理底层网络的作用是提供“IP结构”，它提供从任何物理设备(服务器、存储设备、路由器或交换机)到任何其他物理设备的单播IP连通。底层网络可以提供从网络中的任何点到网络中的任何其他点的统一的低延迟、无阻塞、高带宽连接。
如下文关于虚拟路由器21A所进一步描述的，在虚拟化服务器12的内核或管理程序中运行的虚拟路由器使用它们之间的动态“隧道”网格在物理底层网络之上创建虚拟覆盖网络。例如，这些覆盖隧道可以是GRE/UDP上MPLS隧道，或者VXLAN隧道，或者NVGRE隧道。底层物理路由器和交换机可能不包含用于虚拟机或其他虚拟执行元素的任何每租户状态，例如任何媒体访问控制(MAC)地址、IP地址或策略。底层物理路由器和交换机的转发表可以例如仅包含物理服务器12的IP前缀或MAC地址。(将虚拟网络连接到物理网络的网关路由器或交换机是例外，并且可以包含租户MAC或IP地址。)
服务器12中的虚拟路由器21通常包含每个租户状态。例如，它们可能包含每个虚拟网络的分离转发表(路由实例)。该转发表包含虚拟机或其他虚拟执行元素(例如，容器的pod)的IP前缀(在第3层覆盖的情况下)或MAC地址(在第2层覆盖的情况下)。没有单个虚拟路由器21需要包含整个数据中心中所有虚拟机的所有IP前缀或所有MAC地址。给定的虚拟路由器21只需要包含本地存在于服务器12上的那些路由实例(即，其具有存在于服务器12上的至少一个虚拟执行元素)。
网络控制器24的控制平面节点或物理网关路由器(或交换机)之间的控制平面协议可以是BGP(并且可以是用于管理的Netconf)。这是相同的控制平面协议，也可以用于MPLS L3VPN和MPLS EVPN。例如，网络控制器24和虚拟路由器21之间的协议可以基于XMPP。通过XMPP交换的消息的模式可以符合Mackie等人的“BGP-Signaled End-System IP/VPNs”(BGP信令终端系统IP/VPN)，draft-ietf-l3vpn-end-system-06，2016年12月15日，其通过引用整体并入本文。
“基于容器的”或“操作系统”虚拟化是指操作系统的虚拟化，以在单个机器(虚拟或物理)上运行多个隔离的系统。这种隔离系统表示容器，例如由开源DOCKER容器应用或由CoreOS Rkt(“Rocket”)提供的容器。与虚拟机类似，每个容器都是虚拟化的，并且可以保持与主机和其他容器的隔离。然而，与虚拟机不同，每个容器可以省略单个操作系统，并且仅提供应用套件和应用特定的库。一般而言，容器由主机作为隔离的用户空间实例来执行，并且可以与在主机上执行的其他容器共享操作系统和共同库。因此，容器可能比虚拟机需要更少的处理能力、存储和网络资源。一个或多个容器的群组可以被配置为共享一个或多个虚拟网络接口，用于在对应的虚拟网络上进行通信。
在一些示例中，容器由其主机内核管理，以允许对资源(CPU、存储器、块I/O、网络等)进行限制和区分优先级，而无需启动任何虚拟机，在某些情况下使用命名空间隔离功能，该命名空间隔离功能允许完全隔离操作环境的应用(例如，给定容器)视图，包括过程树、联网、用户标识符和安装的文件系统。在一些示例中，可以根据Linux容器(LXC)来部署容器，LXC是操作系统级的虚拟化方法，用于使用单个Linux内核在控制主机上运行多个隔离的Linux系统(容器)。LXC是操作系统级的虚拟化方法，用于在单个控制主机(LXC主机)上运行多个隔离的Linux系统(容器)。LXC不使用虚拟机(尽管LXC可以由虚拟机托管)。相反，LXC使用具有它自己的CPU、存储器、块I/O、网络和/或其他资源空间的虚拟环境。LXC资源控制机制由LXC主机上的Linux内核中的namespaces和cgroups提供。有关容器的更多信息可以在Docker公司的“Docker概述”中找到，可从此处获取：docs.docker.com/engine/understanding-docker，上次访问时间为2016年7月9日。容器化方法的附加示例包括OpenVZ、FreeBSD jail、AIX工作负载分区和Solaris容器。因此，如本文使用的，术语“容器”不仅可以包括LXC型容器，还可以包括任何以下一项或多项：虚拟化引擎、虚拟专用服务器、silo或jail。
服务器12托管这里由IP结构20和交换结构14表示的物理网络上运行的一个或多个虚拟网络的虚拟网络端点。尽管主要针对基于数据中心的交换网络进行描述，但是诸如服务提供方网络7的其他物理网络也可以在一个或多个虚拟网络之下。
服务器12中的每个服务器可以托管一个或多个虚拟执行元素，虚拟执行元素各自具有用于在物理网络中配置的一个或多个虚拟网络的至少一个虚拟网络端点。虚拟网络的虚拟网络端点可以表示共享虚拟网络的虚拟网络接口的一个或多个虚拟执行元素。例如，虚拟网络端点可以是虚拟机、一个或多个容器(例如，pod)的集合或另一(多个)其他虚拟执行元素，诸如用于虚拟网络的第3层端点。术语“虚拟执行元素”包括为应用提供至少部分独立的执行环境的虚拟机、容器和其他虚拟计算资源。术语“虚拟执行元素”还可以包括一个或多个容器的pod。如图1所示，服务器12A以具有一个或多个容器的pod 22A的形式托管一个虚拟网络端点。然而，在给定服务器12的硬件资源限制的情况下，服务器12可以执行尽可能多的虚拟执行元素。每个虚拟网络端点可以使用一个或多个虚拟网络接口来执行分组I/O或以其他方式处理分组。例如，虚拟网络端点可以使用由NIC13A启用的一个虚拟硬件组件(例如，SR-IOV虚拟功能)来执行分组I/O并且在与TOR交换机16A的一个或多个通信链路上接收/发送分组。下面描述虚拟网络接口的其他示例。
服务器12各自包括至少一个网络接口卡(NIC)13，NIC各自包括用于通过通信链路与TOR交换机16交换分组的至少一个接口。例如，服务器12A包括NIC 13A。任何NIC 13都可以提供用于虚拟输入/输出(I/O)的一个或多个虚拟硬件组件21。用于I/O的虚拟硬件组件可以是物理NIC 13(“物理功能”)的虚拟化。例如，在外围组件接口特殊兴趣组SR-IOV规范中描述的单根I/O虚拟化(SR-IOV)中，网络接口卡(或“网络适配器”)的PCIe物理功能被虚拟化以将一个或多个虚拟网络接口呈现为供在服务器12上执行的相应端点使用的虚拟功能。以此方式，虚拟网络端点可以共享相同的PCIe物理硬件资源，并且虚拟功能是虚拟硬件组件21的示例。
作为另一示例，一个或多个服务器12可以实现Virtio，这是例如可用于Linux操作系统的半虚拟化框架，其提供仿真NIC功能作为一种类型的虚拟硬件组件以向虚拟网络端点提供虚拟网络接口。作为另一示例，一个或多个服务器12可以实现Open vSwitch以在用于托管的虚拟机的一个或多个虚拟NIC(vNIC)之间执行分布式虚拟多层交换，其中这样的vNIC还可以表示向虚拟网络端点提供虚拟网络接口的一种类型的虚拟硬件组件。在一些情况下，虚拟硬件组件是虚拟I/O(例如，NIC)组件。在某些情况下，虚拟硬件组件是SR-IOV虚拟功能。
在一些示例中，服务器12的任何服务器可以实现模拟硬件网桥并且在服务器的虚拟网络接口之间或在服务器的虚拟网络接口与服务器的物理网络接口之间转发分组的Linux网桥。对于由服务器托管的容器的Docker实现，在服务器上执行的在容器之间交换分组的Linux网桥或其他操作系统网桥可以被称为“Docker网桥”。本文使用的术语“虚拟路由器”可以包括Open vSwitch(OVS)、OVS网桥、Linux网桥、Docker网桥或位于主机设备上并且在一个或多个虚拟网络的虚拟网络端点之间执行交换、桥接或路由分组的其他设备和/或软件，其中虚拟网络端点由服务器12中的一个或多个服务器托管。
任何NIC 13都可以包括内部设备交换机，以在与NIC相关联的虚拟硬件组件21之间交换数据。例如，对于支持SR-IOV功能的NIC，内部设备交换机可以是虚拟以太网桥(VEB)，用于在SR-IOV虚拟功能之间，以及相应地在被配置为使用SR-IOV虚拟功能的端点之间进行切换，其中每个端点可以包括访客操作系统。内部设备交换机可以备选地被称为NIC交换机，或者对于SR-IOV实现，被称为SR-IOV NIC交换机。与NIC 13A相关联的虚拟硬件组件可以与第2层目的地地址相关联，第2层目的地地址可以由NIC 13A或负责配置NIC 13A的软件过程分配。物理硬件组件(或SR-IOV实现的“物理功能”)也与第2层目的地地址相关联。
为了在与NIC 13A相关联的虚拟硬件组件之间交换数据，内部设备交换机可以执行第2层转发以交换或桥接NIC 13A的虚拟硬件组件与物理硬件组件之间的第2层分组。每个虚拟硬件组件可以位于使用用于I/O的虚拟硬件组件的虚拟网络端点的虚拟网络的虚拟局域网(VLAN)上。NIC内的SR-IOV实现的进一步示例细节在以下文献中进行了描述：“PCI-SIG SR-IOV Primer:An Introduction to SR-IOV Technology”(PCI-SIG SR-IOV入门：SR-IOV技术简介)，修订版2.5，英特尔公司，2011年1月，其通过引用整体并入本文。
服务器12中的一个或多个服务器可以各自包括虚拟路由器21，该虚拟路由器21为数据中心10内的相应虚拟网络执行一个或多个路由实例，以提供虚拟网络接口并且在虚拟网络端点之间路由分组。每个路由实例可以与网络转发表相关联。每个路由实例可以表示用于网际协议-虚拟专用网(IP-VPN)的虚拟路由和转发实例(VRF)。例如，由服务器12A的虚拟路由器21A(图示为“vROUTER 21A”)从数据中心10的底层物理网络结构(即，IP结构20和交换结构14)接收的分组可以包括外部报头，以允许物理网络结构将有效负载或“内部分组”隧道传送到执行虚拟路由器的服务器12A的网络接口卡13A的物理网络地址。外部报头不仅可以包括服务器的网络接口卡13A的物理网络地址，还可以包括诸如VxLAN标签或多协议标签交换(MPLS)标签的虚拟网络标识符，其标识虚拟网络中的一个虚拟网络以及由虚拟路由器21A执行的对应的路由实例。内部分组包括具有符合由虚拟网络标识符所标识的虚拟网络的虚拟网络寻址空间的目的地网络地址的内部报头。
虚拟路由器21终止虚拟网络覆盖隧道，并且基于接收到的分组的隧道封装报头来确定接收到的分组的虚拟网络，并且向分组的适当目的地虚拟网络端点转发分组。对于服务器12A，例如，对于从服务器12A(例如，pod 22A)托管的虚拟网络端点出站的每个分组，虚拟路由器21A附接指示用于该分组的虚拟网络的隧道封装报头以生成封装的或“隧道”分组，并且虚拟路由器21A经由用于虚拟网络的覆盖隧道向物理目的地计算设备输出封装的分组，诸如服务器12中的另一服务器。如本文所使用的，虚拟路由器21可以执行隧道端点的操作，以封装由虚拟网络端点发起的内部分组以生成隧道分组，并且解封装隧道分组以获取用于路由到其他虚拟网络端点的内部分组。
计算基础设施8实现用于在服务器12上自动部署、缩放和操作虚拟执行元素的自动化平台，以提供用于执行应用工作负载和服务的虚拟化基础设施。在一些示例中，平台可以是容器协调平台，其提供以容器为中心的基础设施，用于自动化容器的部署、缩放和操作，以提供以容器为中心的基础设施。在虚拟化计算基础设施的上下文中，“协调”通常指的是向协调平台可用的主机服务器供应、调度和管理在这样的虚拟执行元素上执行的虚拟执行元素和/或应用和服务。具体地，容器协调允许容器协作，并且指的是例如由容器协调平台对容器到主机服务器的部署、管理、缩放和配置。协调平台的示例实例包括Kubernetes、Docker swarm、Mesos/Marathon、OpenShift、OpenStack、VMware和Amazon ECS。
计算基础设施8的自动化平台的元素至少包括服务器12、协调器23和网络控制器24。可以使用基于集群的框架将虚拟执行元素部署到虚拟化环境，在该框架中，集群中的集群主节点管理容器到集群中的一个或多个集群从属节点的部署和操作。本文使用的术语“主节点”和“从属节点”包含不同的协调平台术语，用于区分主要是集群的管理元素和主要是托管集群的设备的虚拟执行元素的模拟设备。例如，Kubernetes平台使用术语“集群主节点”和“从属节点”，而Docker Swarm平台指的是集群管理器和集群节点。
协调器23和网络控制器24一起实现用于计算基础设施8的控制器5。协调器23和网络控制器24可以在作为计算系统的部分的分离的计算设备上执行，或者可以在同一计算设备上执行。协调器23和网络控制器24中的每个可以是在计算系统的一个或多个计算设备上执行的分布式应用。协调器23和网络控制器24可以为一个或多个集群实现相应的主节点，每个集群具有由相应服务器12实现的一个或多个从属节点。一般而言，网络控制器24控制数据中心10结构的网络配置，以例如建立用于虚拟网络端点之间的分组化通信的一个或多个虚拟网络。网络控制器24提供逻辑上并且在某些情况下物理上集中的控制器，用于协助数据中心10内的一个或多个虚拟网络的操作。在一些示例中，网络控制器24可以响应于从协调器23和/或监管器/运营方接收的配置输入而操作。关于与数据中心10的其他设备或其他软件定义网络结合操作的网络控制器24的附加信息可以在以下文献中找到：国际申请号PCT/US2013/044378，于2013年6月5日提交，题为“PHYSICAL PATH DETERMINATION FORVIRTUAL NETWORK PACKET FLOWS”(虚拟网络分组流的物理路径确定)；美国专利申请第14/226,509号，于2014年3月26日提交，题为“Tunneled Packet Aggregation for VirtualNetworks”(虚拟网络中的隧道分组聚合)；以及美国专利申请第17/305,110号，于2021年6月30日提交，题为“Network Controller Horizontal Scaling for Network DeviceConfigurations Session Management”(用于网络设备配置和会话管理的网络控制器水平扩展)；其每个申请都通过引用并入本文，就如本文完全阐述一样。美国专利申请第14/226,509号还包括对诸如虚拟路由器21A的虚拟路由器的进一步描述。
一般而言，协调器23控制跨服务器集群12和提供计算基础设施的虚拟执行元素的部署、缩放和操作，计算基础设施可以包括以容器为中心的计算基础设施。协调器23，以及在一些情况下网络控制器24，可以为一个或多个Kubernetes集群实现相应的集群主控器。作为示例，Kubernetes是容器管理平台，其提供跨公有云和私有云的可移植性，其中云中的每个云都可以为容器管理平台提供虚拟化基础设施。
在一个示例中，pod 22A是Kubernetes pod和虚拟网络端点的示例。pod是一个或多个逻辑上相关的容器的群组(图1中未示出)、容器的共享存储以及关于如何运行容器的选项。在被实例化以供执行的情况下，备选地将pod称为“pod复制品”。pod 22A的每个容器是虚拟执行元素的示例。pod的容器始终同位于单个服务器上，共同调度，并且在共享上下文中运行。pod的共享上下文可以是Linux命名空间、cgroups和其他隔离方面的集合。在pod的上下文中，各个应用可能会应用更多的子隔离。通常，pod内的容器具有共同的IP地址和端口空间，并且能够经由本地主机彼此检测。因为它们具有共享的上下文，所以pod中的容器也使用过程间通信(IPC)彼此通信。IPC的示例包括SystemV信号量或POSIX共享存储器。一般而言，作为不同pod成员的容器具有不同的IP地址，在没有配置启用该特征的情况下，无法通过IPC进行通信。作为不同pod成员的容器通常经由pod IP地址彼此通信。
服务器12A包括容器平台19A，用于运行容器化的应用，例如pod 22A的那些应用。容器平台19A从协调器23接收请求以获取容器并且将其托管在服务器12A中。容器平台19A获取并且执行容器。
容器平台19A包括为虚拟网络端点配置虚拟网络接口的网络模块17A。容器平台19A使用网络模块17A来管理包括pod 22A在内的pod的联网。例如，网络模块17A创建虚拟网络接口以将pod连接到虚拟路由器21A，并且使得这种pod的容器能够经由虚拟网络接口与虚拟网络上的其他虚拟网络端点通信。例如，网络模块17A可以将用于虚拟网络的虚拟网络接口插入到容器中pod 22A的网络命名空间中，并且在虚拟路由器21A中配置(或请求配置)用于虚拟网络的虚拟网络接口，使得虚拟路由器21A被配置为将经由虚拟网络接口从虚拟网络接收到的分组发送到pod 22A的容器，并且在虚拟网络上发送经由虚拟网络接口从pod22A的容器接收到的分组。
网络模块17A可以分配网络地址(例如，用于虚拟网络的虚拟IP地址)，并且可以为虚拟网络接口设置路由。在Kubernetes中，默认情况下，所有pod都可以与所有其他pod通信，而无需使用网络地址转换(NAT)。在一些情况下，协调器23和网络控制器24创建由分别从其分配服务和pod网络地址的所有命名空间共享的服务虚拟网络和pod虚拟网络。在一些情况下，在Kubernetes集群中产生的所有命名空间中的所有pod能够彼此通信，并且所有pod的网络地址可以从由协调器23指定的pod子网中分配。当用户为pod创建隔离命名空间时，协调器23和网络控制器24可以为新的隔离命名空间创建新的pod虚拟网络和新的共享服务虚拟网络。在Kubernetes集群中产生的隔离命名空间中的pod从新的pod虚拟网络中提取网络地址，并且用于这些pod的对应服务从新的服务虚拟网络中提取网络地址
网络模块17A可以表示用于服务器12A的库、插件、模块、运行时或其他可执行代码。网络模块17A可以至少部分地符合容器联网接口(CNI)规范或rkt联网提案。网络模块17A可以表示Contrail或OpenContrail网络插件。网络模块17A备选地被称为网络插件或CNI插件或CNI实例。就容器网络接口(CNI)规范而言，可以将容器视为Linux网络命名空间的同义词。这对应的单元取决于特定的容器运行时实现：例如，在诸如rkt的应用容器规范的实现中，每个pod在唯一的网络命名空间中运行。然而，在Docker中，每个分离的Docker容器通常都存在网络命名空间。就CNI规范而言，网络指的是可唯一寻址并且可彼此通信的实体的群组。这可以是单个容器、机器/服务器(真实的或虚拟的)或某个其他网络设备(例如，路由器)。容器可以在概念上添加到一个或多个网络或从其中删除。
涉及虚拟执行元素的技术的进一步示例在以下文献中进行了描述：“MULTIPLEVIRTUAL NETWORK INTERFACE SUPPORT FOR VIRTUAL EXECUTION ELEMENTS”(支持虚拟执行元素的多个虚拟网络接口)，2018年8月20日提交的美国申请第16/118,107号；以及“UNIFIED CONTROL PLANE FOR NESTED CLUSTERS IN AVIRTUALIZED COMPUTINGINFRASTRUCTURE”(虚拟计算基础设施中嵌套集群的统一控制平面)，2018年8月31日提交的美国申请第16/118,731号，其中每一个的全部内容通过引用并入本文。
在图1的示例中，协调器是计算系统，其接收用于虚拟化服务的主动测试的声明性测试描述符；从协调层获取与虚拟化服务相关联的元数据，其中元数据指定由协调层管理的集群的命名空间内的虚拟化服务的唯一名称；由计算系统使用声明性测试描述符和元数据来确定用于虚拟化服务的实例的主动测试配置；以及根据主动测试配置来启动主动测试，并且基于主动测试的结果来确定虚拟化服务的实例的服务等级违规。
“主动保证”是指通过使用诸如上述主动网络探测技术(例如，发送测试分组)的主动监控来确保所测量的服务等级符合服务等级要求，使得在不满足SLA要求的情况下可以在网络中采取补救动作。
声明性测试描述符是监控运营方50理解的声明性输入(例如，基于意图)。在一些示例中，监控运营方50可以实现网络系统100的基于意图的配置和管理。例如，声明性要求表达了期望的网络组件配置，而不指定确切的本机设备配置和控制流。通过利用声明性要求，可以指定应当完成什么，而不是应当如何完成。声明性要求可能与描述实现配置的确切设备配置语法和控制流的命令性指令形成对比。通过利用声明性要求而不是命令性指令，减轻了用户和/或用户系统确定实现用户/系统的期望结果所需的确切设备配置的负担。例如，当使用来自不同供应方的各种不同类型的设备时，指定和管理确切的命令指令来配置网络的每个设备通常是困难和繁重的。网络的设备类型和种类可以随着新设备的添加和设备故障的发生而动态变化。
使用不同的配置协议、语法和软件版本来管理来自不同供应方的各种不同类型的设备，以配置具有粘着力的设备网络通常很难实现。因此，通过仅要求用户/系统指定声明性要求，该声明性要求指定适用于各种不同类型设备的期望结果，网络设备的管理和配置变得更高效。
图2是示出根据本公开中描述的技术的示例移动网络系统的框图。移动网络系统100可以是5G网络，其实现由例如第三代合作伙伴计划(3GPP)、开放无线电接入网络(“O-RAN”或“ORAN”)联盟、欧洲电信标准协会(ETSI)、互联网工程任务组(IETF)和国际电信联盟(ITU)公布的5G标准。
通过围绕云本机原则构建，5G网络允许解聚合移动前传和中传网络。由此，服务提供方可以避免被锁定在特定的电器供应方中，并且可以在不同的层和位置组合来自不同供应方的有效解决方案，以构建和供应移动网络系统。这尤其可以通过使无线电接入网络(RAN)更开放、更具弹性和更具可缩放性来改善RAN。
基于O-RAN的网络将传统电信网络中的基带单元(BBU)分解为三个功能单元：无线电单元(RU)、分布式单元(DU)和集中单元(CU)。RU、DU和CU的不同功能可以由基于x86或基于ARM的主机服务器执行的软件来实现。CU可以进一步分为不同的控制平面(CU-CP)和用户平面(CU-UP)功能，以进一步控制用户平面分离(CUPS)。这种解耦合有助于为部署带来灵活性——RU、DU和CU的不同组合可以部署在同一位置，也可以部署在不同的位置。例如，在延时很关键的情况下，RU、DU和CU可以一起放置在边缘处。符合O-RAN的DU和CU通常分别称为O-DU和O-CU。称为用户平面功能(UPF)的附加数据平面元素在移动核心网107中操作以在CU与数据网络115之间转发业务。附加的控制平面元素在移动核心网络107中操作。这些控制平面元素包括网络切片选择功能(NSSF)、策略控制功能(PCF)、认证服务器功能(ASUF)、接入和移动性管理功能(AMF)、网络暴露功能(NEF)、网络功能存储库功能(NRF)、应用功能(AF)、统一数据管理(UDM)和会话管理功能(SMF)。
移动网络系统100包括无线电接入网络109和移动核心网络107。无线电接入网络109包括位于各种蜂窝网络站点(“蜂窝站点”)的RU 114。每个RU 114由LO PHY和RF传输器组成。可以使用用于高性能分组处理的专用硬件来实现LO PHY组件。
RU 114经由前传网络连接到DU 122A至122X(统称为“DU 122”)。前传网络连接LOPHY和HI PHY，并且被RU 114和DU 122用来实现5G的F2接口。DU 122通过RU 114管理无线电的分组传输。在一些情况下，这种分组传输符合公共分组无线电接口(CPRI)和/或增强型CPRI(eCPRI)标准，或符合IEEE 1914.3。DU 122可以实现无线电链路控制(RLC)、媒体访问控制(MAC)和HI PHY层。DU 122至少部分地由CU 113A至113B(统称为“CU 113”)控制。
DU 122经由中传网络连接到CU 113，DU 122和CU 113可以使用该中传网络来实现5G的F1接口。CU 113可以实现无线电资源控制(RRC)和分组数据融合协议(PDCP)层。CU 113经由回传网络连接到移动核心网络107。中传和回传网络中的每个网络都可以是广域网(WAN)。
在移动网络系统100的无线电接入网络109中，gNodeB包括CU 113中的一个CU和DU122中的一个DU。CU可以支持多个DU以实现多个gNodeB。并且一个或多个RU可以由单个DU支持。因此，例如参考图2，模拟的CU 113A和模拟的DU 122A以及模拟的RU可以形成一个模拟的eNodeB，而(服务器112X的)CU 113B和DU 122X以及RU中的一个RU可以形成另一eNodeB。
DU 122中的任何DU可以位于也可以不位于包括由该DU支持的(多个)RU 114的蜂窝站点。移动网络系统100可以具有包括数千个蜂窝站点的无线电接入网络109，每个蜂窝站点具有一个或多个RU 114，并且可选地具有一个或多个DU 122。无论位于蜂窝站点还是站下，DU通常位于所支持的RU的20km范围内。图2中示出了CU 113位于地区数据中心，通常在所支持的DU 122的40km范围内。
无线电接入网络109连接到移动核心网络107以与数据网络115交换分组。移动核心网络107可以是5G核心网络，并且数据网络(DN)115可以表示例如一个或多个服务提供方网络和服务、互联网、第三方服务、IP多媒体子系统或其他网络。
移动网络系统100包括多个服务器112A至112X以执行DU 122。服务器112中的每个服务器可以是托管/执行实现DU 122的软件的真实或虚拟服务器。这样的软件可以包括作为例如虚拟机或容器部署到服务器112的一个或多个应用。虽然图2中未示出，但CU 113也可以由服务器执行。DU 122、中传网络、CU 113和回传网络的组合有效地实现了无线电单元114与移动核心网络107之间的基于IP的传输网络。5G系统的更多细节在以下文献中进行了描述：于2021年6月30日提交的，美国临时专利申请第63/202,928号；以及于2021年9月9日提交的，美国临时专利申请第63/242,434号，其中每个申请的全部内容通过引用并入本文。
协调器148表示容器协调平台。协调器148协调服务器112的模拟UE 120、模拟DU122、模拟CU 113、DU 22x、CU 113B以及至少容器化测试代理140A、140X。
容器，包括那些实现模拟器125和测试代理140的容器，可以使用基于集群的框架被部署到虚拟化环境，其中集群的集群主节点管理容器到集群的一个或多个集群从属节点的部署和操作。服务器112或其上的虚拟机可以表示集群节点。
根据本公开的技术方面，协调器148包括监控运营方150，以管理部署到系统100的网络切片的测试。协调器148的监控运营方150可以将测试代理140A至140X(统称为“测试代理140”)部署为模拟器125的部分和/或部署到另一服务提供方网络(例如，数据网络115)，以针对所请求的网络切片来模拟和测试RAN网络。此外，在已经测试和验证了网络切片之后，在一些示例中，监控运营方150可以插入和控制测试代理140以监控运行中的网络切片，同时在DU 122、CU 113和移动核心网络107之间传输第3层分组。应用工作负载可以是容器化网络功能(CNF)，例如DU 122、CU 113和RU。
协调器148和软件定义网络(SDN)控制器170可以在不同的计算设备上执行或在同一计算设备上执行。协调器148和SDN控制器170中的每个都可以是在一个或多个计算设备上执行的分布式应用。协调器148和SDN控制器170可以为一个或多个集群实现主节点，每个集群具有由相应服务器112实现的一个或多个从属节点。一般而言，SDN控制器170控制无线电接入网络109的网络配置，以协助DU 122、CU 113和移动核心网络107之间的分组化通信。SDN控制器170可以将路由和配置信息分发给无线电接入网络109的控制平面元素。SDN控制器170可以例如在无线电接入网络109的路由器(包括蜂窝站点路由器(未示出))中编程分段路由报头、配置L3VPN、配置虚拟路由和转发实例(VRF)。SDN控制器170可以实现用于配置中传和回传网络的路由器、交换机和其他网络设备的一个或多个南向协议。示例南向协议可以包括路径计算元素协议(PCEP)、BGP、Netconf、OpenConfig等。关于L3VPN的附加信息可以在以下文献中找到：“BGP/MPLS IP Virtual Private Networks(VPNs)”(BGP/MPLS IP虚拟专用网(VPN))，注解请求4364，互联网工程任务组的网络工作组，2006年2月，其通过引用整体并入本文。
SDN控制器170可以提供逻辑上以及在某些情况下物理上集中的控制器。在一些示例中，SDN控制器170可以响应于从协调器48和/或监管器/运营方接收的配置输入而操作。SDN控制器170可以对NFV基础设施(NFVI)进行编程，例如服务器112、网络交换机/路由器和/或其他网络基础设施。在NFVI编程的情况下，SDN控制器170可以配置操作系统内核的各方面以配置L3 IP路由、Linux网桥、iptable、网络命名空间和/或虚拟交换机。
关于示例SDN控制器170、虚拟路由器和虚拟路由器代理的附加信息可以在以下文献中找到：国际申请号PCT/US2013/044378，于2013年6月5日提交，题为“PHYSICAL PATHDETERMINATION FOR VIRTUAL NETWORK PACKET FLOWS”(用于虚拟网络分组流的物理路径确定)；美国专利申请第14/226,509号，于2014年3月26日提交，题为“Tunneled PacketAggregation for Virtual Networks”(针对虚拟网络的隧道分组聚合)；以及美国专利申请第17/305,110号，于2021年6月30日提交，题为“Network Controller HorizontalScaling for Network Device Configurations Session Management”(用于网络设备配置和会话管理的网络控制器水平扩展)，其中每个申请都通过引用并入，就如本文完全阐述一样。
在一些示例中，模拟器125的组件，诸如模拟UE 120、模拟DU 122A和模拟CU 113A，可以通过将模拟器125的组件作为可用于模拟网络切片的RAN的Kubernetes资源呈现给协调平台来集成到Kubernetes基础设施中。因此，通过部署用作Kubernetes资源的容器化模拟器组件和测试代理、集成到移动网络系统100中以及集成到Kubernetes中，这些技术可以协助用于网络切片部署、配置、测试和操作监控的云本机体验。集成到Kubernetes中允许利用其现有机制来监控容器化网络切片的健康状况，并且在必要时重新启动，同时管理网络切片的生命周期，尤其是容器化网络切片。
协调器148可以类似于图1的协调器23，并且网络控制器170可以类似于图1的网络控制器24。协调器148实现用于在服务器112上自动部署、缩放和操作虚拟执行元素的自动化平台，以提供用于执行应用工作负载和服务的虚拟化基础设施。
服务器112A包括用于运行诸如一个或多个pod的容器化应用的容器平台。容器平台从协调器148接收请求，以获取容器并且在服务器112A中托管容器。容器平台获取并且执行容器。pod是一个或多个逻辑上相关的容器的群组、容器的共享存储以及关于如何运行容器的选项。在被实例化以供执行的情况下，备选地将pod称为“pod复制品”。pod或pod的每个容器是虚拟执行元素的示例。pod的容器始终同位于单个服务器上，共同调度，并在共享上下文中运行。pod的共享上下文可以是Linux命名空间、cgroups和其他隔离方面的集合。在pod的上下文中，各个应用可能会应用进一步的子隔离。通常，pod内的容器具有共同的IP地址和端口空间，并且能够经由本地主机彼此检测。因为它们具有共享的上下文，所以pod中的容器也使用过程间通信(IPC)彼此通信。IPC的示例包括SystemV信号量或POSIX共享存储器。一般而言，作为不同pod成员的容器具有不同的IP地址，在没有配置启用该特征的情况下，无法通过IPC进行通信。作为不同pod成员的容器通常经由pod IP地址来彼此通信。
可以根据本公开的技术执行网络切片测试。当创建网络切片时，网络运营方创建具有UE和gNB配置的网络模拟器。UE配置包括用于附接到gNB的UE的配置，该配置包括要使用的网络切片标识符和类型。gNB配置包括gNB IP地址和AMF IP地址。模拟器利用这些配置而被部署到Kubernetes中。在部署时，创建针对每个UE和服务类型的模拟器服务，以暴露服务以提供质量保证。可以利用监控运营方50启动质量保证所需的标签来标记服务，其描述例如将在质量保证中使用的切片服务类型和测试代理。可以自动创建配置并且部署到Kubernetes。监控运营方150通过启动服务等级验证的相关测试来启动切片服务验证。
测试代理140可以作为软件即服务(SaaS)解决方案从云中交付，或者部署在NFV环境中的场所。测试代理140例如通过在测试代理之间发送恒定速率UDP流的UDP测试来执行服务等级验证，并且可以根据端点之间的接收速率、抖动和丢弃来确定服务等级。作为进一步的示例，测试代理40可以发送和/或接收测试分组以计算网络的一个或多个关键性能指标(KPI)，诸如延时、延迟(帧间间隙)、抖动、分组丢失、吞吐量等。将所测量的服务等级KPI与预定义的服务等级要求进行比较。
测试代理140可以根据各种协议来发送测试分组，诸如超文本传输协议(HTTP)，互联网控制消息协议(ICMP)，Speedtest，用户数据报协议(UDP)，传输控制协议(TCP)，操作、管理和维护(OAM)功能(例如，Y.1731)，双向主动测量协议(TWAMP)，互联网协议电视(IPTV)和Over the Top(OTT)协议，VoIP电话和会话发起协议(SIP)，移动无线电，远程分组检测和其他协议以测量网络性能。服务等级要求验证结果由控制中心(未示出)收集，并且可以提供给网络运营方。例如，服务等级要求可以从提供方与客户之间的服务等级协议中获取。
被模拟的服务可以是Kubernetes服务。测试代理和UE/eNodeB/gNodeB服务可以在相同的pod中，也可以在不同的pod中。模拟器125上的测试代理140A通过包括UPF 142和AMF144的实际移动核心网107连接到数据网络115处的测试代理140B。在一些示例中，根据本公开的系统或技术可以使用仿真RAN网络109的(多个)软件组件。UE和/或eNodeB/gNodeB仿真器可以用于将测试代理140A连接到移动核心网络107。
在一些示例中，在使用UE和/或eNodeB/gNodeB仿真器在模拟环境中验证网络切片之后，相同的测试代理140A可以用于在处理实时网络业务时对网络切片进行后续监控。测试代理140X是用于使用蜂窝站点中的DU 122X和CU 113B监控通过RAN 109和移动核心网107部署的网络切片的测试代理的示例。
图3是示出根据本公开中描述的技术，包括与Kubernetes平台集成的监控运营方250的示例计算系统200的框图。监控运营方250将信息提供给控制中心，该控制中心控制用于监控虚拟化服务的测试代理。计算系统200为物理、混合和虚拟网络提供可编程的、主动的测试和监控服务。与被动监控方法不同，本公开描述了发送主动合成业务以在服务递送时和整个服务生命周期自动验证应用和服务性能的测试代理。
主动测试涉及注入带有时间戳的合成分组流，以允许主动检测网络中的异常和性能下降。
控制中心可以是云就绪多租户控制中心，它提供用户友好的web门户GUI，操作人员可以使用该GUI运行按需测试并且查看实时和聚合结果以及关键性能指标(KPI)和服务等级协议(SLA)监控度量。控制中心包括功能丰富的云API，其允许外部操作支持系统(OSS)和网络功能虚拟化(NFV)协调器容易地自动执行分布式主动测试或监控场景。
图3的系统可以包括除了所示的那些之外的附加测试代理。控制中心远程控制基于软件的和业务生成的测试代理，这些代理为服务主动测试、质量监控和故障排除提供分布式测量度量。控制中心还显示测试代理和反射器流跨多个应用、服务和接口主动测量的详细实时结果和统计数据。测试代理功能包括服务激活(Y.1564、MEF 48)、网络性能(UDP、TCP、Y.1731、TW AMP、路径追踪)、互联网性能(HTTP、DNS)、富媒体(IPTV、OTT视频、VoIP电话和SIP)，以及对控制Wi-Fi接口和执行远程分组检测的支持。
测试代理可以放置在整个网络中的策略位置，以进行持续的质量监控。它们还可以按需安装，用于更临时的目的，例如对新部署的服务进行主动测试。测试代理可以以任何多种格式进行部署，例如：在管理程序上作为虚拟机运行的软件、作为容器应用或作为用于安装在专用x86硬件上的软件设备。
计算系统200为全多层、多域服务生命周期管理提供集成的、动态的解决方案，其组合了服务主动测试、质量监控和故障排除，提供了完全协调的保证。
在一些示例中，虚拟化服务与网络服务相关联。在一些示例中，根据本公开的技术的示例方面，网络服务是模拟网络切片或活动网络切片。根据本公开的技术的一些示例方面，通过标记现有服务和入口并且部署监控运营方、监控模板、测试代理和控制中心，可以以最小的努力来协调对Kubernetes服务或其他虚拟执行元素服务的测试。例如，部署监控运营方、监控模板、测试代理和控制中心可以通过Helm完成。测试代理和控制中心可以根据用例的需要而被部署到Kubernetes集群或装置中。本公开描述了利用UE/eNodeB来仿真动态实现5G网络切片测试的用例。
图3的系统提供了实现集成到Kubernetes平台中的监控运营方250。在一些示例中，监控运营方被配置为启用对网络切片的自动监控。监控运营方250读取Kubernetes服务和入口的标签，并且使用这些标签自动启动监控任务。例如，服务可以标记为test_agent_external、http_monitor、ping_monitor。当部署服务时，将创建对应的监控功能，并且从标记的测试代理运行这些功能。在图3的示例中，利用适合于任务的现有Kubernetes资源、pod、部署、复制品集合等来完成协调测试代理。在某些情况下，可以使用定制资源定义(CRD)系统。定义了CRD来为监控提供参数。在某些示例中，CRD不将监控器和测试代理绑定在一起。
示例：
服务和入口利用匹配的标签而被标记。
apiVersion:v1
kind:Service
metadata:
annotations:
labels:
app-kubernetes-io/instance:ncc
app-kubernetes-io/name:ncc
Company.com/monitor:http
Company.com/test-agent:ta-in-cluster
name:ncc
namespace:ncc
spec:
ports:
name:ncc
port:80
protocol:TCP
targetPort:80
selector:
app-kubernetes-io/instance:ncc
app-kubernetes-io/name:ncc
sessionAffinity:None
type:ClusterIP
status:
loadBalancer:{}
入口示例：
apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
labels:
app-kubernetes-io/instance:ncc
Company.com/monitor:http
Company.com/test-agent:ta-outside-cluster
name:ncc-https
namespace:ncc
spec:
rules:
host:app.ncctest.Company.com
http:
paths:
backend:
serviceName:ncc
servicePort:80
path:/
pathType:ImplementationSpecific
tls:
hosts:
app.ncctest.Company.com
如图3所示，可以执行主动监控(也称为主动测试)。监控是使用声明性测试描述符进行的。监控运营方250从系统(例如，Kubernetes)的协调层接收元数据，元数据与由虚拟执行元素提供的多个服务相关联。使用声明性测试描述和元数据来确定主动测试配置。然后利用所应用的配置启动主动测试，并且可以根据主动测试结果来确定服务等级违规。
测试代理被分离部署，既可以作为Kubernetes pod或docker引擎，也可以作为装置。监控运营方250读取标签并且将测试代理IP地址和标签、服务端点、模板名称和参数提供给协调监控的所连接的控制中心。在使用Kubernetes外部测试代理的情况下，则使用标签/标记对其进行绑定。由于声明性测试描述符和元数据，当对虚拟执行元素发生更新时，测试代理可以自动和动态地更新测试配置。附加示例在以下文献中进行了描述：于2020年11月16日提交的美国临时专利申请第63/114,444号，其全部内容通过引用并入本文。
尽管以Kubernetes为例进行了描述，但本文描述的技术可以应用于其他类型的虚拟执行元素。如更详细地描述的，在一些示例中，运营方可以在其他平台上运行，例如Contrail Insights平台和OpenStack平台，Contrail环境的vCenter，在边缘云用例中和在5G系统中。本公开的技术不限于云服务，而是可以在云环境、数据中心环境或内部环境中的任何环境中执行。
有许多即将推出的5G架构，包括云本机5G基础设施。云本机基础设施依赖于5G核心系统的软件定义网络(SDN)和基于服务的架构(SBA)。5G系统(5GS)的3GPP TS 23.501技术规范中描述的云本机5G系统架构是使用遵循微服务设计模式的NF服务组件构建的。服务是使用服务发现机制的SBA架构的部分，在该机制中服务可以彼此发现并且通信，即服务网状结构。
5GS分为两个平面，控制平面和用户平面。这种逻辑分离通常称为控制和用户平面分离(CUPS)。控制平面由负责认证、会话管理、网络切片配置和QoS策略控制等的NF组成。而用户平面由用户平面功能(UPF)和能够更接近终端用户或设备运行的客户定义的服务组成。UPF是负责QoS业务整形、业务使用报告、传输级分组标记以及分组路由和转发等的功能。
客户定义的服务需要非常接近终端用户和设备，这就产生了边缘计算的概念。当设备之间需要低延时和高带宽时，边缘计算将为运行离用户更近的应用提供资源，例如IoT用例。边缘计算提供的执行环境可以与分布式云相比，其中计算资源不仅位于数据中心中，而且位于靠近终端用户的节点中。
网络功能虚拟化基础设施(NFVI)是执行环境，它为供应方提供了用于部署他们的VNF和基于容器的应用的平台。NFVI概念不仅限于托管云本机电信组件，例如5G基础设施。NFVI可用于内容交付网络(CDN)、物联网(IoT)、移动宽带、企业和媒体供应方等，作为可以使用NFVI的客户。
最终，NFVI的网络协调和管理由网络功能虚拟化(NFV)管理和协调(MANO)实体处理。在ETSI NFV-MANO架构框架中，NFV-MANO的主要功能块是：NFV协调器——与下面提到的虚拟化基础设施管理器(VIM)接口的NFVI资源的协调；VNF管理器——VNF实例的生命周期管理，例如实例化、修改和升级；以及虚拟化基础设施管理器(VIM)——控制和管理NFVI计算、存储和网络资源等。
在一些示例中，VIM功能块可以由云计算基础设施支持，例如由OpenStack和VMware提供的那些。在某些示例中，OpenStack平台可以用于提供计算、存储和网络能力。然而，这些由OpenStack和VMware支持的VIM平台并不是唯一的备选。NFVI供应方正朝着将Kubernetes作为其平台中的NF的执行环境的方向发展。Kubernetes环境被认为带来了更容易的生命周期管理和更少的开销等，而不需要任何虚拟化层。
NFVI可以依赖统一的容器和基础设施管理，其中它仅与Kubernetes和Helm API相接口。该MANO将能够同时运行容器化的NF(CNF)和VNF两者。CNF由容器运行时运行，例如Docker或rkt，而VNF可以使用KubeVirt之类的解决方案运行，该解决方案使Kubernetes能够运行基于虚拟机的工作负载。
3.2Kubernetes
Kubernetes协调了容器化流程作为服务的系统，并在其生命周期内监控其运行状况。该系统高度分布，并且运行在节点集合(即集群)之上，其中Kubernetes将在集群中的节点上调度过程。服务可以彼此通信，从而支持微服务架构，其中每个服务都可以执行特定的业务逻辑。人们可以将Kubernetes视为抽象层，它隐藏了底层基础设施，并且简化了应用的部署和生命周期管理。
Kubernetes的控制组件通常被称为控制平面组件，这些组件将一起观察并且动作以向期望的集群状态移动。有四个组件构成了Kubernetes控制平面的基本设置，
·kube-apiserver,
·etcd,
·kube-scheduler,
·kube-controller-manager.
最后，在标准Kubernetes设置中还有另外两个组件，它们通常被称为节点组件。这些组件是，
·Kubelet,
·kube-proxy.
容器由Kubelet(即节点代理)管理，其中容器和Kubelet两者都被托管在工作方节点上。工作方节点以worker为前缀，因为它们处理运行Kubernetes中托管的服务的实际作业。除了Kubelet，同一个工作方节点上还托管了一个名为kube-proxy的服务。kube-proxy是误称，因为该服务实际上并不执行任何代理(历史上它处理代理业务)；相反，该服务使用iptable管理将业务转发到虚拟IP地址后面的PodsK的规则。
3.2.1 API
Kubernetes API是Kubernetes集群的核心组件。集群的所有操作都通过Kubernetes API完成，并且Kubernetes中的所有用户和过程都可以访问。这称为中心辐射型(hub-and-spoke)API模式。实现Kubernetes API的API服务器(例如kube-apiserver)本身是无状态的，而状态被存储在存储后端中，通常是etcd存储。通过无状态，API服务器可以缩放到多个实例，这一点很重要，因为API是处理大量请求的中心组件。API服务器通过HTTP实现RESTful API。这表明通过遵循RESTful设计模式，为操作完成的所有请求都由路径和方法(即，HTTP方法，如GET和POST)定义。
可用的核心Kubernetes操作在/api前缀之后，而其他操作在/apis前缀的API组之后。/api前缀后面的核心Kubernetes API主要是一个历史制品，因为新的Kubernetes提供的API已经作为API组添加。对于API组，前缀(/apis)后跟组名，例如，/apis/apps。
此外，Kubernetes API是版本化的和命名空间的，这为划分提供了另一维度。在组名之后提供版本化，使用
最后一个示例路径，包括版本的路径可以是/apis/apps/v1。版本名称遵循一个约定，即不稳定的API命名为v1alpha1，其中v1是计划发布，alpha是API的稳定性，最后的整数是当前版本。一旦API变得基本稳定，版本就被转移到v1beta1，其中它的工作方式与之前关于计划发布和修订的alpha版本一样。最后，稳定的API可以发布为v1，这些API必须保证向后兼容，并且必须只能替换为下一版本名称下的新的稳定版本，即v2。当在v2版本上工作时，它将遵循与上述相同的模式。
命名空间用于提供可以用于将物理集群划分为多个虚拟集群的范围。它在版本标识符后给出，继续上一示例，命名空间可以是项目名称。将命名空间称为“production”(制作)，则路径为/apis/apps/v1/production。
最后给出了要创建的实际对象，对于部署，路径为/apis/apps/v1/production/deployments。Kubernetes API支持三种不同的编码：JSON、YAML和protobuf。JSON和YAML格式是人类可读的，而protobuf格式是线路上的二进制格式，从而实现了更高效的序列化和吞吐量。
3.2.2控制器&对象
Kubernetes控制器是通过前面描述的Kubernetes API观察集群状态的循环。控制器的任务是尝试将集群的状态从Kubernetes对象设置的约束转移到想要的状态。这些对象是特定类型的资源(在Kubernetes术语中，资源类型也称为Kind(种类))。其中资源，即对象，是Kubernetes集群内表示想要的和当前状态的持久实体。此种类的对象的示例有，
·PodK-描述容器集合的对象的种类，
·ReplicaSetK-描述复制的PodsK的集合对象的种类，
·DeploymentK-帮助ReplicaSetK的生命周期管理的对象的种类，
·DaemonSetK–在多个节点上复制PodsK的对象的种类，
·JobK-运行PodsK的对象的种类，一旦完成将最终终止。
在Kubernetes生态系统中有更多的种类，甚至可以定义自己的种类，称为定制资源定义(CRD)。CRD背后的理论将在下面的3.2.4节中描述。
如前所述，这些特定种类的对象由控制器观察。一旦观察到事件，控制器将分析Kubernetes中对象的当前状态，并且将其与规范(或Spec)进行比较。此规范是存储在对象中的字段，其描述对象的期望状态。在发现差异的情况下，控制器将按照规范的要求采取行动，并且通过Kubernetes API操作状态来将状态移向期望的状态。对该对象的更新将再次触发循环。并且该循环将继续，直到已经达到期望状态，或者继续无限循环。这种观察-分析-动作的循环称为调和(reconciliation)循环。
还存在与其他控制器一起观察同一种类的单个对象的控制器。两个这样的控制器是JobK控制器和TTL控制器。JobK控制器启动并且管理应当运行到完成的作业的生存期，而TTL控制器将在指定时间之后删除已完成的JobK对象。另一种方式也是可能的，即单个控制器观察特定种类的多个对象。
Kubernetes中的对象可以被标记或注释。标签用于标识具有某个或多个属性的对象。而注释用于将非标识数据附接到对象。标签和注释以键-值记录的形式编写，其中键在单个对象的域中必须是唯一的。因此，集群中的多个对象可以具有相同的标签和注释。
标签用于选择与查询或标签选择器匹配的对象。标签选择器是逗号分隔的要求的集合，这些要求被AND:ed在一起以形成查询，即所有要求必须匹配才能选择对象。标签选择器中可以给出两种类型的要求。
第一(1)，基于等式的要求将匹配具有给定标签键和匹配值的标签。同样的要求也可以匹配不等式，即没有指定的标签键和匹配值的对象。等式使用＝或＝＝运算符，而不等式使用！＝运算符。例如，标签选择器zone＝south,environment！＝dev将选择具有清单3中定义的标签的对象。
第二(2)，基于集合的要求面向三个运算符，in、notin和(key)existence。所提到前两个将检查标签是否具有给定集合中的一个值。最后一个将检查标签键是否存在，无论值是什么。
例如，app,zone in(north,south),svc notin(web),将选择满足以下条件的多个对象，
·具有app标签键，无论其值如何(existence运算符)，
·具有以北或南作为其值的zone标签键(in运算符)，
·不具有以web作为其值的svc标签键(notin运算符)。
等式和基于集合的要求可以在单个查询中混合，例如zone in(west,east),environment！＝dev。
注释用于存储预计不会用于标识对象的数据。清单4中是在对象元数据字段中定义的两个注释的示例。注解的值可以是可以被序列化为基于文本的表示的任何结构化或非结构化数据。
清单3：两个标签的示例。数据以JSON编码，并且在对象元数据字段中定义了两个标签。
清单4：来自Kubernetes文献的两个注释的示例。数据以JSON编码，并且两个注释已经在对象元数据字段中定义。
3.2.3 Helm
Helm将自己标榜为“Kubernetes的包管理器”。它们提供了共享包的Kubernetes应用的Helm图表(Chart)的平台，并且简化了集群环境中复杂应用的设置。图表由模板集合组成，这些模板描述了可以使用helm CLI管理的Kubernetes资源。这些模板是KubernetesYAML文件，它使用具有适合Helm用例的专用功能扩展的Go模板语言。helm CLI从文件或命令行输入中读取值，以使用数据填充模板，例如版本名称和部署策略的配置。以此方式，Helm被提供输入并且产生Kubernetes资源。
许多APM供应方和社区项目提供Helm图表来在Kubernetes集群中部署他们的应用。这些可以帮助Kubernetes用户将服务部署到他们的集群中，因为他们不需要自己编写大部分配置，而是可以依赖于所提供的图表。
此外，可以将图表组织到图表存储库中，helm CLI可以从这些存储库中安装图表。存储库是为图表所包含的文件提供服务的HTTP服务器。与其他包管理系统类似，Helm包管理器允许图表依赖于其他图表。这些依赖关系是使用存储库URL声明的，例如，带有https://or file://schemata的URL。
3.2.4运营方
Kubernetes API可以使用定制资源(CR)进行扩展——非标准种类的定制对象。可以通过API组后面的API访问CR，并查询以取回定制数据对象。定制数据将作为定制字段填充到Spec字段内。CR是使用定制资源定义(CRD)定义的，它充当CR可能采用的字段和值的模板。CRD还定义应当为哪个API组注册CR，使得在Kubernetes集群中运行的应用或控制器可以在该API组端点处向CR查询数据。为了让Kubernetes API知道CR，CRD被注册到API，其中CRD是在请求中发送的YAML文件。
由于集群中运行的应用可以使用控制器来查询信息，因此在没有任何控制器的情况下，单独CR也很有用。然而，与定制控制器耦合的CRD可以扩展Kubernetes集群的域。定制控制器是从Kubernetes API监听CR的事件的过程。定制控制器还可以监听Kubernetes集群中可能与其用例相关的任何其他对象的更新。
CR可以用于利用单个CRD和观察CR的定制控制器来定义整个应用，而不是利用诸如PodsK、Configmaps和Deployments的基本Kubernetes资源来管理整个应用。控制器创建前面提到的这些低等级基元，这些基元必须存在才能创建应用，并且通过将工作卸载给控制器来抽象创建应用通常所需的大部分工作。这种将CRD与定制控制器耦合的设计模式被称为运营方(Operator)模式。
3.2.5准入网络挂钩(Webhook)
准入网络挂钩用于拦截Kubernetes API请求，并且可能在对象被其他集群组件读取之前更改对象或验证对象。准入网络挂钩分为两种类型，更改准入网络挂钩可以改变请求对象的内容，而验证准入网络挂钩可以接受或拒绝请求对象的内容。
使用情况的一个示例是对对象实施安全策略，例如要求容器中的非特权用户。此示例可应用于这两种类型的准入网络挂钩。验证准入网络挂钩可以简单地拒绝具有任何不允许的安全做法的任何请求对象，而更改准入网络挂钩可以修改该对象，使得其遵循所要求的安全策略。
准入网络挂钩的消费者称为准入控制器。在初始化时，准入控制器向Kubernetes注册URL路径，准入控制器将在该路径上监听HTTP POST请求。POST请求将包含准入控制器将验证或更改的请求对象(即，Kubernetes资源对象)。
没有要求准入控制器仅执行验证或更改中的一个的限制，因此它也可以在尝试更改对象的同时拒绝该对象。从逻辑上讲，某些对象可能不需要更改，并且准入控制器可以简单地完全忽略请求对象并且使其保持不变。
一个重要区别是，与在对象创建或更新之后触发的其他控制器不同，它们是在Kubernetes中创建或更新对象之前触发的，这一点突出了准入网络挂钩的一个强大功能。
3.2.6联网
PodsK是紧密耦合的容器的小群组，它们一起运行应用的单个实例，这些实例形成Kubernetes集群中服务的部分。容器共享相同的网络命名空间。在Linux中，网络命名空间是网络接口和路由表条目的独立集合。因此，容器可以在网络命名空间内的相同共享网络接口上彼此通信(例如，回送)。具有多个通信容器的pod的一个用例是在未加密的HTTP业务之上添加TLS/HTTPS加密层的代理。然后，代理端口向集群暴露，而未加密的业务在网络命名空间内被隔离。
PodK中的容器还共享相同的卷和过程间通信(IPC)命名空间，使它们能够在没有任何网络层的情况下使用IPC进行通信。在一些示例中，PodK的网络堆栈使用Docker后端。
集群内的每个PodK被赋予每个地址族的唯一IP，即，IPv4和IPv6。因此，共享相同PodK并且希望与外部网络通信的容器必须配置为针对共享地址不使用相同的端口，因为这将导致端口冲突。
PodsK能够与相同的集群中的其他PodK通信，因为Kubernetes集群网络模型采用平面网络拓扑。PodsK由Kubernetes调度到节点上，其中PodsK连接到网桥，该网桥透明地将分组路由到托管在节点中的指定PodsK。节点也称为workers(工作方)，并且通常托管在VM或物理机上。
可以使用平面Kubernetes集群联网模型。只要满足Kubernetes联网模型的要求，即集群中的所有PodsK必须能够彼此通信，就可以通过其他方式实现联网。
除了PodK到PodK联网之外，Kubernetes还提供ServicesK，其将托管在统一端点后面的PodsK集合上的应用暴露。有四(4)种类型的ServicesK，
·ClusterIP-PodsK集群暴露在单个负载均衡IP后面，
·NodePort-集群中的每个节点将指定端口的业务代理到底层ServiceK，
·LoadBalancer-PodsK集合由外部负载均衡器暴露，
·ExternalName-PodsK集合暴露在外部DNS名称后面。
默认使用的是ClusterIP类型。在该设置中，ServiceK被赋予集群IP，即集群中的所有PodsK都可以访问的集群范围的IP。然后，到该集群IP的所有业务都将被路由到ServiceK暴露的任何PodsK集合。
NodePort类型将在集群中的每个节点上分配唯一的端口，ServiceK可以在该端口后面访问。例如，如果为ServiceK分配了端口30000，则集群中的每个节点都将任何业务代理到具有端口30000分配到ServiceK的节点IP。与ClusterIP类型一样，ServiceK被赋予集群IP，该集群IP在代理业务时用作目标。
LoadBalancer类型使用由云提供方提供的外部负载均衡器。业务被路由到底层的ClusterIP或NodePort。
ExternalName类型将ServiceK映射到external name(外部名称)(DNS)，创建CNAME记录，该记录将使用ServiceK集群本地DNS名称并指向外部DNS名称。例如，我们有一个位于集群外部的第三方数据库，可以通过查询db.example.org和名为db-service的ServiceK来访问。ServiceK已经配置为使用主机db.example.org作为其外部名称。然后集群内部的PodsK可以通过查询DNS记录db-service来访问数据库。
3.2.7临时容器
临时容器是暂时的容器，其可以并排添加到PodK中的其他容器中。它们对于部署具有比托管实际应用的容器更多的实用程序的故障排除容器很有用。通过将故障排除卸载到这些容器，可以将应用容器保持在更小的范围内，并且可能减少攻击表面。临时容器缺少Kubernetes提供的大部分执行保证，即它们不会在故障时重新启动，因此临时容器不适合托管应用。
目前没有办法删除终止的临时容器，导致它们将占用PodK，直到该PodK重新启动或删除。此外，不可能创建与目标PodK上托管的另一临时容器同名的新临时容器。对于PodK中的容器组，每个临时容器必须具有唯一的名称。
3.2.8 Sidecar
在Kubernetes部署中，Sidecar容器与主应用容器一起运行。这些容器主要用于遵循关注点分离的原则。与第3.2.7节中描述的临时容器不同，Sidecar容器使用与主应用容器相同的设施，从而保证它在Kubernetes集群中执行。它们是实际DeploymentK的部分，定义方式与应用容器相同。然而，向已经存在的DeploymentK添加sidecar将导致PodsK终止，并且启动新的实例。这突出了Sidecar如何用于运行应用特定的代码，而不需要任何重新启动PodsK的临时容器可以用于故障排除。
用例的示例是运行日志聚合客户端的Sidecar容器，该客户端将日志从主应用容器推送到集中式日志聚合服务。通过使用Sidecar，主应用不必为日志聚合实现任何特定代码，并且可以保持对任何日志聚合框架的不可知性。
4.1部署场景
第3.2.6节中介绍的Kubernetes提供的联网模型和ServiceK类型产生了如何测试联网的多个用例。Kubernetes联网模型使集群中的节点和PodsK能够透明地彼此通信。但是，可能会出现限制并且干扰连通的多个问题。
Kubernetes的混沌工程平台通过造成chaos(混沌)，即扰乱系统，来测试集群的弹性。这些平台可以洞察可能导致集群故障或中断的常见问题。以下是混沌工程平台混沌网格(Chaos Mesh)为测试Kubernetes集群弹性而故意造成的常见问题列表，
1.Pod杀死–杀死PodK，
2.Pod故障-N时间内无法使用PodK(例如，N＝10秒)，
3.容器杀死-杀死PodK中的容器，
4.网络混沌-导致网络损坏、延迟和重复，
5.网络分区-通过将网络拆分成独立的子网来中断PodK连通，
6.IO混沌-导致IO操作延迟或故障，
7.时间混沌-扭曲PodsK的时钟，
8.CPU烧毁-导致主机CPU负载，
9.存储器烧毁-对主机虚拟存储器施加压力，
10.内核混沌-导致特定于内核的操作故障，诸如分配存储器。
其中一些模拟与网络问题直接相关，例如‘网络混沌’和‘网络分区’。而其他问题，诸如‘Pod杀死’、‘时间混沌’和‘CPU混沌’，可能会导致PodsK无法正常运行，并且导致后续的网络问题。
可以通过在Kubernetes集群内外的感兴趣的连接之间定位代理来发现中断，如本公开的技术中所描述的。另一问题是：
11.应用故障-与Kubernetes集群中托管的应用相关的任何种类的故障，例如超时、无效响应等。
由于未知的错误、糟糕的新版本推出或应用中可能失败的其他原因，应用故障可能会零星发生。
以下描述提供了有助于发现问题的网络场景和代理位置。
4.1.1节点到节点连通
图4是示出节点到节点连通场景的框图。在图4的示例中，多个代理位于它们自己的PodsK内的不同节点上。多个代理正在运行全网状分组速率验证监控器。在图4中，通过在Kubernetes集群中的三(3)个节点上部署代理来验证节点之间的连通。代理应用容器部署在其自己的Pod内部，并且该应用不与任何其他容器共享其联网和IPC命名空间。在这些代理上运行全网状UDP或TCP监控任务。该任务将持续测试节点之间的连接是否以N Mbit/s的速率递送包。
这项任务将能够发现前面列出的多个常见问题。例如,
·问题4发生并且导致连接降级，如果其中一个代理测量的速率低于N Mbit/s，则会发现问题，并且将问题报告给代理控制器(AC)，
·问题5发生并且导致网络拆分，问题将表现为代理中的一个或多个代理在AC中报告为脱机，
·问题1、2或3中的任何问题发生在一个或多个代理的PodK或容器上，问题将表现为受影响的代理在AC中报告为脱机。
其他问题也可能在AC中触发警报。然而，此任务不应发现与代理无关的PodsK和容器的问题1、2或3。此外，验证节点之间的连通，而不是PodsK之间的连通。这可能会潜在地导致PodK和节点之间的连通问题未被发现。
4.1.2节点到服务验证
图5是示出节点到服务验证场景的框图。在图5的示例中，单个代理连续地验证ServiceK后面的web应用的响应。更具体地，单个代理持续验证由ServiceK进行负载平衡的web应用的HTTP响应。在图5的示例中，ServiceK位于代理和托管其响应被验证的网络应用的PodsK之间。实际上，ServiceK是kube-proxy拦截并且路由到任何ServiceK PodsK的IP地址(即，集群IP)。为简洁起见，在附图中对此进行了抽象。
通过验证响应是否包含正确的HTTP状态代码和正文来完成对响应的持续验证。
同样，这项任务将能够发现一些常见问题，诸如，
·问题4发生并且导致HTTP响应超时，
·问题11发生并且导致web应用以500状态代码响应，
·问题11发生并且导致HTTP响应正文包含意外内容。
4.1.3 Pod到Pod连通
图6是示出pod到pod连通场景的框图。多个代理正在运行全网状TCP/UDP分组速率验证测试。在该场景中，多个代理位于作为Sidecar与其他应用容器一起运行的不同Pod中。
在图6中，每个代理都被部署为Sidecar，导致代理将与同一PodK中的其他应用共享相同的网络和IPC命名空间。
第4.1.1节中的场景仅验证节点之间的连通，而不验证节点内部托管的PodsK之间的连通。这种情况可以让我们深入了解PodsK之间的连通是否如预期的那样工作。测试的时间限制为N秒，并且将在该时间过后停止执行。
如果PodsK多于节点，则预计此测试的带宽成本将高于第4.1.1节中描述的方案，因为它将导致每个PodK一个代理，而不是每个节点一个代理。
因此，用户可能不想将这种测试作为监控器运行，而是选择使用时间受限的测试变量来对问题进行故障排除。该测试将在短时间内验证PodsK之间的分组速率，并且在得出结论后不会占用那么多的带宽。
通过运行此测试，可以发现未发现的问题，例如，
·问题4发生并且导致分组速率下降，
·问题5发生并且导致某些代理连接失败。
由于Kubernetes是动态系统，并且PodsK可能会被终止，例如，应用上的负载较少，因此Kubernetes Horizonal Pod Autoscaler(HPA)正在缩减PodsK的数目。这种测试可能会失败，因为代理会被应用PodsK拖垮。在第4.3节中，该问题也被描述为其自身的要求。
4.1.4入口验证
图7是示出入口验证场景的框图。在该场景中，通过使用两(2)个远程代理从集群外部验证ServiceK的验证。这些代理各自部署在一个地区。在图7中，代理对暴露的ServiceK运行HTTP监控器或测试。代理托管在Kubernetes之外，因此也应当验证外部访问的功能。
与第4.1.2节中的场景一样，监控器或测试应能够发现问题，例如，
·问题4发生并且导致HTTP响应超时，
·问题11发生并且导致web应用响应“内部服务器错误”(500)状态代码，
·问题11发生并且导致HTTP响应正文包含意外内容。
然而，由于代理位于Kubernetes集群之外，错误可能是由于其他组件出现故障。例如，由于位于Kubernetes集群和ServiceK前面的负载均衡器出现故障，代理可能会得到“不良网关”(502)状态代码。
由于代理中的一个代理与Kubernetes集群之间的广域网(WAN)错误配置而导致的错误也可能导致受影响的代理报告ServiceK不可访问的问题。
报告的粒度应由用户决定。在上述情况下，可以编写监控器或测试来查找代理和ServiceK之间发生的任何访问问题，包括WAN中的问题。另一方面，用户可能想要更细粒度，并且只在Kubernetes集群中发现问题，那么可能会对4.1.2节中描述的配置感兴趣。
4.1.5 pod故障排除
图8是示出pod故障排除场景的框图。在该场景中，通过使用两个代理进行故障排除来评估两个PodsK之间的不良连接。在图8中，两个PodsK之间的通信由于未知原因而受损。这个问题反复出现，但只发生在有限数目的PodsK上。通过在受影响的PodsK中部署临时代理作为Sidecar，可以使用主动保证套件提供的工具来评估问题，例如分组追踪和透明度测试。
以下是一些可能发生的问题，其中使用代理进行故障排除可能是有益的，
·问题4发生，并且分组被破坏，
·问题5发生，并且PodsK无法彼此联系。
事实上，即使对于工作的连接代理，也可以在两个PodsK之间部署代理以执行诸如验证网络策略和网络属性的测试，例如最大传输单元(MTU)发现。
4.1.6初始部署验证
图9是示出初始部署验证场景的框图。根据主动保证平台提供的主动测试能力，此场景验证新部署。在图9中，通过运行从Kubernetes集群外部访问ServiceK的测试来验证新部署的功能。该代理位于相同的Kubernetes集群中。这提供了从局域网(LAN)验证部署的可能性，该LAN可以访问入口，即使它不能从任何WAN(例如，互联网)访问。
与第4.1.2节中的场景一样，测试应当能够发现问题，例如，
·问题4发生并且导致HTTP响应超时，
·问题11发生并且导致web应用响应“内部服务器错误”(500)状态代码，
·问题11发生并且导致HTTP响应正文包含意外内容。
可以使用外部协调器来创建该测试，该协调器在使外部ServiceK可访问之前使用该测试来验证功能。然后，协调器可以获取来自测试的结果，从而做出将业务传递给ServiceK的最终决定。
4.2声明性配置
代理的配置应当在可以存储在版本控制系统(VCS)中的配置中定义。代理应当在Kubernetes集群部署过程中动态配置。使用抽象API，允许VNF动态指定其联网意图。Kubernetes中PodsK的短生命周期也对基于文本的声明性配置提出了要求。配置必须足够强大，以允许在位于集群内和集群间的代理之间运行测试。该配置应允许编写适用于多个代理或服务的通用测试，但也应允许对较少数量的代理或服务进行特定测试。
4.3临时环境
由于Kubernetes中的资源，诸如PodsK，可能具有较短的生命周期，本公开规定，代理必须支持被删除并且重新定位到集群内的其他位置，并且一旦代理再次启动，监控和测试就会恢复。本公开提供了一种持续执行并且适配被测Kubernetes资源的监控器，适应于Kubernetes资源可以被添加、删除或改变。
4.4 Helm图表
Helm是Kubernetes很受欢迎的包管理器。即使主动保证平台的客户选择不使用Helm，通过提供Helm图表，平台供应方也会提供存储库，供它们的客户在设计自己的定制部署时用作参考。主动保证平台供应方应提供用于在集群中简单设置主动保证的Helm图表。Helm图表必须允许用户在集群中创建可以部署在指定节点上的代理。此外，Helm图表应当遵循在Kubernetes中部署的最佳实践，帮助用户正确和安全地部署代理。Helm图表应支持作为DaemonSetsK启动的代理。为了获取更好的灵活性，Helm图表应当允许用户传递节点选择器、亲和度和容差，以控制在哪些节点上部署代理。凭证应易于作为值提供，这些值将传递给Helm图表并且用于填充模板。凭证应当以SecretK Kubernetes种类存储。配置数据应当以ConfigMap Kubernetes种类存储。
4.5临时代理
代理可以部署在Kubernetes中已经存在的PodsK中，其允许通过运行业务生成测试进行故障排除。例如，用例是在故障排除时从与作为目标的PodK中的容器相同的网络命名空间运行与网络相关的测试。这些临时的，或一次性的代理应当易于部署，并且不需要重新启动目标PodsK容器，因为向pod添加容器会产生副作用。
4.6主动测试
如前所述，activation testing(主动测试)是为了验证已经提供的服务的功能而进行的测试。主动保证平台已经提供了用于管理代理和创建测试和监控器的AC API。使用API主动测试可以在提供服务时自动完成。
在Kubernetes中提供服务的同时，还应支持使用主动保证平台运行主动测试，以验证服务的功能。必须存在界面，其允许用户容易地自动化主动测试。还应提供主动测试的结果，并且将其用于自动化。
4.7主动测试和监控
主动保证平台支持两种不同类型的业务生成安排。测试在有限的时间内进行，而监控则持续执行。解决方案应当与这些已经存在的类型保持一致，以与主动保证生态系统集成。
已经标识了两个重要的业务生成安排，
1.“一次性测试”-只运行一次并且不会再次执行的测试。
2.“连续监控器”-持续运行直到删除或停止的监控器。
标识了第三(3)个测试变型，即‘持续测试’。本文运行的测试类似于‘一次性测试’变型，但如果被测系统发生了变化，则会重新执行。
本节描述原型工具箱，该工具箱集成了主动保证平台和Kubernetes生态系统。原型由三(3)个不同的工具组成：
第一(1)，最广泛的原型是运营方，它与Kubernetes生态系统和代理控制器(AC)集成，以管理Kubernetes集群环境中的测试、监控器和代理的生命周期。运营方原型提案在第5.1节中进行描述。
第二(2)，为代理提供通用部署策略的Helm图表存储库的原型。Helm图表存储库原型在第5.2节中进行描述。
第三(3)，kubectl插件的原型，该插件为启动临时代理容器提供支持，以便于故障排除。kubectl插件原型在第5.3节进行描述。
5.1运营方
运营方原型提供运行测试和监控器的功能，这些测试和监控器动态匹配Kubernetes服务和代理。该原型仅限于与这些资源进行匹配，以设置良好的分界，从而展示动态匹配Kubernetes集群内的对象的可能性。
对象的匹配将使用定义测试或监控器输入的CR中提供的Kubernetes标签来完成。作为第二分界，没有定义整个测试和监控器，相反，只提供AC模板的输入，其中CR将引用AC中必须已经存在的模板标识符。
CR使用域特定语言(DSL)语言，从现在起称为资源匹配DSL(RMD)，它实现了与Kubernetes服务和代理对象匹配的能力，然后在用从匹配对象推断的值填充AC模板输入时使用它们。
最后，操作者将使用准入网络挂钩在Sidecar容器内部部署代理。通过在PodK定义中添加特殊的Kubernetes注释来定义将在其上部署Sidecar代理的目标PodsK。
动态对象匹配、声明性模板输入定义和动态代理Sidecar部署的这些能力应当一起满足分别在第4.2节和第4.6节中概述的声明性配置和主动测试的要求。
5.2代理图表
将创建存储库，其提供用于在Kubernetes中运行主动保证的Helm图表。该存储库将提供Helm图表，用于将代理部署为DaemonSetK。将不会实现更多的部署策略来限制原型实现的范围。DaemonSetK将允许用户在选定的Kubernetes节点集合上部署代理，并且使用CR中的RMD与这些代理进行匹配。
通过允许用户将这些设置传递到Helm图表，将支持节点选择器、亲和度和容差。Helm图表将使用ConfigMaps对象来存储Kubernetes中的配置值。运行代理所需的凭证将存储在Kubernetes SecretK对象中。
这应当为Helm图表存储库提供了一个良好的起点，可以简化Kubernetes集群中代理的部署。
5.3插件故障排除
为了帮助创建用于故障排除目的而运行的代理，如第4.5节所述，提议使用kubectl插件。这提供了与kubectl插件集成的CLI。作为起点，它应当提供部署在临时容器中运行的代理的能力。
通过使用临时容器，所部署的代理不会具有在部署目标PodK时重新启动目标PodK的副作用，从而满足第4.5节的要求。所部署的代理将允许用户从AC UI手动运行测试或监控器。
使用Kubernetes API删除临时容器是可能的。然而，通过实现这个原型，我们探索了部署无需重新启动即可排除PodsK故障的代理的可行性。
每节介绍三(3)个不同的概念验证(proof-of-concept)原型中的一个原型：
第一(1)，运营方在6.1节中描述。
第二(2)，Helm图表存储库在第6.2节中描述。
第三(3)，用于临时代理的kubectl插件在第6.3节中描述。
6.1运营方
该设计遵循第3.2.2节中描述的运营方模式，其中架构由三个重要组件组成，
·代理控制器(AC)-控制代理执行的任务并且收集报告。可通过API获取，
·代理-执行诸如主动测试、主动监控和主动测试的任务。结果将报告给AC。部署在Kubernetes中的容器中或远程在Kubernetes外部，
·运营方-充当AC与Kubernetes集群中资源之间的粘合剂。它将匹配资源，管理测试和监控器的生命周期，并且部署Sidecar代理。
运营方是使用来自Red Hat的运营方SDK以Go语言编写的实现的中心组件。按照运营方模式，运营方监听Kubernetes集群更改并且触发资源的调和循环。在运营方调和时，它将从Kubernetes API和AC API获取相关资源，以创建要进行哪些动作的上下文。
使用此上下文，它将启动、停止或更新已定义为CR的测试和监控器，并且针对Kubernetes集群中CR匹配的资源运行这些测试和监控器。有关CR实现的更多细节在第6.1.1节中描述。如何匹配资源在第6.1.2节中描述。
运营方仅与Kubernetes和AC API通信。运营方只需通过Kubernetes API监控代理和其他Kubernetes资源，并且对生命周期更改采取行动。Kubernetes API之间的通信使用Kubernetes库client-go通过HTTP完成。而对于AC，使用主动保证平台提供的REST API进行通信。Go标准库用于实现运营方中的控制器使用的简单REST客户端。有关控制器的更多细节请参阅第6.1.3节。
此外，运营方还可以从主动保证平台部署和删除托管代理应用的Sidecar容器。代理将使用正确的凭证和主机设置来设置这些，使得代理可以与AC通信。有关运营方如何进行Sidecar部署的更多细节在第6.1.4节中描述。
Kubernetes集群中代理的其他类型的部署可以使用其他已经存在的技术进行，例如标准Kubernetes DeploymentsK或Helm图表。
图10是示出根据本公开中描述的技术，包括与Kubernetes平台集成的监控运营方350的另一示例计算系统的框图。在图10的示例中，监控运营方350从Kubernetes API服务器接收元数据，该元数据指示关于所请求的网络切片的信息。监控运营方350经由REST API与代理控制器(本文也称为“控制中心”)通信。代理控制器实例化节点上的服务和测试代理和/或与之通信，以验证和监控网络切片的网络性能。例如，节点上的服务可以包括基于容器的RAN仿真服务。
图11是根据本公开中描述的技术的示例模板驱动的声明性主动测试和监控系统的概念图。在图11中，示出了从用户角度看的简化流程图。
用户使用定制资源创建或更新监控器，并且运营方匹配Kubernetes集群资源，并且在AC中创建、更新或停止监控器。
下面的运营方SDK将运营方部署为DeploymentK，其在分离的Kubernetes命名空间(例如，主动保证运营方系统)中具有单个副本。在运营方SDK术语中，托管控制器的运营方称为管理器，并且实际上是单个Go二进制操作。
运营方期望代理部署在运营方支持的两种变型中的一个变型中。
图12是示出被部署为PodK的代理及其与其他组件的交互的框图。变型一(1)，在图12中示出了仅具有托管代理应用的单个容器的PodK。在该实施例中，代理应用不与任何其他过程共享IPC或网络命名空间。这会导致代理部署与Kubernetes集群中托管的其他服务更加隔离。有关Kubernetes PodsK的IPC和网络命名空间的更多细节在第3.2.6节中描述。
图13是示出部署为sidecar容器的代理及其与其他组件的交互的框图。变型二(2)个容器，在图13中示出了具有两个容器的PodK，一个容器托管服务，另一容器托管代理应用。这里，代理与服务容器共享相同的IPC和网络命名空间，如第3.2.6节中所述。重要的是，这将产生与容器化服务共享相同联网甚至IP的代理。
清单5：监控器CR的概要
6.1.1定制资源定义
通过使用已存储在AC中的模板来生成测试和监控器。这些模板由读取引用模板的CR并且定义所要求输入的运营方填充。然后，运营方将在AC中创建测试或监控器。清单5中显示了示例CR的概要。
CR被定义为安装到集群的CRD。运营方监听集群中应用和更新的CR。有两种定制Kubernetes种类，
通过使用已存储在AC中的模板来生成测试和监控器。这些模板由读取引用模板的CR并且定义所要求输入的运营方填充。然后，运营方将在AC中创建测试或监控器。清单5中显示了示例CR的概要。
CR被定义为安装到集群的CRD。运营方监听集群中应用和更新的CR。有两种定制Kubernetes种类，
·监控器-用于定义AC中的监控器，
·测试-用于定义AC中的测试。
清单5中的apiVersion键必须使用运营方使用的API的当前版本填充。API是版本化的，并且v1alpha1字符串遵循Kubernetes设置的约定，一旦稳定版本发布，字符串应当更改为v1。可以发布其他后续版本，例如v2和v3，并且将使用运营方SDK运营方生命周期管理器利用新实例来升级运营方。旧的CR将继续使用旧的API，直到它们迁移到为新版本定义的新格式。
清单6：可以为RMD CR提供的键。
所有CR所要求的另一重要键是名称元数据字段。它用于在集群的同一命名空间内为监控器和测试提供唯一的名称。对于该命名空间，这些名称必须始终是唯一的，并且相同种类的任何其他CR都不能共享相同的名称。
由运营方在AC中创建的测试和监控器被赋予名称，该名称是来自元数据字段的名称和命名空间的串联，并且在中间添加连字符(-)。
例如，清单5中的监控器将被命名为client-server-monitor-default，因为CR具有名称client-servermonitor并且存在于默认命名空间中。
规范键中提供的资源匹配DSL(RMD)在下面的第6.1.2节中介绍。
6.1.2资源匹配DSL
模板输入、服务和代理由资源匹配DSL(RMD)定义。所有RMD都包含在CR的规范键中。清单6所示的RMD中可以定义四(4)个键。
第一键templateId是强制的。该键通过引用已由AC赋予模板的ID来定义应当使用什么模板。其他三(3)个键是可选的，因为可以创建不需要任何输入的AC模板。键、代理、服务和输入将在下面的小节中描述。
代理选择器
使用代理键定义代理。代理键的值是named selectors(命名选择器)的列表。
每个命名选择器必须包含为集合提供用于输入的可引用名称的名称，以及基于匹配规则选择代理的选择器。
清单7中的完整示例显示了高级版本，它使用多个命名选择器选择多个代理。
选择器中的规则遵循与Kubernetes中的常规标签选择器相同的规则。所有规则进行与操作，即所有规则都必须适用于要选择的代理。
在清单7中的示例中，边缘代理命名选择器将匹配带有label tier:edge的代理。而核心代理命名选择器将匹配满足matchLabels和matchExpressions规则两者的代理。
·matchLabels键用于匹配Kubernetes标签。相同matchLabels键下的所有标签必须匹配才能选择代理。
·matchTags键用于选择仅AC知道的代理，这些代理可能是位于Kubernetes集群外部的远程代理。AC提供的标记设施用于通过AC API取回有关这些代理的信息。
·matchExpressions键是Kubernetes matchExpressions的克隆。
matchLabels和matchExpressions功能两者都使用Kubernetes core/v1 API中提供的库函数。这也应当使Kubernetes的用户更熟悉RMD语法。
服务选择器
ServicesK用服务键定义。服务键的值是Kubernetes named selectors(命名选择器)的列表。
同样，与代理选择器一样，每个命名选择器必须包含名称，该名称为选择器提供用于输入的可引用名称，以及选择器，该选择器基于匹配规则来选择Kubernetes集群内部的ServicesK。
服务选择器可以采用matchLabels和matchExpressions规则来匹配ServicesK。规则的工作方式与代理相同，唯一的区别是将选择Kubernetes中具有种类ServiceK的对象。服务选择器不存在matchTags规则，因为它特定于代理。
模板输入
模板的所有输入都包含在输入键中。清单8中的示例显示了填充AC模板的定义的一般概要。
清单8中的示例中的每个输入块，即服务器和速率下降，都引用AC中为监控器或测试模板定义的模板输入。
输入块包含类型以及值或类型特定的键，诸如代理或服务。类型键设置应当使用的输入类型。此类型引用AC API规范中定义的相同类型。
值键只是原始对象或基本类型，例如整数或YAML编码结构。结构被转换为可以被AC API摄取的JSON编码的结构。这将允许将原始值插入到任何类型中，例如，接口类型可以具有手动定义值，如清单9所示，而不是使用代理键。
可以对照AC API可以提供的OpenAPI规范来验证这些原始值。
此概念验证中实现了三(3)种类型，每种类型都支持传递特殊的帮助器，该帮助器将用于推断应当用作输入的值。
三(3)种类型(表示为T)及其相应的帮助器(表示为H)是，
1.interfaceT—agentH,
2.interface_listT—agentsH,
3.urlT—serviceH
关于每种类型的更多细节在接下来的三节中描述。
清单7：使用RMD选择代理和ServicesK的一些方式的完整示例。
清单8：RMD CR中的输入的简单示例。
清单9：使用原始值而不是使用代理帮助器来定义接口的输入。
清单10：使用代理的帮助器定义接口的输入。
server:
type:interfaceagent:agent1
清单11：由代理接口填充的可能的AC API模式的示例。
1.接口类型
接口类型将代理帮助器或原始值作为输入。该类型用于使用单个代理填充模板输入。
代理帮助器由已使用代理选择器(即命名选择器)定义的代理集合填充。从这个集合中，随机选择代理并且将其用作输入。为了确保始终只使用单个特定代理，用户必须赋予该代理唯一的标签。
使用AC API查询选定的代理，以取回清单11中所示的AgentInterface所要求的代理ID、接口名称和IP版本。
例如，使用清单10中的示例和清单7中定义的命名代理选择器。将使用与标签匹配的代理填充名为agent1的集合。然后使用代理帮助器在服务器模板输入中引用该集合。运营方将在该集合中选择随机代理，然后向AC API查询填充清单11中的模式所需的值。
然后，类型接口的模板输入将使用与AgentInterface匹配的数据填充。
最后，运营方将整个填充的模板发送到AC API，AC将在其中创建测试或监控器。
清单12：使用代理帮助器定义interface_list的输入。
clients:
type:interface_list
agents:[agent2,core-agents,edge-agents]
interface_list类型
interface_list类型将代理帮助器或原始值作为输入。该类型用于使用代理列表填充模板输入。
这与前面描述的代理帮助器的工作方式基本相同。不同之处在于，代理帮助器将收集代理帮助器获取的列表中提供的所有代理集合。
这些集合中的所有代理都将被使用，并且被添加到清单11所示的AgentInterface列表中。与接口类型一样，结果将被发送到AC API，使得AC将创建测试或监控器。
清单12使用代理帮助器来选择三个不同的命名代理选择器，即agent2、core-agents和edge-agents。从选择器产生的集合将被展平为唯一代理的集合，这些代理用于使用每个代理的接口列表(即AgentInterface)填充interface_list类型。
3.url类型
url类型接受服务帮助器或原始值作为输入。该类型用于填充字符串类型的模板输入。它将从所选择的ServiceK推断URL，并且用表示为字符串值的URL来填充类型url的模板输入。与接口类型一样，从集合中选择随机服务，因为该类型仅采用单个URL。
服务帮助器使用的所选ServicesK集合在第6.1.2节中描述的服务选择器中定义。
服务选择器提供的ServicesK的引用集合带有清单13所示的名称键。除了该键之外，还有更多键用于指定应当如何推断URL，以及允许覆盖URL的特定部分的键。
清单13：使用服务帮助器定义url的输入。
这些键最好以列表的形式呈现，下面是服务帮助器的所有支持键以及简短的描述，
·名称-引用从服务选择器创建的集合，即与ServicesK匹配的命名选择器，
·ServicePort-指定在推断URL时应使用哪个ServiceK端口，
·ServiceType-指定在推断URL时应使用什么ServiceK类型，
·方案-用提供的内容覆盖任何推断的URL方案，
·端口-用提供的内容覆盖任何推断的URL端口，
·主机-用提供的内容覆盖任何推断的URL主机。
清单13中显示了类型url的模板输入。这里，当推断URL时，将使用清单7中与清单14中的服务匹配的nginx-production命名选择器。将选择名为http的ServiceK端口，并且其ClusterIP将用作URL中的主机。
由于ServiceK不提供关于所使用的应用协议的任何信息，因此服务帮助器将推断具有方案tcp://的URL。为了缓解这种情况，清单13中的示例使用值http覆盖该方案，该值将产生方案http://.
如果清单14中nginx-service ServiceK的ClusterIP是10.43.0.12，那么该示例中得到的URL将是http://10.43.0.12:80.
清单14：由清单7中的示例所选择的示例服务。
此URL将由服务帮助器添加到模板输入的值，其类型url为字符串。最后，与本文中解释的其他类型一样，填充的模板将被发送到AC API，AC将在其中创建测试或监控器。
完整示例
为了更好地理解如何创建监控器和测试，描述了示例。
第一示例是将从ID等于1的模板创建监控器的监控器。为了提供一些上下文，使用的模板是在多个客户端与服务器之间创建连续流的TCP监控器。该示例使用可用的选择器类型创建多个RMD集合。然后使用这些集合来填充模板输入。
第二示例是测试，它将从ID等于2的模板创建测试。为了给出一些上下文，使用的模板是HTTP测试，它查询来自多个客户端的URL，并根据HTTP状态代码和正文内容验证响应。该示例显示url类型，并且选择所选代理将查询的nginx ServiceK。
6.1.3控制器
由运营方管理的每个CR由分离的控制器处理。这些都由同一个管理器(即可执行文件)运行。控制器将监听来自Kubernetes API的请求，并且触发它自己的CR种类，或者监控它可能需要的种类的其他资源的事件。
该设计使用三种不同的控制器来订阅有关特定种类的资源更新。其中两个控制器，从现在起称为CR控制器，监听有关监控和测试CR种类的事件。
第三控制器，本文称为污染控制器，监听可能需要前两个CR控制器再次调和的核心Kubernetes种类的事件。
为了概括每个控制器的功能，
·监控器控制器-管理MonitorK CR，
·测试控制器-管理TestK CR，
·污染控制器-在代理PodK、通用PodK和ServiceK更新时触发CR控制器。
监控器控制器
监控器控制器将对有关种类MonitorK的CR的事件进行调和。可能发生并且触发调和的事件的示例是，
·创建新的MonitorK，
·更新现有的MonitorK，
·删除MonitorK。
这些事件用于管理Kubernetes中的MonitorK CR的生命周期。监控器控制器不会监听需要在AC中重新配置监控器的集群更改。这是因为污染控制器将通过将CR的状态设置为过时来污染MonitorK CR，这将触发针对MonitorK CR的后续监控器控制器调和。
以下是监控器控制器将根据Kubernetes集群和AC的状态而采取的步骤。监控器控制器将从观察段开始(参见第3.2.2节)。这里，控制器从Kubernetes API接收触发调和循环的请求，即事件。然后，分析段开始，并且监控器控制器将确定是否调度CR用于删除。调度的删除将导致监控器控制器通过停止关联的AC监控器并且返回来采取行动。在监控器控制器完成其清理逻辑之后，实际的CR将被Kubernetes垃圾收集。
在未调度删除CR的另一情况下，监控器控制器将比较当前RMD配置和上次应用的配置。未更改的配置将导致监控器控制器仅返回。而在另一情况下，CR的更改配置将继续执行，并且检查AC监控器是否停止。如果监控器已停止，则监控器控制器将在AC中重新创建监控器，因为它没有调度用于删除，这是我们前面检查过的–从而导致AC中的监控器与CRSpec中存储的RMD配置是最新的。
然而，如果监控器仍在根据AC运行，则监控器控制器将通过停止监控器来动作并且将CR的状态从运行更改为停止。这将触发CR的后续调和。在该后续调和中，监控器控制器将遵循与前面概述的相同逻辑，即，它将在AC中创建新监控器。
图14是示出监控器控制器在调和期间可采取的决策的活动图的框图。停止监控器将更改Kubernetes CR对象的状态，并且触发调和。图14示出了监控器控制器逻辑的活动图，显示了监控器控制器可以采取的不同逻辑路线。
测试控制器
请参阅关于监控器控制器的上一节，因为它描述了一些为简洁起见而此处省略的细节。
与监控器控制器类似，测试控制器将触发与种类TestK的CR有关的事件的调和。
将触发调和的事件是，
·创建新的TestK，
·更新现有的TestK，
·重新调度TestK调和，
·删除TestK。
虽然MonitorK被连续运行直到显式删除，但TestK以‘一次性’的方式运行，即，在它结束并且其生存时间(TTL)已经过去之后，它们被从Kubernetes集群删除。本文意义上的结束是测试失败、通过、出错或导致测试结束其执行的任何其他可能状态。
当TestK结束时，测试控制器将使用TTL来决定何时从Kubernetes中删除TestK。时间从测试结束时开始计算。
图15是示出测试控制器在调和期间可采取的决策的活动图的框图。活动图显示了测试控制器调和循环可采取的不同路径。
当接收到TestK请求时，测试控制器将启动调和观察段，每次更改(创建或更新)TestK CR时都会发生这种情况。然后，测试控制器经由Kubernetes API获取TestK对象，然后启动调和循环的分析段。在分析段中，它将确定TestK对象是否已经被创建(即，其状态被设置为它已由先前的调和创建)。如果尚未创建TestK对象，则测试控制器将动作并且经由ACAPI创建测试。
在另一情况下，如果先前的调和已经创建了TestK，则测试控制器将经由AC API获取测试实例来继续观察段。这里，AC中测试的状态为已调和，其中如果测试尚未结束，则后续调和将排队等待在N分钟内完成(例如，在一(N＝1)分钟内完成)。这将导致稍后执行本段所描述的相同调和。
然而，如果AC中的测试已经结束，那么一旦指定的TTL通过，测试控制器将从Kubernetes集群中删除TestK CR-从TestK结束后的时间开始计时。
污染控制器
污染控制器是较简单的控制器中的一个控制器。污染控制器负责强制调和其他CR，在该示例中仅为MonitorK CR。到目前为止，还没有明确的理由强制TestK的调和，但是为了可扩展性和简化监控器控制器的逻辑，污染控制器从监控器控制器中分离出来。
污染控制器监控两种Kubernetes种类，PodK和ServiceK。当CR使用标签与Kubernetes集群中的资源匹配时，两者都被关注其标签的更改，这些更改可能触发CR控制器。
一旦污染控制器发现可能需要调和CR的更改，它将通过将当前CR状态字段设置为布尔值假来污染CR。然后更新CR，并且Kubernetes API将触发CR的调和。
最后，一旦进行了调和，则CR控制器将把当前状态字段的布尔值重新设置为真。
图16是示出污染控制器在调和期间可采取的决策的活动图的框图。图16中的活动图示出了污染控制在调和期间可能采取的不同决策。
6.1.4准入网络挂钩
准入网络挂钩背后的整体理论在第3.2.5节的理论一章中进行解释。
Sidecar更改准入网络挂钩
Sidecar更改准入网络挂钩(从现在起简称为Sidecar网络挂)启动和停止带有基于PodK注释的代理的Sidecar容器。选择准入网络挂钩，而不是简单地监听Kubernetes创建或更新事件，就像前面提到的其他控制器一样，在它们被持久化到Kubernetes数据存储后端之前触发准入网络挂钩。
通过之前触发，Sidecar网络挂钩可以在其他Kubernetes组件注意到更改并且开始对请求对象的内容进行动作之前更改请求对象。在这种情况下，如果将Sidecar添加到PodK对象而没有准入网络挂钩，则PodK将首先部署在没有Sidecar容器的节点上。然后由控制器更新，这将导致PodK被终止，并且启动具有Sidecar容器的新PodK实例。这种快速PodK重启周期的行为会导致不必要的集群搅动，因为PodK对象进入的每个状态都会导致Kubernetes API创建侦听PodK事件的任何集群组件都必须调和的事件。由于调和循环的性质，即使是创建Sidecar的控制器也会触发其调和循环，如第3.2.2节所解释的。
Sidecar Webhook Controller(Sidecar网络挂钩控制器)(从现在起简称为Sidecar控制器)注册自己，以改变与要在Kubernetes中创建或更新的任何PodK对象有关的准入网络挂钩请求(即，Sidecar网络挂钩)。然后，Sidecar控制器将启动HTTPS web服务器，该服务器在它向Kubernetes注册Sidecar网络挂钩时还指定的URL路径上侦听网络挂钩请求。
在该实现中，Sidecar网络挂钩位于path/mutate-core-v1-pod，并且Sidecar控制器仅使用POST方法侦听HTTPS请求。
如本节开头所提到的，Sidecar网络挂钩将基于其注释来决定是否添加、删除或不更改PodK对象。仅有单个注释键是Sidecar控制器所关心的，即“inject.example.com/sidecar”。正如本节开头所提到的，Sidecar网络挂钩将基于其注释来决定是否添加、删除或不更改PodK对象。仅有一个注释键是Sidecar控制器关心的，即“inject.example.com/sidecar”，并且它的DeploymentK将创建。
图17是示出Sidecar控制器基于注释作出决策的活动图的框图。请注意，在该实现中，只有当存储的值是字符串“true”或字母的任何大写或小写版本的顺序从而形成单词true时，才可以认为注释存在。DeploymentK的开发人员可以显式地注意到，它的PodsK不应当具有Sidecar容器，方法是添加注释“sidecar.example.com/inject”:“false”(或不是单词true的任何其他值)。实际上，Sidecar控制器将简单地忽略该注释，并且将该注释视为不存在。
清单15：DeploymentK示例，它将启动两个PodsK，各自具有一个nginx容器和一个代理Sidecar容器。
如果Sidecar控制器已经决定添加Sidecar容器，它只需将使用代理镜像和所要求的凭证设置的容器对象附加到PodK的容器列表中。从逻辑上讲，如果Sidecar控制器已经决定删除容器，它将从PodK的容器列表中删除它。一旦PodK对象发生更改，则将对其进行编码和打补丁(即发送)，这将导致其他准入网络挂钩或Kubernetes组件进行进一步处理。
6.2代理图表
代理图表存储库包含单个Helm图表，用于在Kubernetes集群中运行代理。图表使用DaemonSetK，因为它满足第4.4节中概述的要求，即代理的部署必须能够以指定的Kubernetes集群节点为目标。
图表接受与如何将代理调度到节点上相关的值，并且将它们传递给DaemonSetK，
·节点选择器–基于标签键和值来选择节点，
·容差-污染的节点提供容差，
·亲和性-使用富表达性规则语法将Pod吸引到节点。
这些都是标准的Kubernetes基元，并且应当会为用户在节点上部署代理提供最大的灵活性。
为了用设置和凭证配置代理，图表还接受与AC的认证相关的值，
·站点-AC实例IP或域名，
·电子邮件-AC用户的电子邮件，
·凭证-AC凭证，
-帐户-AC帐户，
-密码-AC密码。
前两(2)个值存储在ConfigMapK中，该ConfigMapK附接到所得到的DaemonSetKPodsK。其他三(3)个值存储在附接到所得到的DaemonSetK PodsK的SecretK中，因为这些都是机密并且必须受到保护。
6.3插件故障排除
插件故障排除被实现为与kubectl CLI命令的集成，并且可以通过kubectl调用它，如清单16所示。
该插件是用Go语言编写的。为了实现CLI功能，使用spf13/cobra来解析CLI参数和标志。可在以下网址获取：github.com/spf13/cobra。
Kubernetes.io/cli-runtime/pkg/genericclioptions提供了用于与KubernetesAPI连接的其他配置选项。可在以下网址获取：github.com/kubernetes/cli-runtime。genericclioptions库将自动读取kubectl配置，使得用户不必手动为Kubernetes API提供任何连接配置。此外，该库提供了一些标准标志，例如用于定义标准kubectl CLI中可用的Kubernetes命名空间的标志。
为了与Kubernetes REST API通信，使用了Kubernetes.io/client-go库。可在以下网址获取：github.com/kubernetes/client-go。
该插件通过路径中存在的名为kubectl-troubleshoot的二进制文件与kubectl集成。当系统要求运行kubectl故障排除时，kubectl CLI将查找并且调用kubectl-troubleshoot二进制文件。该命令的任何其他参数都将按原样传递给插件。
可用的命令是，
·临时-管理作为临时容器部署的代理，
·帮助-有关故障排除CLI的帮助。
临时命令允许用户部署运行代理镜像的临时容器。针对临时命令的可用子命令如清单17所示。
清单16：当调用kubectl故障排除-help时的输出。
清单17：当调用kubectl故障排除临时–帮助时的输出
清单18：当调用kubectl故障排除临时部署—帮助时的输出。
在kubectl故障排除临时命令下有两个子命令，
·部署POD-在POD处部署临时代理，
·删除POD-从POD中删除临时代理。如第3.2.7节所述，临时容器尚不支持被删除。在Kubernetes API添加支持之前，此命令始终会导致错误。
目标PodK在Kubernetes中按其名称引用。当用户请求在指定的PodK中部署临时代理时，该插件将取回指定命名空间的PodsK(默认为默认命名空间)。然后通过PodK名称取回具有其临时容器的目标PodK。
该插件将确保在部署新的PodK临时代理之前没有已经在运行的PodK临时代理。如果是这种情况，插件将返回并且告诉用户目标PodK已经部署了临时代理。
另一方面，如果没有部署临时代理，插件将附加名为activeassurance-agent的临时代理，并且使用必须由用户提供的AC凭证对其进行配置。部署临时代理所需的凭证如清单18所示。
当用户请求删除临时代理时，插件将开始执行与部署临时代理时相同的步骤。它将取回指定命名空间的PodsK，找到目标PodK，最后取回目标PodK的临时容器。
然后，插件将在其已取回的临时容器列表中查找临时代理。临时代理总是被赋予相同的名称，active-assurance-agent，所以插件将简单地使用该名称来搜索临时容器。
如果存在匹配，则插件将从临时容器列表中删除临时代理，并且使用KubernetesAPI更新PodK。
另一方面，如果不存在匹配，则插件将不会对PodK进行任何更改，从而导致no-op。
然而，如第3.2.7节所述，Kubernetes API尚不支持删除临时容器。因此，使用Kubernetes API更新PodK的删除阶段的最后部分总是失败。
本节通过测试4.1节中描述的部署场景来验证概念验证原型。每个场景都是通过创建满足所描述拓扑的部署来设置的。然后使用概念验证原型来管理Kubernetes集群环境中的主动保证平台。
然后验证所讨论的原型的功能。每个验证程序都使用作者认为足以确认其功能的方法。特别地，混沌网格主要用于确认原型设置正确，并且AC报告预期结果。为每个场景选择特定的混沌网格模拟(称为实验)，使得所讨论的组件将发现故障。
最后，在每个场景的末尾提供了总结，其描述已验证的内容、原型如何满足其要求以及是否已实现预期结果。
为了洞察如何使用概念验证原型，利用所附清单详细描述了场景所采用的每个程序。可以选择许多方式来设置和使用原型，并且下面的场景和安装不应当被认为是详尽的。
7.1节点到节点连通
第4.1.1节中描述的部署场景是通过使用第6.2节中描述的代理图表部署三(3)个代理来创建的。
代理与Helm一起部署在具有三(3)个工作方节点的Kubernetes集群上，这导致Kubernetes集群中填充了清单19所示的代理。因为图表使用DaemonSetK，所以每个代理都部署在各自一个Kubernetes工作方节点上的自己的PodK内部。
清单20中的MonitorK CR和AC中创建的模板给出了部署场景的监控器。这里，模板输入‘客户端’、‘速率(Mbit/s)’和‘ES速率(Mbit/s)’分别由输入客户端、es_速率和速率填充。代理命名选择器将匹配标签为"app":"geared-marsupi-agent"的代理。
清单19：用于验证Helm命令是否确实在Kubernetes集群中的每个节点上创建了代理的命令。
清单20：用于在Kubernetes集群中的每个可用代理之间创建TCP全网状监控器的MonitorK CR。
MonitorK CR成功应用于Kubernetes集群，如清单21所示。
运营方已经读取CR并且在AC中创建TCP全网状任务。因为有三(3)个节点正在建立全网状双向流，所以总共有六(6)个流。
Kubernetes集群中具有清单20所示匹配标签的每个代理都用于在AC中配置任务。通过查看AC中任务的编辑页面，可以进一步验证这一点。实际上，与清单19所示的输出相同，有三(3)个代理的名称与预期相同。其他输入‘速率(Mbit/s)’和‘ES速率(Mbit/s)’也正确地填充了清单20中CR中定义的值。
清单22中描述的混沌网格实验应用于Kubernetes集群中的PodsK。此实验引入了50％的丢失率，这与先前发送的分组有50％的相关性。每15秒重复运行实验10秒。
清单21：
清单22：用于引入代理PodsK之间的网络损耗率的混沌网格实验。
正如预期的那样，所引入的网络混沌导致AC报告代理在维护TCP全网状网络流中遇到问题。
然后，删除PodsK中的一个PodsK，以验证代理是否正确地发现新的PodK被DaemonSetK替换。清单23中的命令删除了名为geared-marsupi-82kqc的PodK。这将产生名为geared-marsupi-jpnm5的新PodK，并且删除旧监控器并且创建包含新代理的新监控器。这一点显示在AC中，其中旧的监控器被停止，而新的监控器正在运行。
最后，通过发出清单24中的命令成功停止了监控器任务。随后，通过查看AC UI进行的验证显示，监控器任务已停止。这在AC UI中显示为‘停止’符号。
这验证了概念验证代理图表原型是否能够按照第4.4节中的要求所描述的在每个节点上部署集群中的代理。
概念验证运营方原型使用正确的代理和参数成功启动了监控器任务。此外，原型能够对集群更改采取行动，其中它停止旧的监控器并且使用新的代理来创建新的监控器。最后，原型能够从集群中删除监控器任务CR并且在AC中停止监控器。
通过启动混沌网格实验，代理确实存在连接问题，这在AC UI中已成功报告。
清单23：用于从Kubernetes集群中删除geared-marsupi-82kqc PodK并且验证是否已经创建新监控器的命令。
清单24：用于从Kubernetes集群中删除MonitorK CR并且停止AC中的监控器的命令。
$kubectl delete-f scenario-1-monitor.yaml
monitor.example.com"scenario-1"deleted
$kubectl get monitors
No resourcesfound in default namespace.
7.2节点到服务验证
通过使用第6.2节中描述的代理图表部署单个(1)代理，创建了所描述的部署场景。图表是使用Helm和清单25中的命令部署的，并且将nodeSelector作为文件包含到图表中。该文件的内容可以在清单26中找到。包含的选择器指示图表以具有特定标签node.example.com/select:"true"的单个节点为目标。
该web应用是nginx web服务器，它将默认的nginx欢迎消息托管在HTML响应中。使用的DeploymentK和ServiceK可以在下面的示例中找到。DeploymentK具有添加的亲和性(affinity)设置，使得只将带有nginx应用的PodsK调度到没有node.example.com/select:"true"标签的节点上。此外，亲和性设置还确保每个节点处只有单个nginx PodK。
通过发出清单27中所示的命令，可以验证Kubernetes集群设置是正确的。
清单25：运行Helm命令以创建位于Kubernetes集群中的单个工作方节点处的代理。
$helm install geared-marsupi-f values.yaml\
./agent-charts/daemonset-agents
清单26：values.yaml文件的内容，该文件用于指示DaemonSetK在具有特定标签的节点处创建代理。
nodeSelector:
node.example.com/select:"true"
清单27：用于验证Kubernetes集群设置是否正确的命令。
用于部署场景的监控器由清单28中的MonitorK CR和在AC中创建的模板提供。该模板创建HTTP任务，该任务将持续验证HTTP URL目标的响应。
模板输入将用其在MonitorK CR中的对应输入填充，
·‘客户端’--clients，
·‘URL’-url，
·‘(多个)请求之间的时间’
-time_between_requests，
·‘HTTP响应代码’-response_code，
·‘响应内容’-response_regexp。
CR还有两(2)个选择器，一个用于代理，一个用于ServicesK。代理选择器‘ta’将与标签为"app":"geared-marsupi-agent"的代理匹配。而服务选择器‘nginx’将与标签为"app":"nginx"的ServicesK匹配。
如清单29所示，MonitorK CR已经成功应用于Kubernetes。在该命令的输出中，包括AC监控器ID。这可以在以后用于在AC UI中查找相同的监控器。
清单28：用于在代理与Kubernetes集群中的ServiceK之间创建HTTP监控器的MonitorK CR。
清单29：这些命令用于应用MonitorK CR，然后验证运营方是否确实创建了监控器。
如图7.8所示，通过查看可以在其中找到监控器的AC UI进一步验证了监控器已被创建。这里，Kubernetes集群中的单个代理与使用清单28中的代理的标签进行了正确匹配。
查看监控器的AC UI中的编辑页面，可以验证运营方已正确地使用ServiceK填充了URL，并且代理已填充了‘客户端’输入。‘(多个)请求之间的时间’、‘HTTP响应代码’和‘响应内容’输入也正确地填充了清单28中CR中定义的值。
清单30中描述的混沌网格实验应用于Kubernetes集群中的nginx PodsK。此实验引入了所有分组的90％的网络分组损坏，每15秒持续时间为10秒。分组损坏在50％的时间内与先前损坏的分组相关。
如所预期的，在AC UI中报告了所引入的网络混沌。网络损坏导致ServiceK定期返回错误的HTTP状态和与正则表达式不匹配的错误正文内容。
这将验证概念验证运营方原型是否能够与集群中的ServiceK匹配，并且对其运行HTTP监控器任务。此外，清单28中的CR展示了向AC中的模板提供整数值和字符串值的可能性。
代理图表能够用于创建与nginx PodsK不在同一节点上的单个代理。然而，这需要在nginx DeploymentK中进行显式的亲和性设置。通过应用混沌网格实验，为nginx PodsK引入分组损坏，代理确实发现了问题并且将其报告给AC。
清单30：用于在ServiceK与PodsK之间引入网络分组损坏的混沌网格实验。
7.3 Pod到Pod连通
4.1.3中描述的部署场景是通过在Kubernetes集群中部署DHT来创建的。DHT由四(4)个DHT节点(在PodsK内部)组成，这些节点被调度到可用的Kubernetes工作方节点上。通过添加代理Sidecar注释"sidecar.example.com/inject":"true"，将代理部署在DHT节点PodsK内部。
本文描述了用于部署该DHT的所有资源以供参考。
通过发出清单31中的命令，可以创建并且验证是否正确设置了DHT。事实上，有四(4)个PodsK托管DHT节点应用，并且PodsK已经调度到所有可用的Kubernetes工作方节点上。重要的是，输出中的READY栏显示每个PodK中有两(2)个正在运行的容器。这表明，不仅DHT节点容器已经启动，而且托管代理应用的第二容器也已启动。
通过发出如清单32所示的命令来检查每个PodK，可以进一步验证每个PodK还托管作为Sidecar容器运行的代理应用。
在AC UI中可以找到Sidecar代理。
清单31：用于部署DHT并且验证其是否已正确设置的命令。为简洁起见，删除了第二命令中的一些栏。
清单32：检查其中一个PodsK的输出。这个‘…’指示为简洁起见已删除的输出。
在验证Sidecar代理正在运行后，应用UDP测试。该测试验证分组速率和丢失率等。该测试是使用清单33中附接的TestK CR定义的。使用标签"run":"node"和"run":"bootstrap"对位于每个DHT节点PodK的Sidecar代理进行匹配。模板是在应用TestK CR之前在AC UI中创建的。然后在TestK CR中引用AC给出的模板ID。最后，TestK CR中的输入es_loss和loss分别给出了模板所需的输入值‘丢失率(％)’和‘速率(Mbit/s)’。
清单33：用于在DHT PodsK之间创建UDP测试的TestK CR
通过发出清单34中的命令，TestK CR被成功应用，并且被验证为已在Kubernetes集群中创建。该测试已经在AC中获取ID，并且已经开始运行。然而，由于AC API中的错误，开始时间未知。结束时间标记为未知，因为测试尚未完成。
查看AC UI可以找到运行测试。这里有四(4)个代理在彼此之间运行全网状UDP测试。这是预期的，因为有四(4)个DHT节点。
查看测试的AC UI中的编辑页面，可以验证运营方是否按照清单33中的TestK CR中的定义正确地填充了‘丢失率(％)’和‘速率(Mbit/s)’模板输入。
清单34：用于应用和验证是否已在Kubernetes集群中创建TestK的命令。为简洁起见，一些输出已被删节。
清单35：从命令行监控测试时给出的输出。
测试运行了60秒，并且可以使用命令行进行监控，如清单35所示。此命令的最后一行显示测试已完成，并且已得出‘通过’的结论，即测试结果成功。
事实上，从AC UI可以进一步验证结果是否通过。这里，测试的结束时间(在‘完成’栏中)与清单35中的命令行输出相同。
现在，创建了混沌网格实验，它引入了50％的丢失率，与之前丢失的分组有50％的相关性。实验以15秒为间隔，重复运行10秒。假设测试被配置为在丢失率超过10％时失败，这应当足以创建测试结果失败。该实验被配置为向带有"run":"node"标签的PodsK引入丢失率。可以在清单36中找到混沌网格实验配置。
清单36：配置用来使测试失败的混沌网格实验。
清单37：用于删除、重新应用和监控测试的命令。
在再次运行测试之前，旧的TestK资源已被删除。这是由于两(2)个原因。第一(1)，在Kubernetes集群中，命名空间只能有一个同名的资源。第二(2)，TestK在特定时间内只运行一次，并且必须重新应用才能再次运行。在删除旧的TestK之后，使用命令行应用和监控TestK。这些步骤可以在清单37中找到。
如所预期的，如清单37所示，测试失败。失败的实际原因可以在AC UI中看到，其中报告的某些代理之间的丢失率超过10％。可以在图7.16中找到这一点的屏幕截图。
清单38：用于重新应用不带Sidecar注释的资源的命令，并且验证Sidecar是否已被删除。
最后，为了删除代理Sidecar容器，从所描述的Kubernetes资源文件中删除了"sidecar.example.com/inject":"true"注释。这些资源被重新应用到Kubernetes集群，后来被验证已经删除了Sidecar。清单38显示，在删除注释之后，旧的PodsK被终止。新实例在没有Sidecar的情况下启动(1/1就绪容器而不是2/2)。
这验证了概念验证运营方原型是否能够将代理Sidecar容器部署在已使用"siddecar.example.com/inject":"true"注释的Pod中。运营方还成功地与这些代理Sidecar容器进行匹配，并且使用它们在AC中填充测试。然而，AC API中存在错误，导致无法从命令行获取开始时间。混沌网格实验表明，在代理Sidecar容器位于的Pod之间可以发现网络损耗。
最后，在从Kubernetes资源中删除Sidecar注释之后，成功地删除了代理Sidecar。如所预期的，删除注释导致PodsK被终止，并且被新的实例取代。
7.4入口验证
部署场景按照第4.1.4节所描述的进行部署。已经在北加州和爱尔兰的一个地区各自部署了两(2)个代理实例。Kubernetes集群位于斯德哥尔摩，并且安装了nginxIngressK控制器。这些代理通过AC UI被分配了名为‘远程’的标签。
如第4.1.4节所描述的，Kubernetes集群部署托管HTTP ServiceK，其通过两(2)个PodsK对请求进行负载平衡。web应用是简单的nginx web服务器，它使用默认的nginx欢迎页面进行响应。最后，指向ServiceK的IngressK资源可以从外部访问ServiceK。本文描述了Kubernetes集群部署的所有资源以供参考。AC服务器与Kubernetes集群位于相同实例上。
通过发出清单39中的命令，创建了web应用，并且验证其设置正确。事实上，有两(2)个PodsK托管nginx web应用。托管Kubernetes集群的实例前面的防火墙被配置为允许来自代理和作者计算机的传入连接。已验证可从作者计算机远程访问web应用，并且已验证代理与AC连接。
然后，将清单39中找到的MonitorK CR应用于Kubernetes集群。此CR将使用ID为四(4)的URL模板。CR已被配置为使用标签名为‘远程’的代理填充模板输入。模板输入‘URL’、‘URL响应代码’和‘响应内容’分别由输入url、response_code和response_regexp填充。
清单39：用于部署web应用并且验证其是否已正确设置的命令。为简洁起见，删除了第一命令中的一些栏。
清单40：创建的MonitorK CR。URL已经被截断以适合此文献的宽度。
运行清单41中的命令来应用CR并且验证它是否已经被创建。事实上，在AC中已经创建了监控器。运营方还可以验证两(2)个可用的远程代理是否匹配。可通过查看运行监控器的编辑页面进行进一步验证。这里，所有模板输入都填入了正确的值和代理客户端。
最后，为了模拟WAN错误配置，删除了允许爱尔兰代理访问web应用的防火墙规则。如所预期的，错误配置导致AC UI报告爱尔兰代理无法再访问web服务。
重要的是，此场景验证了运营方是否可以匹配不在Kubernetes集群中的远程代理。清单40中的CR显示了对URL模板输入使用原始值的可能性。这里为url输入提供了字符串，而不是如清单28所示的url类型。最后，所引入的WAN错误配置显示，部署场景确实有助于标识Kubernetes集群外部的网络问题。
清单41：运行这些命令来应用MonitorK CR并且随后验证它是否已创建。
7.5 Pod故障排除
4.1.5中描述的部署场景是通过在Kubernetes集群中部署DHT来创建的。DHT由两(2)个DHT节点(在PodsK内部)组成，它们被调度到可用的Kubernetes工作方节点上。Pod各自与一个ServiceK互连。本文描述了用于部署该DHT的所有资源。
通过发出清单43中的命令，可以创建并且验证是否正确设置了DHT。这里，有两(2)个PodsK，每个PodsK都分配了一个ServiceK。
然后，使用6.3中描述的概念验证故障排除插件原型在每个PodK上部署临时代理。代理是使用清单44中的命令部署的。每个命令都指向特定的PodK，即dht-node-1和dht-node-2，并且获取所要求的凭证，使得代理可以使用AC进行认证。
然后对PodsK进行检查，以验证插件是否部署了临时代理容器。实际上，如清单45中的一个PodsK所示，代理被正确地部署为临时容器。通过查看AC UI进一步验证了该设置。这里，这两(2)个代理被找到，并且被赋予了与插件托管他们的PodsK相同的名称。
在第4.5节的要求中，要求不得将目标PodsK作为添加临时代理的副作用重新启动。通过运行清单42中的命令，验证了PodsK在添加临时代理后没有重新启动。事实上，RESTARTS栏显示PodsK自部署以来从未重新启动过。
清单42：运行该命令以验证在添加临时代理后PodsK是否没有重新启动。
清单43：运行这些命令来应用DHT部署，并且随后验证它是否正确创建。
清单44：运行的命令在每个PodK上部署临时代理。
$export AC_API_TOKEN＝<redacted>
$kubectl troubleshoot ephemeral deploy dht-node-1\
-H 10.10.10.1-a dev
$kubectl troubleshoot ephemeral deploy dht-node-2\
-H 10.10.10.1-a dev
清单45：用来检查dht-node-1PodK的命令。这个‘…’指示为简洁起见已删除的输出。
在代理之间创建了简单的全网状UDP测试，该测试运行60秒。该测试是通过AC UI定义的。
然后，将清单46中的混沌网格CR应用于Kubernetes集群。该CR引入了50％的丢失率，该丢失率与先前丢失分组的50％相关。这种丢失率每15秒重复10秒。最后，重新运行了7.24中以前运行的测试，产生了7.23中的报告。这里，可以看到引入的反复发生的网络损耗。
此场景验证了是否有可能部署不会导致重新启动PodsK的副作用的临时代理。这些代理在AC UI中照常可用，用户可以在它们之间创建故障排除任务。最后，所引入的网络损耗显示导致了发现集群中Pod之间的网络相关错误的可能性。
然而，AC UI中的可用任务有限。例如，没有用于查找MTU和运行分组捕获的测试。如第3.2.7和6.3节所述，不可能删除临时容器，因此代理将无限期地留在Pod中或直到Pod重新启动。
清单46：用于引入网络损耗的混沌网格CR。
7.6初始部署验证
4.1.6中描述的部署场景是通过在Kubernetes集群中部署HTTP web应用并且部署单个(1)个代理来创建的。web应用由两个PodsK组成，其由DeploymentK管理。web应用是简单的nginx web服务器，它使用默认的nginx欢迎页面进行响应。可以使用ServiceK和IngressK从集群外部访问DeploymentK。描述了用于部署web应用的所有资源。
使用6.2中描述的代理图表部署代理。图表是使用Helm和清单47中的命令部署的。将nodeSelector作为文件包含在图表中。该文件的内容可以在清单48中找到。所包含的选择器指示图表以具有特定标签node.example.com/select:"true"的单个(1)节点为目标。
清单47：运行Helm命令以创建位于Kubernetes集群中的单个工作方节点上的代理。
$helm install geared-marsupi-f values.yaml\
./agent-charts/daemonset-agent
清单48：values.yaml文件的内容，该文件用于指示DaemonSetK在具有特定标签的节点上创建代理。
nodeSelector:
"node.example.com/select":"true"
通过发出清单49中的命令，创建了web应用，并且验证其设置正确。这里有两(2)个托管nginx的PodsK，它们由ServiceK进行负载均衡。可通过IngressK从Kubernetes集群外部访问ServiceK。nginx应用被验证可从Kubernetes集群外部访问并且提供预期的欢迎页面。
然后，将清单50中的TestK CR应用于Kubernetes集群。此CR将使用ID为一(1)的URL模板。模板配置可以在图7.25中找到。已将CR配置为使用标签为geared-marsupi-agent的代理填充模板。模板输入‘URL’、‘URL响应代码’和‘响应内容’分别由输入url、response_code和response_regexp填充。此外，CR配置有ttlSecondsAfterFinished:600，这将在测试结束后六百(600)秒(十(10)分钟)后通知运营方删除CR。
清单49：运行这些命令来应用nginx部署并且随后验证它是否被正确创建。
清单50：运行这些命令来应用nginx部署并且随后验证它是否被正确创建。
运行清单51中的命令来应用CR并且验证它是否已创建。最后一个命令监控Kubernetes中TestK CR的状态。为了进一步验证测试是否正在运行，测试实际上显示为在AC UI中运行。测试最终报告为“通过”，即它已成功执行，没有发现任何问题。通过查看ACUI验证了该状态。事实上，AC也报告了测试通过。
最后，返回到清单51，运行睡眠命令来等待TTL设置的十(10)分钟。然后，再次获取TestK CR，并且运营方已经按照配置的TTL的预期删除了CR。
清单51：运行这些命令来应用nginx部署并且随后验证它是否被正确创建。十(10)分钟后，CR已从Kubernetes集群中删除。
现在，应用了清单53中CR定义的混沌网格实验。此实验引入了90％的分组损坏率，与之前损坏的分组的相关性为50％。损坏每十五(15)秒发生十(10)秒。
在清单52中，重新应用了清单50中的TestK CR。然后，使用命令行监控测试结果。测试结束后，它被报告为错误。这是预期的，因为所引入的分组损坏应当会导致测试失败。事实上，通过查看AC UI所做的进一步验证显示了可归因于分组损坏的重现超时和验证失败的报告。
该场景验证了是否可以进行主动测试，并且通过Kubernetes接口查询结果。一旦Kubernetes中的TestK CR发生状态更改事件，则会通知观看CR的客户。重要的是，这允许以编程方式使用带有协调器的主动测试。例如，使用Kubernetes API的NFV-MANO可以启动主动测试并且收到结果通知。然后，协调器可以使用这些主动结果来相应地行动。此外，该场景还验证了TTL功能是否正常工作。在结束并且通过TTL后将CR删除。
清单52：运行这些命令以重新应用TestK CR并且从命令行监控结果。
清单53：混沌网格实验CR引入了九十(90)％的分组损坏，与之前损坏的分组的相关性为五十(50)％。
在本节中，讨论了设计和实现的一些方面。
8.1删除AgentSet
在某些实现中，可以有名为AgentSet的CR。该CR为Kubernetes集群中的供应代理提供了丰富的选择器。清单54中提供了示例。该设计的灵感来自DaemonSetK，它将成为管理集群中所有代理的中央资源。所需的凭证也将在同一个CR中声明，然而，使用标准的Kubernetes资源可能会更好，比如SecretsK。
后续版本中删除了AgentSet，将重点放在测试和监控器的部署上。相反，代理将使用标准的Kubernetes基元进行部署，诸如DaemonSetK和DeploymentK。
通过以Helm图表形式提供代理，仍然可以提供容易的部署体验。大多数选择器功能仍然是可能的，因为Kubernetes提供了诸如matchExpressions的匹配器。重要的是，Helm图表确保凭证正确存储在SecretsK和ConfigMapsK中。
由于代理图表存储库的当前版本仅包含基于DaemonSetK的图表，因此可能的部署有限。例如，要在特定节点上部署代理，必须使用nodeSelector或亲和性设置。这需要将标签添加到Kubernetes工作方节点。此外，DaemonSetK不支持podAffinity设置，导致更难将代理调度到具有或不具有特定PodK的节点上。此问题的示例显示了DeploymentK如何通过与代理DaemonSetK相关的亲和性设置来处理。除了与运行代理相关的资源外，不应当要求更改其他资源的亲和性设置。
清单54：来自早期版本的AgentSet CR。
使用清单54中描述的AgentSet CR，代理将被部署到也托管特定PodsK的节点上，而不需要对所述PodsK进行任何更改。这可能会导致系统更易于维护，因为依赖项不会跨越多个资源，并且不需要针对代理进行调整。
然而，在代理图表存储库中提供基于DeploymentK的Helm图表可能会解决此问题。这里，可以为代理PodsK提供podAffinit。提供在具有或不具有特定Pod的节点上部署代理的可能性。这种方法可能有自己的问题集合，需要在将其与AgentSet CR思想进行比较之前进行评估。
8.2用于匹配资源的注释
早期的设计要求为运营方可以匹配的每个资源提供注释operator.example.com/match:true。这是为了通过应用过滤器来减少运营方与Kubernetes API之间的闲聊。然而，这一要求被删除了，因为它将需要更改Kubernetes集群中已经存在的资源，从而将运行快速测试和监控器以排除运行资源故障的可能性限制为那些已经有注释的资源。
8.3使用注释配置帮助器
在当前设计中，不支持选择多个ServicesK或PodsK并且将它们用于接受列表(例如，URL列表)的模板输入。例如，用户想要监控集群中的多个HTTP ServicesK共享相同标签的用例是不可能的。这是所使用的主动保证平台中的特征限制，并且需要支持HTTP工具中的URL列表。
然而，如果要添加这一项，则可能需要支持与多个ServicesK和url帮助器进行匹配。此外，用户可能希望使用不同的端口或ServiceTypes与ServicesK进行匹配。
在较早的实现中，这是使用注释解决的，但后来被丢弃，因为它需要更改Kubernetes集群中的资源，如第8.2节中所讨论的。在这个版本中，有多个注释可以用于配置url帮助器将为服务使用哪些参数，
·url.template.example.com/host：
<hostname>-允许覆盖要使用的主机名。
·url.template.example.com/service-type：
<service-type>-允许覆盖ServiceType，例如使用ClusterIP而不是服务的名称。
·url.template.example.com/port:<port>
-允许覆盖端口。
·url.template.example.com/match：
<service-port-name>-允许为帮助器指定在生成URL时应当使用什么ServicePort。
如果主动保证平台添加对例如URL列表的支持，则可以重新评估该方法，并且可能再次将其添加到设计中。
8.4指纹测试和监控器
通过总是生成标识测试或监控器的当前化身的指纹，可以简化调和循环的逻辑。一旦已经生成了监控器或测试，就可以从所产生的模板输入和可能需要在AC中更新监控器或测试的其他相关数据中生成指纹。
未来的调和可以通过比较它们的指纹来将其测试或监控器的版本与旧版本进行比较。如果没有不同，那么调和将导致不执行操作(no-op)。而不同的指纹将导致在AC中更新测试或监控器。
这种方法将消除分析Kubernetes集群状态所需的许多条件语句。相反，控制器将观察状态，从中生成监控器或测试，并且将指纹与之前的监控器或测试进行比较。然而，这可能会导致对Kubernetes和AC API的更多请求，其中控制器将始终必须执行匹配逻辑才能生成指纹。
本公开描述了一种在Kubernetes中进行主动保证的新方法。运营方引入了一种与Kubernetes生态系统集成的容器化服务的主动保证方法。运营方解析资源匹配DSL(RMD)，其以声明性格式描述服务的主动测试或监控。这两者一起提供了在代理之间，并且针对已经与使用Kubernetes中的资源(即清单)的元数据进行匹配的服务运行主动保证的功能。该方法总结为，通过读取声明性主动测试或监控描述符，并且通过与来自Kubernetes API的相关服务相关联的元数据进行匹配。主动测试或监控可以由协调层操作，该协调层根据描述符和收集的元数据来确定主动测试或监控配置。
此方法为协调器提供了通过验证服务功能的Kubernetes API部署RMD中定义的主动测试的可能性。这里，运营方将触发代理之间或代理与服务之间的代理控制器(AC)中的主动测试。并且随后通过Kubernetes API或AC API为协调器提供结果。
可以使用标准Kubernetes基元(如DaemonSetK和DeploymentK)配置和部署代理。标准的Kubernetes分发已经提供了定义元数据的能力，即运营方用来与代理进行匹配的标签和注释。应提供以Helm图表形式包的代理，以简化部署并且确保最佳实践。
Kubernetes资源的故障排除通过引入在其他应用PodsK内运行的临时代理或一次性代理来完成。临时代理不会强制目标PodK重新启动，因此PodK的状况保持不变。这对于对PodK的特定状态进行故障排除是有益的。通过提供可以在集群中的PodsK上部署和配置代理的kubectl插件，简化了临时代理的使用。然而，由于受到限制，并且Kubernetes API中针对临时容器的功能不是最终版本，因此无法从PodK中删除代理。另一限制是运营方不能匹配临时代理，这意味着不可能为该代理类型编写声明性测试和监控器。
最后，运营方有能力部署Sidecar代理容器。它们会自动附接到具有特殊注释的PodsK。IPC和网络命名空间与PodK中其他容器过程共享。这对于作为应用过程的来自相同网络命名空间(即，接口)的网络相关测试是有益的。这些Sidecar代理容器与临时代理容器不同，因为它们需要重新启动PodK。另一方面，与临时代理容器不同，Sidecar代理容器可以与之匹配。
本文描述的三个原型一起形成了工具套件，其可以用于在遵循声明性范例的Kubernetes集群中运行主动保证。验证场景表明，该工具对于简单的Kubernetes集群和部署是足够的。其他环境，例如5G和其他由Kubernetes支持的电信基础设施。
10.2端到端测试
端到端(E2E)用于测试Kubernetes分发。其他供应方也可以使用他们提供的框架对测试集群运行E2E测试。原型应当有E2E测试来测试功能。本公开前面介绍的部署场景可以用作未来E2E测试的基础。也可以使用其他部署方案。
10.3扩展RMD
资源匹配DSL(RMD)可以扩展以支持其他Kubernetes基元。在当前版本中，ServiceK和代理是唯一支持的基元，可以使用命名选择器进行匹配。
PodK基元就是一个示例。PodK包含一个或多个可匹配的IP，并且用于运行测试或监控器。此外，在PodK中有使用特定端口的容器。容器端口可以与PodK IP匹配并且与其一起使用，以产生IP和端口对。其他Kubernetes基元应当在与RMD匹配时评估其值。
还存在平台特定的基元，例如TWAMP反射器。与代理一样，TWAMP反射器可以是Kubernetes集群中可以与之匹配的特殊资源。此外，还可以通过添加对AC中已给予标签的反射器匹配的支持来支持远程TWAMP反射器。
10.4连续测试
在当前化身中，运行TestK CR，一旦结束，运营方将从Kubernetes集群中删除CR对象。这个CR不仅可以扩展为“一次性”，而且还可以具有连续模式，如果集群发生可能会影响测试使用的资源的更改，该模式将重新运行TestK。
连续TestK和MonitorK之间的区别在于，测试针对N单位时间运行，并且仅在特定集群更改时再次运行，而监控器持续生成业务。然后可以使用例如kubectl从Kubernetes查询结果。
可以监控集群更改，并且使用污染控制器以与当前实现相同的方式触发重新运行。
下面在清单55中是运行‘一次性’TestK的示例，并且连续变量如清单56所示。
10.5更新监控器和测试
AC API尚不支持从模板更新现有的监控器和测试实例。这会导致当前实现停止并且将监控器或测试重新创建为具有新ID的新实例。因此，很难在AC UI中追踪报告，因为它们可能分布在多个实例中。
有可能创建监控器和测试而没有模板，但这一方法的实现将面临挑战。
10.6更多部署策略
在验证阶段，发现DaemonSetK策略不支持PodK亲和性。有用的特征是基于其他PodsK在集群中的位置来控制代理的部署位置。通过还提供实现DeploymentK策略的Helm图表，这是可能的。
10.7删除临时容器
临时容器不能从添加了临时容器的PodK中删除。这是Kubernetes API的当前限制。由此，临时代理将留在PodK中运行，直到PodK重新启动。当代理建立VPN隧道时，它将使用PodK的一些网络带宽，即使它没有被使用。使用的带宽应当不足以对PodK产生负面影响，但这仍然是可以调查的事情。然而，由于Kubernetes API将来可能会添加对删除临时容器的支持，因此一旦可以删除代理，这应当不是问题。
清单55：‘一次性’TestK的示例。
清单56：‘连续’TestK的示例。
5G网络切片是一网络架构，其可以在同一物理网络基础设施上实现虚拟化并且独立的逻辑网络的多路复用。每个网络切片是隔离的、端到端网络，专为满足特定应用所要求的不同要求而量身定做。因此，这项技术在支持5G移动网络方面发挥了核心作用，这些网络旨在高效地接受具有非常不同的服务等级要求(SLR)的过多服务。这种面向服务的网络视图的实现利用了软件定义网络(SDN)和网络功能虚拟化(NFV)的概念，这些概念允许在通用网络基础设施之上实施灵活并且可缩放的网络切片。当创建网络切片时，需要验证切片以使其符合SLR，并进一步监控切片提供的SLA。在没有本公开的技术的情况下，验证和监控网络切片的实现是麻烦的。
本文描述的声明性主动保证技术可以应用于网络切片的验证和监控。UE/eNB/gNB模拟器是针对5G核心网模拟UE、eNB和gNB的应用。该模拟器支持将UE附接/分离到网络以及启动/停止用户平面通信会话以及代理从测试代理到用户平面的数据连接的功能。每当创建网络切片时，都会创建测试代理和模拟器并且将其附接到切片，然后执行各种测试以测试切片的SLR满足。此外，相同的测试代理和模拟器可以持续监控SLA。
测试代理和UE/eNB/gNB模拟器Docker镜像作为可以使用声明性(例如，基于意图)规则创建的资源(Pod)添加到Kubernetes。然后，监控运营方350控制两者的创建，监控运营方350与代理控制器(控制中心)交互。控制中心控制测试的执行，并且经由其UI和北向API提供结果。以此方式，整个测试和监控基础设施可以集成为Kubernetes运营的5G网络的部分，从而实现对网络切片的测试和监控的灵活控制。
作为示例，切片测试/质量保证过程可以包括以下内容：(1)当创建切片时，由网络运营方利用UE、eNB和gNB配置来创建网络模拟器；(1.1)UE配置包括用于附接到gNB的UE的配置，该配置包括要使用的网络切片标识符和类型。例如，请参见https://github.com/aligungr/UERANSIM/blob/master/config/free5gc-ue.yaml。gNB配置可以包括gNB IP地址和AMF IP地址，请参见https://github.com/aligungr/UERANSIM/blob/master/config/free5gc-gnb.yaml；这些可以包括gNB服务的不同5G接口的相应IP地址；(2)模拟器被部署到具有配置的Kubernetes中；(3)在部署时，为每个UE和服务类型创建模拟器服务，以暴露用于质量保证的服务；(4)用监控运营方启动质量来保证所需的标签来标记服务；描述例如在质量保证中使用的切片服务类型和测试代理；(5)监控运营方通过启动相关测试进行服务等级验证来开始切片服务验证；(6)测试代理执行服务等级验证，例如使用UDP测试，其在测试代理之间发送恒定速率的UDP流，并且根据端点之间的接收速率、抖动和丢弃来确定服务等级；(7)验证结果被收集到控制中心并且提供给网络运营方。配置创建(步骤1)和部署到Kubernetes(步骤2、3、4)可以自动化/脚本化。
图18是示出根据本公开中描述的技术的用于节点到节点主动保证监控的示例配置和对应的用户界面显示的概念图。
图19是示出根据本公开中描述的技术的用于在不同节点上的测试代理之间创建主动保证监控的监控场景的示例配置和对应用户界面显示的概念图。例如，测试代理140A可以对应于本文描述的测试代理，诸如在图1至图10、图12或图13中。
图20是用于配置诸如UE的模拟无线电接入网络(RAN)元素的示例用户界面显示。例如，用户界面显示可以由图3的控制中心呈现。
图21是示出根据本公开中描述的技术的用于添加可由监控运营方用于网络切片测试的模拟UE和eNodeB的示例配置和对应的用户界面显示的概念图。测试代理140A如本文描述的那样被部署。
图22是示出根据本公开中描述的技术的一个方面，使监控运营方经由代理控制器(控制中心)利用所需的UE/eNodeB设置来配置测试代理以实现YAML输入的意图的示例YAML输入的概念图。监控运营方可以是例如图3的监控运营方250或图10的监控运营方350。
图23是示出根据本公开中描述的技术的一个方面的用于测试网络切片的示例系统的框图。当创建切片时，网络运营方创建具有UE和gNB配置的网络模拟器。UE配置包括用于附接到gNB的UE的配置，该配置包括要使用的网络切片标识符和类型。gNB配置包括gNBIP地址和AMF IP地址。模拟器通过配置部署到Kubernetes中。在部署时，为每个UE和服务类型创建模拟器服务，以暴露服务以提供质量保证。用监控运营方启动质量保证所需的标签来标记服务，其描述例如将在质量保证中使用的切片服务类型和测试代理。可以自动创建配置并且部署到Kubernetes。监控运营方通过启动服务等级验证的相关测试来启动Slice服务验证。测试代理执行服务等级验证，例如使用UDP测试，其在测试代理之间发送恒定速率的UDP流，并且服务等级根据端点之间的接收速率、抖动和丢弃来确定。验证结果被收集到控制中心，并且提供给网络运营方。
根据本发明，4G/5G网络切片的主动保证可以与Kubernetes，以及如何控制Kubernetes平台协同工作。根据本公开的技术可以在节点中或作为pod sidecar自动部署测试代理。此外，根据本公开的技术可以在移动网络中自动设置用户平面并且向测试代理呈现接口。此外，根据本公开的技术或系统可以自动启动YAML中定义的测试或监控器。例如，如果将新节点添加到集群中，则可以基于标签匹配自动部署测试代理。可以自动配置测试代理UE/eNodeB应用，并且可以设置用户平面。可以启动指定的测试/监控器。每个步骤或过程可以由YAML文件经由运营方控制，诸如美国专利申请第63/114,444号中进一步描述的那样，如上所述。
可能存在不同类别(类型)的网络切片。一些网络切片用于实时业务，因此它们可能需要低延时。其他网络切片可以用于浏览，并且可能不需要同样多的吞吐量。通过定义资源类型并且与实际网络相集成，可以允许通过Kubernetes资源进行控制，这提供了集中控制和相对容易的自动化。根据本公开，这些技术可以包括创建网络切片的参数，然后基于该参数创建测试。
图24是示出根据本公开中描述的技术的一个方面，用于使用位于同一虚拟执行元素1110中的测试代理和模拟器来测试网络切片的示例系统1100的框图。在图24中，可以预定义服务类型。例如，服务类型可以是来自移动设备的网络标准的eMBB(增强型移动宽带)。可以为实时流等定义不同的服务类型。监控运营方被配置为从服务类型推导出网络切片需要什么样的质量。纯测试代理可以测试核心网络。Kubernetes运营方可以通过匹配标签来控制或操作服务。可以在数据网络侧提供测试代理。在一些示例中，可以不模拟数据网络，而是可以测试真实网络或核心网络。模拟的服务可以是网络功能。模拟器服务可以是可以在不同配置中测试的不同服务类型。
网络切片可以通过与Kubernetes一起部署的模拟器来完成，这些模拟器具有特定的配置，其可以协调到业务切片测试中。例如，可以使用与Kubernetes一起部署的模拟器来完成服务切片测试。
网络运营方可以启动网络切片的创建。作为创建网络切片的部分，可以自动创建用于服务质量监控或测试的资源。这些资源可以被控制测试的Kubernetes运营方读取。Kubernetes运营方可以根据需要部署网络模拟器。
以下是UE配置示例。配置应提供UE的IMSI、IMEI、主键(在模拟SIM的情况下)、NSSAI等。
根据本发明的gNB配置提供了用于模拟接口的本地地址以及gNB连接到的AMF的地址，例如：
ngapIp:127.0.0.1#针对N2接口的gNB本地IP地址(通常与本地IP相同)
gtpIp:127.0.0.1#针对N3接口的gNB本地IP地址(通常与本地IP相同)
#AMF地址信息列表
amfConfigs:
address:127.0.0.1
可以完成对Kubernetes资源的配置。对于必要的配置，创建了测试代理、UE、gNB定制资源。例如，请参阅https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/_print/。
例如，定制资源定义的示例如下所示：
apiVersion:apiextensions.Kubernetes.io/v1
kind:CustomResourceDefinition
metadata:
name:ue.stable.example.com
spec:
group:stable.example.com
versions:
name:v1
served:true
storage:true
schema:
openAPIV3Schema:
type:object
properties:
spec:
type:object
properties:
imei:
type:string
...
scope:Namespaced
names:
plural:userequipments
singular:userequipment
kind:UserEquipment
shortNames:
ue
创建UE资源可以完成，例如，如下所示：
apiVersion:"stable.example.com/v1"
kind:UserEquipment
metadata:
name:my-ue-object
labels:
example.com/ue.group:test1
spec:
imei:356938035643803
imsi:901700000000001
资源可以绑定在一起。包括UE和gNB列表的示例测试代理如下所示。该测试代理使用选择器将用户设备绑定到它并且定义gNB。apiVersion:"stable.example.com/v1"
kind:UserEquipment
metadata:
name:my-ue-object
labels:
example.com/ue.group:test1
spec:
imei:356938035643803
imsi:901700000000001
绑定到服务监控的示例配置如下：
apiVersion:example.com/v1alpha1
kind:NetworkMonitor
metadata:
name:scenario-2
spec:
templateId:2
agents:
name:ta
selector:
matchLabels:
example.com/serviceType:eMBB
services:
name:nginx
selector:
matchLabels:
app:nginx
inputs:
clients:
type:interface_list
agents:ta
url:
type:url
service:
name:nginx
servicePort:http
serviceType:ClusterIP
scheme:http
time_between_requests:
type:integer
value:10
response_code:
type:integer
value:200
response_regexp:
type:string
value:"(nginx)"
此网络监控器使用选择器绑定到先前定义的测试代理，并使用另一选择器绑定到响应方服务nginx。类似地，可以将测试代理绑定为响应方，并且可以定义其他类型的测试。例如，UDP带宽测试可以在移动网络上的测试代理与数据网络上的测试代理之间进行。
图25是示出根据本公开中描述的技术的一个方面的用于使用位于与模拟器不同的虚拟执行元素中的测试代理来测试网络切片的示例系统的框图。
根据本公开的技术可以包括测试的第一阶段。第一阶段可以包括凭证，以确保其按预期工作。第一阶段可以包括1分钟1GB，具有1毫秒延时。第一阶段可以确保切片正在处理带宽。第一阶段可以使用使用更多带宽的监控参数，因为网络业务尚未流动，并且不会受到测试的影响。
根据本公开的技术可以包括测试的第二阶段。第二阶段凭证可以包括对已建立的网络切片的监控。第二阶段可以包括监控业务，并且包括以使用较少带宽的方式进行监控，例如通过较低频率地发送探测分组。与第一阶段相比，第二阶段可以是在网络切片上运行更长时间，但发送探测分组的频率较低的测试。
在一些示例中，使用相同的测试代理来测试和认证第一阶段和第二阶段。在其他示例中，相对于第一阶段，使用新的测试代理来测试和认证第二阶段。在测试的第一阶段和测试的第二阶段中，控制中心可以不同地配置测试代理。不同的测试配置可以发送不同的测试业务量，如上所述。模拟UE/gNB可以并行运行。
图26是示出根据本公开的一个或多个技术的计算系统的示例操作的流程图。在图26的示例中，诸如图1的计算系统的计算系统接收用于虚拟化服务的主动测试的声明性测试描述符(2600)。计算系统可以从协调层获取与虚拟化服务相关联的元数据，其中元数据指定由协调层管理的集群的命名空间内的虚拟化服务的唯一名称(2650)。协调层可以是例如诸如Kubernetes平台API的虚拟化平台API。计算系统使用声明性测试描述符和元数据来确定用于虚拟化服务的实例的主动测试配置(2655)。计算系统根据主动测试配置来启动主动测试，并且基于主动测试的结果来确定虚拟化服务的实例的服务等级违规(2660)。
主动测试配置包括例如测试代理IP地址、测试代理标签、服务端点、模板名称和参数中的一个或多个。启动主动测试包括将主动测试配置提供给协调主动测试以监控性能的控制中心，其中控制中心基于主动测试配置来将测试代理和监控服务实例化。控制中心包括客户控制器过程，该客户控制器过程监听由来自协调层的定制资源定义的事件，并且响应于通过监听标识事件而接收元数据。控制中心在协调平台的集群内部署虚拟测试代理来执行主动测试，或者在sidecar容器内部署虚拟测试代理来执行主动测试。在一些示例中，在sidecar容器内部署虚拟化测试代理包括使用用于部署虚拟化测试代理的准入网络挂钩，其中其上部署sidecar容器的目标pod由对pod定义的注释来定义。
监控运营方基于主动测试来测量节点之间的服务性能。在虚拟化服务包括第一虚拟化服务的情况下，启动主动测试包括创建第二虚拟化服务以启用第一虚拟化服务的性能测试。在一些示例中，启动主动测试包括在集群外部部署测试代理并且使用该测试代理来测试出站虚拟化服务。
在一些示例中，计算系统响应于确定服务等级违规而触发网络中的修复操作。该计算系统可以是边缘云系统的部分。在一些示例中，计算系统从诸如Kubernetes API的协调层接收对与多个虚拟化服务相关联的集群的改变的指示；由计算系统使用声明性测试描述和更新的元数据来确定更新的主动测试配置；以及由计算系统根据更新的主动测试配置自动更新一个或多个虚拟测试代理的放置。计算系统还可以在定义测试代理或监控器的输入的定制资源中提供标签，其中标签被定义为元数据内的对象，并且其中确定更新的主动测试配置包括通过将标签与Kubernetes集群内的对象进行匹配来动态地将测试代理与虚拟化服务匹配。
图27是示出根据本公开的一个或多个技术的计算系统的示例操作的流程图。例如，计算系统可以是图2的计算系统100。如图27的示例所示，计算系统接收用于主动测试第一虚拟化服务的声明性测试描述符(1402)。该计算系统从协调层获取与所请求的网络切片相关联的元数据，该网络切片由第一虚拟化服务实现，其中该元数据指定在由协调层管理的集群的命名空间内的第一虚拟化服务的唯一名称(1404)。计算系统基于声明性测试描述符和元数据来确定用于验证所请求的网络切片的主动测试配置，该主动测试配置包括测试配置参数、测试代理的放置、以及要被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素(1406)。计算系统根据主动测试配置，使用模拟元素在网络切片上启动主动测试(1408)。计算系统指示主动测试的结果是否指示网络切片满足服务等级要求(1412)。
图28是示出根据本公开的一个或多个技术的计算系统的示例操作的流程图。例如，计算系统可以是图2的计算系统100。在图28的示例中，计算系统接收用于主动测试由网络中的第一虚拟化服务实现的网络切片的声明性测试描述符(1510)。计算系统从协调层接收与网络切片相关联的元数据(1520)。计算系统基于声明性测试描述和元数据来确定用于测试网络切片的主动测试配置(1530)。计算系统根据主动测试配置来启动主动测试，并且基于主动测试的结果来确定服务等级违规(1540)。
示例1：一种计算系统，包括：耦合到存储设备的处理电路，处理电路被配置为：接收用于第一虚拟化服务的主动测试的声明性测试描述符；从协调层获取与所请求的网络切片相关联的元数据，网络切片由第一虚拟化服务实现，其中元数据指定由协调层管理的集群的命名空间内的针对第一虚拟化服务的唯一名称；基于声明性测试描述符和元数据，确定用于验证所请求的网络切片的主动测试配置，主动测试配置包括测试配置参数、测试代理的放置、以及将被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素；根据主动测试配置使用模拟元素在网络切片上启动主动测试；输出主动测试的结果是否指示网络切片满足服务等级要求的指示。
示例2.根据示例1的计算系统，其中处理电路被配置为接收声明性测试描述符包括处理电路被配置为接收针对多个服务类型中的每个的服务类型和针对服务类型的对应主动测试配置。
示例3.根据示例1的计算系统，还包括：响应于确定主动测试的结果指示网络切片满足所要求的服务等级要求，停止使用网络切片的模拟元素。
示例4.根据示例1的计算系统，还包括响应于确定主动测试的结果指示网络切片不满足所要求的服务等级要求而执行动作。
示例5.根据示例1的计算系统，还包括：在使用网络中的网络切片用于实时网络业务之后：根据主动测试配置来启动主动测试；以及基于主动测试的结果来确定服务等级违规。
示例6.根据示例1的计算系统，其中第一虚拟化服务和第二虚拟化服务包括容器化服务。
示例7.根据示例1的计算系统，其中协调层包括Kubernetes协调器。
示例8.根据示例1的计算系统，其中第二虚拟化服务包括选自群组中的至少一个服务，群组包括无线电单元(RU)、分布式单元(DU)和集中式单元(CU)，并且其中测试代理基于至少一个服务的位置来定位。
示例9.根据示例1的计算系统，其中网络中的第一虚拟化服务包括选自群组中的至少一个服务以实现用于移动网络的网络切片，群组包括接入和移动性管理功能(AMF)和用户平面功能(UPF)。
示例10.一种方法，包括：由计算系统接收用于主动测试网络中的虚拟化服务的声明性测试描述符；从协调层获取与所请求的网络切片相关联的元数据，网络切片由第一虚拟化服务实现；由计算系统并且基于声明性测试描述和元数据来确定用于验证所请求的网络切片的主动测试配置，主动测试配置包括测试配置参数、测试代理的放置、以及将被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素；根据主动测试配置，使用模拟元素对网络切片启动主动测试；以及输出主动测试的结果是否指示网络切片满足所要求的服务等级要求的指示。
示例11.根据示例10的方法，还包括在集群内部署虚拟测试代理。
示例12.根据示例10和11的方法，还包括将虚拟测试代理部署为sidecar。
示例13.根据权利要求10至12的方法，还包括测量节点之间的性能。
示例14.根据示例10至13的方法，还包括创建用于允许在节点之间进行性能测试的服务。
示例15.根据示例10至14的方法，还包括在集群外部部署测试代理，以及使用测试代理来测试出站服务。
示例16.根据示例10至15的方法，还包括基于确定存在服务等级违规来触发网络中的修复操作。
示例17.根据示例10至16的方法，其中计算系统是边缘云系统的部分。
示例18.一种方法，包括：由计算系统接收用于主动测试由网络中的第一虚拟化服务实现的网络切片的声明性测试描述符；由计算系统并且从协调层接收与网络切片相关联的元数据；由计算系统并且基于声明性测试描述和元数据，确定用于测试网络切片的主动测试配置；以及根据主动测试配置启动主动测试，并且基于主动测试的结果确定服务等级违规。
示例19.根据示例18的方法，还包括：创建第二虚拟化服务，以允许在节点之间进行主动测试。
示例20.根据示例18至19的方法，其中网络中的第一虚拟化服务包括选自群组中的至少一个服务以实现用于移动网络的网络切片，群组包括接入和移动性管理功能(AMF)和用户平面功能(UPF)。
本文描述的技术可以以硬件、软件、固件或其任意组合来实现。被描述为模块、单元或组件的各种特征可以在集成逻辑设备中一起实现，或者单独实现为离散但可互操作的逻辑设备或其他硬件设备。在一些情况下，电子电路的各种特征可以被实现为一个或多个集成电路设备，诸如集成电路芯片或芯片组。
如果以硬件实现，则本公开可针对诸如处理器的装置或诸如集成电路芯片或芯片组的集成电路设备。备选地或附加地，如果以软件或固件实现，则这些技术可以至少部分地通过计算机可读数据存储介质来实现，计算机可读数据存储介质包括指令，指令在被执行时使处理器执行上述方法中的一个或多个方法。例如，计算机可读数据存储介质可以存储这样的指令以供处理器执行。
计算机可读介质可以形成计算机程序产品的部分，该计算机程序产品可以包括包装材料。计算机可读介质可以包括计算机数据存储介质，诸如随机存取存储器(RAM)、只读存储器(ROM)、非易失性随机存取存储器(NVRAM)、电可擦除可编程只读存储器(EEPROM)、闪存、磁或光数据存储介质等。在一些示例中，制品可以包括一个或多个计算机可读存储介质。
在一些示例中，计算机可读存储介质可以包括非瞬态介质。术语“非瞬态”可以表示存储介质没有包含在载波或传播的信号中。在某些示例中，非瞬态存储介质可以存储可以随时间改变的数据(例如，在RAM或高速缓存中)。
代码或指令可以是由包括一个或多个处理器的处理电路执行的软件和/或固件，一个或多个处理器诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他等效的集成电路或离散逻辑电路。因此，本文使用的术语“处理器”可以指任何前述结构或适合于实现本文描述的技术的任何其他结构。此外，在一些方面，本公开中描述的功能可以在软件模块或硬件模块内提供。
Claims (20)
1.一种计算系统，包括：
处理电路，被耦合到存储设备，所述处理电路被配置为：
接收用于第一虚拟化服务的主动测试的声明性测试描述符；
从协调层获取与所请求的网络切片相关联的元数据，所述网络切片由所述第一虚拟化服务实现，其中所述元数据指定由所述协调层管理的集群的命名空间内的所述第一虚拟化服务的唯一名称；
基于所述声明性测试描述符和所述元数据，确定用于验证所述所请求的网络切片的主动测试配置，所述主动测试配置包括测试配置参数、测试代理的放置、以及将被分配用于验证所述所请求的网络切片并且由第二虚拟化服务实现的模拟元素；
根据所述主动测试配置使用所述模拟元素在所述网络切片上启动主动测试；
输出所述主动测试的结果是否指示所述网络切片满足服务等级要求的指示。
2.根据权利要求1所述的计算系统，其中所述处理电路被配置为，接收所述声明性测试描述符包括：所述处理电路被配置为接收针对多个服务类型中的每个服务类型的服务类型和针对所述服务类型的对应主动测试配置。
3.根据权利要求1和2中的任一项所述的计算系统，其中所述处理电路还被配置为，响应于确定所述主动测试的所述结果指示所述网络切片满足所要求的服务等级要求，停止使用针对所述网络切片的所述模拟元素。
4.根据权利要求1至3中的任一项所述的计算系统，其中所述处理电路还被配置为，响应于确定所述主动测试的所述结果指示所述网络切片不满足所要求的服务等级要求而执行动作。
5.根据权利要求1至4中的任一项所述的计算系统，其中所述处理电路还被配置为：
在使用所述网络中的所述网络切片用于实时网络业务之后：
根据所述主动测试配置来启动主动测试；以及
基于所述主动测试的结果来确定服务等级违规。
6.根据权利要求1至5中的任一项所述的计算系统，其中所述第一虚拟化服务和所述第二虚拟化服务包括容器化服务。
7.根据权利要求1至6中的任一项所述的计算系统，其中所述协调层包括Kubernetes协调器。
8.根据权利要求1至7中的任一项所述的计算系统，其中所述第二虚拟化服务包括选自群组的至少一个服务，所述群组包括无线电单元(RU)、分布式单元(DU)和集中式单元(CU)，并且其中所述测试代理基于所述至少一个服务的位置而被定位。
9.根据权利要求1至8中的任一项所述的计算系统，其中所述网络中的所述第一虚拟化服务包括选自群组的至少一个服务，所述群组以实现用于移动网络的所述网络切片，所述群组包括接入和移动性管理功能(AMF)和用户平面功能(UPF)，。
10.一种方法，包括：
由计算系统接收用于主动测试网络中的虚拟化服务的声明性测试描述符；
从协调层获取与所请求的网络切片相关联的元数据，所述网络切片由第一虚拟化服务实现；
由所述计算系统并且基于所述声明性测试描述和所述元数据来确定用于验证所述所请求的网络切片的主动测试配置，所述主动测试配置包括测试配置参数、测试代理的放置、以及将被分配用于验证所请求的网络切片并且由第二虚拟化服务实现的模拟元素；
根据所述主动测试配置，使用所述模拟元素对所述网络切片启动主动测试；
由所述计算系统确定所述主动测试的所述结果是否指示所述网络切片满足所要求的服务等级要求；以及
输出所述主动测试的所述结果是否指示所述网络切片满足所要求的服务等级要求的指示。
11.根据权利要求10所述的方法，还包括：在集群内部署虚拟测试代理。
12.根据权利要求10和11中的任一项所述的方法，还包括：将虚拟测试代理部署为sidecar。
13.根据权利要求10至12中的任一项所述的方法，还包括：测量节点之间的性能。
14.根据权利要求10至13中的任一项所述的方法，还包括：创建用于允许在节点之间进行性能测试的服务。
15.根据权利要求10至14中的任一项所述的方法，还包括：在集群外部部署测试代理，以及使用所述测试代理来测试出站服务。
16.根据权利要求10至15中的任一项所述的方法，还包括：基于确定存在服务等级违规来触发网络中的修复操作。
17.根据权利要求10至16中的任一项所述的方法，其中所述计算系统是边缘云系统的部分。
18.一种方法，包括：
由计算系统接收用于主动测试由网络中的第一虚拟化服务实现的网络切片的声明性测试描述符；
由所述计算系统并且从协调层接收与所述网络切片相关联的元数据；
由所述计算系统并且基于所述声明性测试描述和所述元数据，确定用于测试所述网络切片的主动测试配置；以及
根据所述主动测试配置来启动主动测试，并且基于所述主动测试的结果来确定服务等级违规。
19.根据权利要求18所述的方法，还包括：
创建第二虚拟化服务，以用于允许在节点之间进行主动测试。
20.根据权利要求18至19中的任一项所述的方法，其中所述网络中的所述第一虚拟化服务包括选自群组的至少一个服务以实现用于移动网络的所述网络切片，所述群组包括接入和移动性管理功能(AMF)和用户平面功能(UPF)。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US202063114444P | 2020-11-16 | 2020-11-16 | |
| US63/114,444 | 2020-11-16 | ||
| US202163261943P | 2021-09-30 | 2021-09-30 | |
| US63/261,943 | 2021-09-30 | ||
| PCT/US2021/072446 WO2022104395A1 (en) | 2020-11-16 | 2021-11-16 | Active assurance of network slices |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115918139A true CN115918139A (zh) | 2023-04-04 |
Family
ID=79185710
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202180046468.2A Pending CN115918139A (zh) | 2020-11-16 | 2021-11-16 | 网络切片的主动保证 |
Country Status (4)
| Country | Link |
|---|---|
| US (3) | US11936548B2 (zh) |
| EP (2) | EP4245057A1 (zh) |
| CN (1) | CN115918139A (zh) |
| WO (2) | WO2022104396A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117389693A (zh) * | 2023-12-12 | 2024-01-12 | 麒麟软件有限公司 | 一种硬件虚拟化系统io层安全检测方法 |
Families Citing this family (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10454714B2 (en) | 2013-07-10 | 2019-10-22 | Nicira, Inc. | Method and system of overlay flow control |
| US10608844B2 (en) | 2017-10-02 | 2020-03-31 | Vmware, Inc. | Graph based routing through multiple public clouds |
| US11115480B2 (en) | 2017-10-02 | 2021-09-07 | Vmware, Inc. | Layer four optimization for a virtual network defined over public cloud |
| US10999100B2 (en) | 2017-10-02 | 2021-05-04 | Vmware, Inc. | Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider |
| US11223514B2 (en) | 2017-11-09 | 2022-01-11 | Nicira, Inc. | Method and system of a dynamic high-availability mode based on current wide area network connectivity |
| US10855757B2 (en) * | 2018-12-19 | 2020-12-01 | At&T Intellectual Property I, L.P. | High availability and high utilization cloud data center architecture for supporting telecommunications services |
| US11895092B2 (en) * | 2019-03-04 | 2024-02-06 | Appgate Cybersecurity, Inc. | Network access controller operation |
| US11121985B2 (en) | 2019-08-27 | 2021-09-14 | Vmware, Inc. | Defining different public cloud virtual networks for different entities based on different sets of measurements |
| WO2021196080A1 (en) | 2020-04-01 | 2021-10-07 | Vmware Information Technology (China) Co., Ltd. | Auto deploying network elements for heterogeneous compute elements |
| US11552971B1 (en) * | 2020-06-17 | 2023-01-10 | Amazon Technologies, Inc. | Detection of fraudulent use of content delivery network served byte streams |
| EP3937453B1 (en) * | 2020-07-09 | 2023-01-11 | Deutsche Telekom AG | Method for an improved emulation and/or interworking functionality between a first mobile communication network and a second mobile communication network, system, emulation function, program and computer program product |
| US11803408B2 (en) | 2020-07-29 | 2023-10-31 | Vmware, Inc. | Distributed network plugin agents for container networking |
| US11863352B2 (en) | 2020-07-30 | 2024-01-02 | Vmware, Inc. | Hierarchical networking for nested container clusters |
| CN115918139A (zh) | 2020-11-16 | 2023-04-04 | 瞻博网络公司 | 网络切片的主动保证 |
| US11729111B2 (en) * | 2020-12-11 | 2023-08-15 | Netapp, Inc. | Pluggable data resource management controller |
| US11601356B2 (en) | 2020-12-29 | 2023-03-07 | Vmware, Inc. | Emulating packet flows to assess network links for SD-WAN |
| US11792127B2 (en) | 2021-01-18 | 2023-10-17 | Vmware, Inc. | Network-aware load balancing |
| US11979325B2 (en) | 2021-01-28 | 2024-05-07 | VMware LLC | Dynamic SD-WAN hub cluster scaling with machine learning |
| US20220247653A1 (en) * | 2021-02-01 | 2022-08-04 | Microsoft Technology Licensing, Llc | Early deployment connectivity testing |
| US11818647B2 (en) * | 2021-03-01 | 2023-11-14 | Juniper Networks, Inc. | Containerized router with a generic data plane interface |
| US11650892B1 (en) * | 2021-04-08 | 2023-05-16 | Spirent Communications, Inc. | Resilient coordination, command, and control of widely distributed test agents |
| US12009987B2 (en) | 2021-05-03 | 2024-06-11 | VMware LLC | Methods to support dynamic transit paths through hub clustering across branches in SD-WAN |
| US11900089B2 (en) * | 2021-05-04 | 2024-02-13 | Red Hat, Inc. | Automatically configuring and deploying a software operator in a distributed computing environment from a package |
| US20220407790A1 (en) * | 2021-06-18 | 2022-12-22 | Vmware, Inc. | Method and apparatus for deploying tenant deployable elements across public clouds based on harvested performance metrics |
| US12015536B2 (en) | 2021-06-18 | 2024-06-18 | VMware LLC | Method and apparatus for deploying tenant deployable elements across public clouds based on harvested performance metrics of types of resource elements in the public clouds |
| US11949734B2 (en) * | 2021-08-17 | 2024-04-02 | Charter Communications Operating, Llc | Cloud native realization of distributed ran elements |
| US11943146B2 (en) | 2021-10-01 | 2024-03-26 | VMware LLC | Traffic prioritization in SD-WAN |
| US11533246B1 (en) * | 2021-10-04 | 2022-12-20 | At&T Intellectual Property I, L.P. | Network probe placement optimization |
| US20230126496A1 (en) * | 2021-10-22 | 2023-04-27 | T-Mobile Usa, Inc. | Systems and Methods for Proxying Real Traffic for Simulation |
| US11989542B2 (en) * | 2021-11-04 | 2024-05-21 | Red Hat, Inc. | Enhancing operator installation and upgrade management and verification |
| US20230171099A1 (en) * | 2021-11-27 | 2023-06-01 | Oracle International Corporation | Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification |
| US11646935B1 (en) * | 2021-12-02 | 2023-05-09 | Charter Communications Operating, Llc | Automated provisioning and configuration for dynamically loaded NFV- and SDN-based networks |
| US11659027B1 (en) * | 2022-01-06 | 2023-05-23 | Vmware, Inc. | Multi-network/domain service discovery in a container orchestration platform |
| US11792120B2 (en) * | 2022-01-13 | 2023-10-17 | HashiCorp | Discovery and routing service for a cloud infrastructure |
| US20230231741A1 (en) * | 2022-01-14 | 2023-07-20 | Vmware, Inc. | Per-namespace ip address management method for container networks |
| US11627061B1 (en) * | 2022-02-24 | 2023-04-11 | Microsoft Technology Licensing, Llc | Packet capture using VXLAN encapsulation |
| US11843537B2 (en) * | 2022-04-14 | 2023-12-12 | Dish Wireless L.L.C. | Telecommunication service provider controlling an underlay network in cloud service provider environment |
| US11909815B2 (en) | 2022-06-06 | 2024-02-20 | VMware LLC | Routing based on geolocation costs |
| US20240007340A1 (en) * | 2022-06-29 | 2024-01-04 | Vmware, Inc. | Executing on-demand workloads initiated from cloud services in a software-defined data center |
| US20240007385A1 (en) * | 2022-07-04 | 2024-01-04 | Vmware, Inc. | Automated methods and systems for simulating a radio access network |
| US11943292B2 (en) * | 2022-07-06 | 2024-03-26 | International Business Machines Corporation | Extend controller for multi-tenancy |
| US11882004B1 (en) | 2022-07-22 | 2024-01-23 | Dell Products L.P. | Method and system for adaptive health driven network slicing based data migration |
| US12009975B2 (en) | 2022-07-22 | 2024-06-11 | Dell Products L.P. | Method and system for generating an upgrade recommendation for a communication network |
| US11811640B1 (en) * | 2022-07-22 | 2023-11-07 | Dell Products L.P. | Method and system for modifying a communication network |
| US20240073137A1 (en) * | 2022-08-29 | 2024-02-29 | Vmware, Inc. | Split control plane for private mobile network |
| WO2024059849A1 (en) * | 2022-09-16 | 2024-03-21 | Juniper Networks, Inc. | Deployment checks for a containerized sdn architecture system |
| US11848910B1 (en) | 2022-11-11 | 2023-12-19 | Vmware, Inc. | Assigning stateful pods fixed IP addresses depending on unique pod identity |
| CN116192863B (zh) * | 2023-01-13 | 2023-11-28 | 中科驭数（北京）科技有限公司 | 微服务流量处理方法、dpu服务网格部署方法及系统 |
| US11831511B1 (en) | 2023-01-17 | 2023-11-28 | Vmware, Inc. | Enforcing network policies in heterogeneous systems |
| CN116938943B (zh) * | 2023-09-15 | 2024-01-12 | 北京城建智控科技股份有限公司 | 云主机调度方法、装置、设备和存储介质 |
Family Cites Families (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7159021B2 (en) | 2002-06-27 | 2007-01-02 | Microsoft Corporation | System and method for testing peer-to-peer network applications |
| US8214193B2 (en) | 2008-10-01 | 2012-07-03 | At&T Intellectual Property I, Lp | Virtualized policy tester |
| US8248958B1 (en) * | 2009-12-09 | 2012-08-21 | Juniper Networks, Inc. | Remote validation of network device configuration using a device management protocol for remote packet injection |
| US9064216B2 (en) | 2012-06-06 | 2015-06-23 | Juniper Networks, Inc. | Identifying likely faulty components in a distributed system |
| US9444717B1 (en) | 2013-02-28 | 2016-09-13 | Amazon Technologies, Inc. | Test generation service |
| US10581687B2 (en) | 2013-09-26 | 2020-03-03 | Appformix Inc. | Real-time cloud-infrastructure policy implementation and management |
| US9917745B2 (en) | 2013-09-27 | 2018-03-13 | Futurewei Technologies, Inc. | Validation of chained network services |
| US9356866B1 (en) | 2014-01-10 | 2016-05-31 | Juniper Networks, Inc. | Receive packet steering for virtual networks |
| US9560081B1 (en) | 2016-06-24 | 2017-01-31 | Varmour Networks, Inc. | Data network microsegmentation |
| US20150229549A1 (en) * | 2014-02-13 | 2015-08-13 | Monolith Technology Services, Inc. | Systems and methods for automated service propagation |
| US10015098B2 (en) * | 2015-07-02 | 2018-07-03 | Dell Products Lp | Systems and methods to create highly scalable network services |
| WO2017053961A1 (en) | 2015-09-25 | 2017-03-30 | Contec, Llc | Universal device testing system |
| WO2017144432A1 (en) * | 2016-02-26 | 2017-08-31 | Nokia Solutions And Networks Oy | Cloud verification and test automation |
| US10671520B1 (en) * | 2016-06-15 | 2020-06-02 | Thousandeyes, Inc. | Scheduled tests for endpoint agents |
| US10187287B2 (en) * | 2016-09-29 | 2019-01-22 | NIIT Technologies Ltd | Estimating effort required for testing web services deployed in an enterprise system |
| US10491528B2 (en) * | 2016-10-27 | 2019-11-26 | Hewlett Packard Enterprise Development Lp | Selectively monitoring a network of network function chains based on probability of service level agreement violation |
| US10681005B2 (en) * | 2016-12-08 | 2020-06-09 | Keysight Technologies Singapore (Sales) Pte. Ltd. | Deploying a networking test tool in a cloud computing system |
| US10756966B2 (en) * | 2017-02-22 | 2020-08-25 | Cisco Technology, Inc. | Containerized software architecture for configuration management on network devices |
| US10761896B2 (en) | 2017-02-22 | 2020-09-01 | Cisco Technology, Inc. | System and method of lightweight decentralized NFV orchestration |
| US10244034B2 (en) | 2017-03-29 | 2019-03-26 | Ca, Inc. | Introspection driven monitoring of multi-container applications |
| CN109219090B (zh) * | 2017-06-30 | 2022-11-08 | 中兴通讯股份有限公司 | 商务特性数据上报方法及装置、网络切片编排方法及装置 |
| US10963349B2 (en) | 2017-08-25 | 2021-03-30 | Vmware, Inc. | Containerized application snapshots |
| US9882784B1 (en) * | 2017-09-26 | 2018-01-30 | Tesuto Llc | Holistic validation of a network via native communications across a mirrored emulation of the network |
| US10728135B2 (en) * | 2017-10-13 | 2020-07-28 | Keysight Technologies, Inc. | Location based test agent deployment in virtual processing environments |
| US10983897B2 (en) * | 2018-01-30 | 2021-04-20 | International Business Machines Corporation | Testing embedded systems and application using hardware-in-the-loop as a service (HILAAS) |
| US10841196B2 (en) * | 2018-03-26 | 2020-11-17 | Spirent Communications, Inc. | Key performance indicators (KPI) for tracking and correcting problems for a network-under-test |
| CN116962221A (zh) | 2018-04-10 | 2023-10-27 | 瞻博网络公司 | 计算机网络的测量指标 |
| US10855531B2 (en) | 2018-08-30 | 2020-12-01 | Juniper Networks, Inc. | Multiple networks for virtual execution elements |
| US10728145B2 (en) | 2018-08-30 | 2020-07-28 | Juniper Networks, Inc. | Multiple virtual network interface support for virtual execution elements |
| US10708082B1 (en) | 2018-08-31 | 2020-07-07 | Juniper Networks, Inc. | Unified control plane for nested clusters in a virtualized computing infrastructure |
| US10795690B2 (en) * | 2018-10-30 | 2020-10-06 | Oracle International Corporation | Automated mechanisms for ensuring correctness of evolving datacenter configurations |
| US10735300B1 (en) * | 2018-11-30 | 2020-08-04 | Intuit Inc. | Discovery and testing of program dependencies in computer networks |
| US10880173B2 (en) * | 2018-12-03 | 2020-12-29 | At&T Intellectual Property I, L.P. | Automated certification of network functions |
| KR102641254B1 (ko) | 2019-01-08 | 2024-02-29 | 삼성전자 주식회사 | 무선 통신 시스템에서 종단 간 네트워크를 제어하는 관리 장치 및 방법 |
| US11307967B2 (en) * | 2019-02-04 | 2022-04-19 | Oracle International Corporation | Test orchestration platform |
| US11128556B2 (en) * | 2019-02-20 | 2021-09-21 | Accenture Global Solutions Limited | Deploying, testing, monitoring, scaling, and healing virtual network functions in a software-defined network |
| US10841226B2 (en) * | 2019-03-29 | 2020-11-17 | Juniper Networks, Inc. | Configuring service load balancers with specified backend virtual networks |
| US11012343B2 (en) * | 2019-10-10 | 2021-05-18 | Verizon Patent And Licensing Inc. | Systems and methods for automatically packaging and deploying virtual network functions based on network interface dependencies and compatibilities |
| US10779178B1 (en) * | 2019-11-20 | 2020-09-15 | Verizon Patent And Licensing Inc. | Systems and methods of using network slicing for test platform |
| CN111181801B (zh) | 2019-12-04 | 2021-11-09 | 腾讯云计算（北京）有限责任公司 | 节点集群测试方法、装置、电子设备及存储介质 |
| US11088915B1 (en) * | 2020-01-17 | 2021-08-10 | Cisco Technology, Inc. | Live network sandboxing on a centralized management system |
| US11824725B2 (en) * | 2020-03-17 | 2023-11-21 | Rebaca Technologies | State machine emulation using domain-specific language constructs |
| US11451973B2 (en) * | 2020-09-23 | 2022-09-20 | T-Mobile Usa, Inc. | Simulating operation of a 5G wireless telecommunication network |
| EP4227812A4 (en) * | 2020-10-09 | 2024-07-03 | Rakuten Symphony Singapore Pte Ltd | NETWORK SERVICE MANAGEMENT SYSTEM AND NETWORK SERVICE MANAGEMENT METHOD |
| US11388234B2 (en) * | 2020-10-19 | 2022-07-12 | Hewlett Packard Enterprise Development Lp | Infrastructure for deploying a security information and event management application on a container platform |
| US20220138081A1 (en) * | 2020-11-02 | 2022-05-05 | Innovate5G, Inc. | Systems and Methods for Optimization of Application Performance on a Telecommunications Network |
| CN115918139A (zh) | 2020-11-16 | 2023-04-04 | 瞻博网络公司 | 网络切片的主动保证 |
| US11350294B1 (en) * | 2020-11-16 | 2022-05-31 | Sprint Communications Company L.P. | Rolling production test |
-
2021
- 2021-11-16 CN CN202180046468.2A patent/CN115918139A/zh active Pending
- 2021-11-16 US US17/455,213 patent/US11936548B2/en active Active
- 2021-11-16 US US17/455,214 patent/US20220158912A1/en active Pending
- 2021-11-16 WO PCT/US2021/072447 patent/WO2022104396A1/en active Application Filing
- 2021-11-16 WO PCT/US2021/072446 patent/WO2022104395A1/en unknown
- 2021-11-16 EP EP21835918.0A patent/EP4245057A1/en active Pending
- 2021-11-16 EP EP21831467.2A patent/EP4245056A1/en active Pending
-
2023
- 2023-09-29 US US18/478,740 patent/US20240048471A1/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117389693A (zh) * | 2023-12-12 | 2024-01-12 | 麒麟软件有限公司 | 一种硬件虚拟化系统io层安全检测方法 |
| CN117389693B (zh) * | 2023-12-12 | 2024-04-05 | 麒麟软件有限公司 | 一种硬件虚拟化系统io层安全检测方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20220158926A1 (en) | 2022-05-19 |
| EP4245056A1 (en) | 2023-09-20 |
| US20220158912A1 (en) | 2022-05-19 |
| WO2022104395A1 (en) | 2022-05-19 |
| EP4245057A1 (en) | 2023-09-20 |
| US11936548B2 (en) | 2024-03-19 |
| WO2022104396A9 (en) | 2022-07-07 |
| US20240048471A1 (en) | 2024-02-08 |
| WO2022104396A1 (en) | 2022-05-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11936548B2 (en) | Active assurance for virtualized services | |
| US10944691B1 (en) | Container-based network policy configuration in software-defined networking (SDN) environments | |
| US11036536B2 (en) | Method, apparatus, and system for deploying virtualized network function using network edge computing | |
| US11190424B2 (en) | Container-based connectivity check in software-defined networking (SDN) environments | |
| US10270658B2 (en) | Zero touch configuration and synchronization of a service appliance in a network environment | |
| US11748132B2 (en) | Apparatus and method for configuring and enabling virtual applications | |
| US20170289060A1 (en) | Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure | |
| WO2016155394A1 (zh) | 一种虚拟网络功能间链路建立方法及装置 | |
| US11258661B2 (en) | Initializing server configurations in a data center | |
| US11016772B2 (en) | System and method for executing scripts in a virtual network function | |
| Lee et al. | High-performance software load balancer for cloud-native architecture | |
| US20240097979A1 (en) | Fabric availability and synchronization | |
| CN116530130A (zh) | 用于虚拟化服务的主动保证 | |
| Lin | Client-centric orchestration and management of distributed applications in multi-tier clouds | |
| TaheriMonfared et al. | Flexible building blocks for software defined network function virtualization | |
| US20240214294A1 (en) | Analysis system for software-defined network architectures | |
| US20240223454A1 (en) | Network policy validation | |
| Borcoci | Network Function Virtualization and Software Defined Networking Cooperation | |
| El-Geder | Performance evaluation using multiple controllers with different flow setup modes in the software defined network architecture | |
| Luchian et al. | Migration of an SDN-Based Testbed into a Private Cloud: An OpenStack Approach | |
| Bosch et al. | Mobile network function and service delivery virtualization and orchestration | |
| Janovic | Integrating ACI with Virtualization and Container Platforms | |
| Τσακαλίδου | Testbed for SDN applications using OpenFlow: create testbed that could be used for experimentation and research of software defined network applications | |
| Aragonès Sabaté | Software Defined Networks (SDN) in data center networks | |
| WO2024059849A1 (en) | Deployment checks for a containerized sdn architecture system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |