A method, apparatus, and electronic device for upgrading components in a Kubernetes cluster.

Abstract

This application provides a component upgrade method, apparatus, and electronic device in a Kubernetes (K8s) cluster, relating to the field of cloud computing technology. The method includes: in the case of a component upgrade in a first container group (POD) within the K8s cluster, receiving a target message body set via an adapter component; obtaining a first message associated with the first POD from the target message body set via the adapter component; processing and encapsulating the first message according to the role of the first POD via the adapter component to obtain a first message body; updating the target message body set via the adapter component, and sending the updated target message body set to the K8s cluster. In this embodiment, when a component in the first POD is in a hot upgrade state, if the first POD restarts or changes state, since the state of the first POD in the information obtained by the K8s cluster has not changed, the K8s cluster will not trigger related processing of services, thus preventing service disconnection.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus and electronic device for upgrading components in a K8s cluster. Background Technology

[0002] In public cloud scenarios, to provide better performance and higher service stability, cloud databases like MySQL are generally deployed in a Kubernetes (K8s) environment. The cloud MySQL instance ordered by the user is composed of multiple container groups (PODs) of K8s, and the functionality of the instance and the capabilities of the database itself are encapsulated in the PODs. These PODs are managed by the software vendor's custom resource definition (CRD).

[0003] As features are continuously iterated, there is a need to upgrade the management components and some essential functions within the PODs of existing user instances. However, during the POD upgrade process, the POD status changes, resulting in service interruptions for public cloud users. Summary of the Invention

[0004] This application provides a component upgrade method, apparatus, and electronic device in a K8s cluster to solve the problem of service disconnection for public cloud users during the upgrade of POD.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a method for upgrading components in a Kubernetes cluster, the method comprising:

[0007] In the case of component upgrade in the first container group POD in the K8s cluster, the target message body set is received through the adapter component. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component.

[0008] The adapter component retrieves the first message associated with the first POD from the target message body set;

[0009] The adapter component processes the first message according to the role to which the first POD belongs, and encapsulates the processed first message to obtain a first message body. The first message body is used to indicate that the first POD is in normal operating state.

[0010] The adapter component updates the target message body set and sends the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

[0011] Optionally, receiving the target message body set through the adapter component includes:

[0012] When the destination address of the K8s cluster is modified to the adapter component through the destination addressing component, the adapter component receives the first message body set sent by the first component to the K8s cluster.

[0013] When the K8s cluster sends the second message body set to the second component, the adapter component receives the second message body set that has been hijacked and sent by the hijacking component.

[0014] Optionally, before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes:

[0015] The destination addressing of the K8s cluster is modified to the adapter component through the destination addressing component;

[0016] After updating the target message body set through the adapter component, the method further includes:

[0017] Once the component upgrade in the first POD is completed, the destination addressing of the K8s cluster is changed from the adapter component to the K8s cluster through the destination addressing component.

[0018] Optionally, before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes:

[0019] In the case of component upgrade in the first container group POD in the K8s cluster, if the K8s cluster sends a second message body set to the second component, the hijacking component performs a hijacking operation on the second message body set and sends the second message body set to the adapter component.

[0020] After updating the target message body set through the adapter component, the method further includes:

[0021] Once the component upgrade in the first POD is completed, control the hijacking component to stop the hijacking operation.

[0022] Optionally, the target message body set is a first message body set sent by the kubelet to the Kubernetes cluster or a second message body set sent by the Kubernetes cluster to the second component; the processing of the first message by the adapter component according to the role to which the first POD belongs includes any one of the following:

[0023] When the role of the first POD is the master library, and the first message indicates that the working status of the first POD is in a preset abnormal state, the working status in the first message is changed from the abnormal state to the normal working state through the adapter component.

[0024] When the role of the first POD is a backup repository and the first POD includes a primary repository tag, the first message is deleted from the target message body set through the adapter component.

[0025] Optionally, the target message body set is the first message body set sent by kubelet to the K8s cluster; after receiving the target message body set through the adapter component, the method further includes:

[0026] The adapter component retrieves a second message associated with the second POD from the target message body set, wherein the second POD is a POD in the K8s cluster other than the first POD;

[0027] The adapter component encapsulates the second message according to the role to which the second POD belongs to obtain a second message body, which is used to indicate that the second POD is in normal operating condition.

[0028] The target message body set is updated through the adapter component, and the updated target message body set is sent to the K8s cluster, wherein the updated target message body set includes the second message body.

[0029] Optionally, the target message body set is the first message body set sent by the first POD to the K8s cluster; the processing of the first message by the adapter component according to the role to which the first POD belongs includes:

