Container cluster firmware upgrading method and device and storage medium

Abstract

The invention relates to a container cluster firmware upgrading method and device and a storage medium. The method comprises the following steps: acquiring cluster firmware configuration information; based on the cluster firmware configuration information, determining one or more target nodes of to-be-upgraded firmware in the cluster and node firmware configuration information corresponding to each target node; and upgrading firmware on each target node on the basis of the node firmware configuration information of the target node. According to the embodiment of the invention, the firmware can be automatically upgraded in a cluster scene, so that the firmware upgrading in the cluster scene is easier, the error possibility is reduced, and the cluster availability is improved. In addition, different configuration information in different node pools in the cluster can be considered, and the specified node is upgraded based on the specified configuration information, so that the method and the device can be suitable for firmware management of different node pools, the requirement of a tenant isolation scene is met, and the method and the device have universality.

Description

Technical Field

[0001] The present disclosure relates to the technical field of firmware management, and in particular to a container cluster firmware upgrade method, device, and storage medium. Background Art

[0002] Firmware refers to the device "driver" stored inside the device. Through firmware, the operating system can implement the operation of a specific machine according to the standard device driver. For example, optical drives and burners have internal firmware. With the advent of the information age, it is difficult for manufacturers' designs to fully meet customer needs. More manufacturers provide users with more updated functions by upgrading firmware.

[0003] At present, most artificial intelligence (AI) applications are deployed in container clusters. During the use of node devices, it is inevitable to encounter the need to upgrade the firmware. However, there is currently a lack of universal firmware upgrade solutions for container cluster scenarios. At present, firmware upgrades in container clusters are usually implemented through manual management, which may lead to complex operations and prone to errors. In addition, it lacks universality for different node pools in the container cluster and cannot meet user needs. Summary of the invention

[0004] In view of this, the present disclosure proposes a container cluster firmware upgrade method, device and storage medium.

[0005] According to one aspect of the present disclosure, a container cluster firmware upgrade method is provided. The method includes:

[0006] Get cluster firmware configuration information;

[0007] Based on the cluster firmware configuration information, determine one or more target nodes in the cluster whose firmware is to be upgraded and the node firmware configuration information corresponding to each target node;

[0008] On each target node, the firmware on the target node is upgraded based on the node firmware configuration information of the target node.

[0009] In a possible implementation, the cluster firmware configuration information includes cluster firmware management configuration information and firmware configuration information. Based on the cluster firmware configuration information, determining one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node includes:

[0010] Determine one or more target nodes in the cluster whose firmware is to be upgraded based on the node field in the cluster firmware management configuration information;

[0011] Determine a general upgrade strategy in the node firmware configuration information corresponding to each target node based on the cluster firmware management configuration information;

[0012] Node firmware configuration information corresponding to each target node is determined based on the firmware configuration information, wherein the node firmware configuration information includes at least one of the following: a firmware file, a storage address of a firmware upgrade tool, and firmware upgrade process information.

[0013] In a possible implementation, the node firmware configuration information includes a storage address of a file for upgrading firmware, and upgrading the firmware on each target node based on the node firmware configuration information of the target node includes:

[0014] Set the target node to an unschedulable state. The unschedulable state is used to prevent the load on other nodes from being scheduled to the target node.

[0015] In response to completion of load execution or load migration on the target node, downloading a file for upgrading the firmware to the target node based on the storage address;

[0016] Upgrade the firmware on the target node based on the file;

[0017] In response to the firmware upgrade being completed, the target node is set to a schedulable state.

[0018] In a possible implementation, the node firmware configuration information further includes a preset load waiting time and a load eviction strategy, and upgrading the firmware on each target node based on the node firmware configuration information of the target node further includes:

[0019] In response to the waiting time for the preset type of load exceeding the preset load waiting time and the load is not executed completely, the load on the target node is migrated to other nodes based on the load eviction strategy.

[0020] In a possible implementation, the load eviction strategy further includes at least one eviction strategy, each eviction strategy corresponds to a different type of resources, and in response to the waiting time for a preset type of load exceeding a preset load waiting time, the load on the target node is migrated to another node based on the load eviction strategy, including:

[0021] In response to the waiting time for the preset type of load exceeding the preset load waiting time, based on the target eviction policy corresponding to the target type of resource, the load corresponding to the target type of resource on the target node is migrated to other nodes.

[0022] In a possible implementation, the node firmware configuration information further includes driver configuration information, and upgrading the firmware on the target node based on the file for upgrading the firmware includes:

[0023] In response to completion of load execution or load migration on the target node, downloading the driver file to the target node based on the driver configuration information;

[0024] Install the driver based on the driver file on the target node;

[0025] In response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0026] In a possible implementation, the node firmware configuration information further includes firmware upgrade switch information, and in response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware, further including:

[0027] In response to the driver installation being completed and in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0028] In one possible implementation, the node firmware configuration information also includes restart information and user-defined operation information. After the firmware on the target node is upgraded based on the file for upgrading the firmware, the target node restarts in response to the instruction of the restart information, and based on the user-defined operation information, the operation indicated in the user-defined operation information is performed on the target node.

[0029] In a possible implementation, the firmware upgrade switch information indicates that the firmware upgrade is enabled and the firmware versions are consistent, or, in response to the firmware upgrade switch information indicating that the firmware upgrade is not enabled, the firmware upgrade is confirmed to be complete.

[0030] In a possible implementation, setting the target node to an unschedulable state further includes:

[0031] In response to the driver not being correctly installed, setting the target node to an unschedulable state;

[0032] Alternatively, in response to the firmware version inconsistency, the target node is set to an unschedulable state.

[0033] According to another aspect of the present disclosure, a container cluster firmware upgrade device is provided. The device includes:

[0034] The acquisition module is used to obtain cluster firmware configuration information;

[0035] A determination module, used to determine one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node based on the cluster firmware configuration information;

[0036] The upgrade module is used to upgrade the firmware on each target node based on the node firmware configuration information of the target node.

