Method and device for adding SAN domain name of server certificate and computer device

Abstract

The application relates to a SAN domain name adding method and device of a server certificate, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: creating a Kubernetes cluster with at least one master node; deploying a Controller controller in the form of a workload pod on any master node in the Kubernetes cluster; creating a stateful workload in the namespace of the Kubernetes cluster in the case that the Controller controller listens to the creation of a SAN custom resource object in the Kubernetes cluster; and adding a SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload. The method can automatically, safely and without manual intervention add a SAN domain name to the server certificate of the Kubernetes cluster, so as to improve the availability and security of the cluster.

Description

Technical Field

[0001] This application relates to the field of cloud platform technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for adding a server certificate to a SAN domain name. Background Technology

[0002] In a Kubernetes cluster, the kube-apiserver component provides a two-way TLS-authenticated HTTPS interface. During TLS authentication, both the client and server need to verify the server's certificate. The server certificate kube-apiserver.crt lists the SAN domains supported by the server through the SAN field. To ensure high availability, load balancing, and public network reachability of the kube-apiserver cluster, it is often necessary to add an elastic load balancer (such as ELB) to the master node. Therefore, SAN domains also need to be added to the SAN list in the server certificate kube-apiserver.crt.

[0003] The current common practice in the community for adding SAN domain names to the kube-apiserver.crt server certificate is as follows: Cluster operations personnel log in to the cluster master node using their username and password and manually execute the relevant commands and scripts. This approach is time-consuming, cumbersome, and prone to errors. Alternatively, automated operations technologies such as Ansible can be used to write Ansible playbook scripts to automatically add the SAN domain name. This approach requires setting up an Ansible environment and providing the usernames and passwords for all master nodes.

[0004] Therefore, there is an urgent need for a method, device, computer equipment, computer-readable storage medium, and computer program product for adding SAN domain names to server certificates for Kubernetes clusters in an automated, secure, and manual manner to improve the availability and security of the clusters. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for adding SAN domain names to server certificates of Kubernetes clusters in an automated, secure, and manual manner to improve the availability and security of the cluster, in order to address the aforementioned technical problems.

[0006] Firstly, this application provides a method for adding a SAN domain name to a server certificate, including:

[0007] Create a Kubernetes cluster with at least one master node;

[0008] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0009] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0010] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0011] In one embodiment, the method further includes:

[0012] When creating stateful workloads 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 stateful workloads across each master node;

[0014] Mount the certificate storage directory on the master node and the communication socket file for container runtime to the pod corresponding to the stateful workload.

[0015] By utilizing the environment variables of the Kubernetes cluster, the certificate storage path for the SAN domain name to be added is recorded on the master node.

[0016] In one embodiment, the step of using Kubernetes cluster environment variables to record the certificate storage path of the SAN domain name to be added on the master node includes:

[0017] Get the SAN domain names supported by the current server certificate of the master node;

[0018] Based on the Kubernetes cluster's environment variables, obtain the SAN domain name to be added;

[0019] Based on the SAN domains to be added and the SAN domains supported by the current server certificate, construct a list of all SAN domains supported by the current server certificate;

[0020] Update the list of all SAN domain names in the Kubernetes cluster configuration information, and record the certificate storage path of the SAN domain names to be added on the master node.

[0021] In one embodiment, after adding the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster via the pod corresponding to the stateful workload, the method further includes:

[0022] Restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster based on the communication socket file of the container runtime.

[0023] Verify the validity of access to the Kubernetes cluster using the added SAN domain name.

[0024] In one embodiment, creating stateful workloads in the namespace of the Kubernetes cluster includes:

[0025] Get the processing status of a custom SAN resource object in the Kubernetes cluster;

[0026] When the processing status is pending, the Controller is used 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 domains to be added, and the list of all SAN domains.

[0027] In one embodiment, after adding the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster via the pod corresponding to the stateful workload, the method further includes:

[0028] Use the Controller to detect whether the state of the pod corresponding to the stateful workload is ready.

[0029] Assuming the number of pods in the ready state matches the number of master nodes, ensure that the SAN domain name has been successfully added to the server certificates of all master nodes, delete stateful workloads, and update the processing status of SAN custom resource objects.

[0030] Secondly, this application also 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 configuration module is used to deploy the Controller on any master node in a Kubernetes cluster as a workload pod.