[0030] When the first POD is the master library and the first message request maintains the first POD's state as the master library state, the master library state of the first POD is updated through the adapter component.

[0031] Optionally, after updating the master library state of the first POD via the adapter component, the method further includes:

[0032] The adapter component sends a response message to the first POD to maintain the state of the master database.

[0033] Optionally, the target message body set is the first message body set sent by the first POD to the K8s cluster; the method further includes:

[0034] When the first POD is a backup database and the first message requests the switching of the first POD's status from backup database to primary database, a request failure response message is sent to the first POD through the adapter component.

[0035] Optionally, before receiving the target message body set through the adapter component, the method further includes:

[0036] The adapter component obtains information about the target POD corresponding to the cloud database service information, wherein the target POD includes the first POD and the second POD.

[0037] The adapter component establishes a mapping relationship between the cloud database service information, the target POD information, and the role to which the target POD belongs. The role includes primary database or backup database.

[0038] Secondly, embodiments of this application provide a component upgrade device in a K8s cluster, the device comprising:

[0039] The receiving module is used to receive a target message body set through the adapter component in the case of component upgrade in the first container group POD in the K8s cluster. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component.

[0040] The first acquisition module is used to acquire a first message associated with the first POD from the target message body set through the adapter component;

[0041] The processing module is used to process the first message according to the role to which the first POD belongs through the adapter component, and to encapsulate the processed first message to obtain a first message body. The first message body is used to indicate that the first POD is in normal operating state.

[0042] The first sending module is configured to update the target message body set through the adapter component and send the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

[0043] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the component upgrade method in the K8s cluster described in the first aspect.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the component upgrade method in the K8s cluster described in the first aspect.

[0045] Fifthly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the component upgrade method in a K8s cluster as described in the first aspect.

[0046] In this embodiment of the application, when the components in the first POD are in a hot upgrade state, if the first POD is restarted or its state is switched, since the state of the first POD in the information obtained by the K8s cluster has not changed, the K8s cluster will not trigger the relevant processing of the service, so the service will not be disconnected. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a flowchart of a component upgrade method in a K8s cluster provided in an embodiment of this application;

[0049] Figure 2 This is one of the traffic diagrams provided in an embodiment of this application during a component upgrade process in a K8s cluster;

[0050] Figure 3 This is the second traffic diagram illustrating the component upgrade process in a K8s cluster, as provided in this application embodiment.

[0051] Figure 4 This is a traffic diagram illustrating the process after a component upgrade in a K8s cluster, as provided in an embodiment of this application.

[0052] Figure 5 This is a schematic diagram of the structure of a component upgrade device in a K8s cluster provided in an embodiment of this application;

[0053] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] Currently, a semi-synchronous replication solution exists for MySQL. This is not a clustering solution; it divides the database processes into two roles: master and slave. The slave starts an input / output process (IO) to pull binlog from the master to its local relay log file via binlog dump. Simultaneously, it starts a slave process responsible for replaying transactions from these binlogs. This solution assumes that data consistency is guaranteed as long as the IO process on the slave is synchronized. However, in the event of a failure on the master, the user needs to be aware of the transaction replay progress on the slave, and the switchover operation can only be completed after the slave has finished replaying. Therefore, to achieve hot upgrades of cloud MySQL, it is essential to ensure that the master and slave roles of the cloud MySQL remain unchanged.

[0056] This application provides a component upgrade method, apparatus, and electronic device in a K8s cluster to solve the problem of service disconnection for public cloud users during the upgrade of POD.

[0057] See Figure 1 , Figure 1 This is a flowchart of a component upgrade method in a Kubernetes cluster provided in an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0058] Step 101: In the case of component upgrade in the first container group (POD) in the K8s cluster, the target message body set is received through the adapter component. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component.

[0059] Step 102: Obtain the first message associated with the first POD from the target message body set through the adapter component;

[0060] Step 103: The adapter component processes the first message according to the role to which the first POD belongs, and encapsulates the processed first message to obtain a first message body. The first message body is used to indicate that the first POD is in normal operating state.

[0061] Step 104: Update the target message body set through the adapter component and send the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

[0062] For details on the interaction between the Kubernetes (K8s) cluster and its components, please refer to [link / reference]. Figure 2 and Figure 3 As shown, Figure 2 This demonstrates how the kubelet component and the components containing the primary and standby MySQL processes send messages to the Kubernetes cluster. Figure 3 This shows the kubelet component sending messages to the K8s cluster.

