Kubernetes upgraded container anti-restart method and system
By updating the rules of the control component in the Kubernetes cluster to verify the container startup timestamp to skip restarts, the service anomaly caused by frequent container restarts was resolved, improving service stability and reducing costs.
Patent Information
- Application Number
- CN202511233752.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-29
- Publication Date
- 2025-11-21
AI Technical Summary
During Kubernetes version upgrades, frequent container restarts can cause service anomalies and affect service stability. Furthermore, existing technologies require the creation of new backup clusters, increasing equipment costs.
By updating the rules of the control component in the Kubernetes cluster, it verifies whether the container startup timestamp meets the restart rules, and sends the container hash data to skip the restart when the conditions are met, thus avoiding container restart.
It improves the stability of Kubernetes services, avoids service anomalies caused by container restarts, reduces business costs, and eliminates the need to build a new backup cluster.
Smart Images
Figure CN120994221A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer cloud computing, and particularly relates to a container anti-restarting method and system for Kubernetes upgrade. BACKGROUND
[0002] Kubernetes (k8s for short) is an open source container cluster management platform supporting automatic deployment, expansion and management of containerized applications. With the continuous upgrading of k8s versions, the cloud native functions supported by k8s are more diversified.
[0003] At present, the related technology usually uses the upgrade scheme recommended by the open source community to realize the upgrade of the k8s version. This kind of way exists the phenomenon of container restart in the upgrading process of k8s version, which is easy to cause service exception, and the service stability of k8s is poor.
[0004] In summary, the technical problems existing in the related technology need to be improved. SUMMARY
[0005] The purpose of the present application is to at least solve one of the technical problems existing in the related art.
[0006] The main purpose of the embodiments of the present application is to provide a container anti-restarting method and system for Kubernetes upgrade, which can reduce the number of container restarts in the Kubernetes upgrade process and improve the stability of the Kubernetes service.
[0007] To achieve the above purpose, one aspect of the embodiments of the present application provides a container anti-restarting method for Kubernetes upgrade, applied to a Kubernetes cluster, wherein the Kubernetes cluster includes a control component and a target node, the control component records container hash data of a target container, the target container is any one of all containers of the target node, and the method includes: When the Kubernetes cluster enters an upgrade process, a target container restart rule and a cache file of the target node are obtained, and the cache file records a container startup timestamp of the target container; According to the target container restart rule, the original container restart rule in the control component is updated, and a control component after rule updating is obtained; According to the control component after rule updating, the container startup timestamp in the cache file is verified, and a rule verification result is obtained; If the rule verification result is that the container start timestamp meets the target container restart rule, the container hash data is sent to the target node by the control component, so that the target container skips restart in the upgrade process of the Kubernetes cluster this time.
[0008] In some embodiments, the method further comprises: obtaining a component start timestamp of the control component and a container start timestamp of each container of the target node; performing timestamp comparison processing on all the container start timestamps according to the component start timestamp to obtain a timestamp comparison result; updating the container hash data of the target container according to the timestamp comparison result to obtain updated container hash data.
[0009] In some embodiments, the timestamp comparison processing on all the container start timestamps according to the component start timestamp to obtain a timestamp comparison result comprises: performing timestamp filtering on all the container start timestamps to obtain an intermediate container timestamp; wherein the intermediate container timestamp is the smallest container start timestamp among all the container start timestamps; comparing the component start timestamp and the intermediate container timestamp to obtain the timestamp comparison result.
[0010] In some embodiments, the updating of the container hash data of the target container according to the timestamp comparison result to obtain updated container hash data comprises: if the timestamp comparison result is that the component start timestamp is smaller than the intermediate container timestamp, deleting the cache file and performing restoration update on the rule-updated control component according to the original container restart rule to obtain a rule-restored control component; performing container hash analysis on the container start timestamp of the target container according to the rule-restored control component to obtain first hash data; replacing and updating the container hash data of the target container according to the first hash data to obtain the updated container hash data.
[0011] In some embodiments, the rule verification on the container start timestamp in the cache file according to the rule-updated control component to obtain a rule verification result comprises: obtaining container version data corresponding to the container start timestamp and cache version data in the cache file, and obtaining a component start timestamp according to the rule-updated control component; According to the cache version data, the container version data is version checked to obtain a version checking result; According to the component start timestamp, the container start timestamp is timestamp checked to obtain a timestamp checking result; According to the version checking result and the timestamp checking result, the rule verification result is obtained.
[0012] In some embodiments, the version checking of the container version data according to the cache version data to obtain a version checking result comprises: According to the cache version data, a container historical version and a container initial version are obtained; According to the container initial version, the container version data is first version checked to obtain a first checking result; According to the container historical version, the container version data is second version checked to obtain a second checking result; According to the first checking result and the second checking result, the version checking result is obtained.
[0013] In some embodiments, the method further comprises: If the rule verification result is that the container start timestamp does not satisfy the target container restart rule, the container hash data of the container start timestamp is analyzed according to the control component to obtain second hash data; According to the second hash data, the container hash data is replaced and updated to obtain updated container hash data; The updated container hash data is sent to the target node through the control component, so that the target container is upgraded.
[0014] To achieve the above-mentioned purpose, another aspect of the embodiment of the present application proposes a container anti-restart system for Kubernetes upgrade, applied to a Kubernetes cluster, the Kubernetes cluster comprising a control component and a target node, the control component recording container hash data of a target container, the target container being any one of the containers of the target node, and the system comprising: A first processing unit is configured to obtain a target container restart rule and a cache file of the target node when the Kubernetes cluster enters an upgrade process, the cache file recording a container start timestamp of the target container; A second processing unit is configured to update a rule of an original container restart rule in the control component according to the target container restart rule to obtain a control component after rule update; a third processing unit, configured to perform rule verification on the container startup timestamp in the cache file according to the control component after the rule update, to obtain a rule verification result; a fourth processing unit, configured to, if the rule verification result is that the container startup timestamp meets the target container restart rule, send the container hash data to the target node through the control component, so that the target container skips restart in the upgrade process of the Kubernetes cluster this time.
[0015] To achieve the above-mentioned purpose, another aspect of the embodiment of the present application provides an electronic device, which comprises a memory and a processor, the memory stores a computer program, and the processor implements the method described above when executing the computer program.
[0016] To achieve the above-mentioned purpose, another aspect of the embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method described above.
[0017] The embodiment of the present application at least has the following beneficial effects: The present application provides a container anti-restart method and system for Kubernetes upgrade, wherein the method is applied to a Kubernetes cluster, the Kubernetes cluster comprises a control component and a target node, the control component records container hash data of a target container, and the target container is any one of the containers of the target node. When the Kubernetes cluster enters an upgrade process, the target container restart rule and the cache file of the target node are obtained, and the cache file records the container startup timestamp of the target container. According to the target container restart rule, the original container restart rule in the control component is updated, and the control component after the rule update is obtained. According to the control component after the rule update, the rule verification is performed on the container startup timestamp in the cache file, and the rule verification result is obtained. If the rule verification result is that the container startup timestamp meets the target container restart rule, the container hash data is sent to the target node through the control component, so that the target container skips restart in the upgrade process of the Kubernetes cluster this time. The method performs rule verification on the cache file recording the container startup timestamp of the target container through the control component after the rule update, and sends the container hash data recorded by the control component to the target node corresponding container when the container startup timestamp meets the target container restart rule, which can make the target container skip restart, and is beneficial to avoid service abnormal phenomenon caused by container restart, and effectively improves the service stability of k8s. BRIEF DESCRIPTION OF DRAWINGS
[0018] Figure 1 This is a schematic diagram illustrating a Kubernetes upgrade process provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a method for preventing container restarts during Kubernetes upgrades, as provided in an embodiment of this application. Figure 3 This is a detailed flowchart of step S230 provided in an embodiment of this application; Figure 4 This is a detailed flowchart of step S320 provided in an embodiment of this application; Figure 5 This is a schematic diagram of the first optional process of a container restart prevention method for Kubernetes upgrades provided in this application embodiment; Figure 6 This is a detailed flowchart of step S520 provided in an embodiment of this application; Figure 7 This is a detailed flowchart of step S530 provided in an embodiment of this application; Figure 8 This is a second optional process diagram of a container restart prevention method for Kubernetes upgrades provided in an embodiment of this application; Figure 9 This is a schematic diagram of the framework of a container restart prevention system for Kubernetes upgrades provided in an embodiment of this application; Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses / devices and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.
[0020] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”
[0021] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.
[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0023] The following is an explanation of the terms used in the embodiments of this application: A Pod is the smallest deployable unit in a Kubernetes cluster. It consists of one or more containers that share network and storage and run in the same context.
[0024] Kubelet is one of the core components of a Kubernetes cluster. It is the main daemon running on each node, responsible for managing and maintaining the containers on the node. Kubelet obtains Pod runtime information from the API server and ensures that these containers are correctly created, running, and reaching the expected state.
[0025] Currently, the common approach to upgrading Kubernetes (k8s) versions involves using upgrade schemes recommended by the open-source community. However, this method suffers from container restarts during the upgrade process, which can easily cause service anomalies and compromise Kubernetes service stability. Specifically, because different versions of kubelet calculate container hash values differently during upgrades, the recalculated hash value may not match the historical hash value, triggering a container restart. Furthermore, this type of container restart caused by Kubernetes upgrades affects the entire cluster, impacting service stability and availability.
[0026] Also, refer to Figure 1There are some related technologies that require the creation of a new backup cluster and the migration of the current task cluster's services to the upgraded backup cluster. Specifically, this involves migrating the service resources of each node in the current task cluster to several nodes in the upgraded backup cluster. Figure 1 The business resources of the current task cluster's 110 nodes (such as nodes o1, o2, o3, and o4) can be migrated to the upgraded standby cluster's 120 nodes (such as nodes N1, N2, N3, and N4). Alternatively, the business of the current task cluster can be migrated to the standby cluster, and after the current task cluster is upgraded, the business can be migrated back from the standby cluster to the upgraded task cluster. This achieves the version upgrade of the Kubernetes cluster. Both methods require the creation of a new standby cluster, which increases the number of devices required for the Kubernetes cluster and results in higher business costs.
[0027] It should be noted that the aforementioned related technologies are only used to assist in understanding the technical solutions of this application and do not mean that they belong to the publicly disclosed prior art.
[0028] In view of this, this application provides a method and system for preventing container restarts during Kubernetes upgrades. The method uses a control component with updated rules to perform rule verification on a cache file that records the container startup timestamp of the target container. When the container startup timestamp meets the target container restart rule, the control component sends the recorded container hash data to the corresponding container on the target node. This ensures that even after a Kubernetes version upgrade, the control component can still send data equal to the historical hash value to the corresponding container on the target node, thereby allowing the target container to skip restarts. This helps avoid service anomalies caused by container restarts and effectively improves the service stability of the Kubernetes cluster.
[0029] Furthermore, this method obtains a cache file containing the container startup timestamp of the target container from the target node through the control component, and sends the container hash data to the target node after the container startup timestamp meets the target container restart rules, so that the target container skips the restart. It does not require the creation of a new backup cluster, that is, it does not require an increase in the number of devices required for the k8s cluster, effectively reducing the business costs required for the k8s cluster.
[0030] This application provides a method and system for preventing container restarts during Kubernetes upgrades, which can be applied to cloud computing service application scenarios. In cloud computing service application scenarios, cloud service providers can use the method provided in this application to prevent container restarts during Kubernetes cluster upgrades, ensuring the normal operation of Kubernetes cluster services. This method can effectively improve the stability of Kubernetes services and reduce the business costs required by the Kubernetes cluster.
[0031] The method provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited thereto; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network; the software can be an application implementing the method, but is not limited to the above forms.
[0032] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0033] Reference Figure 2 , Figure 2 This is an optional flowchart illustrating a container restart prevention method for Kubernetes upgrades provided in an embodiment of this application. Figure 2 The method described above is applied to a Kubernetes cluster, which includes a control component and a target node. The control component records the container hash data of the target container. The target container is any one of all containers on the target node, and may include, but is not limited to, steps S210 to S240.
[0034] Step S210: When the Kubernetes cluster enters the upgrade process, obtain the target container restart rules and the cache file of the target node. The cache file records the container startup timestamp of the target container. In this embodiment, the control component can be a Kubelet component in a Kubernetes cluster; the container hash data can be the hash value of the target container most recently parsed and calculated by the control component; and the target container restart rule can be a logical rule executed by the Kubelet component. For any container (i.e., the target container) in the target node of the Kubernetes cluster, a cache file recording the container startup timestamp of the target container can be obtained. This cache file is recorded by the target node to which the target container belongs. There are various specific implementation methods, which will not be described in detail here.
[0035] Step S220: Update the original container restart rule in the control component according to the target container restart rule to obtain the updated control component; In this embodiment of the application, the original container restart rule can be the default container restart rule for the control component during the upgrade process of the Kubernetes cluster; while the target container restart rule can be obtained by adding the logic of judging whether the container startup timestamp is before the kubelet component startup timestamp on the basis of the original container restart rule.
[0036] Specifically, the original container restart rule can be the default containerChanged function logic in the Kubelet component. This containerChanged function logic is the function logic used by the Kubelet component in Kubernetes to determine whether a container needs to be restarted. The target container restart rule can be obtained by adding the logic of whether the container startup timestamp is before the kubelet component startup timestamp in the copied text based on the containerChanged function logic.
[0037] Understandably, rule updates can involve replacing the original container restart rule in the control component with the target container restart rule to obtain a rule-updated control component, which is then used to execute the target container restart rule.
[0038] Step S230: According to the updated control component based on the rules, perform rule verification on the container startup timestamp in the cache file to obtain the rule verification result; In this embodiment of the application, rule verification can be performed by using the updated control component to verify the container startup timestamp of the target container using the target container restart rule, thereby obtaining the rule verification result of whether the container startup timestamp meets the target container restart rule.
[0039] Reference Figure 3In some embodiments, step S230, which involves the control component updated according to the rules performing rule verification on the container startup timestamp in the cache file to obtain a rule verification result, includes: Step S310: Obtain the container version data corresponding to the container startup timestamp and the cache version data in the cache file, as well as the control component updated according to the rules, and obtain the component startup timestamp; In this embodiment, the cache file, in addition to recording the container startup timestamp of the target container, may also record cached version data of the target container. This container version data is used to indicate the historical container version of the target container. The container version data may be the current container version of the target container recorded in the cache file; alternatively, it may be the current container version data returned by the target container after the control component queries the target container for its version. The component startup timestamp may be the latest startup timestamp of the control component.
[0040] Step S320: Based on the cached version data, perform version verification on the container version data to obtain the version verification result; Reference Figure 4 Further, step S320, which involves verifying the container version data based on the cached version data to obtain a version verification result, includes: Step S410: Obtain the container's historical version and initial version based on the cached version data; Step S420: Based on the initial version of the container, perform a first version verification on the container version data to obtain a first verification result; Step S430: Perform a second version verification on the container version data based on the container's historical version to obtain a second verification result; Step S440: Obtain the version verification result based on the first verification result and the second verification result.
[0041] In this embodiment of the application, version verification may involve dividing the container initial version and several container historical versions from the cached version data. The container initial version is the initial container version of the target container, while the container historical versions may be historical container versions other than the container initial version of the target container.
[0042] Understandably, the first version verification could be to check whether the current container version of the target container is equal to the initial version of the target container. Specifically, it could be to check whether the initial version of the container is equal to the container version data, thus obtaining the first verification result. The second version verification could be to check whether the current container version of the target container is equal to any historical version of the target container recorded in the cache file. Specifically, it could be to check whether the container version data is equal to any historical version of the container, thus obtaining the second verification result.
[0043] It should be noted that if the first verification result is that the initial container version is not equal to the container version data, and the second verification result is that the historical container version is not equal to the container version data, then a version verification result indicating successful version verification can be generated. This version verification result indicates that the target container's container version has been successfully upgraded. Alternatively, if the first verification result is that the initial container version is equal to the container version data, or the second verification result is that the historical container version is equal to the container version data, then a version verification result indicating failed version verification can be generated. This version verification result indicates that the target container's container version has not been upgraded, the container version upgrade has failed, or the container version is being upgraded.
[0044] Step S330: Based on the component startup timestamp, perform timestamp verification on the container startup timestamp to obtain the timestamp verification result; Step S340: Obtain the rule verification result based on the version verification result and the timestamp verification result.
[0045] In this embodiment, timestamp verification can be performed by verifying the order between the component startup timestamp of the control component and the container startup timestamp of the target container, thereby obtaining a timestamp verification result. Specifically, if the container startup timestamp of the target container is before the component startup timestamp of the control component, a timestamp verification result indicating successful timestamp verification can be obtained, which indicates that the target container has been upgraded and updated in the time dimension; or, if the container startup timestamp of the target container is after the component startup timestamp of the control component, a timestamp verification result indicating failed timestamp verification can be obtained, which indicates in the time dimension that the container version of the target container has not been upgraded, the container version upgrade has failed, or the container version is being upgraded, etc.
[0046] Understandably, if both the version verification result and the timestamp verification result are successful, a rule verification result indicating that the container startup timestamp meets the target container restart rule can be generated; or, if either the version verification result or the timestamp verification result is unsuccessful, a rule verification result indicating that the container startup timestamp does not meet the target container restart rule can be generated.
[0047] Step S240: If the rule verification result shows that the container startup timestamp meets the target container restart rule, then the container hash data is sent to the target node through the control component so that the target container skips the restart in this Kubernetes cluster upgrade process.
[0048] In this embodiment of the application, if the rule verification result is that the container startup timestamp meets the target container restart rule, the control component can directly return the container hash data it records and send it to the corresponding container of the target node. This skips the process of the Kubelet component re-parses the target container configuration file (such as Docker image configuration), thereby avoiding the situation where the recalculation of the container's hash value after the kubelet version upgrade is not equal to the historical hash value, thus avoiding the target container restart and improving the service stability of Kubernetes.
[0049] Reference Figure 5 In some embodiments, the method further includes: Step S510: Obtain the component startup timestamp of the control component and the container startup timestamp of each container of the target node; In this embodiment of the application, the container startup timestamp of each container of the target node can be obtained based on a cache file that records the container startup timestamp of each container.
[0050] Step S520: Based on the component startup timestamp, perform timestamp comparison processing on all the container startup timestamps to obtain the timestamp comparison result; Reference Figure 6 Further, step S520, which involves comparing the startup timestamps of all containers based on the component startup timestamp to obtain a timestamp comparison result, includes: Step S610: Filter all container startup timestamps to obtain intermediate container timestamps; wherein, the intermediate container timestamp is the smallest container startup timestamp among all the container startup timestamps; Step S620: Compare the component startup timestamp and the intermediate container timestamp to obtain the timestamp comparison result.
[0051] In this embodiment of the application, the timestamp comparison process can first be to filter out the smallest container startup timestamp from all container startup timestamps and record it as the intermediate container timestamp. The smallest container startup timestamp is the earliest container startup timestamp among all container startup timestamps.
[0052] Understandably, step S620 can be a comparison of the component's start timestamp and the intermediate container's timestamp to obtain a timestamp comparison result. Specifically, if the component's start timestamp is before the intermediate container's timestamp, a timestamp comparison result indicating that the component's start timestamp is less than the intermediate container's timestamp can be generated. This timestamp comparison result indicates, in the time dimension, that all containers in the target node have been updated. Alternatively, if the component's start timestamp is equal to or after the intermediate container's timestamp, a timestamp comparison result indicating that the component's start timestamp is greater than or equal to the intermediate container's timestamp can be generated.
[0053] It should be noted that if the timestamp comparison result is that the component start timestamp is greater than or equal to the intermediate container timestamp, this timestamp comparison result indicates that at least one container in the target node has not been updated in the time dimension, that is, not all containers in the target node have been updated. Step S510 can be returned and executed periodically until the timestamp comparison result is that the component start timestamp is less than the intermediate container timestamp.
[0054] Step S530: Update the container hash data of the target container according to the timestamp comparison result to obtain the updated container hash data.
[0055] Reference Figure 7 Further, step S530, updating the container hash data of the target container based on the timestamp comparison result to obtain updated container hash data, includes: Step S710: If the timestamp comparison result is that the component startup timestamp is less than the intermediate container timestamp, then delete the cache file, and restore and update the control component after the rule update according to the original container restart rule to obtain the control component after rule restoration; Step S720: According to the restored control component based on the rules, perform container hash analysis on the container startup timestamp of the target container to obtain the first hash data; Step S730: Replace and update the container hash data of the target container according to the first hash data to obtain the updated container hash data.
[0056] In this embodiment of the application, if the timestamp comparison result is that the component startup timestamp is less than the intermediate container timestamp, the target node can delete its own recorded cache file; then, after determining that the target node's cache file does not exist, the control component can replace and update the target container restart rule in the control component, thereby obtaining the control component with restored rules.
[0057] Understandably, container hash analysis can be achieved by a control component that restores rules, calculating the hash value of the target container's startup timestamp to recalculate the target container's hash value and obtain the first hash data. Replacement update can be achieved by the control component replacing the previously recorded container hash data about the target container with the recalculated first hash data to obtain the updated container hash data.
[0058] Reference Figure 8 In some embodiments, the method further includes: Step S810: If the rule verification result is that the container startup timestamp does not meet the target container restart rule, then according to the control component, perform container hash analysis on the container startup timestamp to obtain second hash data; Step S820: Replace and update the container hash data according to the second hash data to obtain the updated container hash data; Step S830: The updated container hash data is sent to the target node through the control component so that the target container can be upgraded.
[0059] In this embodiment of the application, if the rule verification result is that the container startup timestamp does not meet the target container restart rule, the target container startup timestamp can be hashed by the control component after the rule update to realize the recalculation of the target container hash value and obtain the second hash data; the content of step S820 is similar to the content of the aforementioned step S730 and can be simply deduced.
[0060] Understandably, after the control component obtains the updated container hash data, it can send the updated container hash data to the target container to trigger the target container's restart and upgrade.
[0061] Please see Figure 9 This application also provides a container restart prevention system for Kubernetes upgrades, applied to a Kubernetes cluster. The Kubernetes cluster includes a control component and a target node. The control component records the container hash data of the target container. The target container is any one of all containers on the target node. The system includes: The first processing unit 910 is used to obtain the target container restart rules and the cache file of the target node when the Kubernetes cluster enters the upgrade process. The cache file records the container startup timestamp of the target container. The second processing unit 920 is used to update the original container restart rule in the control component according to the target container restart rule, so as to obtain the control component after rule update; The third processing unit 930 is used to perform rule verification on the container startup timestamp in the cache file according to the updated control component based on the rules, and obtain the rule verification result; The fourth processing unit 940 is used to send the container hash data to the target node through the control component if the rule verification result shows that the container startup timestamp meets the target container restart rule, so that the target container skips the restart in the current Kubernetes cluster upgrade process.
[0062] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.
[0063] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.
[0064] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0065] Please see Figure 10 , Figure 10 This illustration depicts the hardware structure of an electronic device according to one embodiment. The electronic device includes: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.
[0066] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.
[0067] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.
[0068] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0069] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0070] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0071] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0072] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0073] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0074] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0075] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0076] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0077] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0078] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0079] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. A method for preventing container restarts during Kubernetes upgrades, characterized in that, Applied to a Kubernetes cluster, the Kubernetes cluster including a control component and a target node, the control component recording container hash data of a target container, the target container being any one of all containers on the target node, the method includes: When the Kubernetes cluster enters the upgrade process, it obtains the target container restart rules and the cache file of the target node. The cache file records the container startup timestamp of the target container. Based on the target container restart rule, the original container restart rule in the control component is updated to obtain the updated control component. Based on the updated control component according to the rules, the container startup timestamp in the cache file is validated to obtain the rule validation result. If the rule verification result shows that the container startup timestamp meets the target container restart rule, then the control component sends the container hash data to the target node so that the target container skips the restart in this Kubernetes cluster upgrade process.
2. The method according to claim 1, characterized in that, The method further includes: Obtain the component startup timestamp of the control component and the container startup timestamp of each container of the target node; Based on the component startup timestamp, perform timestamp comparison processing on all container startup timestamps to obtain timestamp comparison results; Based on the timestamp comparison result, the container hash data of the target container is updated to obtain the updated container hash data.
3. The method according to claim 2, characterized in that, The step of comparing the startup timestamps of all containers based on the component startup timestamp to obtain a timestamp comparison result includes: The timestamps of all container startup timestamps are filtered to obtain the intermediate container timestamp; wherein, the intermediate container timestamp is the container startup timestamp with the smallest value among all the container startup timestamps. The timestamp of the component startup is compared with the timestamp of the intermediate container to obtain the timestamp comparison result.
4. The method according to claim 3, characterized in that, The step of updating the container hash data of the target container based on the timestamp comparison result to obtain the updated container hash data includes: If the timestamp comparison result is that the component startup timestamp is less than the intermediate container timestamp, then the cache file is deleted, and the control component after the rule update is restored according to the original container restart rule to obtain the control component after the rule is restored. The control component, restored according to the rules, performs container hash analysis on the container startup timestamp of the target container to obtain the first hash data; Based on the first hash data, the container hash data of the target container is replaced and updated to obtain the updated container hash data.
5. The method according to claim 1, characterized in that, The control component, updated according to the rules, performs rule verification on the container startup timestamp in the cache file to obtain the rule verification result, including: Obtain the container version data corresponding to the container startup timestamp and the cache version data in the cache file, as well as the control component updated according to the rules, and obtain the component startup timestamp; Based on the cached version data, the container version data is verified to obtain the version verification result; Based on the component startup timestamp, the container startup timestamp is timestamped to obtain the timestamp verification result; The rule verification result is obtained based on the version verification result and the timestamp verification result.
6. The method according to claim 5, characterized in that, The step of performing version verification on the container version data based on the cached version data to obtain the version verification result includes: Based on the cached version data, obtain the container's historical version and initial version; Based on the initial version of the container, the container version data is subjected to a first version verification to obtain a first verification result; Based on the container's historical versions, a second version verification is performed on the container version data to obtain a second verification result; The version verification result is obtained based on the first verification result and the second verification result.
7. The method according to any one of claims 1-6, characterized in that, The method further includes: If the rule verification result indicates that the container startup timestamp does not meet the target container restart rule, then according to the control component, a container hash analysis is performed on the container startup timestamp to obtain second hash data; The container hash data is replaced and updated based on the second hash data to obtain the updated container hash data; The updated container hash data is sent to the target node through the control component, so that the target container can perform a container upgrade.
8. A container restart prevention system for Kubernetes upgrades, characterized in that, Applied to a Kubernetes cluster, the Kubernetes cluster includes a control component and a target node. The control component records container hash data of a target container, and the target container is any one of all containers on the target node. The system includes: The first processing unit is used to obtain the target container restart rules and the cache file of the target node when the Kubernetes cluster enters the upgrade process. The cache file records the container startup timestamp of the target container. The second processing unit is used to update the original container restart rule in the control component according to the target container restart rule, so as to obtain the control component with updated rules. The third processing unit is used to perform rule verification on the container startup timestamp in the cache file according to the updated control component based on the rules, and obtain the rule verification result; The fourth processing unit is used to send the container hash data to the target node through the control component if the rule verification result shows that the container startup timestamp meets the target container restart rule, so that the target container skips the restart in the current Kubernetes cluster upgrade process.
9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1-7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.