K8s root certificate change method and device, electronic equipment and storage medium

Abstract

The invention provides a k8s root certificate change method and device, electronic equipment and a storage medium, and the method comprises the steps: combining an original root certificate with a target root certificate to obtain a combined root certificate, and gradually replacing the root certificate of each component with the combined root certificate according to a first preset replacement sequence and a second preset replacement sequence, according to the method, each component has the original root certificate and the target root certificate at the same time, so that each component can be normally accessed by using the request of the original root certificate and the request of the updated target root certificate, the normal operation of the service in the updating process is ensured, then the original root certificate in the root certificates of each component is removed, and the component is restarted; and automatic updating of the root certificate of each component in k8s is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of big data processing, and in particular, to a method, device, electronic device and storage medium for changing the k8s root certificate. Background Art

[0002] With the development of container technology, more and more enterprises choose to run network services through containerization technology to achieve the independent operation of network service instances, thereby improving the stability of service operation. Kubernetes (abbreviated as K8s) is widely used in containerization technology. K8s is an open-source container orchestration engine used for automated deployment, scaling, and management of containerized applications.

[0003] In K8s, in order to ensure the security of communication between components within the cluster and prevent man-in-the-middle attacks and data leakage, root certificates are usually used to sign the certificates required by other components within the cluster to verify the credibility of each component based on the certificates. The root certificate is a self-signed CA certificate, that is, a digital certificate issued by a certificate authority (CA), and is usually used to identify the k8s cluster.

[0004] In a Kubernetes (K8S) cluster, due to security requirements, the certificates used by each component will expire over time. For a Kubernetes cluster installed using kubeadm (a k8s installation tool) or manually, the certificate expiration period for each component is usually 1 year, while the CA root certificate is 10 years. When the certificate expires, these certificates need to be updated manually to ensure the normal operation of the cluster, resulting in low efficiency. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method, device, electronic device and storage medium for changing the k8s root certificate to improve the efficiency of changing the k8s root certificate.

[0006] According to one aspect of the present invention, there is provided a method for changing the k8s root certificate, the method comprising:

[0007] Obtain the original root certificate to be changed and the target root certificate, where the target root certificate is the changed root certificate;

[0008] Merge the original root certificate and the target root certificate to obtain a merged root certificate;

[0009] Replace the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate, where each of the components includes a k8s configuration node, an APIserver server, an APIserver client, and multiple sub-components; the first preset replacement order is that after the root certificate in the k8s configuration node is replaced, replace the root certificate in the configuration node of the APIserver, then replace the root certificate of the APIserver server, then replace the root certificates of each of the sub-components, then replace the root certificate of the k8s cluster, and then replace the root certificate of the APIserver client;

[0010] After replacing the root certificate in the configuration node of the APIserver by using the merged root certificate, replace the public and private keys in each component in the k8s according to the second preset replacement order by using the public and private keys corresponding to the target root certificate, where the second preset replacement order is that after replacing the public and private keys in the k8s configuration node, replace the public and private keys of the APIserver client, then replace the public and private keys of the APIserver server, and then replace the public and private keys of each of the sub-components.

[0011] Delete the original root certificates in each of the components according to the third preset order, where the third preset order is that after deleting the original root certificate in the configuration node of the APIserver, delete the original root certificate in the k8s configuration node, then delete the original root certificate of the k8s cluster, then delete the original root certificates in each of the sub-components, and then delete the original root certificate of the APIserver;

[0012] Verify whether the functions of the k8s cluster are normal. If normal, it is determined that the change of the k8s root certificate is completed.

[0013] In a possible embodiment, the step of replacing the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate includes:

[0014] Change the root certificate in each of the k8s configuration nodes to the merged root certificate one by one, and when changing each k8s node, determine the master node from the remaining configuration nodes through the master-slave election method, where the remaining configuration nodes are the other k8s configuration nodes except the k8s configuration node being changed among each of the k8s configuration nodes;

[0015] Replace the root certificate in the APIserver configuration node with the merged root certificate;

[0016] Replace the root certificate of the APIserver server with the merged root certificate;

[0017] Replace the root certificate of each of the sub-components with the merged root certificate.

[0018] In a possible embodiment, the sub-component includes a stateful service control unit. The step of replacing the root certificate of each of the sub-components with the merged root certificate includes:

[0019] When changing the root certificate of the stateful service control unit, determine the master control unit from the remaining control units through a master-slave election, where the remaining control units are other control units in each of the stateful service control units except the stateful service control unit being changed;

[0020] After changing the root certificate of the stateful service unit, verify whether the access of each of the stateful service units is normal; if not, return to the step of replacing the root certificate of each of the sub-components with the merged root certificate;

[0021] Restart each of the stateful service control units one by one.

[0022] In a possible embodiment, before replacing the root certificate of the APIserver server with the merged root certificate, the method further includes:

[0023] Use the target root certificate to replace the root certificate of the k8s configuration node.

[0024] In a possible embodiment, the method further includes: updating the original root file in the service private key with the merged root certificate;

[0025] And after completing all changes, restart the pods related to each component with a root certificate change.