[0063] In some implementations, during the component upgrade process in the first container group (POD) of the Kubernetes cluster, the destination address of the Kubernetes cluster is changed to the adapter component. In this way, messages sent by the first component (the component containing the kubelet component and the primary / standby MySQL processes) to the Kubernetes cluster are sent to the adapter component.

[0064] In other implementations, it can also be achieved in other ways. For example, during the first POD upgrade process, the first component sends the message to be sent to the K8s cluster to the adapter component and the K8s cluster respectively according to the message type.

[0065] Meanwhile, if the K8s cluster sends a message to the second component (kubelet component), the message will be intercepted by the traffic hijacking component and sent to the adapter component.

[0066] In this manner, if the first component sends a first set of message bodies to the Kubernetes cluster, these messages are received through the adapter component; similarly, if the Kubernetes cluster sends a second set of message bodies to the second component, it is also received through the adapter component. The message body set can include multiple message bodies, which may include messages related to the first POD that is being upgraded, messages related to the second POD that is not being upgraded, and other messages that do not involve the first or second POD.

[0067] After receiving the message body set, the adapter retrieves messages related to the first POD and processes them according to the primary / standby role of the first POD. For example, if a message involves the first POD undergoing an upgrade, and indicates that the first POD is the primary database and is in an abnormal state, the message is processed so that the processed message indicates that the first POD is in a normal operating state. In this way, during a hot upgrade of the first POD, if a high-availability component container restarts, the state of the first POD remains unchanged for the Kubernetes cluster, and the Kubernetes cluster's processing flow for services and pod controllers is not triggered, thus ensuring normal business operations.

[0068] Optionally, in some embodiments, receiving the target message body set through the adapter component includes:

[0069] When the destination address of the K8s cluster is modified to the adapter component through the destination addressing component, the adapter component receives the first message body set sent by the first component to the K8s cluster.

[0070] When the K8s cluster sends the second message body set to the second component, the adapter component receives the second message body set that has been hijacked and sent by the hijacking component.

[0071] After the destination addressing of the Kubernetes cluster is changed to the adapter component, when the first component sends a message to the Kubernetes cluster, the adapter component receives the message.

[0072] When the Kubernetes cluster sends a message to the second component, the traffic hijacking component intercepts the message and sends it to the adapter component.

[0073] In this way, the adapter component can receive messages between the K8s cluster and the first and second components.

[0074] Optionally, in some embodiments, before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes:

[0075] The destination addressing of the K8s cluster is modified to the adapter component through the destination addressing component;

[0076] After updating the target message body set through the adapter component, the method further includes:

[0077] Once the component upgrade in the first POD is completed, the destination addressing of the K8s cluster is changed from the adapter component to the K8s cluster through the destination addressing component.

[0078] While components in the first POD are being upgraded or preparing to be upgraded, the destination addressing of the Kubernetes cluster is changed to the adapter component via the destination addressing component. After the upgrade is complete, the destination addressing of the Kubernetes cluster is changed back to the Kubernetes cluster via the destination addressing component. In this way, during the upgrade process, messages are processed by the adapter component, ensuring that the Kubernetes cluster receives a normal state for the first POD. After the upgrade is complete, the Kubernetes cluster can communicate normally with the first component, such as... Figure 4 As shown.

[0079] Optionally, in some embodiments, before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes:

[0080] In the case of component upgrade in the first container group POD in the K8s cluster, if the K8s cluster sends a second message body set to the second component, the hijacking component performs a hijacking operation on the second message body set and sends the second message body set to the adapter component.

[0081] After updating the target message body set through the adapter component, the method further includes:

[0082] Once the component upgrade in the first POD is completed, control the hijacking component to stop the hijacking operation.

[0083] During the upgrade process of the components in the first POD, a hijacking component intercepts the second message body set sent by the Kubernetes cluster to the second component and forwards it to the adapter component. Thus, during the upgrade, the adapter component processes the messages, ensuring that the Kubernetes cluster perceives the first POD as being in a normal state. After the upgrade is complete, the hijacking component is stopped, allowing the Kubernetes cluster to communicate normally with the first component. Figure 4 As shown.

[0084] Optionally, in some embodiments, the target message body set is a first message body set sent by the kubelet to the Kubernetes cluster or a second message body set sent by the Kubernetes cluster to the second component; the processing of the first message by the adapter component according to the role to which the first POD belongs includes any one of the following:

[0085] When the role of the first POD is the master library, and the first message indicates that the working status of the first POD is in a preset abnormal state, the working status in the first message is changed from the abnormal state to the normal working state through the adapter component.