[0037] In a possible implementation, the cluster firmware configuration information includes cluster firmware management configuration information and firmware configuration information, and the determination module is used to:

[0038] Determine one or more target nodes in the cluster whose firmware is to be upgraded based on the node field in the cluster firmware management configuration information;

[0039] Determine a general upgrade strategy in the node firmware configuration information corresponding to each target node based on the cluster firmware management configuration information;

[0040] Node firmware configuration information corresponding to each target node is determined based on the firmware configuration information, wherein the node firmware configuration information includes at least one of the following: a firmware file, a storage address of a firmware upgrade tool, and firmware upgrade process information.

[0041] In a possible implementation, the node firmware configuration information includes a storage address of a file for upgrading the firmware, and an upgrade module for:

[0042] Set the target node to an unschedulable state. The unschedulable state is used to prevent the load on other nodes from being scheduled to the target node.

[0043] In response to completion of load execution or load migration on the target node, downloading a file for upgrading the firmware to the target node based on the storage address;

[0044] Upgrade the firmware on the target node based on the file;

[0045] In response to the firmware upgrade being completed, the target node is set to a schedulable state.

[0046] In a possible implementation, the node firmware configuration information also includes a preset load waiting time and a load eviction strategy, and the upgrade module is also used to:

[0047] In response to the waiting time for the preset type of load exceeding the preset load waiting time and the load is not executed completely, the load on the target node is migrated to other nodes based on the load eviction strategy.

[0048] In a possible implementation, the load eviction strategy further includes at least one eviction strategy, each eviction strategy corresponds to a different type of resources, and in response to the waiting time for a preset type of load exceeding a preset load waiting time, the load on the target node is migrated to another node based on the load eviction strategy, including:

[0049] In response to the waiting time for the preset type of load exceeding the preset load waiting time, based on the target eviction policy corresponding to the target type of resource, the load corresponding to the target type of resource on the target node is migrated to other nodes.

[0050] In a possible implementation, the node firmware configuration information further includes driver configuration information, and upgrading the firmware on the target node based on the file for upgrading the firmware includes:

[0051] In response to completion of load execution or load migration on the target node, downloading the driver file to the target node based on the driver configuration information;

[0052] Install the driver based on the driver file on the target node;

[0053] In response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0054] In a possible implementation, the node firmware configuration information further includes firmware upgrade switch information, and in response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware, further including:

[0055] In response to the driver installation being completed and in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0056] In one possible implementation, the node firmware configuration information also includes restart information and user-defined operation information. After the firmware on the target node is upgraded based on the file for upgrading the firmware, the target node restarts in response to the instruction of the restart information, and based on the user-defined operation information, the operation indicated in the user-defined operation information is performed on the target node.

[0057] In a possible implementation, the firmware upgrade switch information indicates that the firmware upgrade is enabled and the firmware versions are consistent, or, in response to the firmware upgrade switch information indicating that the firmware upgrade is not enabled, the firmware upgrade is confirmed to be complete.

[0058] In a possible implementation, setting the target node to an unschedulable state further includes:

[0059] In response to the driver not being correctly installed, setting the target node to an unschedulable state;

[0060] Alternatively, in response to the firmware version inconsistency, the target node is set to an unschedulable state.

[0061] According to another aspect of the present disclosure, a container cluster firmware upgrade device is provided, comprising: a processor; a memory for storing processor executable instructions; wherein the processor is configured to implement the above method when executing the instructions stored in the memory.

[0062] According to another aspect of the present disclosure, a non-volatile computer-readable storage medium is provided, on which computer program instructions are stored, wherein the computer program instructions implement the above method when executed by a processor.

[0063] According to another aspect of the present disclosure, a computer program product is provided, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above method.

[0064] According to the embodiment of the present application, by obtaining cluster firmware configuration information, the user's upgrade configuration requirements are met, and based on the cluster firmware configuration information, the node firmware configuration information of the node is determined to perform firmware upgrades, thereby realizing automated firmware upgrades in cluster scenarios, making firmware upgrades in cluster scenarios easier, reducing the possibility of errors, and improving cluster availability. And by determining one or more target nodes of the firmware to be upgraded in the cluster and the node firmware configuration information corresponding to each target node based on the cluster firmware configuration information, the firmware on each target node is upgraded based on the node firmware configuration information of the target node, and the difference in configuration information in different node pools in the cluster can be taken into account, and the specified node can be upgraded based on the specified configuration information, so that the present application can be applied to different node pools for firmware management, meeting the needs of tenant isolation scenarios, and having universality.

[0065] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0067] Figure 1 A schematic diagram showing an application scenario according to an embodiment of the present application.

[0068] Figure 2 A flowchart of a container cluster firmware upgrade method according to an embodiment of the present application is shown.

[0069] Figure 3 A flowchart of a container cluster firmware upgrade method according to an embodiment of the present application is shown.

[0070] Figure 4 A schematic diagram of a firmware upgrade process according to an embodiment of the present application is shown.

[0071] Figure 5 A structural diagram of a container cluster firmware upgrade device according to an embodiment of the present application is shown.

[0072] Figure 6 It is a block diagram of a device 1900 for upgrading container cluster firmware according to an exemplary embodiment. DETAILED DESCRIPTION

[0073] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0074] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0075] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present disclosure.

[0076] Firmware refers to the device "driver" stored inside the device. Through firmware, the operating system can implement the operation of a specific machine according to the standard device driver. For example, optical drives and burners have internal firmware. With the advent of the information age, it is difficult for manufacturers' designs to fully meet customer needs. More manufacturers provide users with more updated functions by upgrading firmware. At present, most AI applications are deployed in container clusters. During the use of node devices, it is inevitable to encounter situations where firmware upgrades are required. However, there is currently a lack of universal firmware upgrade solutions for container cluster scenarios. At present, firmware upgrades in container clusters are usually implemented through manual management, which may lead to complex and error-prone operations, and lack of universality for different node pools in container clusters, which cannot meet user needs.