[0033] The configuration module is also used to create stateful workloads in the namespace of the Kubernetes cluster when the Controller listens to the creation of custom SAN resource objects in the Kubernetes cluster.

[0034] The domain name addition module is used to add SAN domain names to the server certificates of all master nodes in a Kubernetes cluster for pods corresponding to stateful workloads.

[0035] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0036] Create a Kubernetes cluster with at least one master node;

[0037] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0038] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0039] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0040] Fourthly, this application also provides a computer-readable storage medium having stored thereon a computer program that creates a Kubernetes cluster with at least one master node;

[0041] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0042] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0043] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0044] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0045] Create a Kubernetes cluster with at least one master node;

[0046] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0047] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0048] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0049] The aforementioned methods, devices, computer equipment, computer-readable storage media, and computer program products for adding SAN domain names to server certificates automate the process, reducing the tedium of manual operations and mitigating the risks associated with human error. The automated process reduces the time spent by operations personnel manually logging into each master node to execute commands, improving operational efficiency. Since it eliminates the need to provide account passwords for all master nodes, it reduces the risk of sensitive information leakage and enhances cluster security. The automated process also reduces human intervention, lowering the risk of operational errors and system instability caused by human factors. Automated SAN domain name addition ensures rapid response when adding new load balancers or public domain names, improving cluster availability and reliability. Using Kubernetes' declarative API and controller pattern makes the system easy to maintain and scale, readily adapting to changes in cluster size and new business needs. It reduces the time and effort invested by operations personnel in certificate management, thereby lowering overall operational costs. When new domain names or IPs need to be added to the cluster, the system can respond quickly without waiting for manual intervention, improving system flexibility and responsiveness. In summary, managing server-side certificates and SAN domains in a Kubernetes cluster in an automated and secure manner improves the cluster's availability, security, and operational efficiency. Attached Figure Description

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

[0051] Figure 1 This is an application environment diagram of a method for adding a SAN domain name to a server certificate in one embodiment;

[0052] Figure 2 This is a flowchart illustrating a method for adding a SAN domain name to a server certificate in one embodiment;

[0053] Figure 3 This is an architectural diagram of a device for adding a SAN domain name to a server certificate in another embodiment;

[0054] Figure 4 This is a flowchart illustrating the method for adding a SAN domain name to a server certificate in the most detailed embodiment.

[0055] Figure 5 This is a structural block diagram of a device for adding a SAN domain name to a server certificate in one embodiment;

[0056] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0058] The method for adding a SAN domain name to a server certificate provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server.

[0059] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. The server 104 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.

[0060] In one exemplary embodiment, such as Figure 2 As shown, a method for adding a server certificate to a SAN domain name is provided, which can be applied to... Figure 1 Taking the server in the example, the explanation includes the following steps S202 to S208. Wherein:

[0061] Step S202: Create a Kubernetes cluster with at least one master node.

[0062] Specifically, the first step is 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, handling cluster events, and storing cluster state. Within the Kubernetes cluster, the master node needs to be configured with the kube-apiserver component, which is the front-end service of the Kubernetes cluster, providing HTTPS RESTful API interface services. kube-apiserver uses an apiserver certificate (stored by default in / etc / kubernetes / pki / apiserver.crt) for TLS authentication.

[0063] To ensure high availability, load balancing, and public network reachability of the cluster, an elastic load balancer (such as ELB) needs to be added to the master node and bound to a public IP address and domain name. This requires adding the ELB's VIP or public domain name / IP address to the SAN (Subject Alternative Name) field of the apiserver.crt certificate.

[0064] Step S204: Deploy the Controller as a workload pod on any master node in the Kubernetes cluster.

[0065] Specifically, deploying a Controller as a Pod typically requires creating a StatefulSet (i.e., a stateful workload) resource. StatefulSets are suitable for scenarios requiring persistent identification and ordered deployment. Within a StatefulSet, a Pod template needs to be defined, specifying the container image running within the Pod, environment variables, volume mounts, and other configurations.

[0066] While a controller can be deployed on any master node, it's typically necessary to specify the node where a Pod should be scheduled using a node selector or affinity rules. For master nodes, specific labels need to be set so that the StatefulSet can schedule Pods to those nodes.

[0067] In this way, the Controller can leverage Kubernetes' native features, such as self-healing, auto-scaling, and load balancing, to improve its reliability and availability. Simultaneously, it can seamlessly integrate with other components in the cluster, enabling automated cluster management.