[0086] When the role of the first POD is a backup repository and the first POD includes a primary repository tag, the first message is removed from the target message body set through the adapter component.

[0087] If the first message pertains to the primary database (POD) and indicates that the POD's working state is abnormal, then the first message can specify one or more abnormal states that might occur during the upgrade process, such as role state switching or restarting. For example, during the upgrade of the first POD, the high-availability component container might restart, indicating an abnormal state. The adapter component then modifies the abnormal state in the first message to a normal operating state.

[0088] If the first POD involved in the first message is a backup repository and includes a primary repository tag, then the role of this first POD will be promoted from backup repository to primary repository. By removing it from the target message body set via the adapter component, the role of the first POD will not switch during the component upgrade process.

[0089] Optionally, in some embodiments, the target message body set is a first message body set sent by the kubelet to the K8s cluster; after receiving the target message body set through the adapter component, the method further includes:

[0090] The adapter component retrieves a second message associated with the second POD from the target message body set, wherein the second POD is a POD in the K8s cluster other than the first POD;

[0091] The adapter component encapsulates the second message according to the role to which the second POD belongs to obtain a second message body, which is used to indicate that the second POD is in normal operating condition.

[0092] The target message body set is updated through the adapter component, and the updated target message body set is sent to the K8s cluster, wherein the updated target message body set includes the second message body.

[0093] The adapter component obtains the second message from the target message body set. The second message involves the second POD, which is a POD that is not in a hot upgrade state.

[0094] For the second message sent by kubelet to the K8s cluster, the corresponding request for the second POD is encapsulated according to the primary and backup roles, forwarded to the K8s cluster, reporting the normal status and normal status maintenance operations, and returning the request result of the K8s cluster to kubelet.

[0095] In this way, for the second message of a POD that has not been hot-upgraded, it can report a normal status and will not affect the operation of the business.

[0096] Optionally, in some embodiments, the target message body set is the first message body set sent by the first POD to the Kubernetes cluster; the processing of the first message by the adapter component according to the role to which the first POD belongs includes:

[0097] When the first POD is the master library and the first message request maintains the first POD's state as the master library state, the master library state of the first POD is updated through the adapter component.

[0098] This prevents state switching from occurring due to failure of the master database state maintenance logic.

[0099] Optionally, in some embodiments, after updating the master library state of the first POD via the adapter component, the method further includes:

[0100] The adapter component sends a response message to the first POD to maintain the state of the master database.

[0101] While maintaining the master database state information, the adapter component can send a response message to the first POD to maintain the master database state, and send a message to the Kubernetes cluster to maintain the master database state.

[0102] Optionally, in some embodiments, the target message body set is the first message body set sent by the first POD to the K8s cluster; the method further includes:

[0103] When the first POD is a backup database and the first message requests the switching of the first POD's status from backup database to primary database, a request failure response message is sent to the first POD through the adapter component.

[0104] If the first POD requests to switch its role from backup database to primary database, the adapter component sends a request failure response message to the first POD so that the first POD does not switch states during the upgrade process, thereby maintaining the normal operation of the business.

[0105] Optionally, in some embodiments, before receiving the target message body set through the adapter component, the method further includes:

[0106] The adapter component obtains information about the target POD corresponding to the cloud database service information, wherein the target POD includes the first POD and the second POD.

[0107] The adapter component establishes a mapping relationship between the cloud database service information, the target POD information, and the role to which the target POD belongs. The role includes primary database or backup database.

[0108] For example, assuming the cloud MySQL instance is named test, its primary POD is test-0, and its standby POD is test-1, based on the above information, a mapping relationship can be established as test-0->primary and test-1->standby.

[0109] To facilitate understanding of the above embodiments, the embodiments of this application will be illustrated below through specific examples.

[0110] A highly available component image hot upgrade solution in a Kubernetes (k8) environment is proposed. This solution utilizes an adapter component and manages the Kubernetes (k8s) layer of instance PODs based on this adapter. The adapter component is a self-developed role-based adapter with the following functionalities.

[0111] (1) Subscribe to the POD information of the K8s cluster in real time and update it to the local queue of the adapter component.

[0112] (2) Based on the information of the cloud MySQL instance, determine its POD and its role, and determine the mapping relationship between the POD name and the role. For example, assume that the cloud MySQL instance is named test, its primary POD is test-0, and its backup POD is test-1; go to (3)

[0113] (3) The adapter component initializes a memory mapping table, which stores the mapping relationship between instance PODs and roles. For example, based on the above assumptions, the memory mapping table will store two data entries: test-0->primary and test-1->backup;

