Cloud platform version upgrade method, device and electronic device

Abstract

The present disclosure provides a method, apparatus, and electronic device for cloud platform version upgrade, relating to the technical field of cloud platforms. The specific steps are as follows: scheduling a first container group to be updated to a public cloud platform through a virtual node and generating a scheduling result; creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated; scheduling a second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, and upgrading the control plane components and node components in the core cloud platform according to the target version information. The present disclosure realizes the upgrade of node components and container components in the public cloud platform by the core cloud platform through virtual nodes, realizes the decoupling between the core cloud platform and the public cloud platform, avoids the version compatibility dependencies between the control plane components and the node components, and improves the efficiency of cloud platform version upgrade.

Description

Technical Field

[0001] The present disclosure relates to the technical field of cloud platforms, and particularly to a method, device, and electronic device for upgrading cloud platform versions. Background Art

[0002] The Kubernetes (abbreviated as K8S) cluster is an open-source container group orchestration and management engine used to manage containerized applications on multiple hosts in a cloud platform, providing a mechanism for application deployment planning, update, and maintenance.

[0003] In the related art, in a hybrid cloud architecture, the node components to be upgraded are located on the core cloud platform and the public cloud platform respectively. If the version of the node components on the public cloud is too high compared to the version of the node components on the core cloud, it will cause the running status of the container groups scheduled to the public cloud platform to be abnormal. The current upgrade method has low efficiency and cannot meet the high-efficiency requirements in actual production. Summary of the Invention

[0004] The present disclosure provides a method, device, and electronic device for upgrading cloud platform versions. The technical solution of the present disclosure is as follows:

[0005] According to the first aspect of the embodiments of the present disclosure, a method for upgrading cloud platform versions is provided, including:

[0006] Scheduling a first container group to be updated to the public cloud platform through a virtual node and generating a scheduling result, where the scheduling result includes node component version upgrade information;

[0007] In response to the scheduling result being a successful scheduling, creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated;

[0008] Scheduling a second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, and upgrading the control plane components and node components in the core cloud platform according to the target version information.

[0009] Optionally, the step of scheduling the first container group to be updated to the virtual node specifically includes:

[0010] Obtaining the resource types and resource tags declared by the public cloud platform, and obtaining the resource specifications of the first container group to be updated;

[0011] Matching the resource types and resource tags with the resource specifications to determine the public cloud platform that matches the first container group to be updated;

[0012] Schedule the first container group to be updated to a matching public cloud platform through the virtual node.

[0013] Optionally, the step of creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane component in the core cloud platform and the target version information of the first container group to be updated specifically includes:

[0014] Determine the configuration in the version information of the management plane component in the core cloud that is different from the target version information of the first container group to be updated as the target configuration;

[0015] Create the first node component on the public cloud platform according to the target version information, and cause the first node component to create a first container group instance according to the target configuration;

[0016] Send the node component status and container group status on the public cloud platform to the core cloud.

[0017] Optionally, after the step of scheduling the second container group to be updated managed by the node component in the core cloud platform to the public cloud platform, further includes:

[0018] Create a node component consistent with the target version in the public cloud platform.

[0019] Optionally, after the step of upgrading the control plane component and the node component in the core cloud platform according to the target version information, further includes:

[0020] Schedule the second container group to be updated in the public cloud platform back to the core cloud platform.

[0021] According to the second aspect of the embodiments of the present disclosure, a cloud platform version upgrade device is provided, including:

[0022] A scheduling module, configured to schedule a first container group to be updated to a public cloud platform through a virtual node and generate a scheduling result, where the scheduling result includes node component version upgrade information;

[0023] A public cloud platform upgrade module, configured to, in response to the scheduling result being a successful scheduling, create a first node component and a first container group instance on the public cloud platform according to the version information of the management plane component in the core cloud platform and the target version information of the first container group to be updated;

[0024] A core cloud platform upgrade module, configured to schedule the second container group to be updated managed by the node component in the core cloud platform to the public cloud platform and upgrade the control plane component and the node component in the core cloud platform according to the target version information.

[0025] Optionally, the scheduling module specifically includes:

[0026] A type acquisition sub-module, configured to acquire the resource types and resource tags declared by the public cloud platform, and acquire the resource specifications of the first container group to be updated;

[0027] A matching sub-module, configured to match the resource types and resource tags with the resource specifications to determine the public cloud platform that matches the first container group to be updated;