[0026] According to another aspect of the present invention, there is provided a k8s root certificate change device, the device includes:

[0027] An acquisition module, configured to acquire the original root certificate to be changed and the target root certificate, where the target root certificate is the changed root certificate;

[0028] A merging module, configured to merge the original root certificate and the target root certificate to obtain a merged root certificate;

[0029] The first replacement module is used to replace the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate, where each of the components includes a k8s configuration node, an API server server, an API server client, and multiple sub-components; the first preset replacement order is that after the root certificate in the k8s configuration node is replaced, the root certificate in the configuration node of the API server is replaced, then the root certificate of the API server server is replaced, then the root certificates of each of the sub-components are replaced, then the root certificate of the k8s cluster is replaced, and then the root certificate of the API server client is replaced;

[0030] The second replacement module is used to, after replacing the root certificate in the configuration node of the API server by using the merged root certificate, replace the public and private keys in each component in the k8s according to the second preset replacement order by using the public and private keys corresponding to the target root certificate, where the second preset replacement order is that after the public and private keys in the k8s configuration node are replaced, the public and private keys of the API server client are replaced, then the public and private keys of the API server server are replaced, and then the public and private keys of each of the sub-components are replaced;

[0031] The deletion module is used to delete the original root certificates in each of the components according to the third preset order, and the third preset order is that after the original root certificate in the configuration node of the API server is deleted, the original root certificate in the k8s configuration node is deleted, then the original root certificate of the k8s cluster is deleted, then the original root certificates in each of the sub-components are deleted, and then the original root certificate of the API server is deleted;

[0032] The verification module is used to verify whether the functions of the k8s cluster are normal, and if so, it is determined that the change of the k8s root certificate is completed.

[0033] In a possible embodiment, the replacing the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate includes:

[0034] Changing the root certificate in each of the k8s configuration nodes to the merged root certificate one by one, and when changing each of the k8s nodes, determining the master node from the remaining configuration nodes through a master-slave election, where the remaining configuration nodes are the other k8s configuration nodes except the k8s configuration node being changed among each of the k8s configuration nodes;

[0035] Replacing the root certificate in the API server configuration node with the merged root certificate;

[0036] Replacing the root certificate of the API server server with the merged root certificate;

[0037] Replace the root certificate of each of the sub-components with the merged root certificate.

[0038] In a possible embodiment, a stateful service control unit is included in the sub-components. The replacing the root certificate of each of the sub-components with the merged root certificate includes:

[0039] When changing the root certificate of the stateful service control unit, determine the master control unit from the remaining control units by means of master-slave election, where the remaining control units are other control units except the stateful service control unit being changed among each of the stateful service control units;

[0040] After changing the root certificate of the stateful service unit, verify whether the access of each of the stateful service units is normal; if not, return to the step of replacing the root certificate of each of the sub-components with the merged root certificate;

[0041] Restart each of the stateful service control units one by one.

[0042] According to another aspect of the present invention, there is provided an electronic device, including:

[0043] A processor; and

[0044] A memory storing a program,

[0045] wherein the program includes instructions that, when executed by the processor, cause the processor to execute any one of the above-mentioned k8s root certificate change methods.

[0046] According to another aspect of the present invention, there is provided a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute any one of the above-mentioned k8s root certificate change methods.

[0047] In one or more technical solutions provided in the embodiments of the present invention, the original root certificate and the target root certificate are merged to obtain a merged root certificate, and the merged root certificate is used to gradually replace the root certificates of each component according to the first preset replacement order and the second preset replacement order, so that each component has both the original root certificate and the target root certificate at the same time, thereby ensuring that requests using the original root certificate and requests using the updated target root certificate can both access each component normally, ensuring the normal operation of the service during the update process. Then, the original root certificate in the root certificate of each component is removed, and the component is restarted, realizing the automatic update of the root certificates of each component in K8s. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In the following description of exemplary embodiments in conjunction with the accompanying drawings, more details, features, and advantages of the present invention are disclosed, in which:

[0049] Figure 1 FIG. 4 is a schematic flowchart of a method for changing the k8s root certificate provided by an embodiment of the present invention;

[0050] Figure 2 FIG. 5 is another schematic flowchart of a method for changing the k8s root certificate provided by an embodiment of the present invention;

[0051] Figure 3 FIG. 6 is a schematic structural diagram of a device for changing the k8s root certificate provided by an embodiment of the present invention;

[0052] Figure 4 FIG. 7 shows a block diagram of the structure of an exemplary electronic device that can be used to implement the embodiments of the present invention. Detailed Embodiments

[0053] Embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Instead, these embodiments are provided to more thoroughly and completely understand the present invention. It should be understood that the drawings and embodiments of the present invention are only for exemplary purposes and are not used to limit the protection scope of the present invention.

[0054] It should be understood that the various steps recited in the method embodiments of the present invention can be executed in a different order and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this regard.

[0055] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to". The term "based on" is "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc. mentioned in the present invention are only used to distinguish different devices, modules, or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules, or units.