[0077] In view of this, the present application provides a container cluster firmware upgrade method, device and storage medium. The container cluster firmware upgrade method of the embodiment of the present application satisfies the user's upgrade configuration requirements by obtaining cluster firmware configuration information, and determines the node firmware configuration information of the node based on the cluster firmware configuration information to perform firmware upgrade, thereby realizing the automatic upgrade of firmware in the container cluster scenario, making the firmware upgrade in the cluster scenario easier, reducing the possibility of errors, and improving cluster availability. And by determining one or more target nodes of the firmware to be upgraded in the cluster and the node firmware configuration information corresponding to each target node based on the cluster firmware configuration information, the firmware on each target node is upgraded based on the node firmware configuration information of the target node, and the different configuration information in different node pools in the cluster can be taken into account, and the specified node is upgraded based on the specified configuration information, so that the present application can be applied to different node pools for firmware management, meeting the needs of tenant isolation scenarios, and having universality.

[0078] Figure 1 A schematic diagram of an application scenario according to an embodiment of the present application is shown. The container cluster firmware upgrade system of the embodiment of the present application can be applied to the scenario of firmware upgrade in a Kubernetes (k8s for short) cluster, such as Figure 1 As shown, the container cluster firmware upgrade system of the embodiment of the present application may include an API server (k8s apiserver), a master node (master node), other nodes 1 to 3 (node-1 to 3) and a file server. Among them, the master node can be a non-business node, and may include a cluster firmware management configuration information processor (clusterconfig-controller) and a node firmware configuration information processor (nodeconfig-controller). Other nodes 1 to 3 may include a driver toolkit (driver-toolkit) and a kured component respectively.

[0079] The API server can be used to receive cluster firmware configuration information created by users, which includes cluster firmware management configuration information (clusterconfig) and firmware configuration information (firmwareconfig). The cluster firmware management configuration information and firmware configuration information can be CRD (custom resource definition) in Kubernetes.

[0080] The master node can listen to (Polling) the API server and obtain the cluster firmware management configuration information and firmware configuration information created by the user from the API server, wherein the cluster firmware management configuration information processor can determine the node firmware configuration information (nodeconfig, corresponding to node firmware configuration information 1 to 3 in the figure) for each node to be upgraded based on the cluster firmware management configuration information and the firmware configuration information, and the node firmware configuration information processor can send a request (for example, a gRPC request) to the driver toolkit on the corresponding node according to each node firmware configuration information, so as to perform a firmware upgrade on the corresponding node according to the node firmware configuration information. The node firmware configuration information can also be a CRD in kubernetes.

[0081] The file server may be a server based on the HTTP protocol, and may be used to store driver files, firmware files, firmware upgrade tools, firmware upgrade scripts, etc., which are used to upgrade the firmware.

[0082] During the firmware upgrade process, the driver toolkit on each node can download the required files from the file server for firmware upgrade. The kured component can be used to control the automatic restart of nodes in the cluster to ensure that the nodes can be restarted safely when necessary.

[0083] The following Figure 1 Based on this, the container cluster firmware upgrade method of the embodiment of the present application is introduced.

[0084] Figure 2 A flowchart of a container cluster firmware upgrade method according to an embodiment of the present application is shown. The method can be used in the above container cluster firmware upgrade system, such as Figure 2 As shown, the method includes:

[0085] Step S201, obtaining cluster firmware configuration information.

[0086] The cluster firmware configuration information may be created by a user and may include cluster firmware management configuration information and firmware configuration information.

[0087] The cluster firmware management configuration information may represent the overall configuration at the cluster level, and the cluster firmware management configuration information may include a general upgrade policy (UpgradePolicy) field and a node (Nodes) field, and the field represents user-configurable options in the cluster firmware management configuration information.

[0088] The General Upgrade Policy field can include:

[0089] The waitForCompletion field is used to set the time to wait for the execution of a preset type of load before performing a firmware upgrade. In the waitForCompletion field, you can set the time to wait for the corresponding load to execute before performing a firmware upgrade. For example, you can set the time to wait for the load with the label "app=xxx". For some training tasks, this field can be used to wait for the training task to complete before performing a firmware upgrade.

[0090] The special load eviction (devicePodDeletion) field is used to evict pods (loads) that use special types of devices (such as graphics processors GPUs, sriov devices, etc.) on the node to migrate the loads to other nodes. You can configure the eviction policy for special types of loads in this field, such as (drain policy in k8s).

[0091] The Drain field is used to evict common loads (other than special loads) from a node to migrate the loads to other nodes. You can configure the eviction policy for common loads in this field. Since you generally need to restart the node after upgrading the device firmware, which will affect the operation of the load on the node, you can migrate the load on the node through the devicePodDeletion field and the Drain field.

[0092] The autoUpgrade field is used to indicate whether automatic firmware upgrade is enabled. When this field is false, it means that automatic firmware upgrade is not enabled, and the firmware upgrade on the node will not be started.

[0093] The maxParallelUpgrades field is used to indicate the number of nodes in the cluster that can be upgraded simultaneously. This field can be used to control the overall speed of firmware upgrades in the cluster.

[0094] The node field can be used to set firmware in each node pool to achieve tenant isolation during the firmware upgrade process. The node pool can be divided through the selector field. In the selector field, the nodes are divided into multiple node pools with the help of the labels on each node in k8s.

[0095] Node fields can include:

[0096] The firmware parameter (firmwareSpec) field is used to select one or more nodes in the node pool (where the node name can be specified through the nodeName field or a batch of nodes can be specified through the selector field) for upgrade, and set the firmware version that each node needs to be upgraded to.

[0097] The firmware configuration (firmwareConfig) field is used to reference a defined fixed configuration object (ie, firmware configuration (firmwareconfig)) to determine the firmware configuration mode corresponding to the node.