[0068] Step S206: If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, create a stateful workload in the namespace of the Kubernetes cluster.

[0069] Specifically, a SAN custom resource object refers to a custom resource definition (CRD) that allows users to declaratively define the list of SAN domain names / IPs that need 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 a Kubernetes cluster. It listens for the creation and changes of SAN custom resource objects via the Kubernetes API. Once a new SAN custom resource object is detected, the Controller begins processing it. Based on the cluster configuration and the list of SAN domain names / IPs defined in the SAN custom resource object, the Controller creates a StatefulSet in the specified namespace. The purpose of the StatefulSet is to automatically add the new SAN domain name / IP to the apiserver.crt certificate on all master nodes of the cluster.

[0071] Step S208: Add the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.

[0072] Specifically, StatefulSet is a workload type in Kubernetes used to manage stateful applications. It provides Pods with stable network identification, stable storage, and ordered deployment and scaling capabilities. StatefulSet is used to create Pods, which are distributed across all master nodes in the Kubernetes cluster. The configuration of a StatefulSet ensures that exactly one Pod replica runs on each master node.

[0073] The Pod's environment variables record a list of SAN domains / IPs to be added and the certificate storage path, so that containers within the Pod know which operations need to be performed. In the Pod's `initContainer`, the business logic for adding SAN domains / IPs to the server certificate is executed. This typically includes the following steps:

[0074] Read the SAN list from the current apiserver.crt certificate.

[0075] Merge the list of new SAN domain names / IPs specified in the environment variables with the current list.

[0076] Update the cluster configuration, including a full list of SAN domain names / IPs.

[0077] Regenerate or update the apiserver.crt certificate using the updated configuration, making it include the new SAN domain name / IP.

[0078] Restart the apiserver service or send a signal to the container runtime daemon process to make the certificate changes take effect.

[0079] It should be noted that, due to the characteristics of StatefulSet, the Pod will start and execute the above business logic on one master node after another in sequence, ensuring that the certificate on each master node is updated.

[0080] The above method for adding SAN domain names to server certificates automates the process, reducing the tedium of manual operations and mitigating the risks associated with human error. The automated process reduces the time spent by operations personnel manually logging into each master node to execute commands, improving operational efficiency. Since it eliminates the need to provide the account passwords for all master nodes, it reduces the risk of sensitive information leakage, enhancing cluster security. The automated process also reduces human intervention, mitigating the risks of operational errors and system instability caused by human factors. Automated SAN domain name addition ensures the cluster can respond quickly when adding new load balancers or public domain names, improving cluster availability and reliability. Using Kubernetes' declarative API and controller pattern makes the system easy to maintain and scale, readily adapting to changes in cluster size and new business needs. It reduces the time and effort operations personnel invest in certificate management, thereby lowering overall operational costs. When new domain names or IPs need to be added to the cluster, the system can respond quickly without waiting for manual intervention, improving system flexibility and response speed. In summary, managing server certificate SAN domain names in a Kubernetes cluster in an automated and secure manner improves cluster availability, security, and operational efficiency.

[0081] In one exemplary embodiment, such as Figure 3 As shown, the method also includes:

[0082] In step S302, during the process of creating stateful workloads in the namespace of the Kubernetes cluster, the number of master nodes in the Kubernetes cluster is used as the number of pods for the stateful workloads.

[0083] Step S304: Distribute the pods corresponding to stateful workloads across each master node;

[0084] Step S306: Mount the certificate storage directory on the master node and the communication socket file for 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 a StatefulSet is created, its replica count (number of pods) is set to match the number of master nodes in the Kubernetes cluster. This is done to ensure that each master node has a corresponding pod 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 distributed across each master node. This guarantees that each master node has a Pod responsible for performing certificate updates, while avoiding excessive concentration of Pods on the same node, thus improving system reliability and fault tolerance. Pods in a StatefulSet need access to the certificate storage directory on the master node (e.g., / etc / kubernetes / pki / apiserver.crt) and the communication socket files for the container runtime. These directories and files are mounted inside the Pod, allowing containers within the Pod to directly read and modify certificate files on the host machine and communicate with container runtimes on the host machine.

[0088] In Kubernetes, environment variables can be used to pass configuration information to containers within a Pod. In this scenario, environment variables are used to record the list of SAN domains / IPs to be added and the storage path of the certificates. This way, when containers within the Pod start, they can read these environment variables to understand the SAN domains / IPs that need to be added to the apiserver certificate, as well as the specific location of the certificate files.