[0056] It should be noted that the modifications of "one" and "multiple" mentioned in the present invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise clearly stated in the context, it should be understood as "one or more".

[0057] The names of the messages or information exchanged between multiple devices in the embodiments of the present invention are for illustrative purposes only and do not limit the scope of these messages or information.

[0058] As described in the background art, in the related art, the root certificate of k8s is usually updated manually. The specific process is to check the certificate expiration time, back up the old certificate, delete the old certificate, regenerate the certificate, update the configuration file, restart the relevant components, and verify the update.

[0059] Although the technology of manually deploying the K8S root certificate update plays an important role in ensuring the security of the cluster, it also has some obvious disadvantages:

[0060] 1. Complex operation: Manually updating the certificate requires the administrator to have a high technical level and rich operation experience, otherwise it is easy to make mistakes. The operation steps are cumbersome and it is easy to miss or make mistakes, especially in a multi-node cluster.

[0061] 2. High risk: During the certificate update process, if the operation is improper, it may cause the cluster service to be interrupted or data to be lost. Especially when the certificate has expired and the cluster cannot run normally, the difficulty and risk of manually updating the certificate will increase greatly.

[0062] 3. Low automation level: At present, although kubeadm provides some commands for automatically updating the certificate, some operations still need to be completed manually and full automation cannot be achieved. A low automation level means that when the certificate is about to expire, manual intervention is required for the update, increasing the operation and maintenance cost.

[0063] 4. Dependence on external tools: In some cases, external tools (such as openssl) may be required to generate or verify the certificate, which increases the complexity and dependence of the system.

[0064] 5. Difficult certificate management: As the scale of the cluster expands and the number of components increases, the number of certificates will also increase sharply, and it will become very difficult to manage these certificates manually. An effective certificate management mechanism needs to be established to track information such as the expiration time, storage location, and usage of the certificates.

[0065] In summary, although the technology of manually deploying the K8S root certificate update is of great significance in ensuring the security of the cluster, its disadvantages such as complex operation, high risk, low automation level, dependence on external tools, and difficult certificate management cannot be ignored.

[0066] Based on this, the embodiments of the present invention provide a method, device, electronic device and storage medium for changing the k8s root certificate. The method for changing the k8s root certificate provided by the embodiments of the present invention can be applied to any electronic device with the function of changing the k8s root certificate, and the electronic device can be a server, a computer, a mobile terminal, etc. The solution of the present invention will be described below with reference to the accompanying drawings:

[0067] Figure 1 FIG. 4 is a schematic flowchart of a method for changing the k8s root certificate provided by an embodiment of the present invention, which may include the following steps:

[0068] S101. Obtain the original root certificate to be changed and the target root certificate, where the target root certificate is the root certificate after change;

[0069] S102. Merge the original root certificate and the target root certificate to obtain a merged root certificate;

[0070] S103. Use the merged root certificate to replace the root certificates in each component in k8s according to a first preset replacement order. Each of the components includes a k8s configuration node, an APIserver server, an APIserver client, and multiple sub-components. The first preset replacement order is that after the root certificate in the k8s configuration node is replaced, the root certificate in the configuration node of the APIserver is replaced, then the root certificate of the APIserver server is replaced, then the root certificates of each sub-component are replaced, then the root certificate of the k8s cluster is replaced, and then the root certificate of the APIserver client is replaced;

[0071] S104. After using the merged root certificate to replace the root certificate in the configuration node of the APIserver, use the public and private keys corresponding to the target root certificate to replace the public and private keys in each component in k8s according to a second preset replacement order. The second preset replacement order is that after the public and private keys in the k8s configuration node are replaced, the public and private keys of the APIserver client are replaced, then the public and private keys of the APIserver server are replaced, and then the public and private keys of each sub-component are replaced;

[0072] S105. Delete the original root certificates in each component according to a third preset order. The third preset order is that after the original root certificate in the configuration node of the APIserver is deleted, the original root certificate in the k8s configuration node is deleted, then the original root certificate of the k8s cluster is deleted, then the original root certificates in each sub-component are deleted, and then the original root certificate of the APIserver is deleted;

[0073] S106. Verify whether the functions of the k8s cluster are normal. If they are normal, it is determined that the change of the k8s root certificate is completed.

[0074] Applying the embodiments of the present invention, the original root certificate and the target root certificate are merged to obtain a merged root certificate, and the root certificates of each component are gradually replaced by using the merged root certificate according to the first preset replacement order and the second preset replacement order, so that each component has both the original root certificate and the target root certificate at the same time. Furthermore, it is ensured that the requests using the original root certificate and the requests using the updated target root certificate can both access each component normally, ensuring the normal operation of the service during the update process. Then, the original root certificate in the root certificates of each component is removed, and the component is restarted, realizing the automatic update of the root certificates of each component in k8s.

[0075] The following is an exemplary description of the above S101 - S106:

[0076] The above-mentioned original root certificate to be changed refers to the root certificate that reaches the update time. As described above, the validity period of the root certificate is usually 10 years. Therefore, as a possible implementation manner, a root certificate validity time timer can be maintained when generating the root certificate. When the validity time of the root certificate reaches a preset duration, a change message can be sent. The change message can include the identifier, content, and generation time of the root certificate to be changed, etc.