[0028] A scheduling sub-module, configured to schedule the first container group to be updated to the matching public cloud platform through the virtual node.

[0029] Optionally, the public cloud platform upgrade module includes:

[0030] A target configuration determination sub-module, configured to determine the configuration that is different from the target version information of the first container group to be updated in the version information of the management plane components in the core cloud as the target configuration;

[0031] A container group creation sub-module, configured to create the first node component on the public cloud platform according to the target version information, and cause the first node component to create a first container group instance according to the target configuration;

[0032] A status notification sub-module, configured to send the node component status and container group status on the public cloud platform to the core cloud platform through the virtual node.

[0033] Optionally, the device further includes:

[0034] A node component creation sub-module, configured to create a node component that is consistent with the target version in the public cloud platform.

[0035] Optionally, the device further includes:

[0036] A scheduling sub-module, configured to schedule the second container group to be updated in the public cloud platform back to the core cloud platform.

[0037] According to a third aspect of the embodiments of the present disclosure, there is provided an electronic device, including:

[0038] A processor;

[0039] A memory for storing executable instructions of the processor;

[0040] Wherein, the processor is configured to execute the instructions to implement the method according to any one of the first aspect.

[0041] According to a fourth aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium, which enables an electronic device to execute the method according to any one of the first aspect when the instructions in the storage medium are executed by a processor of the electronic device.

[0042] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:

[0043] The present disclosure realizes the upgrade of node components and container components in the public cloud platform by the core cloud platform through virtual nodes, realizes the decoupling between the core cloud platform and the public cloud platform, avoids the version compatibility dependencies between the control plane components and the node components, and improves the efficiency of cloud platform version upgrade.

[0044] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure, and do not constitute an improper limitation of the present disclosure.

[0046] Figure 1 is a flowchart of a method for upgrading a cloud platform version shown according to an exemplary embodiment.

[0047] Figure 2 is a flowchart of a method for upgrading a cloud platform version shown according to an exemplary embodiment.

[0048] Figure 3 is a flowchart of a method for upgrading a cloud platform version shown according to an exemplary embodiment.

[0049] Figure 4 is a block diagram of a device for upgrading a cloud platform version shown according to an exemplary embodiment.

[0050] Figure 5 is a block diagram of a device shown according to an exemplary embodiment.

[0051] Figure 6 is a block diagram of a device shown according to an exemplary embodiment. DETAILED DESCRIPTION

[0052] In order to enable those of ordinary skill in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0053] It should be noted that the terms "first", "second", etc. in the description, claims and above-mentioned drawings of the present disclosure are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described here can be implemented in an order other than those illustrated or described here. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0054] To better understand the solutions provided in the embodiments of the present disclosure, the following first introduces some related technologies involved in the embodiments of the present disclosure:

[0055] Pod (Container Group): The smallest deployable unit in the K8s system. A container group represents an independent running instance in the K8s system, which may consist of a single container group or several coupled containers. The K8s system may include multiple nodes, and each node may run one or more container groups.

[0056] Master Node: The machine that controls the Kubernetes nodes and is also the place where job tasks are created.

[0057] Node: These machines execute the assigned tasks under the control of the Kubernetes master node.

[0058] A hybrid cloud is a cloud computing environment that combines on-premises infrastructure (usually a private cloud) with a public cloud. A hybrid cloud includes a mixture of internal systems (or private clouds) and third-party public cloud services.

[0059] There are mainly two forms of the existing hybrid cloud construction methods. One is that each cloud in the hybrid cloud independently schedules its own resources, and the global resource management is completed through a management module independent of each cloud. The global resource scheduling decision of the hybrid cloud is completed through a scheduler independent of each cloud, and then the scheduling results are allocated to each cloud, and each cloud independently executes the scheduling results. The other is to select a certain cloud in the hybrid cloud as the core cloud, and other clouds report resource and status information to it, and it conducts unified scheduling. The former hybrid cloud architecture is relatively complex, and the latter implementation is the currently popular hybrid cloud architecture. In the latter implementation, Kubernetes is usually adopted as the hybrid cloud application orchestration and scheduling platform in the core cloud. When the core cloud schedules a Pod to the public cloud, a service will be created on the public cloud to manage the Pod, and this service will use native Kubernetes Node components such as kubelet and kube-proxy to achieve the same functional form and characteristics as the native Pod. With the rapid evolution of the community Kubernetes version, there will be more upgrade requirements for Kubernetes and Node components such as kubelet and kubelet-porxy on the public cloud in this type of hybrid cloud.