[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 operational efficiency and accuracy but also enhances cluster security, reduces the need for direct operation of the master node, and lowers the risk caused by human error. Furthermore, this method fully utilizes native Kubernetes features, such as StatefulSet, Pod affinity rules, and environment variables, to accomplish complex cluster management tasks.

[0090] In one exemplary embodiment, the certificate storage path for the SAN domain name to be added is recorded on the master node using Kubernetes cluster environment variables, including:

[0091] Get the SAN domain names supported by the current server certificate of the master node;

[0092] Based on the Kubernetes cluster's environment variables, obtain the SAN domain name to be added;

[0093] Based on the SAN domains to be added and the SAN domains supported by the current server certificate, construct a list of all SAN domains supported by the current server certificate;

[0094] Update the list of all SAN domains in the Kubernetes cluster configuration information, and record the certificate storage path of the SAN domains to be added on the master node.

[0095] Specifically, the first step is to extract the list of currently supported SAN domain names from the server certificate (apiserver.crt) on the master node. This typically involves reading the certificate file and parsing the SAN fields to obtain the existing list of domain names / IPs.

[0096] The Controller can obtain a user-defined list of SAN domain names / IPs to be added using environment variables in the Kubernetes cluster. These environment variables are set when creating SAN Custom Resource Objects (CRDs) and contain the new domain names / IPs that the user wants to add to the certificate.

[0097] The Controller performs a union operation on the SAN domains currently supported by the server certificate and the SAN domains to be added specified in the environment variables, constructing a complete list of SAN domains. This list contains all the domains / IPs that need to be supported, including existing ones and newly added ones.

[0098] Next, the Controller updates the Kubernetes cluster configuration, applying 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 names are accepted and used by the cluster. While updating the cluster configuration, the Controller records the certificate storage path for the SAN domain names to be added. This path points to the apiserver.crt file on the master node, as this is the server-side certificate file for which the SAN information needs to be updated.

[0099] Once the cluster configuration update is complete, the Controller will update the apiserver.crt certificate on the master node using the new full list of SAN domain names. After updating the certificate, the kube-apiserver service may need to be restarted for the new certificate and configuration to take effect. The entire process is automated; users create custom SAN resource objects through the declarative API, and the Controller listens for these changes and executes the above steps without manual intervention.

[0100] In this embodiment, the Kubernetes cluster can flexibly manage the SAN domain name of the apiserver certificate in this way, ensuring that the certificate supports all the domain names / IPs required by the cluster, while maintaining the cluster's security and high availability. This process demonstrates the power of Kubernetes' declarative API and Custom Resource Objects (CRDs), allowing users to programmatically extend and automate cluster management tasks.

[0101] In one exemplary embodiment, after adding the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the method further includes:

[0102] Restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster based on the communication socket file of the container runtime.

[0103] Verify the validity of access to the Kubernetes cluster using 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 that certificate needs to be restarted for the new certificate and SAN domain name to take effect. This is done via a communication socket file within the container runtime, which is mounted to the Pod performing the update operation. The initContainer within the Pod reads the mounted socket file and sends a restart signal to the container runtime daemon process. This triggers a restart of the kube-apiserver container without requiring direct action on the host machine. The restart operation ensures that the new certificate is immediately used by the kube-apiserver service, thus allowing access to the Kubernetes cluster via the new SAN domain name.

[0105] After updating the certificates and restarting the relevant containers, it's necessary to verify that the Kubernetes cluster can be successfully accessed via the newly added SAN domain name. This is done by attempting to access the cluster's API server using the new domain name / IP. This verification step ensures that the update operation did not break cluster reachability, that the new SAN domain name was correctly added to the certificates, and that the cluster's security and functionality are unaffected. Verification can be performed using automated test scripts or manual testing to ensure the new configuration is correct.

[0106] The entire verification process is automated. The Controller listens for changes to custom resource objects in the SAN and triggers the creation and execution of Pods in the StatefulSet. These Pods perform the operation of adding SAN domain names and send a restart signal upon completion. The verification steps can also be integrated into the automated process to ensure that the health and functionality of the cluster are checked promptly after each update.

[0107] In this embodiment, the security and reliability of the operation are ensured through Pod operations and verification steps. Pod operations reduce the need for direct access to the master node, thus lowering security risks. The verification steps ensure that any configuration changes will not unexpectedly interrupt the service. This process demonstrates how to securely and reliably update the SAN domain name of the server certificate in a Kubernetes cluster, and ensures the stability and availability of the cluster after the update through an automated process.

[0108] In one exemplary embodiment, a stateful workload is created in the namespace of a Kubernetes cluster, including:

[0109] Get the processing status of a custom SAN resource object in the Kubernetes cluster;

[0110] When the processing status is pending, the Controller is used to create stateful workloads based on the number of master nodes, the labels of the master nodes, the certificate storage paths of the SAN domains to be added, and a list of all SAN domains.

[0111] Specifically, in Kubernetes, Custom Resource Objects (CRDs) can have their own status fields to indicate the current processing status of the resource object. In this scenario, the SAN CRD has a status field indicating whether it has been processed (e.g., "Pending," "Processing," or "Processed"). The Controller periodically checks the status of the SAN CRD. If the status is "Pending," it means that a new SAN domain name needs to be added to the server certificate of the master node, and the Controller will take action.

[0112] When a SAN custom resource object is in the "Pending" state, the Controller creates a StatefulSet (stateful workload) based on the following information:

[0113] Determine the number of replicas of the StatefulSet based on the number of Master nodes, ensuring that there is one Pod on each Master node.

[0114] Based on the label of the Master node, a label selector is used to ensure that the Pod is scheduled to the correct Master node.

[0115] Based on 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 list of SAN domains is a complete list that combines currently supported SAN domains and newly added SAN domains, and is used for certificate updates.

[0117] The Pods in a StatefulSet will contain an initContainer, which executes the business logic for updating the apiserver certificate SAN list. This includes steps such as reading the current SAN list, merging the old and new SAN lists, and updating the certificate files. The Controller monitors the status of the Pods in the StatefulSet to ensure that all Pods have successfully performed the update operation. Once all Pods have completed their tasks, the Controller updates the status of the SAN custom resource object, marking it as "processed".

[0118] This process enables the Kubernetes cluster to automatically manage the SAN domain name of the apiserver certificate, ensuring that the certificate supports all the domain names / IPs required by the cluster while maintaining cluster security and high availability. This process demonstrates the power of Kubernetes' declarative API and Custom Resource Objects (CRDs), allowing users to programmatically extend and automate cluster management tasks.

[0119] In one exemplary embodiment, after adding the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the method further includes:

[0120] Use the Controller to detect whether the state of the pod corresponding to the stateful workload is ready.

[0121] Assuming the number of pods in the ready state matches the number of master nodes, ensure that the SAN domain name has been successfully added to the server certificates of all master nodes, delete stateful workloads, and update the processing status of SAN custom resource objects.

[0122] Specifically, the Controller is responsible for monitoring the status of each Pod in the StatefulSet. In particular, it needs to check if each Pod is in the "Ready" state, meaning the Pod has successfully started and its internal containers are 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 match, it indicates that the corresponding Pods on all master nodes have successfully started and are ready.

[0123] When the number of Pods in the ready state matches the number of master nodes, the Controller can reasonably infer that the server certificates on all master nodes have been successfully added to the SAN domain. This is because each Pod is responsible for performing the SAN domain addition operation on its corresponding master node. Once it is confirmed that the server certificates on all master nodes have been updated, the Controller will delete the StatefulSet. This is because the purpose of the StatefulSet has been achieved—adding the SAN domain to each master node—and these Pods are no longer needed to run.

[0124] Finally, the Controller updates the status of the SAN custom resource object, marking it as "processed" or another similar status to indicate that the operation of adding the SAN domain name has been successfully completed. This allows other system components or operations personnel to know the certificate update status and take further action, such as verifying whether the update was successful.

[0125] In this embodiment, through this process, the Kubernetes cluster can automatically manage the SAN domain name of the apiserver certificate, ensuring that the certificate supports all the domain names / IPs required by the cluster, while maintaining the cluster's security and high availability. This process demonstrates the power of 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 as follows:

[0127] like Figure 4 As shown, 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 list of SAN domain names / IPs to be added.

[0129] 2. Deployed in the Kubernetes cluster as a workload pod, responsible for listening to the creation of custom resource objects (CRDs) for SAN certificate domains in the cluster; install and deploy the Controller.

[0130] 3. After the Controller starts, it listens for custom resource objects in the SAN through kube-apiserver.

[0131] 4. Bind a load balancer, public IP address, or public domain name to the master node of the Kubernetes cluster to obtain the domain name / IP address that needs to be added to the SAN list.

[0132] 5. Create a custom SAN resource object using kubectl, client-go, or the Kubernetes console web UI. The object should be set to "pending".

[0133] 6. The Controller detects the creation of a SAN custom resource object and its status is pending. It then obtains a list of SAN domain names to be added through the source attribute of the SAN custom resource.

[0134] 7. The Controller creates a StatefulSet of stateful workloads based on configurations such as the number of master nodes in the cluster, master node labels, the path to the API server certificates on the master nodes, and the SAN domain name list. This StatefulSet satisfies the following constraints:

[0135] (1) Use the number of master nodes as the number of replicas of the StatefulSet;

[0136] (2) By leveraging the node affinity and pod anti-affinity properties, the pods corresponding to the StatefulSet are distributed across each master node;

[0137] (3) Using the pod corresponding to StatefulSet, mount the certificate storage directory on the master node and the sock file for communication between the client and daemon process during container runtime;

[0138] (4) StatefulSet records the list of SAN domain names / IPs to be added and the certificate storage path 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 the apiserver.crt file in the certificate storage path and obtain the list of SAN domain names / IPs supported by the current certificate;

[0141] (5.2) Read the environment variables, obtain the list of new SAN domain names / IPs, and combine it with the domain names / IPs 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 finally needs to support;

[0142] (5.3) Obtain cluster configuration;

[0143] (5.4) Update the list of all SAN domain names / IPs that the cluster needs to support in the cluster configuration;

[0144] (5.5) Use the cluster configuration to update the list of SAN domain names / IPs supported by the certificate in the apiserver.crt file under the mounted certificate directory on this node;

[0145] (5.6) Restart the cluster apiserver container by sending a restart signal to the container runtime daemon process through the mounted container runtime sock;

[0146] 8. The pods corresponding to the StatefulSet are started sequentially on the master node in the cluster. The initContainer of the pod completes the addition of the SAN domain name / IP of the certificate in the apiserver.crt of the current master node.

[0147] 9. The Controller checks the number of replicas in the Ready state of the StatefulSet's status. When the number of Ready replicas is the same as the number of master nodes, it means that the addition of SAN domain names / IPs on all master nodes has been completed. The Controller then deletes the StatefulSet and updates the status of the SAN certificate domain name CR resource.

[0148] 10. The Controller updates the status of the SAN custom resource object to "processed".

[0149] 11. Accessing the Kubernetes cluster using the new domain name / IP address returns results correctly.

[0150] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0151] Based on the same inventive concept, this application also provides an apparatus for adding a SAN domain name of a server certificate to implement the above-described method for adding a SAN domain name of a server certificate. The solution provided by this apparatus is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the apparatus for adding a SAN domain name of a server certificate provided below can be found in the limitations of the method for adding a SAN domain name of a server certificate described above, and will not be repeated here.