[0077] The root certificate is a digital certificate issued by a certificate authority (CA) and is used to prove the identity of the holder and the legitimacy of the public key. The CA certificate usually contains information such as the electronic visa authority, public key user information, public key, signature of the authoritative institution, and validity period. These information are unified in terms of format and verification method through the X.509 international standard. Correspondingly, the content of the above-mentioned original root certificate can include public key user information and public key information.

[0078] The content of the above-mentioned original root certificate can also include a private key, which is a password defined by the user for decrypting the specific data transmitted by the user. The user can refer to the user of k8s. Similarly, the target root certificate can also include public key information, public key user information, and private key information. The specific values of this information can be set according to the actual application scenario, and the present invention does not make specific limitations on this.

[0079] In a possible embodiment, the information of the same type in the original root certificate and the target root certificate can be merged according to the types of each information in the original root certificate and the target root certificate, that is, the information of the same type in the original root certificate and the target root certificate are all stored in the type in the configuration file. Exemplarily, the public key of the original root certificate and the public key of the target root certificate can be stored in the public key configuration file.

[0080] As a possible implementation, the original root certificate and the target root certificate can be merged by the command cat old.crt new.crt>latest.crt, which is used to merge the contents of two certificate files (old.crt and new.crt) into a new file (latest.crt).

[0081] After obtaining the merged root certificate, the root certificates in each component can be replaced using the merged root certificate according to the first preset replacement order. As the starting point of the trust chain, the root certificate is used to verify the authenticity of all subsequent issued certificates. Therefore, the certificates in each component usually include information about the root certificate, and when the root certificate in k8s needs to be updated, the root certificates in each component also need to be updated.

[0082] The above components are parts of k8s and can include k8s configuration nodes, API servers, API clients, and multiple sub-components. Specifically, the k8s configuration node can be an etcd (Enhanced Transactional Data Store, a key-value storage system) node. An etcd node is an independent instance in the etcd cluster, which is used to store data and participate in ensuring the consistency and high availability of the cluster. In Kubernetes, etcd stores the configuration data, status data, and metadata of the cluster, and is the data backbone of the entire cluster. Each etcd node constitutes the etcd cluster.

[0083] The above sub-components refer to the components in k8s that provide containerized services and can include controller-manager, sheduler, and kubelet. Among them, Controller Manager is the management control center in the Kubernetes cluster, responsible for maintaining the status of the cluster, including automated tasks for fault detection and recovery. It monitors the status changes of specific resources in the cluster in real time through the interfaces provided by the API Server. When various failures cause the status changes of a certain resource object, the Controller will try to adjust its status to the desired status. Scheduler is the scheduler in the Kubernetes cluster, responsible for allocating newly created Pod instances to appropriate nodes for startup. It makes decisions based on node resources, Pod scheduling policies, and other constraints to ensure that Pods can run efficiently and stably in the cluster. Kubelet is an agent running on each node in the Kubernetes cluster, responsible for maintaining the containers on the node. It obtains the Pod specification by interacting with the kube-APIserver in the control plane and ensures that the containers in the Pod run according to the specification.

[0084] The above API Server is the core component of the cluster, responsible for providing and managing RESTful API interfaces, serving as the central contact point for all users, automation, and components to access cluster resources. The API Server can include a server-side and a client-side. Among them, the API Server server-side is one of the core components of the Kubernetes control plane, which provides a set of HTTP / HTTPS interfaces for external clients to call to operate resource objects in the Kubernetes cluster. The API Server client is any program or tool that needs to interact with the Kubernetes API Server. These clients perform various operations, such as creating, reading, updating, or deleting cluster resources, by sending HTTP / HTTPS requests to the API Server.

[0085] Each of the above components contains a root certificate and a component certificate issued by the root certificate. Correspondingly, each component can include public key and private key information. The public key information is usually defined by the root certificate, and the private key information can be defined by the component certificate of the component. The private keys of each component can be the same or different, and the present invention does not make specific limitations on this.

[0086] In a possible embodiment, the original root certificate can be replaced with the merged root certificate in the following order: after the root certificate in the k8s configuration node is replaced, the root certificate in the configuration node of the client is replaced; after the root certificate in the configuration node of the client is replaced, the root certificate of the client is replaced; after the root certificate of the client is replaced, the root certificate of the server-side is replaced.

[0087] In a possible embodiment, the root certificate in each of the k8s configuration nodes can be changed to the merged root certificate one by one. When changing each k8s node, the master node is determined from the remaining configuration nodes through the master-slave election method, where the remaining configuration nodes are the other k8s configuration nodes except the k8s configuration node being changed among all the k8s configuration nodes.

[0088] After the change, the k8s configuration node includes the merged root certificate of the original root certificate + the target root certificate and the original public key and private key pair of the configuration node. In this way, the APIserver holding the original certificate can normally access the etcd cluster.