[0114] (4) Determine and perform the corresponding processing based on the received message body set.

[0115] If it originates from kubelet, iterate through all the content one by one, and handle each message differently depending on the POD involved in the message body:

[0116] If the POD involved is an instance in the hot upgrade state of the management component, then go to (5).

[0117] If the POD involved is not an instance in the hot upgrade state of the management component, then go to (9);

[0118] If it does not come from kubelet, then go to (6).

[0119] (5) Process this part of the content based on the primary and backup roles to which its POD currently belongs, and then encapsulate it and add it to the message body collection.

[0120] If the POD involved in the message body is the primary database, and the POD's status in the kubelet information is abnormal or undergoing a status change, then modify this part of the message to restore its status to normal before putting it back into the message body set. If the POD involved in the message body is the secondary database, then check if the secondary database POD in the message has a primary database tag added. If so, remove that part of the content before putting it back into the message body set; otherwise, do not process it.

[0121] For example, based on the assumption in (2) above, the kubelet will search for the corresponding POD information involving the cloud MySQL instance test. If the message is test-0, it will be determined that it belongs to the master database according to the memory mapping table. Then, it will be checked whether the status report of test-0 has changed. If it has changed, the change will be removed, its status will be set to normal operation, and its role will still be the master database before being put back into the message body set. If the message is test-1, it can also be concluded that it is the standby database. At this time, it is necessary to check whether it has a master database logical message body. If it does, it will be removed, modified, and put back into the message body set; go to (9).

[0122] (6) If this part of the message body content comes from a POD, then iterate through this part of the message body and perform different processing based on the different PODs in the content:

[0123] If this POD information is an instance in the hot upgrade state of the management component, then go to (8);

[0124] If this POD information is not an instance in the hot upgrade state of the management component, then go to (10).

[0125] If this part of the message body does not come from POD, then proceed to (7).

[0126] (7) If this part of the message body comes from the K8s cluster management layer outside the node, then this part comes from the communication between the K8s cluster and kubelet. This part is also encapsulated according to the different PODs and returned to the K8s cluster. For specific logic, refer to (5).

[0127] (8) If the POD involved in the message body is the primary database, then return a success message for the primary database status maintenance logic requested by it to prevent a status switch due to failure of the primary database status maintenance logic, and synchronize the corresponding status maintenance operation to the K8s cluster. If it is the backup database, then return a failure message for all requests to switch to the primary database role to prevent the original backup database role from being upgraded to the primary database and written by user services, and do not process others; go to (11).

[0128] (9) Forward the message body of the corresponding component's request according to the role to the K8s cluster, report its normal status and normal status maintenance operation, and return the request result of the K8s cluster to kubelet.

[0129] (10) Pass this part of the message body through to the K8s cluster and return the normal result of the K8s cluster to the instance POD, thus completing the normal interaction between the non-upgraded instance POD and the K8s cluster.

[0130] (11) Return the processed results to the POD instance in the upgrade process.

[0131] In addition, a traffic hijacking component is used to hijack and forward the K8s control traffic outside the instance POD node to the adapter component, thus completing part (7) of the above functions;

[0132] By using a destination addressing modification component, the destination address for communication between the node where the instance POD is located and K8s is changed to the address of the adapter component. This ensures that the communication between the node and the K8s cluster is processed by the adapter and proceeds in the expected manner.

[0133] See Figure 2 and Figure 3 In this context, the client is the link that users connect to, typically passing through a service. During a normal client connection to the cloud MySQL master database process and a hot upgrade, the following operations are performed:

[0134] (1) The adapter component synchronizes data in the K8s cluster;

[0135] (2) By using the traffic hijacking component and the destination addressing component, all traffic and message bodies at the K8s management layer on the node are forwarded to the adapter component for processing. The processing flow is as described in the adapter component's functions (2)-(11). The core point is that at this time, all traffic of the instance POD passes through the adapter component and is processed based on its role, thus maintaining the POD's state and role in K8s without change throughout the upgrade process.

[0136] (3) Upgrade the image version of the high availability component in the primary and backup cloud MySQL POD. During this process, the high availability component Container will restart. However, for the K8s cluster, the entire POD state remains unchanged and will not trigger the K8s cluster's service and pod controller related processing flow.

[0137] (4) After the image version of the high availability component in the primary and backup cloud MySQL POD is upgraded, the traffic hijacking component and the destination addressing component will release the traffic hijacking, thereby turning the K8s management layer interaction link into a normal path; at this time, since client-go will reuse the existing connection, the K8s management layer interaction still goes through the adapter component.