[0098] In this application, the firmware configuration information (firmwareconfig) is designed in combination with the CRD (Custom Resource Definition) technology in k8s to facilitate users to dynamically configure the firmware upgrade solution. The firmware configuration information (firmwareconfig) can be used to indicate the storage address of the firmware file, firmware upgrade tool, etc., as well as the steps for performing firmware upgrades.

[0099] The firmware configuration information may include the following fields:

[0100] The device identification (DeviceId) field is used to indicate the device ID number.

[0101] The Vendor Identification (VendorId) field is used to indicate the vendor number of the device. The DeviceId and VendorId fields can be used to identify devices that can upgrade firmware. By setting these two fields, problems caused by multiple upgrades of the same type of device on the node can also be avoided.

[0102] The firmware field is used to indicate the storage address of the firmware file, which can be the address in the above file server. By using the remote storage form, it is convenient for users to replace the file and it is convenient to adapt to the firmware of different manufacturers.

[0103] The upgrade tool (upgradeTool) field is used to indicate the storage address of the firmware upgrade tool (including the firmware upgrade script, etc.), which can also be the address in the above-mentioned file server. The user can specify to use the firmware upgrade script written by himself for upgrading, or use the firmware upgrade tool provided by this application for upgrading. In the case of using the firmware upgrade tool provided by this application, the user can adapt the firmware upgrade tool provided by this application through a self-written adapter. The firmware upgrade tool may include a function for realizing the selection of a predetermined type of device on the target node for firmware upgrade and / or a function for realizing the verification of whether the firmware on the target node is successfully upgraded.

[0104] Among them, in the firmware upgrade tool provided by the present application, an example of the format of the upgrade (update) sub-command is: " / app / data / upgrade_tool update-firmware={firmware_path}-deviceId={xxxx}-vendorId={xxx}", wherein "firmware_path" represents the storage address of the firmware file, which is the file path of the firmware file after it is downloaded from the file server to the local, and includes deviceId and vendorId. The update sub-command is used to implement the function of selecting a predetermined type of device on the target node for firmware upgrade.

[0105] In the firmware upgrade tool provided in this application, an example of the format of the assert interface is: " / app / data / upgrade_tool assert-firmware={firmware_path}-deviceId={xxxx}-vendorId={xxx}". The assert interface is used to verify whether the firmware on the device is consistent with expectations, and to realize the function of verifying whether the firmware on the target node is successfully upgraded.

[0106] The above “ / app / data / ” indicates a working directory (workDir), which is a storage location for firmware files, firmware upgrade tools, etc. used to upgrade the firmware.

[0107] In the firmware configuration information, users can also customize the steps in the firmware upgrade. Users can define the following types of steps and execute the following types of steps in sequence during the upgrade process:

[0108] The step type is upgrade-card, which is used to implement the firmware upgrade for the device corresponding to deviceId and vendorId. In upgrade-card, the user can specify a firmware upgrade tool that meets the above format. If the user provides a firmware upgrade script, the above update subcommand and assert interface can be customized, and the file used to implement the update subcommand (such as upgrade.sh) and the file used to implement the assert interface (such as assert.sh) can be packaged in a preset compression package format (such as tar.gz format). The storage address of the firmware upgrade tool (including the firmware upgrade script) can be indicated by the upgradeTool field.

[0109] The step type is user-defined operation (custom-step), which is used to perform user-defined operations after the firmware is upgraded. The user can specify the user-defined operation to be performed after the firmware is upgraded through the command and script fields in custom-step. The command field is the name of the operation, and the script field is the method of the corresponding operation.

[0110] The reboot step is used to set whether to reboot the node after upgrading the firmware.

[0111] The step of type check is used to check the device firmware to determine whether the firmware upgrade is successful. The check can be performed through the assert interface of the above firmware upgrade tool or assert.sh in the firmware upgrade script provided by the user.

[0112] The upgrade-card, reboot, and check steps are mandatory, and the custom-step step is optional.

[0113] The firmware configuration information may also include configuration information about the driver, such as the storage address of the driver file.

[0114] The master node can monitor (Polling) the API server and obtain the above cluster firmware management configuration information and firmware configuration information created by the user from the API server.

[0115] Step S202: based on the cluster firmware configuration information, determine one or more target nodes in the cluster whose firmware is to be upgraded and the node firmware configuration information corresponding to each target node.

[0116] The cluster firmware management configuration information processor in the master node can determine the node firmware configuration information (such as the above nodeconfig-1 to 3) for each target node to be upgraded based on the cluster firmware management configuration information and the firmware configuration information.

[0117] Determine one or more target nodes of the firmware to be upgraded based on the node field in the cluster firmware management configuration information; determine the general upgrade strategy in the node firmware configuration information corresponding to each target node based on the cluster firmware management configuration information; determine the node firmware configuration information corresponding to each target node based on the firmware configuration information.

[0118] The node firmware configuration information may include at least one of the following: firmware file, storage address of firmware upgrade tool, firmware upgrade process information. The storage address of firmware file and firmware upgrade tool may be determined according to the above-mentioned firmware field, upgrade tool field, etc.

[0119] The node firmware configuration information may also include a preset load waiting time and a load eviction policy. The preset load time indicates the time required to wait for the preset type of load to execute before the firmware upgrade. The preset type of load may be a load selected using the label selector of k8s, which can be determined according to the above-mentioned load waiting (waitForCompletion) field. The load eviction policy indicates the way to migrate the load before the firmware upgrade, and may include at least one eviction policy, each eviction policy corresponding to different types of resources. For example, the eviction policy may include an eviction policy for ordinary type loads and an eviction policy for special type loads. The eviction policy for ordinary type loads can be determined according to the above-mentioned ordinary load eviction (Drain) field, and the eviction policy for special type loads can be determined according to the above-mentioned special load eviction (devicePodDeletion) field.

[0120] The node firmware configuration information may also include driver configuration information. The driver configuration information may include a storage address of a driver file, etc., which may be determined based on the firmware configuration information.