[0089] In a possible embodiment, after the change to a single etcd node is completed, it is possible to verify whether the etcd cluster is running properly. Specifically, the command. / etcdctl–endpoints=”xxxx”status can be used to verify whether the etcd cluster is normal, where "xxx" represents the etcd node address. If an exception occurs, the master node can be reselected through the master-slave election method, or the change can be paused to find the etcd node where the exception occurs.

[0090] After that, the root certificate in the client configuration node can be replaced with the merged root certificate. Specifically, the ca certificate of etcd of the APIserver can be gradually replaced with the latest merged root certificate, and the service can be restarted. The above-mentioned client configuration node refers to the etcd node of the APIserver, which is used to store the data of the APIserver. The ca certificate of the API Server configuration node is used as the CA certificate when the client accesses etcd to verify the identity of the etcd cluster.

[0091] The APIserver is a stateless service. Restarting a single instance can still achieve high-availability compatibility by creating and running other instances. And through the above technical solution, both the APIserver with the new etcd certificate and the APIserver with the old etcd certificate can access the etcd cluster.

[0092] After the above update is completed, the public and private keys of the etcd node can be updated to the latest public and private keys, and the service can be restarted. The latest public and private keys can be determined based on the target root certificate. Specifically, the public and private key content is stored in a fixed file in the target root certificate. Therefore, the fixed file can be obtained to update the public and private key pair of the etcd node.

[0093] After the update is completed, the configuration node contains the merged root certificate and the new public and private keys, and the client includes the merged root certificate of the configuration node, the new public and private keys of the configuration node, and the merged root certificate of the APIserver.

[0094] After that, the ca certificate of the APIserver can be gradually replaced with the merged root certificate, and the APIserver itself retains the old certificate. Specifically, the root certificate of the APIserver client can be replaced with the merged root certificate so that the APIserver can accept access from those holding the merged root certificate. The server certificate of the APIserver itself is still issued by the original root certificate, which makes the public and private keys of the APIserver unchanged. After the change is completed, both the client and the server of the APIserver contain the merged root certificate and the old public and private keys.

[0095] Afterwards, replace the CA certificates of each sub-component with the merged root certificate. Each sub-component may include a stateful service control unit, such as the aforementioned controller-manager and sheduler. When changing the CA certificate of the stateful service control unit, the master control unit can be determined from the remaining control units through a master-slave election, where the remaining control units are other control units in each of the stateful service control units except the stateful service control unit being changed.

[0096] After changing the CA certificate of the stateful service unit, verify whether the access of each stateful service unit is normal; if not, return to the step of replacing the CA certificate of the server with the merged root certificate; restart each stateful service control unit one by one.

[0097] In a possible embodiment, the root certificates in each controller-manager and scheduler can be changed one by one using the merged root certificate, and high availability of the components can be achieved through master-slave selection within the components during the change without affecting service stability.

[0098] During the process of changing the root certificate of the component instance, the log information can be monitored in real time to determine that there is no error in accessing the APIserver x509 in the log and the overall function and health check are normal. If an exception occurs, the change is stopped.

[0099] After restarting kube-controller-manager one by one, all service accounts created will obtain private keys that contain both the old CA certificate and the new CA certificate, and the pods created later will automatically adapt to this private key.

[0100] Wait for the root certificate (i.e., the root certificate of the k8s cluster) in the public and private keys of the service account to be updated so that it contains both the old and new CA certificates. In this way, if a new pod is started before the new CA is used in the api server, these new pods will obtain this update and trust both the old and new CA certificates at the same time. The new pods use the new certificate to access the cluster, and the old pods can still use the old certificate. This ensures that the old pods can work properly without needing to be upgraded. The above services can be all network services using k8s, that is, the root certificate in the network service can be updated to the merged root certificate so that the network service can communicate with the k8s cluster through the public and private keys contained in the original root certificate or the public and private keys contained in the target root certificate, thereby ensuring that the requests of the network service can also be processed normally during the change. After the change is completed, each component contains the merged root certificate and the new public and private keys of the corresponding component.

[0101] After that, the root certificate of the APIserver service in kubelet can be replaced with the latest merged root certificate, and the service can be restarted so that the kubelet with the old certificate can access the APIserver cluster normally. After updating the root certificate of kublet, the corresponding kubeconfig needs to be regenerated.

[0102] In a possible embodiment, the certificates of the components can be replaced in accordance with a second preset replacement order by using the target root certificate, where the second preset replacement order is to replace the public and private keys in the k8s configuration node, then replace the public and private keys of the APIserver client, and then replace the public and private keys of the APIserver server, and then replace the public and private keys of each sub-component.

[0103] In a possible embodiment, the public and private keys of etcd can be gradually updated to the latest public and private keys. Specifically, the non-leader nodes among them can be updated. The master node refers to the main node for processing service requests, which is usually determined through master-slave election. In a possible embodiment, after changing the root certificates of etcd to the target root certificates, the root certificates of APIserver can be gradually replaced with the merged root certificates.

[0104] After that, the public and private keys of APIserver itself can be changed to the latest public and private keys, that is, the root certificate of APIserver is updated by using the target root certificate. In this way, the kubelet with the old certificate can access the APIserver cluster normally.

