执行生命周期管理的制作方法

计算;推算;计数设备的制造及其应用技术1.本公开涉及执行生命周期管理。背景技术：2.工作负载(诸如虚拟机(vm)和物理服务器)的生命周期管理具有挑战性。例如，可能需要创建多个vm，当任何vm故障时进行检测，通过删除和重新创建任何故障vm来修复故障vm和/或动态地向上扩展或向下扩展vm池。可以针对vm所在的特定vm环境(诸如openstack或vmware)来编写和运行协调器。这可以使生命周期管理事件发生并使生命周期管理操作被执行。然而，这样的协调器可能是重量级的、脆弱的、难以使用的和/或高度特定于环境的。技术实现要素：3.根据第一实施例，提供了一种在数据处理系统中执行生命周期管理的方法，所述方法包括：4.在第一工作负载环境中提供第一工作负载；和5.使用所述第一工作负载将所述第一工作负载环境中的所述第一工作负载的一个或多个第一生命周期管理状态与第二工作负载的一个或多个第二生命周期管理状态对齐，6.其中，所述第二工作负载在不同的第二工作负载环境中。7.根据第二实施例，提供了一种被布置成执行根据第一实施例的方法的数据处理系统。8.根据第三实施例，提供了一种工作负载，被配置为在被执行时根据第一实施例来使用，其中，所述工作负载是第一工作负载。9.进一步的特征和优点将从以下参照附图仅作为示例给出的描述中变得明显。附图说明10.图1示出了表示数据处理系统的示例的示意框图；11.图2示出了表示执行生命周期管理的方法的示例的流程图；12.图3示出了表示数据处理系统的另一示例的示意框图；13.图4示出了表示数据处理系统的另一示例的示意框图；14.图5示出了表示数据处理系统的另一示例的示意框图；15.图6示出了表示数据处理系统的另一示例的示意框图；和16.图7示出了表示数据处理系统的另一示例的示意框图。具体实施方式17.本文描述的示例一般涉及环境间(或“跨环境”)生命周期管理，在所述环境间(或“跨环境”)生命周期管理中，一个环境中的生命周期管理功能在另一环境中被利用。这与上述环境内生命周期管理不同，在所述环境内生命周期管理中，生命周期管理功能与被管理的工作负载在相同的环境中。例如，容器化环境(诸如开源容器编排系统(kubernetes))中的生命周期管理功能可用于在vm环境(诸如开源云计算管理平台(openstack))中执行vm的环境间生命周期管理。因此，可能不需要针对vm环境自定义编写的重量级的、脆弱的和/或难以使用的协调器来管理vm环境中的vm。此外，与编写了许多特定于环境的协调器并且每个协调器特定于使用它的特殊环境的上述场景相比，在示例中可以避免编写超过一个这样的协调器的需要并且可以使用现有的协调器功能。18.环境间生命周期管理违背了本领域的组合多个不同的环境(诸如kubernetes和vm(通常被视为单独的技术))会增加复杂性的偏见kubernetes。环境间生命周期管理与仅彼此交互的多个不同环境不同，例如，一个环境中的工作负载仅与另一环境中的工作负载通信。相比之下，环境间生命周期管理具体涉及跨环境生命周期管理。与kubernetes相关的术语“工作负载”是指作为在kubernetes上运行的应用的组件来运行的容器，但更一般地应理解为另外包括与可以执行生命周期管理相关的其他实体，例如包括但不限于vm和物理服务器。19.以上面kubernetes环境和vm环境为例，原则上，现有的vm功能可以从vm环境中的vm迁移到kubernetes中的容器化工作负载，这样kubernetes就可以在自己的环境中管理迁移到容器化工作负载。然而，在实践中，此类迁移可能涉及大量资源(例如，时间)，并且可能需要或可能首选一些此类功能以在vm环境中运行，使得其在实践中无法迁移。因此，在实践中，可能仍然需要通过vm环境中的vm提供一些功能。例如，vm环境可以针对具有复杂逻辑和网络的大型进程进行优化。另一方面，kubernetes可以针对快速故障、较小的流程和不太复杂的网络需求进行优化。特别地，vm可以具有多个可以直接映射到物理接口的网络接口，而容器通常各自具有一个映射到少量物理接口的网络接口。因此，vm在一些环境中可以拥有更灵活、更强大的网络。20.在本文描述的示例中，软件实例(本文也称为“工作负载”、“影子”或“影子工作负载”)在第一环境(本文也称为“平台”)中被创建。此类软件实例在不同的第二环境中作为工作负载的影子工作负载运行。因此，影子工作负载与第二环境中的工作负载相关联。因为第一环境中的给定影子工作负载与第二环境中的单个给定工作负载相关联，所以这种关联可以是一对一的。影子工作负载在第一环境中由第一环境中的层(本文称为“部署协调”层)管理。因此，位于第一环境中的影子工作负载由相同的第一环境中的部署协调层管理。影子工作负载用于对齐第一环境中的影子工作负载的一个或多个第一生命周期管理状态和第二环境中相关联工作负载的一个或多个第二生命周期管理状态。采取并影响第一环境中的影子工作负载的生命周期管理状态的操作(特别是生命周期管理操作)被传递到第二环境中的工作负载，使得第二环境中的工作负载的生命周期管理状态与第一环境中的影子工作负载的生命周期管理状态对齐和/或反之亦然。此类操作的结果通过影子工作负载(例如通过影子工作负载的生命周期管理状态)报告回来。21.如以下将更详细描述的，第一环境中的部署协调层可以在第一环境中创建影子工作负载，使得影子工作负载具有与创建影子工作负载相关的“已创建”生命周期管理状态。新创建的影子工作负载又可以在第二环境中创建相关联的工作负载。然后，第二环境中新创建的工作负载也具有“已创建”生命周期管理状态，其中，该生命周期管理状态与影子工作负载的“已创建”生命周期管理状态一致(或“匹配”、“映射到”或“镜像”)。另外，响应于影子工作负载确定第二环境中的工作负载具有与第二环境中的工作负载的准备就绪相对应的“准备就绪”生命周期管理状态(例如，第二环境中的工作负载具有正确的配置并且是健康的)，影子工作负载可以将其生命周期管理状态与第二环境中的工作负载的生命周期管理状态(即“准备就绪”生命周期管理状态)对齐。然后，影子工作负载可以将其“准备就绪”生命周期管理状态报告给第一环境中的部署协调层。22.通过管理第一环境中的影子工作负载，第一环境的部署协调层因此在第二环境中被利用。23.在示例中，第一环境和第二环境分别使用不同的技术(诸如容器技术和vm技术)。相反，如果第一环境和第二环境彼此使用相同的技术，那么第一环境中的部署协调层也可以简单地在第二环境中运行。因此，这里描述的技术对于跨环境生命周期管理更有效，在所述跨环境生命周期管理中，不同的环境使用不同的技术。24.本文描述的示例允许以环境中立的方式来利用现有的部署协调层技术(诸如kubernetes)。这种现有的部署协调层技术(例如kubernetes)可以是鲁棒的、维护良好的和经过良好测试的。这种现有技术可以被利用，而不是编写自定义生命周期管理器(lcm)产品或使用其他功能较弱的产品。在示例中，一个环境(诸如kubernetes)中的现有软件的现有功能用于管理另一环境(例如vm)中的工作负载。具体地，kubernetes操作部署协调层以提供应用程序编程接口(api)和功能来管理包括本文描述的生命周期管理码的容器。让单个kubernetes集群管理vm集(在kubernetes环境外部)允许在单个位置进行一致的管理，其中，对所有工作负载(容器、vm、物理裸机服务器等)的控制在一个位置利用一致的api甚至相同的码被管理。kubernetes具有添加一系列特征的功能(诸如基于角色的访问控制(rbac)、审核、gitops集成等)。因此，这些功能默认情况下是使用kubernetes提供的。如果改用自定义编写的协调器，协调器本身就需要被管理；在协调器故障时修复协调器，使协调器具有高可用性(ha)等。与大多数协调产品不同，kubernetes具有自我修复功能，可以轻松地以ha模式部署。25.在示例中，用于管理vm的逻辑被划分为两部分；复杂的生命周期逻辑在kubernetes中独立于底层平台被执行，平台特定逻辑在容器图像中被维护。然而，容器图像被设计为轻量级且小尺寸(例如，与vm的尺寸相比)，并且本文描述的技术可以容易地应用于各种平台(例如openstack、vmware、云平台(诸如azure和亚马逊网络服务(aws)))，甚至是裸机。在示例中，因为容器图像没有协调或应用逻辑，所以容器图像可以做得很小(并且可以跨应用使用，在某种程度上，还可以用于vm环境)。相反，在示例中，它们具有最少的逻辑(即检查具有特定参数的工作负载(例如，vm)存在)。26.除了通过利用另一环境中的部署协调层来促进一个环境中的工作负载的生命周期管理之外，这里描述的示例还促进了外部报告。例如，kubernetes可以提供一个显示其管理的所有工作负载(无论是容器、vm还是物理服务器)的状态的控制面板。27.在本文描述的示例中，协调器存在于第一环境(例如，kubernetes环境)中。协调器负责管理第一环境中的一个或多个软件实例的集合。一个或多个软件实例中的一些或全部一对一地映射到不同的第二环境(例如，vm环境中的vm)中的一个或多个单独的软件实例。从第一环境中的协调器接收到的、影响映射的软件实例的生命周期操作以第二环境理解的方式(例如，通过第一到第二环境映射)被传递到第二配对环境。来自第二环境的响应和状态被传回，以便第二环境中的每个一对一映射的软件实例例如通过第二环境映射正确地出现在第一环境中的协调器中。28.一个已知的项目vmctl使用kubernetes通过影子配置模型来管理vm。然而，vmctl管理kubernetes资源内部的vm，而不是管理kubernetes外部的vm。因为vmctl仅在非常有限的环境中管理vm，因此vmctl项目远比本文描述的技术受到更多限制，其中，vm是在kubernetes环境中的容器内部创建的。相比之下，本文描述的技术使kubernetes环境外部的基础结构能够从kubernetes环境内进行管理。29.参照图1，示出了数据处理系统100的示例。30.数据处理系统100包括第一环境105，其中，所述第一环境105在该示例中是工作负载环境。术语“工作负载环境”在本文中用于表示可以定位工作负载的环境。在该示例中，第一环境105是容器化环境，在所述容器化环境中，kubernetes是示例。第一环境105包括第一工作负载110，在该示例中，第一工作负载110是容器化工作负载。在该示例中，第一工作负载110是影子工作负载。31.数据处理系统100包括第二环境115，该第二环境115与第一环境105的不同之处在于第一环境105和第二环境115使用不同的技术。第二环境115包括第二工作负载120，该第二工作负载120例如可以是vm或物理服务器。在该示例中，第二工作负载120提供电话功能，诸如长期演进语音(volte)功能、媒体资源功能(mrf)、ip多媒体子系统(ims)核心功能、会话边界控制器(sbc)功能等。例如因为复杂性、网络要求、重新实现现有的成本虚拟化码等，所以此功能可能需要或可能更有效地由vm而不是容器执行。32.在该示例中，影子工作负载110不提供电话功能，并且其唯一或主要功能是充当影子工作负载，执行第二工作负载120的生命周期管理(在本文中也称为“生命周期管理”或“拥有”第二工作负载120)。33.参照图2，示出了执行与工作负载相关的生命周期管理的示例方法。在本示例中，该方法在图1所示的数据处理系统100中执行。34.在该示例方法中，影子工作负载110用于将影子工作负载110的一个或多个第一生命周期管理状态与第二工作负载120的一个或多个第二生命周期管理状态对齐。35.在项s2a，影子工作负载110开始生命周期管理例程。影子工作负载110可以间歇地执行例程。该例程可以周期性地被执行(诸如每30秒一次)。在该示例中，例程涉及检查第二工作负载120是否存在，如果存在，则检查第二工作负载120是否具有正确的图像和/或配置并且是否健康。36.在项s2b，影子工作负载110检查第二工作负载120是否存在。37.如果第二工作负载120不存在，则影子工作负载110在项s2c创建第二工作负载120。为了创建第二工作负载120，影子工作负载110可以生成“创建”命令并将“创建”命令发送到第二环境115。这样的传输可以包括影子工作负载110例如通过第一环境105和第二环境115之间的超文本传输协议安全(https)接口对第二环境115进行api调用。38.在项s2d，影子工作负载110检查第二工作负载120是否具有正确的配置。39.在项s2e，如果第二工作负载120存在但具有错误的配置，则影子工作负载110确定是否可以实时更改配置。40.在项s2f，如果可以实时更改配置，则影子工作负载110更改第二工作负载120的配置。41.在项s2g，影子工作负载110检查第二工作负载120是否健康。42.在项s2h，如果第二工作负载120具有正确的配置并且是健康的，则认为第二工作负载120处于“准备就绪”生命周期管理状态。影子工作负载110将其自己的生命周期管理状态与第二工作负载120的“准备就绪”生命周期管理状态对齐。在该示例中，这涉及影子工作负载110将其生命周期管理状态报告为“准备就绪”给第一环境105中的部署协调层。因此，如果第二工作负载120启动并准备好正确配置，则影子工作负载110报告“准备就绪”状态。43.在项s2i，如果第二工作负载120存在但具有无法实时更改的错误配置，或者如果第二工作负载120存在但不健康，则影子工作负载110删除第二工作负载120。例程的稍后循环可以(重新)创建第二工作负载120。44.影子工作负载110可以在例程期间和/或外部向第二环境115一次或多次发送认证令牌。认证令牌指示影子工作负载110可以对第二工作负载120进行生命周期管理(例如，创建)。认证令牌可以是影子工作负载110在认证由影子工作负载110向第二环境115提供的凭证(诸如用户名和密码)之后存储的秘密。45.参照图3，示出了数据处理系统300的另一示例。图3中示出的示例数据处理系统300包括与图1中示出的对应元素相同或相似的若干元素。这些元素使用相同但以200递增的参考符号表示。46.在该示例中，第二环境315中的第二工作负载320提供电话功能并且在第一环境305中具有影子工作负载310。在该示例中，第一环境305包括另一工作负载325，该工作负载325不是影子工作负载而是“全功能”工作负载。在该示例中，其他工作负载325提供当与第二工作负载320提供的功能结合时允许数据处理系统300传递服务(诸如电话)的功能。因此，第一环境305实现了影子工作负载310和非影子全功能工作负载325两者的混合部署，这两者共存于第一环境305中并且可以由第一环境305中的公共部署协调层管理.47.参照图4，示出了数据处理系统400的另一示例。图4中示出的示例数据处理系统400包括与图3中示出的对应元素相同或相似的若干元素。这些元素使用相同但以100递增的参考符号表示。48.在该示例中，并且与图3中所示的示例数据处理系统300类似，第一环境405除了影子工作负载410之外还包括另一工作负载430。然而，在示例数据处理系统300中，另一工作负载325是提供电话功能的非影子、全功能工作负载，此示例中的另一工作负载430不提供电话功能并且是第二工作负载420的影子工作负载。因此，在此示例中，影子工作负载410、430两者在第一环境405中对第二工作负载420进行生命周期管理。第一环境405中的工作负载410、430中的一个可以执行与另一未被配置为执行的第二工作负载420相关的生命周期管理操作。这种生命周期管理操作的示例是响应于满足删除条件(诸如第一影子工作负载410不再用于对第二工作负载420进行生命周期管理)而使第二工作负载420被删除。49.参照图5，示出了数据处理系统500的另一示例。图5中示出的示例数据处理系统500包括与图4中示出的对应元素相同或相似的若干元素。这些元素使用相同但以100递增的参考符号表示。50.在该示例中，并且与图4所示的示例数据处理系统400类似，第一环境505包括第一工作负载510和另一影子工作负载535。然而，在示例数据处理系统400中，另一影子工作负载430对第二工作负载430进行生命周期管理，本示例中的另一影子工作负载535对在本示例中位于第二环境515中的又一工作负载540进行生命周期管理。第二环境515中的工作负载520、540可以具有与彼此相同的功能，或者可以具有不同的功能。因此，在该示例中，因为第一环境505中的工作负载510、535不对除了第二环境515中它们各自对应的工作负载520、540之外的任何工作负载进行生命周期管理，所以第一环境505中的影子工作负载510、535与第二环境515中的对应工作负载520、540之间存在一对一的映射。51.参照图6，示出了数据处理系统600的另一示例。图6中示出的示例数据处理系统600包括与图5中示出的对应元素相同或相似的若干元素。这些元素使用相同但以100递增的参考符号表示。52.在该示例中，并且与图5中所示的示例数据处理系统500类似，第一环境605包括第一工作负载610和另一影子工作负载645。然而，在示例数据处理系统500中，另一影子工作负载535对第二环境515中的又一工作负载540进行生命周期管理，本示例中的另一影子工作负载645对本示例中与第一环境605和第二环境615不同的第三环境655中的又一工作负载650进行生命周期管理。因此，在该示例中，第一环境605外部的多个环境615、655中的工作负载由第一环境605中的部署协调层管理。这与针对第二环境615和第三环境655中的每个编写特定于环境的协调器的实现形成对比。即使一些码对于这两种特定于环境的协调器都是通用的，但大量特定于环境的码仍可用于每个环境。53.参照图7，显示了数据处理系统700的另一示例。图7中所示的示例数据处理系统700包括与一个或多个较早附图中所示的对应元素相同或相似的若干元素。这些元素使用相同但以100的倍数递增的参考符号表示。54.示例数据处理系统700在特定示例中实现环境间生命周期管理，在所述特定示例中，vm环境715中的vm 720、740-1、740-2形式的工作负载由kubernetes环境705中的kubernetes通过kubernetes环境705中的影子工作负载710、735-1、735-2进行管理。55.在该示例中，kubernetes环境705包括三个实体710、735-1、735-2，每个实体在图7中都标记为“vm管理器舱(manager pod)”。每个实体710、735-1、735-2表示一个kubernetes舱包括单个容器，进而包括单个容器化工作负载。基于上下文，这里对影子工作负载710、735-1、735-2的引用应视情况理解为包括对舱本身、容器和/或容器化工作负载的引用。特别地，因为舱是共享作为一个单元被管理的网络命名空间的一个或多个容器集，所以术语“舱”和“容器”几乎可以互换使用。56.kubernetes了解容器，但不了解vm。因此，kubernetes不直接管理vm 720、740-1、740-2，而是通过影子工作负载710、735-1、735-2管理vm 720、740-1、740-2。具体地，kubernetes对映射并传播到vm 720、740-1、740-2的影子工作负载710、735-1、735-2执行生命周期操作。kubernetes中的部署协调层可能不知道它通过影子工作负载710、735-1、735-2间接管理vm 720、740-1、740-2，甚至不知道vm存在720、740-1,740-2。57.为了使kubernetes能够以这种方式间接管理vm 720、740-1、740-2，创建有状态集(statefulset)对象755来管理影子工作负载710、735-1、735-2。有状态集对象755在kubernetes中用于管理有状态工作负载。还创建部署(deployment)对象760以管理单独的影子工作负载730，这将在下面更详细地描述。部署对象760在kubernetes中用于管理无状态工作负载。部署对象760通常比有状态集对象755更轻量并且可以优先于有状态集对象755用于无状态工作负载。在单独的影子工作负载730被实现为无状态工作负载的这个示例中，部署对象760的使用因此可以提供效率。58.有状态集对象755和部署对象760的手动配置可能相对耗时且繁重。在示例中，kubernetes运算符(operator)模型用于促进此类配置。在此示例中，这与添加新的服务器池(serverpool)对象765以及在kubernetes中为该池创建任何其他对象的码对应。在图7所示的示例kubernetes环境705中，服务器池对象765是本公开定义的新对象。有状态集对象755和部署对象760是具有自己的控制器的标准对象，并且默认情况下与kubernetes一起提供。可以使用kubernetes api添加新的服务器池对象765，该kubernetes api可以被扩展以添加新的对象和控制器。59.kubernetes管理影子工作负载710、735-1、735-2的创建、滚动升级、修复、缩放、删除等。在此示例中，每个影子工作负载710、735-1、735-2负责以一对一的对应关系对单个相应的vm 720、740-1、740-2进行生命周期管理，并被设计为使用最小逻辑。60.如上所述，影子工作负载逻辑可以简单地了解影子工作负载710、735-1、735-2对哪个vm 720、740-1、740-2进行生命周期管理，如果vm 720、740-1、740-2处于错误状态，则删除它们，如果vm 720、740-1、740-2不存在，则创建它们，和/或如果vm 720、740-1、740-2以正确的状态存在，则将它们的状态报告为“准备就绪”。影子工作负载710、735-1、735-2可以使用vm 720、740-1、740-2的vm标识符识别其进行生命周期管理的vm 720、740-1、740-2。每个影子工作负载710、735-1、735-2还负责获取有关其各自vm 720、740-1、740-2的信息，并将该信息暴露给kubernetes和/或在kubernetes环境705中运行的应用程序。例如，影子工作负载710、735-1、735-2可以报告它们各自的vm 720、740-1、740-2的版本和/或一旦它们各自的vm 720、740-1、740-2准备好就可以报告“准备就绪”。61.如果在影子工作负载710、735-1、735-2进行生命周期管理的vm 720、740-1、740-2已经存在并且vm 720、740-1、740-2已经在正确的状态时创建影子工作负载710、735-1、735-2(例如，当kubernetes检测到影子工作负载710、735-1、735-2故障并重新创建影子工作负载710、735-1、735-2)，影子工作负载710、735-1、735-2可能没做什么。62.在一些情况下，影子工作负载710、735-1、735-2的删除或故障可能导致删除其相应的vm 720、740-1、740-2。集群故障(换言之，所有影子工作负载710、735-1、735-2的故障)可能因此导致丢失所有vm 720、740-1、740-2。63.在此示例中，vm不会被有状态集对象755中的影子工作负载710、735-1、735-2删除。相反，删除由部署对象760中的单独影子工作负载730来执行，该单独影子工作负载730由图7中的标签“收割器(reaper)舱”指示，在本文中称为“收割器影子工作负载”。收割器影子工作负载730的逻辑也可以被设计为具有有限的复杂性，即例如通过确定来自服务器池对象765的vm 720、740-1、740-2的状态应该是什么来找到不应该存在的任何被管理的vm 720、740-1、740-2并去除它们。收割器影子工作负载730在kubernetes中特别有效，kubernetes是一个快速故障的环境，其中，在所述环境中影子工作负载710、735-1、735-2预计会故障，但可以在故障后迅速再次启动。收割器影子工作负载730也可以在集群发生故障、重新启动并通过删除现有的vm 720、740-1、740-2、现在未使用的vm 720、740-1、740-2来创建与重新启动的影子工作负载710、735-1、735-2对应的另一vm集(未示出)的情况下有效。在示例中，当删除服务器池对象765时，kubernetes给收割器影子工作负载730时间来删除所有vm 720、740-1、740-2。64.因此，在该示例中，存在单个对象(即服务器池对象765)，它在kubernetes环境705中具有声明性配置。当创建服务器池对象765时，vm 720、740-1、740-的整个池已创建并保持最新。对服务器池对象765的配置的改变例如通过缩放和/或滚动更新自动反映在vm 720、740-1、740-2中。65.如上所述，示例生命周期管理事件是创建事件。影子工作负载710、735-1、735-2可以逐一创建，使得它们每个都具有“已创建”生命周期管理状态。因为影子工作负载710、735-1、735-2的创建映射到由vm 720、740-1、740-2各自的影子工作负载710、735-1、735-2正在逐一创建的vm 720、740-1、740-2，所以“已创建”生命周期管理状态将在vm环境715中被镜像。在创建之后，vm 720、740-1、740-2也处于“已创建”生命周期管理状态。66.另一示例生命周期管理事件是扩展。在此示例中，正如创建一样，可以添加额外的影子工作负载，从而产生额外的vm。67.另一示例生命周期管理事件是去除影子工作负载的缩减事件或删除事件。在该示例中，由于以下情况，所以收割器影子工作负载730负责删除vm 720、740-1、740-2：因为vm 720,740-1,740-2应该被删除，或者因为例如影子工作负载被分配了更高的内存阈值或发生了节点错误情况，所以影子工作负载710、735-1、735-2不能容易地确定它是否正在被关闭。缩减可以被认为具有两个部分。首先，随着有状态集对象755被重新配置，影子工作负载710、735-1、735-2被去除。其次，收割器影子工作负载730在重新配置收割器影子工作负载730时去除vm 720、740-1、740-2。保持配置和有状态集对象755一致是提供服务器池对象765和运算符的原因。68.另一示例生命周期事件是康复事件。在此示例中，故障的影子工作负载710、735-1、735-2被kubernetes替换，故障的vm 720、740-1、740-2被检测到并被其影子工作负载710、735-1、735-2替换。69.另一示例生命周期管理事件是升级事件或修改事件。在此示例中，影子工作负载710、735-1、735-2可以逐一替换，因此它们会连续关闭并使用更新的配置被重新创建。kubernetes具有仅在先前的影子应用报告“准备就绪”时(换言之，当它们完成了它们映射的工作负载所需要的一切时)执行替换的智能。这种滚动升级或替换是在例如openstack中默认不存在的默认的kubernetes特征。图7中仅示出了单个vm环境715、单个服务器池对象765和三个vm 720、740-1、740-2。然而，在其他示例中这些元素中的任何一个都可以有不同数量。图7中的箭头示出了控制权和所有权。kubernetes内的控制表示运行在kubernetes中的控制器基于高级别对象的声明式配置来管理(包括创建、删除、缩放、滚动升级等)低级别对象。70.在示例中，尽管影子工作负载710、735-1、735-2被参数化，有状态集对象755中的所有影子工作负载710、735-1、735-2也具有彼此相同的规范，使得例如第三影子工作负载735-2可以确定它是第三影子工作负载735-2。71.不同的应用可以逐一迁移(例如从vm环境715迁移到kubernetes环境705)，这种迁移是在应用级别执行的。例如，三个不同的应用，每个具有多个vm，在kubernetes环境705中可以具有三个相应的服务器池设置来管理它们。一个应用可以通过去除与该应用对应的整个服务器池设置并将该服务器池设置替换为在kubernetes环境705中运行的本机对象来迁移到kubernetes，其中，kubernetes管理整个迁移处理中的工作负载。72.以上实施例应理解为说明性示例。设想了进一步的实施例。73.在上述示例中，被管理的工作负载是vm。然而，本文描述的技术可以扩展到管理其他类型的工作负载。例如，本文描述的技术可以应用于其他云技术和/或物理服务器。对于物理服务器，影子工作负载可能无法删除或创建物理服务器，但可以验证物理服务器是否存在，如果物理服务器不健康，可以重新启动该物理服务器，可以使用其他方法(诸如ansible脚本)来执行滚动状态改变，和/或可以使用自动化物理服务器部署平台(例如“金属即服务(metal as a service)”)。74.上述示例涉及基于容器的vm生命周期管理。如果有理由利用这种生命周期管理，本文描述的技术可以扩展到任何速度较慢、规模更大的技术的基于容器的生命周期管理，甚至是另一种技术对一种技术的生命周期管理。75.可以使用新服务器池对象中的声明性配置添加gitops和/或持续集成/持续交付(ci/cd)集成，以自动将状态推出到部署协调层。76.与本文描述的那些技术相似的技术可以用于在一个环境中、在另一容器环境中复制容器。然而，如上所述，这可能不如跨环境生命周期管理有效。77.可以提供影子工作负载的智能和逻辑复杂性与它们周围的框架之间的不同平衡以促进这一点。例如，影子工作负载可以实现所需的逻辑以在内部翻译命令和信息，或者可以利用任一(或两个)环境中提供的服务来执行此类翻译。78.在上述示例中，影子工作负载与其他工作负载一一对应。这使得影子工作负载在逻辑上被设计得相对简单。影子工作负载可以具有一对多映射，但这可能会将协调挑战转移到影子工作负载，从而增加复杂性并降低粒度，尤其是在影子工作负载相对容易启动的情况下，几乎没有任何好处，。一个影子工作负载可能管理一对主动-备用工作负载，但在影子工作负载中可能需要另外的逻辑来报告一个工作负载的故障而不是另一个工作负载的故障，以避免共同命运的情况。79.上述示例主要涉及kubernetes。在其他示例中，可以使用替代的容器化环境(诸如docker swarm和mesos)。80.应当理解，针对任一实施例所描述的任何特征可以单独使用，也可以与所描述的其他特征组合使用，也可以与任何其他实施例的一个或多个特征组合使用，或者任意组合使用任何其他实施例。此外，在不脱离由所附权利要求限定的本发明的范围的情况下，也可以采用以上未描述的等同和修改。









图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!




内容声明：本文中引用的各种信息及资料（包括但不限于文字、数据、图表及超链接等）均来源于该信息及资料的相关主体（包括但不限于公司、媒体、协会等机构）的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理！本站为非盈利性质站点,发布内容不收取任何费用也不接任何广告!




免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理，本文部分文字与图片资源来自于网络，部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!的,若有来源标注错误或侵犯了您的合法权益，请立即通知我们，情况属实，我们会第一时间予以删除，并同时向您表示歉意,谢谢!