Method and device for adding SAN domain name of server certificate and computer equipment
By deploying Controller controller and stateful workload pods in Kubernetes clusters, SAN domain names are automatically added to all master nodes, solving the problems of cumbersome and high security risks in the existing technology, and achieving efficient and secure certificate management.
Patent Information
- Application Number
- CN202411768570.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-04
- Publication Date
- 2025-02-25
- Estimated Expiration
- 2044-12-04
AI Technical Summary
The prior art requires manual operation when adding SAN domain names to server certificates of Kubernetes clusters, which takes a long time, is cumbersome and is prone to errors. It also requires providing the account password of the master node, which poses a security risk.
By deploying Controller controllers in Kubernetes clusters, using stateful workload pods to automatically add SAN domain names on all master nodes, realizing unmanned, automated and secure certificate management.
It reduces the cumbersomeness of manual operations and the risk of human error, improves operation efficiency, cluster availability and security, and reduces operation and maintenance costs and the risk of sensitive information leakage.
Smart Images

Figure CN119520476A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of cloud platform technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for adding a SAN domain name to a server certificate. Background Art
[0002] In the Kubernetes cluster, the kube-apiserver component provides a two-way TLS authenticated Https interface. When performing TLS authentication during the communication process, not only the client needs to verify the server certificate, but the server also needs to verify the client certificate. The server certificate kube-apiserver.crt lists the SAN domain names that the server supports and can access through the SAN field. In order to ensure the high availability, load balancing, and public network accessibility of the cluster kube-apiserver, it is often necessary to add elastic load balancing (such as ELB, etc.) to the master node. Therefore, it is also necessary to add the SAN domain name to the SAN list of the server certificate kube-apiserver.crt.
[0003] The general solution for adding SAN domain names to the server certificate kube-apiserver.crt in the current community is: cluster operation and maintenance personnel use their account and password to log in to the cluster master node and manually execute related commands and scripts. This solution is time-consuming, cumbersome, and prone to errors. Alternatively, use automated operation and maintenance technologies such as Ansible to write Ansibleplaybook scripts to automatically add SAN domain names. This solution requires the establishment of an Ansible environment and the provision of account and passwords for all master nodes.
[0004] Therefore, there is an urgent need for a method, apparatus, computer device, computer-readable storage medium and computer program product for adding a SAN domain name to a server certificate, which can automatically, securely and without human intervention add a SAN domain name to the server certificate of a Kubernetes cluster to improve the availability and security of the cluster. Summary of the invention
[0005] Based on this, it is necessary to provide a method, device, computer equipment, computer-readable storage medium and computer program product for adding SAN domain name to the server certificate of a Kubernetes cluster in an automated, secure and human-intervention manner to improve the availability and security of the cluster in response to the above technical problems.
[0006] In a first aspect, the present application provides a method for adding a SAN domain name to a server certificate, comprising:
[0007] Create a Kubernetes cluster with at least one master node;
[0008] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0009] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0010] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0011] In one embodiment, the method further comprises:
[0012] When creating a stateful workload in the namespace of a Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workload.
[0013] Distribute the pods corresponding to the stateful workload on each master node;
[0014] Mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload;
[0015] Use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
[0016] In one embodiment, the step of using the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node includes:
[0017] Get the SAN domain name supported by the current server certificate of the master node;
[0018] Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster;
[0019] Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed;
[0020] Update the list of the full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0021] In one embodiment, after adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the method further includes:
[0022] Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running;
[0023] Verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0024] In one embodiment, creating a stateful workload in a namespace of a Kubernetes cluster includes:
[0025] Get the processing status of the SAN custom resource object in the Kubernetes cluster;
[0026] When the processing status is pending, a stateful workload is created using the Controller controller according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of the full SAN domain names.
[0027] In one embodiment, after adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the method further includes:
[0028] Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state.
[0029] When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
[0030] In a second aspect, the present application further provides a device for adding a SAN domain name to a server certificate, comprising:
[0031] The cluster creation module is used to create a Kubernetes cluster with at least one master node;
[0032] The setup module is used to deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0033] The setup module is also used to create a stateful workload in the namespace of the Kubernetes cluster when the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster;
[0034] The domain name adding module is used to add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0035] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:
[0036] Create a Kubernetes cluster with at least one master node;
[0037] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0038] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0039] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0040] In a fourth aspect, the present application further provides a computer-readable storage medium storing a computer program for creating a Kubernetes cluster having at least one master node;
[0041] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0042] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0043] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0044] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:
[0045] Create a Kubernetes cluster with at least one master node;
[0046] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0047] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0048] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0049] The method, device, computer equipment, computer-readable storage medium and computer program product for adding the SAN domain name of the server certificate in the above-mentioned way add the SAN domain name to the server certificate in an automated manner, reducing the tediousness of manual operation and reducing the risk caused by human operation errors. The automated process reduces the time for operation and maintenance personnel to manually log in to each master node to execute commands, thereby improving the efficiency of operation. Since it is not necessary to provide the account password of all master nodes, the risk of sensitive information leakage is reduced, and the security of the cluster is enhanced. The automated process reduces manual intervention and reduces the risk of operation errors and system instability caused by human factors. By automatically adding SAN domain names, it is ensured that the cluster can respond quickly when adding new load balancing or public domain names, thereby improving the availability and reliability of the cluster. Using Kubernetes' declarative API and controller mode, the system is easy to maintain and expand, and can easily adapt to changes in cluster scale and new business needs. It reduces the time and energy investment of operation and maintenance personnel in certificate management, thereby reducing the overall operation and maintenance costs. When a new domain name or IP needs to be added to the cluster, the system can respond quickly without waiting for manual operation, thereby improving the flexibility and response speed of the system. In short, managing the server certificate SAN domain name in the Kubernetes cluster in an automated and secure manner improves the availability, security, and operation and maintenance efficiency of the cluster. BRIEF DESCRIPTION OF THE DRAWINGS
[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0051] FIG1 is an application environment diagram of a method for adding a SAN domain name to a server certificate in one embodiment;
[0052] FIG2 is a flow chart of a method for adding a SAN domain name to a server certificate in one embodiment;
[0053] FIG3 is a schematic diagram of a device for adding a SAN domain name to a server certificate in another embodiment;
[0054] FIG4 is a flow chart of a method for adding a SAN domain name to a server certificate in the most detailed embodiment;
[0055] FIG5 is a structural block diagram of a device for adding a SAN domain name to a server certificate in one embodiment;
[0056] FIG. 6 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION
[0057] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0058] The method for adding a SAN domain name to a server certificate provided in an embodiment of the present application can be applied in an application environment as shown in FIG1 . In which, the terminal 102 communicates with the server 104 through a network. The data storage system can store data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on a cloud or other network server.
[0059] The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The server 104 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.
[0060] In an exemplary embodiment, as shown in FIG2 , a method for adding a SAN domain name to a server certificate is provided, and the method is applied to the server in FIG1 as an example for description, including the following steps S202 to S208 . Among them:
[0061] Step S202: Create a Kubernetes cluster with at least one master node.
[0062] Specifically, first, you need to initialize a Kubernetes cluster, which involves configuring the Kubernetes control plane, including at least one master node. The master node is the brain of the cluster, responsible for scheduling Pods, processing cluster events, and storing cluster status. In a Kubernetes cluster, the master node needs to configure the kube-apiserver component, which is the front-end service of the Kubernetes cluster and provides HTTPS RESTful API interface services to the outside world. The kube-apiserver uses the apiserver certificate (stored in / etc / kubernetes / pki / apiserver.crt by default) for TLS authentication.
[0063] In order to ensure high availability, load balancing, and public network accessibility of the cluster, you need to add elastic load balancing (such as ELB) to the master node and bind the public IP and public domain name. This requires adding the ELB VIP or public domain name / IP in the SAN (Subject Alternative Name) field of the api server.crt certificate.
[0064] Step S204: deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod.
[0065] Specifically, deploying the Controller as a Pod usually requires creating a StatefulSet (i.e., stateful workload) resource. StatefulSet is suitable for scenarios that require persistent identification and orderly deployment. In StatefulSet, a Pod template needs to be defined to specify the container image, environment variables, volume mounts, and other configurations running in the Pod.
[0066] Although the Controller can be deployed on any master node, it is usually necessary to specify the node to which the Pod should be scheduled through a Node Selector or Affinity rule. For the master node, specific labels need to be set so that the StatefulSet can schedule the Pod to these nodes.
[0067] In this way, the Controller can take advantage of Kubernetes' native features, such as self-healing, automatic expansion, and load balancing, to improve its reliability and availability. At the same time, it can also seamlessly integrate with other components in the cluster to achieve automated management of the cluster.
[0068] Step S206: When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0069] Specifically, the SAN custom resource object refers to a custom resource definition (CRD), which allows users to declaratively define the SAN domain name / IP list that needs to be added to the apiserver certificate. This CRD is the interface for users to interact with the Kubernetes cluster and is used to trigger the certificate update process.
[0070] The Controller is deployed as a Pod and runs in the Kubernetes cluster. It listens to the creation and changes of SAN custom resource objects through the Kubernetes API. Once a new SAN custom resource object is detected to be created, the Controller will start processing this resource object. The Controller will create a StatefulSet in the specified namespace based on the cluster configuration and the SAN domain name / IP list defined in the SAN custom resource object. The purpose of StatefulSet is to automatically add new SAN domain names / IPs to the apiserver.crt certificates on all master nodes in the cluster.
[0071] Step S208: Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0072] Specifically, StatefulSet is a workload type used in Kubernetes to manage stateful applications. It provides Pods with stable network identities, stable storage, and orderly deployment and expansion capabilities. StatefulSet is used to create Pods, which are distributed to all master nodes in the Kubernetes cluster. The configuration of StatefulSet ensures that exactly one Pod replica runs on each master node.
[0073] The Pod's environment variables will record the SAN domain name / IP list to be added and the certificate storage path so that the containers in the Pod can know what operations need to be performed. In the Pod's initContainer, the business logic of adding the SAN domain name / IP to the server certificate will be executed. This usually includes the following steps:
[0074] Read the SAN list in the current apiserver.crt certificate.
[0075] Merge the new SAN domain name / IP list specified in the environment variable with the current list.
[0076] Update the cluster configuration, including the full SAN domain name / IP list.
[0077] Regenerate or update the apiserver.crt certificate with the updated configuration to include the new SAN domain name / IP.
[0078] Restart the apiserver service or send a signal to the container runtime daemon process for the certificate changes to take effect.
[0079] It should be noted that due to the characteristics of StatefulSet, Pod will start and execute the above business logic on master nodes one by one in sequence to ensure that the certificates on each master node are updated.
[0080] In the above method for adding the SAN domain name of the server certificate, the SAN domain name is added to the server certificate in an automated manner, which reduces the tediousness of manual operations and reduces the risks caused by human operation errors. The automated process reduces the time for operation and maintenance personnel to manually log in to each master node to execute commands, thereby improving the efficiency of operations. Since the account and password of all master nodes do not need to be provided, the risk of sensitive information leakage is reduced, and the security of the cluster is enhanced. The automated process reduces manual intervention and reduces the risk of operation errors and system instability caused by human factors. By automatically adding SAN domain names, it is ensured that the cluster can respond quickly when adding new load balancing or public domain names, thereby improving the availability and reliability of the cluster. Using Kubernetes' declarative API and controller mode, the system is easy to maintain and expand, and can easily adapt to changes in cluster scale and new business needs. It reduces the time and energy investment of operation and maintenance personnel in certificate management, thereby reducing the overall operation and maintenance costs. When a new domain name or IP needs to be added to the cluster, the system can respond quickly without waiting for manual operation, thereby improving the flexibility and response speed of the system. In short, the availability, security and operation and maintenance efficiency of the cluster are improved by managing the SAN domain name of the server certificate in the Kubernetes cluster in an automated and secure manner.
[0081] In an exemplary embodiment, as shown in FIG3 , the method further includes:
[0082] Step S302, in the process of creating a stateful workload in the namespace of the Kubernetes cluster, the number of master nodes of the Kubernetes cluster is used as the number of pods of the stateful workload;
[0083] Step S304, distributing the pods corresponding to the stateful workload on each master node;
[0084] Step S306: mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload;
[0085] Step S308, using the environment variables of the Kubernetes cluster, record the certificate storage path of the SAN domain name to be added on the master node.
[0086] Specifically, when creating a StatefulSet, its number of replicas (pods) is set to match the number of master nodes in the Kubernetes cluster. This is done to ensure that there is a corresponding Pod on each master node to perform a specific task, namely updating the apiserver certificate to include the new SAN domain name / IP.
[0087] By using Node Affinity and Pod Anti-Affinity rules, StatefulSet ensures that Pods are evenly and dispersedly scheduled to each master node. This ensures that each master node has a Pod responsible for performing the certificate update operation, while avoiding excessive concentration of Pods on the same node, improving the reliability and fault tolerance of the system. Pods in StatefulSet need to access the certificate storage directory on the master node (such as / etc / kubernetes / pki / apiserver.crt) and the communication socket file of the container runtime. These directories and files are mounted inside the Pod, allowing the containers in the Pod to directly read and modify the certificate files on the host, and communicate with the container runtime on the host.
[0088] In Kubernetes, you can pass configuration information to the containers in the Pod by setting environment variables. In this scenario, environment variables are used to record the list of SAN domain names / IPs to be added and the path to save the certificate. In this way, when the containers in the Pod are started, they can read these environment variables to understand the SAN domain names / IPs that need to be added to the apiserver certificate and the specific location of the certificate file.
[0089] In this embodiment, through the above configuration, the Kubernetes cluster can automatically manage and update the SAN domain name / IP list of the apiserver certificate without manual intervention. This method not only improves the efficiency and accuracy of operations, but also enhances the security of the cluster, reduces the need for direct operations on the master node, and reduces the risk caused by human operation errors. In addition, this method also makes full use of Kubernetes' native functions, such as StatefulSet, Pod affinity rules, and environment variables, to implement complex cluster management tasks.
[0090] In an exemplary embodiment, the certificate storage path of the SAN domain name to be added is recorded on the master node by using the environment variables of the Kubernetes cluster, including:
[0091] Get the SAN domain name supported by the current server certificate of the master node;
[0092] Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster;
[0093] Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed;
[0094] Update the list of all SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0095] Specifically, first, you need to extract the currently supported SAN domain name list from the server certificate (apiserver.crt) on the master node. This usually involves reading the certificate file and parsing the SAN field to obtain the existing domain name / IP list.
[0096] Through the environment variables of the Kubernetes cluster, the Controller can obtain the user-defined list of SAN domain names / IPs to be added. These environment variables are set when creating a SAN custom resource object (CRD) and contain the new domain names / IPs that the user wants to add to the certificate.
[0097] The Controller combines the SAN domain names supported by the current server certificate with the SAN domain names to be added specified in the environment variables to build a full SAN domain name list. This list contains all the domain names / IPs that need to be supported, that is, the existing ones plus the newly added ones.
[0098] Next, the Controller will update the Kubernetes cluster configuration information and apply the full list of SAN domain names to the cluster configuration. This may involve updating the cluster's API server configuration to ensure that the new SAN domain name is accepted and used by the cluster. While updating the cluster configuration, the Controller will record the certificate storage path for the SAN domain name to be added. This path points to the apiserver.crt file on the master node because this is the server certificate file that needs to update the SAN information.
[0099] Once the cluster configuration is updated, the Controller will use the new full SAN domain name list to update the apiserver.crt certificate on the master node. After updating the certificate, you may need to restart the kube-apiserver service for the new certificate and configuration to take effect. The entire process is automated. Users create SAN custom resource objects through the declarative API, and the Controller monitors these changes and executes the above steps without manual intervention.
[0100] In this embodiment, in this way, the Kubernetes cluster can flexibly manage the SAN domain name of the apiserver certificate to ensure that the certificate can support all domain names / IPs required by the cluster while maintaining the security and high availability of the cluster. This process demonstrates the powerful capabilities of the Kubernetes declarative API and custom resource objects (CRDs), allowing users to programmatically extend and automate cluster management tasks.
[0101] In an exemplary embodiment, after adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the following is further included:
[0102] Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running;
[0103] Verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0104] Specifically, once a new SAN domain name is added to the server certificate (apiserver.crt) on the master node, the kube-apiserver container using the certificate needs to be restarted for the new certificate and SAN domain name to take effect. This is done through the communication socket file of the container runtime, which is mounted to the Pod that performs the update operation. The initContainer in the Pod sends a restart signal to the daemon process of the container runtime by reading the mounted socket file. This triggers the restart of the kube-apiserver container without having to operate directly on the host. The restart operation ensures that the new certificate is immediately used by the kube-apiserver service, allowing access to the Kubernetes cluster through the new SAN domain name.
[0105] After updating the certificate and restarting the relevant containers, you need to verify that the Kubernetes cluster can be successfully accessed through the newly added SAN domain name. This is done by trying to access the cluster's API server using the new domain name / IP. This verification step ensures that the update operation has not disrupted the reachability of the cluster, and that the new SAN domain name has been correctly added to the certificate, and the security and functionality of the cluster have not been affected. Verification can be done through automated test scripts or manual testing to ensure that the new configuration is correct.
[0106] The entire verification process is automated, with the Controller monitoring changes to the SAN custom resource object and triggering the creation and execution of Pods in the StatefulSet. These Pods perform the operation of adding the SAN domain name and send a restart signal after completion. The verification step can also be integrated into the automated process to ensure that the health and functionality of the cluster are checked in a timely manner after each update.
[0107] In this example, the Pod operation and verification steps ensure the security and reliability of the operation. The Pod operation reduces the need for direct access to the master node and reduces security risks. The verification step ensures that any configuration changes will not accidentally interrupt the service. This process shows how to safely and reliably update the SAN domain name of the server certificate in a Kubernetes cluster, and ensure the stability and availability of the cluster after the update through an automated process.
[0108] In an exemplary embodiment, creating a stateful workload in a namespace of a Kubernetes cluster includes:
[0109] Get the processing status of the SAN custom resource object in the Kubernetes cluster;
[0110] When the processing status is pending, use the Controller to create a stateful workload based on the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of all SAN domain names.
[0111] Specifically, in Kubernetes, a custom resource object (CRD) can have its own status field to indicate the current processing status of the resource object. In this scenario, the SAN custom resource object has a status field to indicate whether it has been processed (for example, "pending", "processing", or "processed"). The Controller controller periodically checks the status of the SAN custom resource object. If the status is "pending", it means that there is a new SAN domain name that needs to be added to the server certificate of the master node, and the Controller controller will take action.
[0112] When the status of the SAN custom resource object is "pending", the Controller creates a StatefulSet (stateful workload) based on the following information, including:
[0113] Determine the number of StatefulSet replicas based on the number of Master nodes, ensuring that there is a Pod on each master node.
[0114] Use label selectors to ensure that Pods are scheduled to the correct master node based on the labels of the master node.
[0115] According to the certificate storage path of the SAN domain name to be added, determine the location of the certificate file that the Pod needs to access and modify.
[0116] The full SAN domain name list is a complete list that combines the currently supported SAN domain names and the newly added SAN domain names, and is used to update certificates.
[0117] The Pods in the StatefulSet will contain an initContainer, which is used to execute the business logic of updating the SAN list of the apiserver certificate. This includes steps such as reading the current SAN list, merging the old and new SAN lists, and updating the certificate file. The Controller monitors the status of the Pods in the StatefulSet to ensure that all Pods have successfully executed the update operation. Once all Pods have completed the task, the Controller updates the status of the SAN custom resource object and marks it as "processed".
[0118] Through this process, the Kubernetes cluster can automatically manage the SAN domain name of the apiserver certificate, ensuring that the certificate can support all domain names / IPs required by the cluster while maintaining the security and high availability of the cluster. This process demonstrates the power of the Kubernetes declarative API and custom resource objects (CRDs), allowing users to programmatically extend and automate cluster management tasks.
[0119] In an exemplary embodiment, after adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the following is further included:
[0120] Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state.
[0121] When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
[0122] Specifically, the Controller is responsible for monitoring the status of each Pod in the StatefulSet. In particular, it needs to check whether each Pod is in the "Ready state", which means that the Pod has been successfully started and the container inside it is running and ready to accept traffic. The Controller compares the number of Pods in the Ready state with the number of master nodes in the cluster. If these two numbers are the same, this indicates that the corresponding Pods on all master nodes have been successfully started and are ready.
[0123] When the number of Pods in the Prepared state matches the number of master nodes, the Controller can reasonably infer that the server certificates of all master nodes have successfully added the SAN domain name. This is because each Pod is responsible for performing the operation of adding the SAN domain name on its corresponding master node. Once it is confirmed that the server certificates of all master nodes have been updated, the Controller will delete the StatefulSet. This is because the purpose of the StatefulSet has been achieved, that is, adding the SAN domain name on each master node, and these Pods are no longer needed to continue running.
[0124] Finally, the Controller updates the status of the SAN custom resource object and marks it as "processed" or other similar status to indicate that the operation of adding the SAN domain name has been successfully completed. In this way, other system components or operation and maintenance personnel can know the status of the certificate update and take further actions accordingly, such as verifying whether the update is successful.
[0125] In this example, through this process, the Kubernetes cluster can automatically manage the SAN domain name of the apiserver certificate to ensure that the certificate can support all domain names / IPs required by the cluster while maintaining the security and high availability of the cluster. This process demonstrates the powerful capabilities of the Kubernetes declarative API and custom resource objects (CRDs), allowing users to programmatically extend and automate cluster management tasks.
[0126] The most detailed embodiment of this application is:
[0127] As shown in Figure 4, the technical solution proposed in this paper is as follows:
[0128] 1. Create a Kubernetes cluster with multiple master nodes, including the storage path attribute of the apiserver certificate on the master node in the Kubernetes cluster and the source attribute of the SAN domain name / IP list to be added.
[0129] 2. Deployed in the Kubernetes cluster as a workload pod, responsible for monitoring the creation of custom resource objects CRD of the SAN certificate domain name in the cluster; install and deploy the Controller controller.
[0130] 3. After the Controller is started, it monitors the SAN custom resource object through the kube-apiserver.
[0131] 4. Bind the load balancer or public IP or public domain name to the master node of the Kubernetes cluster to obtain the domain name / IP that needs to be added to the SAN list.
[0132] 5. Use kubectl, client-go, or the Kubernetes console web UI to create a SAN custom resource object with a status of pending.
[0133] 6. The Controller monitors the creation of the SAN custom resource object and its status is pending. It obtains the SAN domain name list to be added through the source attribute of the SAN custom resource.
[0134] 7. The Controller creates a stateful workload StatefulSet based on the number of cluster master nodes, master node labels, apiserver certificate storage path on the master node, SAN domain name list, and other configurations. The StatefulSet meets the following constraints:
[0135] (1) The number of master nodes is used as the number of replicas of StatefulSet;
[0136] (2) Through the node affinity and pod anti-affinity features, the pods corresponding to the StatefulSet are distributed on each master node;
[0137] (3) Use the pod corresponding to StatefulSet to mount the certificate storage directory on the master node and the sock file for interactive communication between the client and daemon processes when the container is running;
[0138] (4) StatefulSet records the SAN domain name / IP list and certificate storage path to be added through environment variables;
[0139] (5) Execute the business logic of adding the certificate SAN domain name / IP in the initContainer of StatefulSet; the business logic is as follows:
[0140] (5.1) Read apiserver.crt in the certificate save path and obtain the SAN domain name / IP list supported by the current certificate;
[0141] (5.2) Read the environment variables to obtain the list of SAN domain names / IPs that need to be added, and combine them with the domain names / IPs that are already supported in the current Kubernetes cluster to obtain the full list of SAN domain names / IPs that the apiserver.crt certificate on the cluster master node needs to support.
[0142] (5.3), obtain cluster configuration;
[0143] (5.4) Update the full list of SAN domain names / IP addresses that the cluster needs to support in the cluster configuration;
[0144] (5.5) Use this cluster configuration to update the SAN domain name / IP list supported by the apiserver.crt certificate in the certificate directory mounted on this node;
[0145] (5.6) Send a restart signal to the container runtime daemon process through the mounted container runtime sock to restart the cluster apiserver container;
[0146] 8. The pods corresponding to StatefulSet are started on the master nodes in the cluster one by one, and the SAN domain name / IP of the current master node apiserver.crt certificate is added in the initContainer of the pod.
[0147] 9. The Controller detects the number of replicas in the Ready state in the status of the StatefulSet. When the number of Ready replicas is consistent with the number of master nodes, it means that the addition of SAN domain names / IPs on all master nodes has been completed. The StatefulSet is deleted and the status of the SAN certificate domain name CR resource is updated.
[0148] 10. The Controller updates the status of the SAN custom resource object to processed.
[0149] 11. Use the new domain name / IP to access the Kubernetes cluster, and the results will be returned normally.
[0150] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.
[0151] Based on the same inventive concept, the embodiment of the present application also provides a device for adding the SAN domain name of the server certificate for implementing the method for adding the SAN domain name of the server certificate involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiment of the device for adding the SAN domain name of one or more server certificates provided below can be referred to the limitations of the method for adding the SAN domain name of the server certificate above, and will not be repeated here.
[0152] In an exemplary embodiment, as shown in FIG5 , a device for adding a SAN domain name to a server certificate is provided, comprising:
[0153] A cluster creation module 502 is used to create a Kubernetes cluster with at least one master node;
[0154] A setting module 504 is used to deploy a Controller controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0155] The setting module 504 is further used to create a stateful workload in the namespace of the Kubernetes cluster when the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster;
[0156] The domain name adding module 506 is used to add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0157] In an exemplary embodiment, the setting module 504 is also used to use the number of master nodes of the Kubernetes cluster as the number of pods of the stateful workload during the process of creating a stateful workload in the namespace of the Kubernetes cluster; disperse the pods corresponding to the stateful workload on each master node; mount the certificate storage directory on the master node and the communication socket file during the container runtime to the pod corresponding to the stateful workload; and use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
[0158] In an exemplary embodiment, the domain name adding module 506 is also used to obtain the SAN domain names supported by the current server certificate of the master node; obtain the SAN domain name to be added according to the environment variables of the Kubernetes cluster; build a list of full SAN domain names supported by the current server certificate based on the SAN domain name to be added and the SAN domain name supported by the current server certificate; update the list of full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0159] In an exemplary embodiment, the domain name adding module 506 is used to restart the container corresponding to the server certificate with the SAN domain name added in the Kubernetes cluster according to the communication socket file when the container is running; and verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0160] In an exemplary embodiment, the domain name adding module 506 is used to obtain the processing status of the SAN custom resource object in the Kubernetes cluster; when the processing status is pending, the Controller controller is used to create a stateful workload according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of all SAN domain names.
[0161] In an exemplary embodiment, the domain name adding module 506 is used to use the Controller controller to detect whether the status of the pod corresponding to the stateful workload is in a ready state; when the number of pods in the ready state is consistent with the number of master nodes, it is determined that the SAN domain name has been successfully added to the server certificates of all master nodes, the stateful workload is deleted, and the processing status of the SAN custom resource object is updated.
[0162] Each module in the device for adding a SAN domain name of the server certificate can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.
[0163] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG6. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for adding a SAN domain name to a server certificate is implemented.
[0164] Those skilled in the art will understand that the structure shown in FIG. 6 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.
[0165] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:
[0166] Create a Kubernetes cluster with at least one master node;
[0167] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0168] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0169] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0170] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0171] When creating a stateful workload in the namespace of a Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workload.
[0172] Distribute the pods corresponding to the stateful workload on each master node;
[0173] Mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload;
[0174] Use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
[0175] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0176] Get the SAN domain name supported by the current server certificate of the master node;
[0177] Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster;
[0178] Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed;
[0179] Update the list of the full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0180] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0181] Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running;
[0182] Verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0183] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0184] Get the processing status of the SAN custom resource object in the Kubernetes cluster;
[0185] When the processing status is pending, a stateful workload is created using the Controller controller according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of the full SAN domain names.
[0186] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0187] Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state.
[0188] When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
[0189] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:
[0190] Create a Kubernetes cluster with at least one master node;
[0191] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0192] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0193] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0194] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0195] When creating a stateful workload in the namespace of a Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workload.
[0196] Distribute the pods corresponding to the stateful workload on each master node;
[0197] Mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload;
[0198] Use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
[0199] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0200] Get the SAN domain name supported by the current server certificate of the master node;
[0201] Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster;
[0202] Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed;
[0203] Update the list of the full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0204] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0205] Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running;
[0206] Verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0207] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0208] Get the processing status of the SAN custom resource object in the Kubernetes cluster;
[0209] When the processing status is pending, a stateful workload is created using the Controller controller according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of the full SAN domain names.
[0210] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0211] Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state.
[0212] When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
[0213] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:
[0214] Create a Kubernetes cluster with at least one master node;
[0215] Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod;
[0216] When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.
[0217] Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
[0218] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0219] When creating a stateful workload in the namespace of a Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workload.
[0220] Distribute the pods corresponding to the stateful workload on each master node;
[0221] Mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload;
[0222] Use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
[0223] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0224] Get the SAN domain name supported by the current server certificate of the master node;
[0225] Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster;
[0226] Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed;
[0227] Update the list of the full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
[0228] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0229] Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running;
[0230] Verify the access validity of the Kubernetes cluster through the added SAN domain name.
[0231] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0232] Get the processing status of the SAN custom resource object in the Kubernetes cluster;
[0233] When the processing status is pending, a stateful workload is created using the Controller controller according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of the full SAN domain names.
[0234] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0235] Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state.
[0236] When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
[0237] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.
[0238] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.
[0239] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0240] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.
Claims
1. A method for adding a SAN domain name to a server certificate, characterized in that: The method comprises: Create a Kubernetes cluster with at least one master node; Deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod; When the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster. Add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
2. The method according to claim 1, characterized in that The method further comprises: When creating a stateful workload in the namespace of a Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workload. Distribute the pods corresponding to the stateful workload on each master node; Mount the certificate storage directory on the master node and the communication socket file during container runtime to the pod corresponding to the stateful workload; Use the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node.
3. The method according to claim 2, characterized in that The method of using the environment variables of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node includes: Get the SAN domain name supported by the current server certificate of the master node; Get the SAN domain name to be added based on the environment variables of the Kubernetes cluster; Based on the SAN domain name to be added and the SAN domain names supported by the current server certificate, a list of all SAN domain names supported by the current server certificate is constructed; Update the list of the full SAN domain names in the configuration information of the Kubernetes cluster, and record the certificate storage path of the SAN domain name to be added on the master node.
4. The method according to claim 1, characterized in that After adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the following steps are also included: Restart the container corresponding to the server certificate to which the SAN domain name has been added in the Kubernetes cluster according to the communication socket file when the container is running; Verify the access validity of the Kubernetes cluster through the added SAN domain name.
5. The method according to claim 3, characterized in that: Creating a stateful workload in the namespace of a Kubernetes cluster includes: Get the processing status of the SAN custom resource object in the Kubernetes cluster; When the processing status is pending, a stateful workload is created using the Controller controller according to the number of master nodes, the labels of the master nodes, the certificate storage path of the SAN domain name to be added, and the list of the full SAN domain names.
6. The method according to claim 5, characterized in that After adding the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the following steps are also included: Use the Controller to detect whether the pod corresponding to the stateful workload is in the ready state. When the number of pods in the preparation state is the same as the number of master nodes, confirm that the SAN domain name has been successfully added to the server certificates of all master nodes, delete the stateful workload, and update the processing status of the SAN custom resource object.
7. A device for adding a SAN domain name to a server certificate, characterized in that: The device comprises: The cluster creation module is used to create a Kubernetes cluster with at least one master node; The setup module is used to deploy the Controller on any master node in the Kubernetes cluster in the form of a workload pod; The setting module is also used to create a stateful workload in the namespace of the Kubernetes cluster when the Controller monitors that a SAN custom resource object has been created in the Kubernetes cluster; The domain name adding module is used to add the SAN domain name to the server certificates of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.
10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.
Citation Information
Patent Citations
Database deployment method, domain name resolution method and related devices
CN115687294A
Server security check method and device based on domain name list
CN116545705A
Cluster deployment method and device, equipment and storage medium
CN117348975A
Intelligent Process Management in Serverless Workflow Cloud Environments
US20240111588A1
Cited By
Switch management method and device applied to kubernetes GPU cluster, electronic equipment, storage medium and computer program product
CN121151353A