[0121] The node firmware configuration information may also include firmware upgrade switch information, which is used to indicate whether to enable automatic firmware upgrade, which can be determined based on the above-mentioned automatic upgrade (autoUpgrade) field.

[0122] The node firmware configuration information may further include restart information, which is used to indicate whether to restart the node after upgrading the firmware, and can be determined according to the step of the reboot type in the above firmware configuration information.

[0123] The node firmware configuration information also includes user-defined operation information, which is used to indicate whether to perform a user-defined operation after upgrading the firmware, and can be determined according to the step of the type of user-defined operation (custom-step) in the above firmware configuration information.

[0124] The node firmware configuration information also includes firmware version information, which is used to indicate the firmware version to which the node is to be upgraded, and can be determined according to the above-mentioned firmware parameter (firmwareSpec) field.

[0125] Step S203: upgrading the firmware on each target node based on the node firmware configuration information of the target node.

[0126] Among them, the node firmware configuration information processor on the master node can send a request (for example, a gRPC request) to the driver toolkit on the corresponding target node according to each node firmware configuration information, so as to perform firmware upgrade on the corresponding target node according to the node firmware configuration information.

[0127] According to the embodiment of the present application, by obtaining cluster firmware configuration information, the user's upgrade configuration requirements are met, and based on the cluster firmware configuration information, the node firmware configuration information of the node is determined to perform firmware upgrades, thereby realizing automated firmware upgrades in cluster scenarios, making firmware upgrades in cluster scenarios easier, reducing the possibility of errors, and improving cluster availability. And by determining one or more target nodes of the firmware to be upgraded in the cluster and the node firmware configuration information corresponding to each target node based on the cluster firmware configuration information, the firmware on each target node is upgraded based on the node firmware configuration information of the target node, and the difference in configuration information in different node pools in the cluster can be taken into account, and the specified node can be upgraded based on the specified configuration information, so that the present application can be applied to different node pools for firmware management, meeting the needs of tenant isolation scenarios, and having universality.

[0128] Among them, a status flag can be set in the node firmware configuration information of each target node, and the firmware upgrade can be automatically implemented on the target node based on the status flag. For example, the cluster firmware management configuration information processor can set the status flag to UpgradeRequired (or installRequired) in the process of determining the node firmware configuration information for the target node, indicating a request for a firmware upgrade on the target node. Then, the node firmware configuration information processor can send a request (such as a gRPC request) to the driver toolkit on the target node in response to the status flag in the node firmware configuration information to perform the corresponding operation on the target node.

[0129] The firmware on the target node can be upgraded based on the following process.

[0130] See also Figure 3 , showing a flow chart of a container cluster firmware upgrade method according to an embodiment of the present application. Figure 3 As shown, step S203 may include:

[0131] Step S301, determining whether the driver is installed.

[0132] For example, in response to the state flag being UpgradeRequired, the node firmware configuration information processor may modify the state flag to validateNodeDriver, indicating validating the node driver. In response to the flag, a request is sent to the driver toolkit on the corresponding target node based on the node firmware configuration information. The driver toolkit on the target node may determine whether the driver is installed based on the node firmware configuration information, wherein it may determine whether the correct driver is installed on the target node based on the driver configuration information in the node firmware configuration information.

[0133] If the driver is not installed, the status flag may be modified to CordonRequired, indicating that the target node can be scheduled for firmware upgrade, and step S305 is executed;

[0134] If the driver installation is complete, step S302 may be executed.

[0135] Step S302: In response to the driver installation being completed, determining whether to enable firmware upgrade based on the firmware upgrade information.

[0136] If the firmware upgrade information indicates that the firmware upgrade is enabled, the status indicator may be modified to ValidateNodeFirmware, indicating that the node firmware version is verified, and step S303 is executed;

[0137] If the firmware upgrade information indicates that the firmware upgrade is not enabled, the status flag may be modified to UncordonRequired, indicating that the target node cannot be scheduled for firmware upgrade, and step S304 is executed.

[0138] Step S303: in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, it is determined whether the firmware version on the target node is consistent with the firmware version indicated in the firmware version information.

[0139] For example, a step of the check type in the above configuration information may be used to verify whether the firmware of each device on the node is consistent with the indicated firmware version.

[0140] If the versions are consistent, the status flag may be changed to UncordonRequired, and step S304 may be executed;

[0141] If the versions are inconsistent, the status flag may be modified to CordonRequired and step S305 may be executed.

[0142] Step S304: in response to the firmware upgrade being completed, setting the target node to a schedulable state.

[0143] The firmware upgrade may be confirmed to be complete in response to the firmware upgrade switch information indicating that the firmware upgrade is enabled and the firmware versions are consistent, or in response to the firmware upgrade switch information indicating that the firmware upgrade is not enabled.

[0144] Setting the target node to a schedulable state may include removing an unschedulable stain on the target node. The uncordon instruction in k8s may be used to remove the unschedulable stain on the node, which may be used to prevent loads on other nodes from being scheduled to the target node, and modifying the state flag to InstallDone. In response to the state flag being InstallDone, the firmware upgrade may be terminated.

[0145] Step S305: setting the target node to an unschedulable state.

[0146] The unschedulable state is used to prevent the load on other nodes from being scheduled to the target node. The method of setting the unschedulable state may include adding an unschedulable taint to the target node.

[0147] In response to the driver not being installed correctly, the target node may be set to an unschedulable state; or, in response to the firmware version being inconsistent, the target node may be set to an unschedulable state.

[0148] After adding the unschedulable taint, the state flag can be changed to WaitForJobRequired, which means waiting for the preset type of load to be executed and waiting for the target node to execute the load within the load waiting time.

[0149] If the target node completes the load execution within the load waiting time, the state flag may be modified to DownloadRequired, indicating a request to download the file, and step S307 is executed;

[0150] Otherwise, step S306 may be executed.

[0151] Step S306, in response to the waiting time for the preset type of load exceeding the preset load waiting time and the load is not executed completely, the load on the target node is migrated to other nodes based on the load eviction strategy.