[0105] After that, change the public and private keys of the kubelet of the APIserver server to the target root certificate to enable the kubelet to access the APIserver normally.

[0106] After that, gradually update the certificates of the components of controller-manager, scheduler, and kublet to the new public and private keys.

[0107] In a possible embodiment, the pods involved in obtaining certificates need to be restarted, that is, all pods related to the components with root certificate changes need to be restarted. A pod is the smallest deployable unit in Kubernetes. It is a collection of a group of closely related containers. These containers share resources such as storage and network and are scheduled and managed as a whole.

[0108] In a possible embodiment, the original root certificates in each component may be deleted in the above-mentioned third preset order, and the relevant pods may be restarted. The third preset order is the same as the above-mentioned second preset replacement order. Specifically, the original root certificates may be deleted in the order of: the ca certificate of etcd in apisever has only the target root certificate --> etcd changes its own ca certificate to have only the target root certificate --> kubelet changes the ca certificate to have only the target root certificate --> controller-manager and scheduler are changed to have only the target root certificate --> APIserver changes the root certificate to have only the target root certificate.

[0109] After the change is completed, it is possible to verify whether the functions of the cluster are normal. For example, it can be verified by means of traffic playback, etc. In the embodiments of the present invention, any feasible method can be used to verify whether the functions of the cluster are normal, and the present invention does not make specific limitations in this regard.

[0110] In the embodiments of the present invention, when changing the root certificate, it will involve the certificate update of all components. In order to ensure the lossless change operation of the overall cluster and all components. It is necessary to change the component server to be compatible with the old and new root certificates, analyze the client sources of each component, and preferentially update the client certificates to be compatible with the old and new root certificates at the same time, and change the server root certificate to the latest certificate, so that the access of all clients holding the new certificate is also normal. Such a change step idea plus the corresponding high-availability means can achieve the final lossless change operation.

[0111] As Figure 2 shown, Figure 2 FIG. is a schematic flowchart of a method for changing k8s certificates provided by an embodiment of the present invention, which may include the following steps: merging the old root certificate and the new root certificate into one root certificate to achieve compatibility between the old and new certificates. Gradually replace the ca certificate of the etcd node with the latest merged root certificate, restart the service, and after the change, the etcd node is the merged root certificate + the original public key and private key pair.

[0112] Gradually replace the ca certificate of etcd in APIserver with the latest merged root certificate, and update the private key and public key of etcd to the latest public key and private key, restart the service, and after the change, APIserver includes the etcd merged root certificate, the new etcd public key and private key pair, and the APIserver merged root certificate.

[0113] Gradually update the public key and private key of etcd to the latest public key and private key. At this time, etcd contains the merged root certificate and the new etcd public key and private key pair.

[0114] Gradually replace the CA certificate of the API server with the merged root certificate. The API server itself retains the old certificate. At this time, the API server contains the merged root certificate and the original API server public and private key pair.

[0115] Modify the CA certificate configurations of the controller-manager, scheduler, and kublet one by one to the latest merged root certificate and restart them one by one. After restarting the kube-controller-manager one by one, all created ServiceAccounts will obtain a private key that contains both the original root certificate and the new root certificate. Replace the CA certificate of the apiserver service in the kublet with the latest merged root certificate and restart the service.

[0116] The API server changes its own public and private keys to the latest public and private keys. At this time, the API server includes the merged root certificate and the new public and private key pair. The API server changes the public and private keys of the server-side kublet to the latest public and private keys.

[0117] The controller-manager, scheduler, and kublet gradually update the certificates of their components to the new public and private keys. After the update, each component includes the merged root certificate and the new public and private key pair of the component. Gradually remove the old CA certificate configurations of each component and restart. At this time, all components are updated to the latest certificates. Verify that the cluster functions properly.

[0118] Based on the same inventive concept, an embodiment of the present invention further provides a k8s root certificate change device, as Figure 3 shown. The device 300 may include:

[0119] An acquisition module 301, configured to acquire the original root certificate to be changed and the target root certificate, where the target root certificate is the root certificate after the change;

[0120] A merging module 302, configured to merge the original root certificate and the target root certificate to obtain a merged root certificate;

[0121] The first replacement module 303 is used to replace the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate, where each of the components includes a k8s configuration node, an APIserver server, an APIserver client, and multiple sub-components; the first preset replacement order is that after the root certificate in the k8s configuration node is replaced, the root certificate in the configuration node of the APIserver is replaced, then the root certificate of the APIserver server is replaced, then the root certificates of each of the sub-components are replaced, then the root certificate of the k8s cluster is replaced, and then the root certificate of the APIserver client is replaced;

[0122] The second replacement module 304 is used to replace the public and private keys in each component in the k8s according to the second preset replacement order by using the public and private keys corresponding to the target root certificate after replacing the root certificate in the configuration node of the APIserver with the merged root certificate, where the second preset replacement order is that after replacing the public and private keys in the k8s configuration node, the public and private keys of the APIserver client are replaced, then the public and private keys of the APIserver server are replaced, and then the public and private keys of each of the sub-components are replaced;