[0138] (5) The adapter component actively releases the connection and relies on the reconnection mechanism of client-go. The high availability management component in the cloud MySQL instance POD communicates normally with the K8s cluster and begins to be managed by the K8s cluster again.

[0139] After the upgrade, the cloud MySQL instance returned to normal, and its network traffic was as follows: Figure 4 As shown.

[0140] Based on the above steps, K8s will not detect any anomalies during the entire cloud MySQL high availability management component image upgrade process, so the user's business data link will not change and there will be no impact on the user's business.

[0141] In some hot upgrade methods, Kruise's image hot upgrade approach defines a custom set of CRDs for the software. Through the Informer mechanism and Kubernetes CRD controller tuning technology, it hijacks the processing flow of this CRD, enabling control over this type of CRD and the POD resources it manages, thus achieving in-situ upgrades of POD images. Using this software requires that the CRDs the product itself depends on must be the software's CRDs. This necessitates modifications to the product so that its corresponding CRDs can be detected by Kruise, which is intrusive to the product's architecture. Because it needs to adapt to Kruise's corresponding CRDs, it means that the CRD dependencies of cloud MySQL need to be changed accordingly. These modifications involve POD restarts, fundamentally making it impossible to perform hot upgrades of existing instances. In this method, Kruise achieves hot upgrades through tuning specific CRDs, which is not suitable for the current cloud MySQL scenario. Furthermore, container image upgrades in the Kruise solution can cause short connections in user service links, which is determined by the endpoint controller mechanism in the Kubernetes controller manager.

[0142] In some hot upgrade methods, a virtual switch, acting as a network device, simultaneously launches two different versions of the virtual machine switch process. By ensuring the backup of the data flow table and the transfer of traffic between the two versions, hot upgrade of the virtual machine switch is achieved. This method mainly realizes traffic forwarding and routing synchronization. During the forwarding process, it is not guaranteed that requests from the lower version will be seamlessly switched to the upgraded process. The upgrade process involves connection interruption, which still affects user services.

[0143] In other hot upgrade methods, the subsystems and methods that the current kernel system depends on are replaced and upgraded independently. During the upgrade process, the entire kernel system remains capable of providing services. Once the subsystem upgrade is complete, the kernel subsystem is re-registered, thus achieving the kernel system upgrade. This approach is used in scenarios where subsystem upgrades will not cause problems with the kernel system. It is primarily applied to the upgrade of eBPF type subsystems, which mainly implement user-unrelated business scenarios.

[0144] Since the cloud MySQL itself is deployed in a Kubernetes environment, users access the instance master database POD in the form of a service. The high availability management component runs in the user instance POD in the form of a sidecar. If the cloud MySQL POD image version is simply upgraded in place, the master database POD will undergo a state change and be detected by Kubernetes. Furthermore, this will prompt Kubernetes to modify the service chain, thereby affecting the user's business.

[0145] In this embodiment of the application, during the upgrade of the cloud MySQL high availability management component image, the adapter component will encapsulate the message into the corresponding reply message corresponding to the role of the instance POD and report it to the K8s cluster. This enables the instance POD to maintain its own status during the hot upgrade of the management component, temporarily remove it from the control and awareness of K8s, and prevent the user service link from being disconnected.

[0146] In addition, this application provides some processing methods to ensure that user service is not interrupted during the upgrade of high-availability components.

[0147] For example, for cloud database instances running on Kubernetes, lifecycle management, including master-slave failover and high availability, does not use the Informer mechanism. Instead, it uses direct API calls, which are implemented by calling scripts to ensure that users are unaware of the process and that their business is not affected.

[0148] For example, by cloning a new instance of a high-version management component POD, the middleware can be used to migrate some database transactions during the instant of POD switching, so that the user business is not aware of the disconnection (the disconnection time is short). This solution is aware of the disconnection in the user business, and the user business needs to implement thread pools or automatic disconnection and reconnection mechanisms.

[0149] See Figure 5 , Figure 5 This is a schematic diagram of the structure of a component upgrade device in a K8s cluster provided in an embodiment of this application, as shown below. Figure 5 As shown, the component upgrade device 500 in the K8s cluster includes:

[0150] The receiving module 501 is used to receive a target message body set through the adapter component in the case of component upgrade in the first container group POD in the K8s cluster. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component.

[0151] The first acquisition module 502 is used to acquire a first message associated with the first POD from the target message body set through the adapter component;

[0152] Processing module 503 is used to process the first message according to the role to which the first POD belongs through the adapter component, and encapsulate the processed first message to obtain a first message body, the first message body being used to indicate that the first POD is in normal operating state.