[0152] In step S306, you can:

[0153] In response to the waiting time for the preset type of load exceeding the preset load waiting time, based on the target eviction policy corresponding to the target type of resource, the load corresponding to the target type of resource on the target node is migrated to other nodes.

[0154] The other nodes can be available nodes in the cluster that do not undergo firmware upgrade.

[0155] The eviction policy based on the common type of load can also be used to migrate the load of other types of resources other than the special type of resources on the target node to other nodes.

[0156] The target eviction policy corresponding to the target type of resource can include the eviction policy of the special type of load. The special type of load can be the load for a specific kubernetes resource name.

[0157] For example, the state flag may be first modified to PodDeletionRequired, indicating a request to evict a special type of load. In response to the flag, the load of the special type of resources on the target node is migrated to other nodes based on the eviction policy of the special type of load.

[0158] Then the state flag may be modified to DrainNodeRequired, indicating a request to evict common loads. In response to the flag, the loads of other types of resources other than special types of resources on the target node are migrated to other nodes based on the eviction policy for common loads.

[0159] You can also migrate common loads first and then migrate special loads.

[0160] After the load is migrated, the state flag may be modified to DownloadRequired, indicating a request to download the file, and step S307 is executed.

[0161] Step S307 , in response to the completion of the load execution or the completion of the load migration on the target node, a file for upgrading the firmware is downloaded to the target node based on the above storage address.

[0162] The execution condition of step S307 may be that the load migration in step S306 is completed, or the waiting time for the preset type of load does not exceed the preset load waiting time, and the load execution is completed. For example, the file for upgrading the firmware may be downloaded from the above-mentioned file server to the target node. The file for upgrading the firmware may include the above-mentioned firmware file and the firmware upgrade tool.

[0163] Step S308: Upgrade the firmware on the target node based on the above file.

[0164] In step S308, you can:

[0165] In response to the completion of load execution or load migration on the target node, the driver file is downloaded to the target node based on the driver configuration information; the driver is installed on the target node based on the driver file; in response to the completion of the driver installation, the firmware on the target node is upgraded based on the above-mentioned file for upgrading the firmware.

[0166] The driver file can also be downloaded from the above file server to the target node together with the above file for upgrading the firmware. After the driver file and the above file for upgrading the firmware are downloaded, the status flag can be modified to InstallDriverRequired, indicating a request to install the driver. In response to the status flag, the driver can be installed on the target node based on the driver file. After the driver is installed, the status flag can be modified to UpgradeFirmWareRequired, indicating a request to upgrade the firmware.

[0167] In response to the driver installation being completed, in the process of upgrading the firmware on the target node based on the file for upgrading the firmware, the following may be performed:

[0168] In response to the driver installation being completed and in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0169] For example, in response to the state flag being modified to UpgradeFirmWareRequired, it can be determined whether to enable the firmware upgrade based on the firmware upgrade switch information. If the firmware upgrade switch information indicates that the firmware upgrade is not enabled, the state flag can be modified to UncordonRequired to stop the firmware upgrade; if the firmware upgrade switch information indicates that the firmware upgrade is enabled, the node firmware configuration information processor can send a request to the driver-toolkit on the target node to upgrade the device firmware on the target node.

[0170] After the firmware on the target node is upgraded based on the file for upgrading the firmware, the operation indicated in the user-defined operation information may be performed on the target node based on the user-defined operation information.

[0171] For example, if the user configures the above-mentioned type of step as a user-defined operation (custom-step), the state identifier can be modified accordingly, and the node firmware configuration information processor can send a corresponding request to the driver-toolkit on the target node according to the modified state identifier to execute the operation defined in the custom-step on the target node.

[0172] After the firmware on the target node is upgraded based on the file for upgrading the firmware, the target node may be restarted in response to an instruction of the restart information.

[0173] For example, if the user configures the above-mentioned step of the reboot type, the status flag can be modified to RebootNodeRequired, indicating a request to restart the node. The node firmware configuration information processor can send a corresponding request to the driver-toolkit on the target node according to the modified status flag. The load (pod) on the driver-toolkit can create a corresponding file (such as the var / run / reboot-required file) on the target node, and the kured component on the target node restarts the target node based on the file.

[0174] After the target node is restarted, the process can return to step S301 to verify whether the firmware upgrade is successful through steps S301-S304. If the upgrade is successful, the firmware upgrade on the target node can be completed.

[0175] Figure 4 FIG. 2 is a schematic diagram showing a process of upgrading firmware according to an embodiment of the present application. Figure 4 As shown, the cluster firmware management configuration information processor may modify the state identifier in the node firmware configuration information to UpgradeRequired (or installRequired) after allocating the driver or firmware to the node firmware configuration information of the target node.

[0176] The node firmware configuration information processor can change the state flag to validateNodeDriver.

[0177] In response to the status identifier being validateNodeDriver, it is determined whether the node driver is installed. If the driver installation is complete, it can be determined whether the firmware upgrade is currently enabled. If the driver installation is not complete, the status identifier can be modified to cordonRequired.

[0178] If the firmware upgrade is enabled, the status flag is changed to ValidateNodeFirmware; if the firmware upgrade is not enabled, the status flag is changed to UncordonRequired.

[0179] In response to the status identifier being ValidateNodeFirmware, it can be determined whether the firmware version on the target node is correct. If the firmware version is correct, it indicates that the firmware upgrade is complete and the status identifier is modified to UncordonRequired. If the firmware version is incorrect, it indicates that a firmware upgrade is required and the status identifier is modified to cordonRequired.

[0180] In response to the state flag being UncordonRequired, the unschedulable stain on the target node may be removed to make the load on the target node schedulable, and the state flag is modified to InstallDone, thereby ending the firmware upgrade process.

[0181] In response to the state flag being cordonRequired, an unschedulable taint may be added to the target node, and the state flag may be modified to WaitForJobRequired.