[0123] The deletion module 305 is used to delete the original root certificates in each of the components according to the third preset order, and the third preset order is that after deleting the original root certificate in the configuration node of the APIserver, the original root certificate in the k8s configuration node is deleted, then the original root certificate of the k8s cluster is deleted, then the original root certificates in each of the sub-components are deleted, and then the original root certificate of the APIserver is deleted;

[0124] The verification module 306 is used to verify whether the functions of the k8s cluster are normal, and if so, it is determined that the k8s root certificate change is completed.

[0125] In a possible embodiment, the replacing the root certificates in each component in k8s according to the first preset replacement order by using the merged root certificate includes:

[0126] Changing the root certificate in each of the k8s configuration nodes to the merged root certificate one by one, and when changing each k8s node, determining the master node from the remaining configuration nodes through the master-slave election method, where the remaining configuration nodes are the other k8s configuration nodes except the k8s configuration node being changed among the k8s configuration nodes;

[0127] Replacing the root certificate in the APIserver configuration node with the merged root certificate;

[0128] Replace the root certificate of the API server with the merged root certificate;

[0129] Replace the root certificates of the respective sub-components with the merged root certificate.

[0130] In a possible embodiment, the sub-component includes a stateful service control unit, and the step of replacing the root certificates of the respective sub-components with the merged root certificate includes:

[0131] When changing the root certificate of the stateful service control unit, determine the master control unit from the remaining control units through a master-slave election, where the remaining control units are the other control units in each of the stateful service control units except the stateful service control unit being changed;

[0132] After changing the root certificate of the stateful service unit, verify whether the access of each stateful service unit is normal; if not, return to the step of replacing the root certificates of the respective sub-components with the merged root certificate;

[0133] Restart each of the stateful service control units one by one.

[0134] Among them, in the present invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information and other processes all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0135] An exemplary embodiment of the present invention further provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program that can be executed by the at least one processor, and when the computer program is executed by the at least one processor, it is used to cause the electronic device to execute the method according to the embodiment of the present invention.

[0136] An exemplary embodiment of the present invention further provides a non-transitory computer-readable storage medium storing a computer program, where when the computer program is executed by a processor of a computer, it is used to cause the computer to execute the method according to the embodiment of the present invention.

[0137] An exemplary embodiment of the present invention further provides a computer program product, including a computer program, where when the computer program is executed by a processor of a computer, it is used to cause the computer to execute the method according to the embodiment of the present invention.

[0138] Reference Figure 4, a block diagram of an electronic device 400 that can be a server or a client of the present invention will now be described. It is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as, personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0139] As Figure 4 shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the electronic device 400 can also be stored. The computing unit 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0140] A plurality of components in the electronic device 400 are connected to the I / O interface 405, including: an input unit 406, an output unit 407, a storage unit 408, and a communication unit 409. The input unit 406 can be any type of device that can input information into the electronic device 400. The input unit 406 can receive input digital or character information, and generate key signal inputs related to the user settings and / or function controls of the electronic device. The output unit 407 can be any type of device that can present information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 408 can include, but is not limited to, magnetic disks, optical disks. The communication unit 409 allows the electronic device 400 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a BluetoothTM device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0141] The computing unit 401 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 executes the various methods and processes described above. For example, in some embodiments, any of the k8s root certificate change methods described above can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as the storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 400 via the ROM 402 and / or the communication unit 409. In some embodiments, the computing unit 401 can be configured to execute any of the k8s root certificate change methods described above in any other suitable manner (e.g., by means of firmware).

[0142] The program code for implementing the method of the present invention can be written in any combination of one or more programming languages. These program codes can be provided to the processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the program codes are executed by the processor or controller, the functions / operations specified in the flowchart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0143] In the context of the present invention, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0144] As used in this invention, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and / or device (e.g., magnetic disks, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0145] For purposes of providing an interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic, speech, or tactile input).

[0146] The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described here), or in a computing system that includes any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local area network (LAN), wide area network (WAN), and the Internet.

[0147] A computer system can include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Claims

1. A method for changing the k8s root certificate, characterized in that, The method includes: Obtaining the original root certificate to be changed and the target root certificate, where the target root certificate is the root certificate after change; Merging the original root certificate and the target root certificate to obtain a merged root certificate; Using the merged root certificate to replace the root certificates in each component in k8s according to a first preset replacement order, where each of the components includes a k8s configuration node, an APIserver server, an APIserver client, and multiple sub-components; the first preset replacement order is that after the root certificate in the k8s configuration node is replaced, the root certificate in the configuration node of the APIserver is replaced, then the root certificate of the APIserver server is replaced, then the root certificates of each of the sub-components are replaced, then the root certificate of the k8s cluster is replaced, and then the root certificate of the APIserver client is replaced; After using the merged root certificate to replace the root certificate in the configuration node of the APIserver, using the public and private keys corresponding to the target root certificate to replace the public and private keys in each component in k8s according to a second preset replacement order, where the second preset replacement order is that after the public and private keys in the k8s configuration node are replaced, the public and private keys of the APIserver client are replaced, then the public and private keys of the APIserver server are replaced, and then the public and private keys of each of the sub-components are replaced; Deleting the original root certificates in each of the components according to a third preset order, where the third preset order is that after the original root certificate in the configuration node of the APIserver is deleted, the original root certificate in the k8s configuration node is deleted, then the original root certificate of the k8s cluster is deleted, then the original root certificates in each of the sub-components are deleted, and then the original root certificate of the APIserver is deleted; Verifying whether the functions of the k8s cluster are normal, and if so, determining that the change of the k8s root certificate is completed.