[0060] Currently, the small version rolling upgrade method is commonly used for the version upgrade of the hybrid cloud in this architecture. If the difference between the small versions of the native Kubernetes control platform components and between the Node components and the control platform components is small, Kubernetes can ensure the compatibility between components. The small version upgrade method is designed based on this premise.

[0061] Currently, under this hybrid cloud architecture, the Node components that need to be upgraded are located in the core cloud and the public cloud. If the upgrade version of the Kubernetes management node has too large a span, it will cause the Node components on the public cloud and the management components to be unable to cooperate. If the version of the Node components on the public cloud after upgrade is too high compared to the version of the Kubernetes management components on the core cloud, it will cause the running status of the Pods scheduled to the public cloud to be abnormal.

[0062] First, upgrade the version of the Kubernetes control platform components, requiring that the version difference between the node components and container groups in the public cloud platform and the core cloud platform is within a reasonable range. Therefore, when a large version span upgrade is required (such as upgrading from version 1.2.1 to 1.2.5), it is necessary to upgrade the node components and container groups in the public cloud platform and the core cloud platform alternately, which is also called rolling upgrade, and such upgrade efficiency is relatively low.

[0063] The number of node components in a hybrid cloud is relatively large. If the gap between the current version of Kubernetes and the version to which it is expected to be upgraded is large, the process of rolling upgrade of minor versions is complex, with a huge workload and poor feasibility. In the case of a large number of hybrid clouds, the disadvantages of this upgrade method will be more obvious.

[0064] Figure 1 It is a flowchart of a cloud platform upgrade method shown according to an exemplary embodiment, as Figure 1 shown, and the method includes the following steps.

[0065] Step 101, schedule the first container group to be updated to the public cloud platform through a virtual node and generate a scheduling result, where the scheduling result includes node component version upgrade information;

[0066] In this embodiment, a certain cloud platform in the hybrid cloud is used as the core cloud platform, and other cloud platforms are used as public cloud platforms. The public cloud platforms report resource and status information to the core cloud platform, and the core cloud platform uniformly schedules other public cloud platforms. The resource scheduling of the hybrid cloud is implemented by the scheduler component in the core cloud platform. In this embodiment, the public cloud resource scheduling component in the hybrid cloud is abstracted as a virtual node, virtual node, of the Kubernetes platform in the core cloud. Each public cloud platform corresponds to one or more virtual nodes. When scheduling a container group, the hybrid cloud resource scheduling component can determine the most suitable public cloud platform based on the resource types and labels declared by the public cloud platform corresponding to the virtual node, and can schedule the first container group to be updated to the most suitable public cloud platform through the virtual node. Each virtual node will start the corresponding management program to obtain the scheduling result information of the first container group to be updated from the control plane component.

[0067] Among them, the Kubernetes control plane consists of the Kubernetes application programming interface service API Server, the distributed etc directory (etcd) database, the controller manager, the scheduler, and any other controllers that may exist in the cloud environment.

[0068] Step 102, in response to the scheduling result being a successful scheduling, create a first node component and a first container group instance on the public cloud platform according to the version information of the management plane component in the core cloud platform and the target version information of the first container group to be updated.

[0069] In this embodiment, after the hybrid cloud starts the upgrade process, if the scheduling result is successful scheduling, it means that a new first container group to be updated is scheduled to the virtual node. The hypervisor started by the virtual node will communicate with the core cloud platform. If the core cloud platform sends an instruction indicating that the public cloud platform corresponding to the current virtual node is to execute the task of creating the first container group to be updated, then the upgrade of the node components on the public cloud platform can be started. The virtual node compares the version information of the management plane components currently used in the core cloud platform with the target version information configured in the first container group to be updated to determine the target configuration that can operate normally on the public cloud platform after the upgrade, and creates new first node components and first container group instances according to the target configuration.

[0070] Step 103: Schedule the second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, and upgrade the control plane components and node components in the core cloud platform according to the target version information.

[0071] In this embodiment, after upgrading the node components on the public cloud platform, the management plane components and node components on the core cloud platform are upgraded. To ensure the normal processing of tasks by the cloud platform, the second container group to be updated managed by the node components in the core cloud platform needs to be scheduled to the public cloud platform, and then the control plane components and node components in the core cloud platform are upgraded to the versions corresponding to the target version information.