[0182] In response to the status indicator being WaitForJobRequired, you can wait for the target node to execute the load within the load waiting time. If the waiting time for the preset type of load times out and the load is not executed, the status indicator is modified to PodDeletionRequired.

[0183] In response to the state flag being PodDeletionRequired, the load of the special resource device type on the target node is migrated, and the state flag is modified to DrainNodeRequired.

[0184] In response to the state flag being DrainNodeRequired, the load of the common resource device type on the target node is migrated, and the state flag is modified to DownloadRequired.

[0185] In response to the status flag being DownloadRequired, files and driver files for upgrading the firmware are downloaded from the file server, and the status flag is modified to InstallDriverRequired.

[0186] In response to the state flag being InstallDriverRequired, the driver is installed on the target node based on the driver file. After the driver is installed, the state flag is modified to InstallDriverRequired.

[0187] In response to the status flag being InstallDriverRequired, it is determined whether firmware upgrade is currently enabled. If firmware upgrade is enabled, the status flag is modified to UpgradeFirmWareRequired; if firmware upgrade is not enabled, the status flag is modified to UncordonRequired.

[0188] In response to the status being identified as UpgradeFirmWareRequired, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0189] After the upgrade is complete, determine whether to restart the node. If you want to restart the node, change the status flag to RebootNodeRequired, otherwise change the status flag to UncordonRequired.

[0190] In response to the state flag being RebootNodeRequired, the node may be restarted, and the state flag may be modified to validateNodeDriver, and based on the above steps, it may be verified whether the driver and firmware are correctly installed.

[0191] Figure 5 The structure diagram of the container cluster firmware upgrade device according to an embodiment of the present application is shown. Figure 5 As shown, the device comprises:

[0192] The acquisition module 501 is used to acquire cluster firmware configuration information;

[0193] A determination module 502 is used to determine one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node based on the cluster firmware configuration information;

[0194] The upgrading module 503 is used to upgrade the firmware on each target node based on the node firmware configuration information of the target node.

[0195] In a possible implementation, the cluster firmware configuration information includes cluster firmware management configuration information and firmware configuration information, and the determination module 502 is used to:

[0196] Determine one or more target nodes in the cluster whose firmware is to be upgraded based on the node field in the cluster firmware management configuration information;

[0197] Determine a general upgrade strategy in the node firmware configuration information corresponding to each target node based on the cluster firmware management configuration information;

[0198] Node firmware configuration information corresponding to each target node is determined based on the firmware configuration information, wherein the node firmware configuration information includes at least one of the following: a firmware file, a storage address of a firmware upgrade tool, and firmware upgrade process information.

[0199] In a possible implementation, the node firmware configuration information includes a storage address of a file for upgrading the firmware, and the upgrading module 503 is used to:

[0200] Set the target node to an unschedulable state. The unschedulable state is used to prevent the load on other nodes from being scheduled to the target node.

[0201] In response to completion of load execution or load migration on the target node, downloading a file for upgrading the firmware to the target node based on the storage address;

[0202] Upgrade the firmware on the target node based on the file;

[0203] In response to the firmware upgrade being completed, the target node is set to a schedulable state.

[0204] In a possible implementation, the node firmware configuration information further includes a preset load waiting time and a load eviction strategy, and the upgrade module 503 is further used to:

[0205] In response to the waiting time for the preset type of load exceeding the preset load waiting time and the load is not executed completely, the load on the target node is migrated to other nodes based on the load eviction strategy.

[0206] In a possible implementation, the load eviction strategy further includes at least one eviction strategy, each eviction strategy corresponds to a different type of resources, and in response to the waiting time for a preset type of load exceeding a preset load waiting time, the load on the target node is migrated to another node based on the load eviction strategy, including:

[0207] In response to the waiting time for the preset type of load exceeding the preset load waiting time, based on the target eviction policy corresponding to the target type of resource, the load corresponding to the target type of resource on the target node is migrated to other nodes.

[0208] In a possible implementation, the node firmware configuration information further includes driver configuration information, and upgrading the firmware on the target node based on the file for upgrading the firmware includes:

[0209] In response to completion of load execution or load migration on the target node, downloading the driver file to the target node based on the driver configuration information;

[0210] Install the driver based on the driver file on the target node;

[0211] In response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0212] In a possible implementation, the node firmware configuration information further includes firmware upgrade switch information, and in response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware, further including:

[0213] In response to the driver installation being completed and in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, the firmware on the target node is upgraded based on the file for upgrading the firmware.

[0214] In one possible implementation, the node firmware configuration information also includes restart information and user-defined operation information. After the firmware on the target node is upgraded based on the file for upgrading the firmware, the target node restarts in response to the instruction of the restart information, and based on the user-defined operation information, the operation indicated in the user-defined operation information is performed on the target node.

[0215] In a possible implementation, the firmware upgrade switch information indicates that the firmware upgrade is enabled and the firmware versions are consistent, or, in response to the firmware upgrade switch information indicating that the firmware upgrade is not enabled, the firmware upgrade is confirmed to be complete.

[0216] In a possible implementation, setting the target node to an unschedulable state further includes:

[0217] In response to the driver not being correctly installed, setting the target node to an unschedulable state;

[0218] Alternatively, in response to the firmware version inconsistency, the target node is set to an unschedulable state.

[0219] According to the embodiment of the present application, by obtaining cluster firmware configuration information, the user's upgrade configuration requirements are met, and based on the cluster firmware configuration information, the node firmware configuration information of the node is determined to perform firmware upgrades, thereby realizing automated firmware upgrades in cluster scenarios, making firmware upgrades in cluster scenarios easier, reducing the possibility of errors, and improving cluster availability. And by determining one or more target nodes of the firmware to be upgraded in the cluster and the node firmware configuration information corresponding to each target node based on the cluster firmware configuration information, the firmware on each target node is upgraded based on the node firmware configuration information of the target node, and the difference in configuration information in different node pools in the cluster can be taken into account, and the specified node can be upgraded based on the specified configuration information, so that the present application can be applied to different node pools for firmware management, meeting the needs of tenant isolation scenarios, and having universality.