2. The method according to claim 1, wherein The using the merged root certificate to replace the root certificates in each component in k8s according to a first preset replacement order includes: Changing the root certificate in each of the k8s configuration nodes to the merged root certificate one by one, and when changing each k8s node, determining the master node from the remaining configuration nodes through the master-slave election method, where the remaining configuration nodes are the other k8s configuration nodes except the k8s configuration node being changed among each of the k8s configuration nodes; Replacing the root certificate in the APIserver configuration node with the merged root certificate; Replacing the root certificate of the APIserver server with the merged root certificate; Replacing the root certificates of each of the sub-components with the merged root certificate.

3. The method according to claim 2, wherein The sub-component includes a state service control unit, and the replacing the root certificates of each of the sub-components with the merged root certificate includes: When changing the root certificate of the stateful service control unit, determine the master control unit from the remaining control units through a master-slave election, where the remaining control units are other control units among all the stateful service control units except the stateful service control unit whose root certificate is being changed; After changing the root certificate of the stateful service unit, verify whether the access of each stateful service unit is normal; if not, return to the step of replacing the root certificate of each sub-component with the merged root certificate; Restart each stateful service control unit one by one.

4. The method according to claim 2, characterized in that, Before replacing the root certificate of the APIserver server with the merged root certificate, the method further includes: Replace the root certificate of the k8s configuration node with the target root certificate.

5. The method according to claim 1, wherein The method further includes: Update the original root file in the service private key with the merged root certificate; And after all changes are completed, restart the pods related to each component with root certificate changes.

6. A k8s root certificate change device, characterized in that, The device includes: An acquisition module, configured to acquire the original root certificate to be changed and the target root certificate, where the target root certificate is the changed root certificate; A merging module, configured to merge the original root certificate and the target root certificate to obtain a merged root certificate; A first replacement module, configured to replace the root certificates in each component in k8s with the merged root certificate according to a first preset replacement order, where each component includes a k8s configuration node, an APIserver server, an APIserver client, and multiple sub-components; the first preset replacement order is that after replacing the root certificate in the k8s configuration node, replace the root certificate in the configuration node of the APIserver, then replace the root certificate of the APIserver server, then replace the root certificates of each sub-component, then replace the root certificate of the k8s cluster, and then replace the root certificate of the APIserver client; A second replacement module, configured to, after replacing the root certificate in the configuration node of the APIserver with the merged root certificate, replace the public and private keys in each component in k8s with the public and private keys corresponding to the target root certificate according to a second preset replacement order, where the second preset replacement order is that after replacing the public and private keys in the k8s configuration node, replace the public and private keys of the APIserver client, then replace the public and private keys of the APIserver server, and then replace the public and private keys of each sub-component; A deletion module, configured to delete the original root certificates in each component according to a third preset order, where the third preset order is that after deleting the original root certificate in the configuration node of the APIserver, delete the original root certificate in the k8s configuration node, then delete the original root certificate of the k8s cluster, then delete the original root certificates of each sub-component, and then delete the original root certificate of the APIserver; A verification module, configured to verify whether the function of the k8s cluster is normal, and if so, determine that the k8s root certificate change is completed.

7. The device according to claim 6, characterized in that, Replacing the root certificates in each component in k8s by using the merged root certificate according to a first preset replacement order includes: Changing the root certificate in each of the k8s configuration nodes one by one to the merged root certificate, and when changing each k8s node, determining a master node from the remaining configuration nodes through a master-slave election, where the remaining configuration nodes are other k8s configuration nodes in each of the k8s configuration nodes except the k8s configuration node being changed; Replacing the root certificate in the APIserver configuration node with the merged root certificate; Replacing the root certificate of the APIserver server with the merged root certificate; Replacing the root certificates of the respective sub-components with the merged root certificate.

8. The device according to claim 7, characterized in that, The sub-components include a stateful service control unit, and replacing the root certificates of the respective sub-components with the merged root certificate includes: When changing the root certificate of the stateful service control unit, determining a master control unit from the remaining control units through a master-slave election, where the remaining control units are other control units in each of the stateful service control units except the stateful service control unit being changed; After changing the root certificate of the stateful service unit, verifying whether the access of each stateful service unit is normal; if not, returning to the step of replacing the root certificates of the respective sub-components with the merged root certificate; Restarting each of the stateful service control units one by one.

9. An electronic device, comprising: A processor; And A memory storing a program, Wherein the program includes instructions that, when executed by the processor, cause the processor to execute the method according to any one of claims 1-5.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause a computer to execute the method according to any one of claims 1-5.

Images