[0152] In one exemplary embodiment, such as Figure 5 As shown, a device for adding a server certificate to a SAN domain name is provided, comprising:

[0153] Cluster creation module 502 is used to create a Kubernetes cluster with at least one master node;

[0154] Configure module 504 to deploy a Controller on any master node in a Kubernetes cluster as a workload pod.

[0155] The configuration module 504 is also used to create stateful workloads in the namespace of the Kubernetes cluster when the Controller listens to the creation of a custom SAN resource object in the Kubernetes cluster.

[0156] The domain name addition module 506 is used to add SAN domain names to the server certificates of all master nodes in a Kubernetes cluster based on the pods corresponding to stateful workloads.

[0157] In an exemplary embodiment, the setting module 504 is further configured to, during the process of creating a stateful workload in the namespace of the Kubernetes cluster, use the number of master nodes of the Kubernetes cluster as the number of pods of the stateful workload; distribute the pods corresponding to the stateful workloads across each master node; mount the certificate storage directory and the communication socket file for container runtime on the master node to the pods corresponding to the stateful workloads; 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 addition module 506 is further configured 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; construct a list of all SAN domain names supported by the current server certificate based on the SAN domain name to be added and the SAN domain names supported by the current server certificate; 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.

[0159] In an exemplary embodiment, the domain name addition module 506 is used to restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster according to the communication socket file of the container runtime; and to verify the access validity of the Kubernetes cluster through the added SAN domain name.