[0072] Figure 2 is a flowchart of a cloud platform upgrade method shown according to an exemplary embodiment, as Figure 2 shown, Figure 1 The specific steps of step 101 in

[0073] Step 201: Obtain the resource types and resource labels declared by the public cloud platform, and obtain the resource specifications of the first container group to be updated;

[0074] Step 202: Match the resource types and resource labels with the resource specifications to determine the public cloud platform that matches the first container group to be updated;

[0075] In this embodiment, the resource types and resource labels represent the resource types and resource sizes supported by the public cloud platform, such as CPU resources and the size of CPU resources; memory resources and the size of memory resources, etc. Only when the public cloud platform meets the resource specifications of the first container group to be updated can the first container group to be updated operate normally on the public cloud platform.

[0076] Step 203: Schedule the first container group to be updated to the matching public cloud platform through the virtual node.

[0077] Figure 3 is a flowchart of a cloud platform upgrade method shown according to an exemplary embodiment, as Figure 3 shown, Figure 1 Step 102 in

[0078] Step 301: Determine the configuration in the version information of the management plane components in the core cloud that is different from the target version information of the first container group to be updated as the target configuration.

[0079] In this embodiment, the virtual node compares the version information of the management plane components in the core cloud with the target version information of the first container group to be updated. Specifically, it obtains the first configuration list corresponding to the target version information of the first container group to be updated and the second configuration list corresponding to the version information of the management plane components in the core cloud. The configuration list is the various configurations of the container groups and other control components in the cloud platform for each version. By comparing the first configuration list and the second configuration list, the configuration in the first configuration list that is different from the second configuration list is determined as the target configuration. When updating, only the target configuration needs to be added to the original configuration.

[0080] Step 302: Create the first node component on the public cloud platform according to the target version information, and let the first node component create the first container group instance according to the target configuration;

[0081] Step 303: Send the node component status and container group status on the public cloud platform to the core cloud platform through the virtual node.

[0082] In this embodiment, after creating the first node component and the first container group instance, the upgrade of the node components and container groups on the public cloud platform is completed. During the operation of the first node component and the first container group instance, the core cloud platform needs to monitor them. The node component status and container group status on the public cloud platform are reported to the core cloud platform through the virtual node corresponding to the public cloud platform for the core cloud platform to make management decisions.

[0083] In a possible embodiment, for the existing running node components and container groups in the public cloud platform, they cannot be directly upgraded. The hybrid cloud scheduling component deletes them and then creates the container groups of the target version again on other public cloud platforms to complete the upgrade.

[0084] Through this implementation, the virtual node realizes the creation of the first node component and the first container group instance of the latest version that can run normally without upgrading the version of the core cloud platform, decouples the upgrade of the core cloud platform from the upgrade of the public cloud platform, and improves the efficiency of cloud platform version update.

[0085] Optionally, after the step of scheduling the second container group to be updated in the node component management in the core cloud platform to the public cloud platform in step 103, the following steps are further included:

[0086] Create node components consistent with the target version in the public cloud platform.

[0087] In this embodiment, since the virtual node decouples the upgrade of the node components in the core cloud platform from the upgrade of the node components in the public cloud platform, there is no need to consider the compatibility between the node components in the core cloud platform and the node components in the public cloud platform during the upgrade. The node components in the public cloud platform can be upgraded to a higher version before upgrading the node components in the core cloud platform. After scheduling the second container group to be updated in the node component management in the core cloud platform to the public cloud platform, create node components consistent with the target version in the public cloud platform to manage the second container group to be updated.

[0088] Optionally, after the step of upgrading the control plane components and node components in the core cloud platform according to the target version information in step 103, the following steps are further included:

[0089] Schedule the second container group to be updated in the public cloud platform back to the core cloud platform.

[0090] In this embodiment, when upgrading the control plane components and node components in the core cloud platform according to the target version information, since the second container group to be updated in the core cloud platform is scheduled to the public cloud at this time, there is no need to consider the compatibility between the control plane components and node components and the container group when updating the control plane components and node components. Batch upgrades with a large version span can be performed on them, improving the upgrade efficiency of the core cloud platform.