[0153] The first sending module 504 is used to update the target message body set through the adapter component and send the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

[0154] Optionally, the receiving module 501 includes:

[0155] The first receiving submodule is configured to receive the first message body set sent by the first component to the K8s cluster through the adapter component when the destination addressing of the K8s cluster is modified to the adapter component through the destination addressing component.

[0156] The second receiving submodule is used to receive the second message body set hijacked and sent by the hijacking component through the adapter component when the K8s cluster sends the second message body set to the second component.

[0157] Optionally, the device further includes:

[0158] The first modification module is used to modify the destination addressing of the K8s cluster to the adapter component through the destination addressing component;

[0159] The device further includes:

[0160] The second modification module is used to modify the destination addressing of the K8s cluster from the adapter component to the K8s cluster through the destination addressing component when the component upgrade in the first POD is completed.

[0161] Optionally, the device further includes:

[0162] The hijacking module is used to hijack the second message body set when the K8s cluster sends a second message body set to the second component during component upgrade in the first container group POD of the K8s cluster, and then send the second message body set to the adapter component.

[0163] The device further includes:

[0164] The control module is used to control the hijacking component to stop hijacking operations after the component upgrade in the first POD is completed.

[0165] Optionally, the target message body set is a first message body set sent by the kubelet to the K8s cluster or a second message body set sent by the K8s cluster to the second component; the processing module 503 includes any one of the following:

[0166] The modification submodule is used to modify the working status in the first message from the abnormal state to the normal working state through the adapter component when the role of the first POD is the main library and the first message indicates that the working status of the first POD is in a preset abnormal state.

[0167] The deletion submodule is used to delete the first message from the target message body set through the adapter component when the role of the first POD is a backup library and the first POD includes a primary library tag.

[0168] Optionally, the target message body set is the first message body set sent by the kubelet to the K8s cluster; the device further includes:

[0169] The second acquisition module is used to acquire a second message associated with the second POD from the target message body set through the adapter component, wherein the second POD is a POD in the K8s cluster other than the first POD;

[0170] The encapsulation module is used to encapsulate the second message according to the role to which the second POD belongs through the adapter component to obtain a second message body. The second message body is used to indicate that the second POD is in normal operating state.

[0171] The second sending module is used to update the target message body set through the adapter component and send the updated target message body set to the K8s cluster, wherein the updated target message body set includes the second message body.

[0172] Optionally, the target message body set is the first message body set sent by the first POD to the K8s cluster; the processing module 503 is specifically used for:

[0173] When the first POD is the master library and the first message request maintains the first POD's state as the master library state, the master library state of the first POD is updated through the adapter component.

[0174] Optionally, the device further includes:

[0175] The third sending module is used to send a response message to the first POD to maintain the state of the master library through the adapter component.

[0176] Optionally, the target message body set is the first message body set sent by the first POD to the K8s cluster; the device further includes:

[0177] The fourth sending module is used to send a request failure response message to the first POD through the adapter component when the first POD is a backup database and the first message request switches the status of the first POD from backup database to primary database.

[0178] Optionally, the device further includes:

[0179] The third acquisition module is used to acquire information about the target POD corresponding to the cloud database service information through the adapter component, wherein the target POD includes the first POD and the second POD.

[0180] The module is used to establish a mapping relationship between the cloud database service information, the target POD information and the role to which the target POD belongs through the adapter component. The role includes primary database or backup database.

[0181] The component upgrade device in the Kubernetes cluster can achieve... Figure 1 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0182] The component upgrade device in the Kubernetes cluster in this embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, etc., or it can be a server, network attached storage (NAS), personal computer (PC), etc. This embodiment does not specifically limit the specific devices described.

[0183] like Figure 6 As shown, this application embodiment also provides an electronic device 600, including: a processor 601, a memory 602, and a program stored on the memory 602 and executable on the processor 601. When the program is executed by the processor 601, it implements the various processes of the above-described component upgrade method embodiment in the K8s cluster and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0184] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the component upgrade method embodiments in the above-described Kubernetes cluster, achieving the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0185] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the above-described... Figure 1 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0186] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0187] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0188] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for upgrading components in a Kubernetes cluster, characterized in that, include: In the case of component upgrade in the first container group POD in the K8s cluster, the target message body set is received through the adapter component. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component. The adapter component retrieves the first message associated with the first container group POD from the target message body set; The adapter component processes the first message according to the role to which the first container group POD belongs, and encapsulates the processed first message to obtain a first message body. The first message body is used to indicate that the first container group POD is in normal operating state. The adapter component updates the target message body set and sends the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