[0160] In an exemplary embodiment, the domain name addition module 506 is used to obtain the processing status of SAN custom resource objects in the Kubernetes cluster; when the processing status is pending, the Controller is used 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.

[0161] In an exemplary embodiment, the domain name addition module 506 is used to detect whether the status of the pod corresponding to the stateful workload is ready, using the Controller; if the number of pods in the ready state is consistent with the number of master nodes, it determines that the SAN domain name has been successfully added to the server certificate of all master nodes, deletes the stateful workload, and updates the processing status of the SAN custom resource object.

[0162] The modules in the aforementioned SAN domain name addition device for server certificates can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0163] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a method for adding a SAN domain name for a server certificate.

[0164] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0166] Create a Kubernetes cluster with at least one master node;

[0167] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0168] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0169] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0170] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0171] When creating stateful workloads 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 stateful workloads across each master node;

[0173] Mount the certificate storage directory on the master node and the communication socket file for container runtime to the pod corresponding to the stateful workload.

[0174] By utilizing the environment variables of the Kubernetes cluster, the certificate storage path for the SAN domain name to be added is recorded on the master node.

[0175] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0176] Get the SAN domain names supported by the current server certificate of the master node;

[0177] Based on the Kubernetes cluster's environment variables, obtain the SAN domain name to be added;