[0091] Figure 4 It is a block diagram of a cloud platform upgrade device shown according to an exemplary embodiment. Refer to Figure 4 , the device includes:

[0092] A scheduling module 410, configured to schedule the first container group to be updated to the public cloud platform through a virtual node and generate a scheduling result, where the scheduling result includes node component version upgrade information;

[0093] A public cloud platform upgrade module 420, configured to, in response to the scheduling result being a successful scheduling, create a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated;

[0094] The core cloud platform upgrade module 430 is used to schedule the second container group to be updated in the node component management of the core cloud platform to the public cloud platform, and upgrade the control plane components and node components in the core cloud platform according to the target version information.

[0095] Optionally, the scheduling module 410 specifically includes:

[0096] A type acquisition sub-module, which is used to acquire the resource types and resource labels declared by the public cloud platform, and acquire the resource specifications of the first container group to be updated;

[0097] A matching sub-module, which is used to match the resource types and resource labels with the resource specifications to determine the public cloud platform that matches the first container group to be updated;

[0098] A scheduling sub-module, which is used to schedule the first container group to be updated to the matching public cloud platform through the virtual node.

[0099] Optionally, the public cloud platform upgrade module 420 includes:

[0100] A target configuration determination sub-module, which is used to determine the configuration in the version information of the management plane components in the core cloud that is different from the target version information of the first container group to be updated as the target configuration;

[0101] A container group creation sub-module, which is used to create the first node component on the public cloud platform according to the target version information, and make the first node component create a first container group instance according to the target configuration;

[0102] A status notification sub-module, which is used to send the node component status and container group status on the public cloud platform to the core cloud platform through the virtual node.

[0103] Optionally, the device further includes:

[0104] A node component creation sub-module, which is used to create node components that are consistent with the target version in the public cloud platform.

[0105] Optionally, the device further includes:

[0106] A scheduling sub-module, which schedules the second container group to be updated in the public cloud platform back to the core cloud platform.

[0107] Regarding the device in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0108] Figure 5FIG. 0 is a block diagram of an apparatus 800 according to an exemplary embodiment. For example, the apparatus 800 can be a computer, a digital broadcast terminal, a messaging device, a personal digital assistant, etc.

[0109] Referring Figure 5 to FIG. 5, the apparatus 800 may include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input / output (I / O) interface 812, a sensor component 814, and a communication component 816.

[0110] The processing component 802 generally controls the overall operation of the apparatus 800, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above-described methods. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0111] The memory 804 is configured to store various types of data to support the operation of the device 800. Examples of such data include instructions for any application or method operating on the apparatus 800, contact data, phone book data, messages, pictures, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a disk, or an optical disk.

[0112] The power component 806 provides power to the various components of the apparatus 800. The power component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the apparatus 800.

[0113] The multimedia component 808 includes a screen that provides an output interface between the device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of a touch or swipe action but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.

[0114] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC) that is configured to receive external audio signals when the device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, the audio component 810 further includes a speaker for outputting audio signals.

[0115] The I / O interface 812 provides an interface between the processing component 802 and a peripheral interface module, which can be a keyboard, a click wheel, buttons, etc. These buttons can include but are not limited to: a home button, a volume button, a power button, and a lock button.

[0116] The sensor component 814 includes one or more sensors for providing an assessment of the various aspects of the state of the device 800. For example, the sensor component 814 can detect the on / off state of the device 800, the relative positioning of components, such as the display and the keypad of the device 800, the sensor component 814 can also detect a change in the position of the device 800 or a component of the device 800, the presence or absence of user contact with the device 800, the orientation or acceleration / deceleration of the device 800, and the temperature change of the device 800. The sensor component 814 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor component 814 can also include a light sensor, such as a CMOS or a CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 814 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0117] The communication component 816 is configured to facilitate communication, either wired or wirelessly, between the device 800 and other devices. The device 800 may access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0118] In an exemplary embodiment, the device 800 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above-described method.

[0119] In an exemplary embodiment, a storage medium including instructions is also provided, such as the memory 804 including instructions that may be executed by the processor 820 of the device 800 to complete the above-described method. Optionally, the storage medium may be a non-transitory computer-readable storage medium. For example, the non-transitory computer-readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, among others.