[0220] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0221] The embodiment of the present disclosure also provides a computer-readable storage medium on which computer program instructions are stored, and the computer program instructions implement the above method when executed by a processor. The computer-readable storage medium can be a volatile or non-volatile computer-readable storage medium.

[0222] The embodiment of the present disclosure also proposes a container cluster firmware upgrade device, comprising: a processor; a memory for storing processor executable instructions; wherein the processor is configured to implement the above method when executing the instructions stored in the memory.

[0223] The embodiments of the present disclosure also provide a computer program product, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above method.

[0224] Figure 6 1 is a block diagram of an apparatus 1900 for upgrading container cluster firmware according to an exemplary embodiment. For example, the apparatus 1900 may be provided as a server or a terminal device. Figure 6 , the apparatus 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0225] The device 1900 may also include a power supply component 1926 configured to perform power management of the device 1900, a wired or wireless network interface 1950 configured to connect the device 1900 to a network, and an input / output interface 1958 (I / O interface). The device 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server 2000. TM , MacOS X TM , Unix TM ,Linux TM , FreeBSD TM or similar.

[0226] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions, which can be executed by the processing component 1922 of the device 1900 to perform the above method.

[0227] The present disclosure may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0228] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples of computer-readable storage media (a non-exhaustive list) include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0229] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0230] The computer program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0231] Various aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0232] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0233] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0234] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0235] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A container cluster firmware upgrade method, characterized in that: The method comprises: Get cluster firmware configuration information; Based on the cluster firmware configuration information, determine one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node; On each target node, the firmware on the target node is upgraded based on the node firmware configuration information of the target node.

2. The method according to claim 1, characterized in that: The cluster firmware configuration information includes cluster firmware management configuration information and firmware configuration information. The step of determining one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node based on the cluster firmware configuration information includes: Determine one or more target nodes in the cluster whose firmware is to be upgraded based on the node field in the cluster firmware management configuration information; Determine a general upgrade strategy in the node firmware configuration information corresponding to each target node based on the cluster firmware management configuration information; Node firmware configuration information corresponding to each target node is determined based on the firmware configuration information, wherein the node firmware configuration information includes at least one of the following: a firmware file, a storage address of a firmware upgrade tool, and firmware upgrade process information.

3. The method according to claim 1, characterized in that The node firmware configuration information includes a storage address of a file for upgrading firmware, and the firmware on each target node is upgraded based on the node firmware configuration information of the target node, including: Setting the target node to an unschedulable state, wherein the unschedulable state is used to prevent loads on other nodes from being scheduled to the target node; In response to completion of load execution or load migration on the target node, downloading a file for upgrading the firmware to the target node based on the storage address; Upgrading the firmware on the target node based on the file; In response to the firmware upgrade being completed, the target node is set to a schedulable state.

4. The method according to claim 3, characterized in that The node firmware configuration information also includes a preset load waiting time and a load eviction strategy, and the firmware on each target node is upgraded based on the node firmware configuration information of the target node, and further includes: In response to the waiting time for the preset type of load exceeding the preset load waiting time and the load is not executed to completion, the load on the target node is migrated to other nodes based on the load eviction strategy.

5. The method according to claim 4, characterized in that The load eviction strategy further includes at least one eviction strategy, each eviction strategy corresponds to a different type of resource, and in response to the waiting time for a preset type of load exceeding the preset load waiting time, migrating the load on the target node to other nodes based on the load eviction strategy, includes: In response to the waiting time for the preset type of load exceeding the preset load waiting time, based on the target eviction policy corresponding to the target type of resource, the load corresponding to the target type of resource on the target node is migrated to other nodes.

6. The method according to claim 3, characterized in that The node firmware configuration information also includes driver configuration information, and the upgrading of the firmware on the target node based on the file for upgrading the firmware includes: In response to completion of load execution or load migration on the target node, downloading the driver file to the target node based on the driver configuration information; Installing a driver on a target node based on the driver file; In response to the driver installation being completed, the firmware on the target node is upgraded based on the file for upgrading the firmware.

7. The method according to claim 6, characterized in that The node firmware configuration information also includes firmware upgrade switch information, and in response to the driver installation being completed, upgrading the firmware on the target node based on the file for upgrading the firmware, further includes: In response to the driver installation being completed and in response to the firmware upgrade switch information indicating that the firmware upgrade is turned on, the firmware on the target node is upgraded based on the file for upgrading the firmware.

8. The method according to claim 3, characterized in that The node firmware configuration information also includes restart information and user-defined operation information. After the firmware on the target node is upgraded based on the file for upgrading the firmware, the target node restarts in response to the instruction of the restart information, and based on the user-defined operation information, the operation indicated in the user-defined operation information is performed on the target node.

9. The method according to claim 3, characterized in that: In response to the firmware upgrade switch information indicating that the firmware upgrade is enabled and the firmware versions are consistent, or in response to the firmware upgrade switch information indicating that the firmware upgrade is not enabled, confirming that the firmware upgrade is complete.

10. The method according to claim 3, characterized in that The step of setting the target node to an unschedulable state further includes: In response to the driver not being correctly installed, setting the target node to an unschedulable state; Alternatively, in response to the firmware version inconsistency, the target node is set to an unschedulable state.

11. A container cluster firmware upgrade device, characterized in that: The device comprises: The acquisition module is used to obtain cluster firmware configuration information; A determination module, configured to determine, based on the cluster firmware configuration information, one or more target nodes in the cluster whose firmware is to be upgraded and node firmware configuration information corresponding to each target node; The upgrade module is used to upgrade the firmware on each target node based on the node firmware configuration information of the target node.

12. A container cluster firmware upgrade device, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the method described in any one of claims 1 to 10 when executing the instructions stored in the memory.

13. A non-volatile computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images