[0178] Based on the SAN domains to be added and the SAN domains supported by the current server certificate, construct a list of all SAN domains supported by the current server certificate;

[0179] Update the list of all SAN domain names in the Kubernetes cluster configuration information, and record the certificate storage path of the SAN domain names to be added on the master node.

[0180] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0181] Restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster based on the communication socket file of the container runtime.

[0182] Verify the validity of access to the Kubernetes cluster using the added SAN domain name.

[0183] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0184] Get the processing status of a custom SAN resource object in the Kubernetes cluster;

[0185] When the processing status is pending, the Controller is used 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 domains to be added, and the list of all SAN domains.

[0186] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0187] Use the Controller to detect whether the state of the pod corresponding to the stateful workload is ready.

[0188] Assuming the number of pods in the ready state matches the number of master nodes, ensure that the SAN domain name has been successfully added to the server certificates of all master nodes, delete stateful workloads, and update the processing status of SAN custom resource objects.

[0189] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0190] Create a Kubernetes cluster with at least one master node;

[0191] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0192] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0193] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0194] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0195] When creating stateful workloads 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 stateful workloads across each master node;

[0197] Mount the certificate storage directory on the master node and the communication socket file for container runtime to the pod corresponding to the stateful workload.

[0198] By utilizing the environment variables of the Kubernetes cluster, the certificate storage path for the SAN domain name to be added is recorded on the master node.

[0199] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0200] Get the SAN domain names supported by the current server certificate of the master node;

[0201] Based on the Kubernetes cluster's environment variables, obtain the SAN domain name to be added;

[0202] Based on the SAN domains to be added and the SAN domains supported by the current server certificate, construct a list of all SAN domains supported by the current server certificate;

[0203] Update the list of all SAN domain names in the Kubernetes cluster configuration information, and record the certificate storage path of the SAN domain names to be added on the master node.

[0204] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0205] Restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster based on the communication socket file of the container runtime.

[0206] Verify the validity of access to the Kubernetes cluster using the added SAN domain name.

[0207] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0208] Get the processing status of a custom SAN resource object in the Kubernetes cluster;

[0209] When the processing status is pending, the Controller is used 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 domains to be added, and the list of all SAN domains.

[0210] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0211] Use the Controller to detect whether the state of the pod corresponding to the stateful workload is ready.

[0212] Assuming the number of pods in the ready state matches the number of master nodes, ensure that the SAN domain name has been successfully added to the server certificates of all master nodes, delete stateful workloads, and update the processing status of SAN custom resource objects.

[0213] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0214] Create a Kubernetes cluster with at least one master node;

[0215] Deploy the Controller as a workload pod on any master node in the Kubernetes cluster;

[0216] If the Controller detects that a custom SAN resource object has been created in the Kubernetes cluster, a stateful workload is created in the namespace of the Kubernetes cluster.

[0217] By adding SAN domain names to the server certificates of all master nodes in the Kubernetes cluster for the pods corresponding to stateful workloads.

[0218] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0219] When creating stateful workloads 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 stateful workloads across each master node;

[0221] Mount the certificate storage directory on the master node and the communication socket file for container runtime to the pod corresponding to the stateful workload.