2. The method according to claim 1, characterized in that, The step of receiving the target message body set through the adapter component includes: When the destination address of the K8s cluster is modified to the adapter component through the destination addressing component, the adapter component receives the first message body set sent by the first component to the K8s cluster. When the K8s cluster sends the second message body set to the second component, the adapter component receives the second message body set that has been hijacked and sent by the hijacking component.

3. The method according to claim 2, characterized in that, Before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes: The destination addressing of the K8s cluster is modified to the adapter component through the destination addressing component; After updating the target message body set through the adapter component, the method further includes: Once the component upgrade in the first container group POD is completed, the destination addressing of the K8s cluster is changed from the adapter component to the K8s cluster through the destination addressing component.

4. The method according to claim 2, characterized in that, Before receiving the first message body set sent by the first component to the K8s cluster through the adapter component, the method further includes: In the case of component upgrade in the first container group POD in the K8s cluster, if the K8s cluster sends a second message body set to the second component, the hijacking component performs a hijacking operation on the second message body set and sends the second message body set to the adapter component. After updating the target message body set through the adapter component, the method further includes: Once the component upgrade in the first container group POD is completed, control the hijacking component to stop the hijacking operation.

5. The method according to any one of claims 1 to 4, characterized in that, The target message body set is either the first message body set sent by the kubelet to the K8s cluster or the second message body set sent by the K8s cluster to the second component; the processing of the first message by the adapter component according to the role to which the first container group POD belongs includes any one of the following: When the role of the first container group POD is the master library, and the first message indicates that the working status of the first container group POD is in a preset abnormal state, the working status in the first message is changed from the abnormal state to the normal working state through the adapter component. When the role of the first container group POD is a backup repository and the first container group POD includes a primary repository tag, the first message is deleted from the target message body set through the adapter component.

6. The method according to any one of claims 1 to 4, characterized in that, The target message body set is the first message body set sent by kubelet to the K8s cluster; After receiving the target message body set through the adapter component, the method further includes: The adapter component retrieves the second message associated with the second POD from the target message body set, wherein the second POD is a POD in the K8s cluster other than the first container group POD; The adapter component encapsulates the second message according to the role to which the second POD belongs to obtain a second message body, which is used to indicate that the second POD is in normal operating condition. The target message body set is updated through the adapter component, and the updated target message body set is sent to the K8s cluster, wherein the updated target message body set includes the second message body.

7. The method according to any one of claims 1 to 4, characterized in that, The target message body set is the first message body set sent by the first container group POD to the K8s cluster; The step of processing the first message through the adapter component according to the role to which the first container group POD belongs includes: When the first container group POD is the primary repository and the first message request maintains the state of the first container group POD as the primary repository, the primary repository state of the first container group POD is updated through the adapter component.

8. The method according to claim 5, characterized in that, After updating the master library state of the first container group POD via the adapter component, the method further includes: The adapter component sends a response message to the first container group POD to maintain the state of the master library.

9. The method according to any one of claims 1 to 4, characterized in that, The target message body set is the first message body set sent by the first container group (POD) to the K8s cluster; the method further includes: When the role of the first container group POD is a backup database, and the first message request switches the status of the first container group POD from backup database to primary database, a request failure response message is sent to the first container group POD through the adapter component.

10. The method according to any one of claims 1 to 4, characterized in that, Before receiving the target message body set through the adapter component, the method further includes: The adapter component obtains information about the target POD corresponding to the cloud database service information, and the target POD includes the first container group POD and the second POD. The adapter component establishes a mapping relationship between the cloud database service information, the target POD information, and the role to which the target POD belongs. The role includes primary database or backup database.

11. A component upgrade device in a Kubernetes cluster, characterized in that, include: The receiving module is used to receive a target message body set through the adapter component in the case of component upgrade in the first container group POD in the K8s cluster. The target message body set includes a first message body set sent by the first component to the K8s cluster and a second message body set sent by the K8s cluster to the second component. The first acquisition module is used to acquire the first message associated with the first container group POD from the target message body set through the adapter component; The processing module is used to process the first message according to the role to which the first container group POD belongs through the adapter component, and to encapsulate the processed first message to obtain a first message body. The first message body is used to indicate that the first container group POD is in normal operating state. The first sending module is configured to update the target message body set through the adapter component and send the updated target message body set to the K8s cluster, wherein the updated target message body set includes the first message body.

12. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the component upgrade method in a K8s cluster as claimed in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the component upgrade method in a K8s cluster as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the component upgrade method in a K8s cluster as described in any one of claims 1 to 10.

Images