[0120] Figure 6 is a block diagram of a device 900 shown in accordance with an exemplary embodiment. For example, the device 900 may be provided as a server. Referring to Figure 6 , the device 900 includes a processing component 922, which further includes one or more processors, and memory resources represented by a memory 932 for storing instructions executable by the processing component 1922, such as application programs. The application programs stored in the memory 932 may include one or more modules each corresponding to a set of instructions. Additionally, the processing component 922 is configured to execute the instructions to perform the above-described method.

[0121] The device 900 may further include a power supply component 926 configured to perform power management of the device 900, a wired or wireless network interface 950 configured to connect the device 900 to a network, and an input / output (I / O) interface 958. The device 900 may operate based on an operating system stored in the memory 932, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, or the like.

[0122] Other embodiments of the present disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common general knowledge or conventional technical means in the technical field not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the present disclosure are pointed out by the following claims.

[0123] It should be understood that the present disclosure is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.

Claims

1. A method for upgrading the version of a cloud platform, characterized in that, including: Scheduling a first container group to be updated to a public cloud platform through a virtual node and generating a scheduling result, where the scheduling result includes node component version upgrade information; In response to the scheduling result being a successful scheduling, creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated; Scheduling a second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, and upgrading the control plane components and node components in the core cloud platform according to the target version information.

2. The method according to claim 1, wherein The step of scheduling the first container group to be updated to a virtual node specifically includes: Obtaining the resource types and resource tags declared by the public cloud platform, and obtaining the resource specifications of the first container group to be updated; Matching the resource types and resource tags with the resource specifications to determine the public cloud platform that matches the first container group to be updated; Scheduling the first container group to be updated to the matching public cloud platform through the virtual node.

3. The method according to claim 1, wherein The step of creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated specifically includes: Determining the configuration that is different from the target version information of the first container group to be updated in the version information of the management plane components in the core cloud as the target configuration; Creating the first node component on the public cloud platform according to the target version information, and causing the first node component to create a first container group instance according to the target configuration; Sending the node component status and container group status on the public cloud platform to the core cloud platform through the virtual node.

4. The method according to claim 1, wherein After the step of scheduling the second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, further including: Creating a node component consistent with the target version in the public cloud platform.

5. The method according to claim 1, wherein After the step of upgrading the control plane components and node components in the core cloud platform according to the target version information, further including: Scheduling the second container group to be updated in the public cloud platform back to the core cloud platform.

6. A cloud platform version upgrade device, characterized in that including: A scheduling module for scheduling a first container group to be updated to a public cloud platform through a virtual node and generating a scheduling result, where the scheduling result includes node component version upgrade information; A public cloud platform upgrade module for, in response to the scheduling result being a successful scheduling, creating a first node component and a first container group instance on the public cloud platform according to the version information of the management plane components in the core cloud platform and the target version information of the first container group to be updated; A core cloud platform upgrade module for scheduling a second container group to be updated managed by the node components in the core cloud platform to the public cloud platform, and upgrading the control plane components and node components in the core cloud platform according to the target version information.

7. The device according to claim 6, characterized in that, The scheduling module specifically includes: A type acquisition sub-module, configured to acquire the resource types and resource tags declared by the public cloud platform, and acquire the resource specifications of the first container group to be updated; A matching sub-module, configured to match the resource types and resource tags with the resource specifications to determine the public cloud platform that matches the first container group to be updated; A scheduling sub-module, configured to schedule the first container group to be updated to the matching public cloud platform through the virtual node.

8. The device according to claim 6, characterized in that, The public cloud platform upgrade module includes: A target configuration determination sub-module, configured to determine the configuration that is different from the target version information of the first container group to be updated in the version information of the management plane components in the core cloud as the target configuration; A container group creation sub-module, configured to create the first node component on the public cloud platform according to the target version information, and cause the first node component to create a first container group instance according to the target configuration; A status notification sub-module, configured to send the node component status and container group status on the public cloud platform to the core cloud platform through the virtual node.

9. The device according to claim 6, characterized in that, The device further includes: A node component creation sub-module, configured to create a node component that is consistent with the target version in the public cloud platform.

10. The device according to claim 6, characterized in that The device further includes: A scheduling sub-module, configured to schedule the second container group to be updated in the public cloud platform back to the core cloud platform.

11. An electronic device, characterized in that, including: a processor; a memory for storing executable instructions of the processor; wherein, the processor is configured to execute the instructions to implement the method according to any one of claims 1 to 5.

12. A computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enabling the electronic device to execute the method according to any one of claims 1 to 5.

Images