[0222] By utilizing the environment variables of the Kubernetes cluster, the certificate storage path for the SAN domain name to be added is recorded on the master node.

[0223] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0224] Get the SAN domain names supported by the current server certificate of the master node;

[0225] Based on the Kubernetes cluster's environment variables, obtain the SAN domain name to be added;

[0226] Based on the SAN domains to be added and the SAN domains supported by the current server certificate, construct a list of all SAN domains supported by the current server certificate;

[0227] Update the list of all SAN domain names in the Kubernetes cluster configuration information, and record the certificate storage path of the SAN domain names to be added on the master node.

[0228] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0229] Restart the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster based on the communication socket file of the container runtime.

[0230] Verify the validity of access to the Kubernetes cluster using the added SAN domain name.

[0231] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0232] Get the processing status of a custom SAN resource object in the Kubernetes cluster;

[0233] When the processing status is pending, the Controller is used 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 domains to be added, and the list of all SAN domains.

[0234] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0235] Use the Controller to detect whether the state of the pod corresponding to the stateful workload is ready.

[0236] Assuming the number of pods in the ready state matches the number of master nodes, ensure that the SAN domain name has been successfully added to the server certificates of all master nodes, delete stateful workloads, and update the processing status of SAN custom resource objects.

[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, data stored, data displayed, 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 the relevant data must comply with relevant regulations.

[0238] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0239] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for adding a SAN domain name of a server certificate, characterized in that, The method comprises: creating a Kubernetes cluster with at least one master node; deploying a Controller controller in the form of a workload pod on any master node in the Kubernetes cluster; creating a stateful workload in the namespace of the Kubernetes cluster when the Controller controller listens to the creation of a SAN custom resource object in the Kubernetes cluster; adding a SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload.

2. The method of claim 1, wherein, The method further comprises: during the process of creating a stateful workload in the namespace of the Kubernetes cluster, taking the number of master nodes of the Kubernetes cluster as the number of pods of the stateful workload; dispersing the pod corresponding to the stateful workload on each master node; mounting the certificate storage directory on the master node and the communication socket file of the container runtime to the pod corresponding to the stateful workload; using the environment variable 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 of claim 2, wherein, The use of the environment variable of the Kubernetes cluster to record the certificate storage path of the SAN domain name to be added on the master node comprises: obtaining the SAN domain name supported by the current server certificate of the master node; obtaining the SAN domain name to be added according to the environment variable of the Kubernetes cluster; based on the SAN domain name to be added and the SAN domain name supported by the current server certificate, constructing a list of full SAN domain names supported by the current server certificate; updating the list of full SAN domain names in the configuration information of the Kubernetes cluster, and recording the certificate storage path of the SAN domain name to be added on the master node.

4. The method of claim 1, wherein, After adding the SAN domain name to the server certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload, the method further comprises: restarting the container corresponding to the server certificate of the added SAN domain name in the Kubernetes cluster according to the communication socket file of the container runtime; verifying the effectiveness of access to the Kubernetes cluster through the added SAN domain name.

5. The method of claim 3, wherein, The creation of a stateful workload in the namespace of the Kubernetes cluster comprises: obtaining the processing state of the SAN custom resource object in the Kubernetes cluster; when the processing state is to be processed, using the Controller controller to create a stateful workload according to the number of master nodes, the label of the master node, the certificate storage path of the SAN domain name to be added, and the list of full SAN domain names.

6. The method of claim 5, wherein, The adding SAN domain name on the service end certificate of all master nodes in the Kubernetes cluster through the pod corresponding to the stateful workload further comprises: Detecting whether the state of the pod corresponding to the stateful workload is the preparation state by using the Controller controller; In the case that the number of pods in the preparation state is consistent with the number of master nodes, it is determined that the SAN domain name has been successfully added on the service end certificate of all master nodes, the stateful workload is deleted, and the processing state of the SAN custom resource object is updated.

7. A device for adding a SAN domain name to a server certificate, characterized in that, The device comprises: A cluster creation module for creating a Kubernetes cluster with at least one master node; A setting module for deploying a Controller controller in the form of a workload pod on any master node in the Kubernetes cluster; The setting module is further configured to create a stateful workload in the namespace of the Kubernetes cluster in the case that the Controller controller listens to the creation of the SAN custom resource object in the Kubernetes cluster; A domain name adding module for adding a SAN domain name on the service end certificate 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, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

Images