A method for automating updates to the Kubernetes scheduler

Abstract

This invention discloses a method for automatically updating a Kubernetes scheduler, belonging to the field of Kubernetes cloud platforms. Specifically, it includes: configuring an ApiServer virtual machine, deploying a highly available Kubernetes cluster, configuring a Job Controller, using the Job Controller to generate Kubernetes Jobs for the Master node and submitting them to the Kubernetes cluster deployed on the ApiServer, the Kubelet in the Kubernetes cluster detecting the new Job configuration file, a rolling update mechanism starting the Pod corresponding to the Job configuration file and executing the scheduler update logic, checking the Job status, verifying the update results, and implementing status management and failure rollback for scheduler deployment tasks to reduce the impact of update failures.

Description

Technical Field

[0001] This invention belongs to the field of Kubernetes cloud platforms, specifically a method for automating the updating of the Kubernetes scheduler. Background Technology

[0002] Currently, production environments typically deploy with a single scheduler to avoid resource contention issues caused by multiple schedulers lacking state sharing. The scheduler is a crucial functional component of the operating system, primarily responsible for scheduling tasks or processes across various CPUs for execution. The Kubernetes scheduler is deployed as a static Pod, managed by the kubelet daemon. When the manifest configuration file changes, kubelet restarts the scheduler container group. Therefore, updates require manual modification of the configuration file to trigger the startup of the new scheduler Pod. The current industry standard is to log in to the corresponding node via SSH and update the scheduler's manifest file to adjust the scheduler's image and configuration. However, this method lacks task state management and struggles to handle a large number of nodes.

[0003] For example, Chinese patent CN111352717B discloses a method for implementing a custom Kubernetes scheduler. Its features include: storing Pod events in a queue and filtering out Pods that do not need scheduling based on the "schedulerName" field in the Pod resource YAML configuration; specifying the configuration for binding Pods created by the application to a specified worker node; formatting the Pod binding node configuration configured by the administrator and submitting it to the Etcd cluster; submitting the Statefulset resource to the Kubernetes cluster; and determining whether the Pod needs to be scheduled. This invention relates to the field of container orchestration technology. This method for implementing a custom Kubernetes scheduler ensures that when a Pod is rebuilt, the Pod created by the Statefulset will still be scheduled to run on that node, guaranteeing that the data Pod mounted on the worker node can still be read. When a specified Pod needs to be bound to a new worker node, the binding configuration is modified through the container cloud platform, and the custom scheduler will bind the Pod to the new worker node according to the new binding configuration, thus meeting practical usage requirements.

[0004] For example, Chinese patent application CN116841718A discloses a physical resource scheduling method and scheduler based on Kubernetes. This invention includes: acquiring scheduling information from the Kubernetes cluster, including Pod information of the Pod to be scheduled and load information of each node; then traversing each node, inputting the Pod information of the Pod to be scheduled and the load information of the current node into a scheduling evaluation model to obtain the evaluation information output by the scheduling evaluation model when the Pod to be scheduled is scheduled to the current node; preferably, scheduling the Pod to be scheduled based on the evaluation information corresponding to each node. This method incorporates the load information of the current node, avoiding the situation where physical resources on the node become abnormal due to only considering hardware resources, ensuring the safe operation of the Kubernetes cluster and improving the stability of the Kubernetes cluster.

[0005] The existing technologies mentioned above all have the following problems: 1) They cannot be automated or scaled up, and cannot meet the needs of a large number of scheduler updates; 2) Scheduler updates lack a guarantee mechanism; 3) They rely on SSH. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention proposes a method for automatically updating the Kubernetes scheduler. The method updates the scheduler based on a job approach, generates job task description files, runs only on the Master node, and adds a rolling update scheduler update and scheduler update rollback guarantee mechanism to reduce the impact of the update process on cluster stability.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A method for automating updates to the Kubernetes scheduler includes:

[0009] Step S1: Configure the ApiServer virtual machine and deploy a highly available Kubernetes cluster;

[0010] Step S2: Configure the Job Controller to generate Kubernetes Jobs for the Master node and submit them to the Kubernetes cluster deployed on the API Server;

[0011] Step S3: The Kubelet in the Kubernetes cluster detects the new Job configuration file, and the rolling update mechanism starts the Pod corresponding to the Job configuration file and executes the update scheduler logic;

[0012] Step S4: Check the Job status and verify the update results.

[0013] Specifically, the high-availability Kubernetes cluster in step S1 includes 3 Master nodes.

[0014] Specifically, step S2 includes the following steps:

[0015] Step S201: Obtain Master node information;

[0016] Step S202: Generate Job description information and restrict the bound nodes;

[0017] Step S203: Submit the task according to the different gray-scale strategies.

[0018] Specifically, the method for restricting the bound nodes in step S202 includes:

[0019] Step S2021: Use nodeSelector to limit the execution scope of the Job for nodes with Label annotations;

[0020] Step S2022: For clusters without labels, query the list of master nodes via API, and then limit the execution scope of the Job by nodeName.

[0021] Specifically, step S203 includes the following steps:

[0022] Step S2031: Determine the grayscale strategy to be used based on requirements and strategies;

[0023] Step S2032: Create a Kubernetes Job using a YAML or JSON configuration file;

[0024] Step S2033: Build a new Docker image using a Dockerfile, add tags to the new Docker image, and push the built Docker image to an accessible DockerRegistry;

[0025] Step S2034: In the Kubernetes Jobs configuration file, update the container image reference to point to the new Docker image, and update the deployment target and port number configuration parameters according to the canary deployment strategy;

[0026] Step S2035: Submit the updated Kubernetes Jobs to the Kubernetes cluster deployed on the APIServer using the kubectl command or the Kubernetes API.

[0027] Specifically, step S3 includes the following steps:

[0028] Step S301: Detect the new Job configuration file, analyze the file content, and create and start the new Pod according to the defined Pod layout and strategy;

[0029] Step S302: Add a rolling update mechanism. In the rolling update mechanism, Kubelet adds new Pods to the Kubernetes cluster and replaces or deletes old Pods.

[0030] Step S303: Launch the Pod corresponding to the Job configuration file;

[0031] Step S304: Start the Pod, and the container executes the corresponding update scheduler logic.

[0032] Specifically, step S4 includes the following steps:

[0033] Step S401: Use the Kubernetes API or the kubectl command to obtain the status of the updated Job;

[0034] Step S402: Analyze the obtained Job status information and check for errors or anomalies;

[0035] Step S403: Verify the updated scheduler running status according to the definitions in the Job configuration file;

[0036] Step S404: Verify the update results, perform performance testing and verification operations;

[0037] Step S405: Clean up unnecessary temporary files or resources, and continuously monitor the scheduler's performance and the cluster's status.

[0038] Specifically, the status information in step S402 includes: the Job's name, description, execution strategy, and dependencies.

[0039] Specifically, a method for automating updates to the Kubernetes scheduler is characterized by including: a JobController module and a Jobs module.

[0040] The Job Controller module is used to generate job task description files and submit them to the API Server.

[0041] The Jobs module is used to execute the logic of the upgrade scheduler.

[0042] Specifically, the Job Controller module includes: a status management unit, a task scheduling unit, a task execution unit, and an update management unit.

[0043] The status management unit is used to maintain the status information of the Job;

[0044] The task scheduling unit is responsible for determining the specific tasks and order of Job execution based on the defined execution strategy and dependencies.

[0045] The task execution unit is used to interact with the Kubernetes API to create, start, and monitor Pods to execute tasks;

[0046] The update management unit is used to analyze new Job configuration files, gradually introduce new versions according to the rolling update mechanism, and coordinate the rolling upgrade process of tasks.

[0047] Compared with the prior art, the beneficial effects of the present invention are:

[0048] 1. This invention proposes a method for automatically updating the Kubernetes scheduler, and optimizes and improves the architecture, operation steps and processes. The system has the advantages of simple process, low investment and operation costs and low production costs.

[0049] 2. This invention proposes a method for automatically updating the Kubernetes scheduler. The scheduler upgrade logic is implemented based on Kubernetes Job, does not rely on SSH, is suitable for environments where SSH cannot be used, and supports viewing task progress information and status.

[0050] 3. This invention proposes a method for automatically updating the Kubernetes scheduler, which adds job status management, canary updates, and operation rollback functions, making the update process more reliable and reducing the impact of update failures. At the same time, the update method adopts automated updates, which is suitable for large-scale update scenarios. Attached Figure Description

[0051] Figure 1 This is a flowchart of a method for automatically updating a Kubernetes scheduler according to the present invention;

[0052] Figure 2 This is a system analysis flowchart of a method for automatically updating a Kubernetes scheduler according to the present invention;

[0053] Figure 3 This is a diagram illustrating the overall architecture of a method for automatically updating a Kubernetes scheduler according to the present invention.

[0054] Figure 4 This is a system architecture diagram of a method for automatically updating the Kubernetes scheduler according to the present invention. Detailed Implementation

[0055] To facilitate understanding of the technical means, creative features, and achieved objectives and effects of this invention, it should be noted in the description of this invention that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "number one," "number two," and "number three" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The invention will be further described below in conjunction with specific embodiments.

[0056] Example 1

[0057] Please see Figures 1-3 The present invention provides an embodiment of a method for automatically updating a Kubernetes scheduler, comprising the following steps:

[0058] Step S1: Configure the ApiServer virtual machine and deploy a highly available Kubernetes cluster;

[0059] Kubernetes clusters are an open-source platform for automating and managing containerized applications. They consist of master and worker nodes and support automation, high availability, resilience, and portability. This enables developers to easily deploy and scale applications and achieve container orchestration and load balancing by defining resource objects such as Deployments and Services.

[0060] This invention prepares four virtual machines configured with four CPU cores and eight gigabytes of memory to deploy a highly available Kubernetes cluster.

[0061] Step S2: Configure the Job Controller to generate Kubernetes Jobs for the Master node and submit them to the Kubernetes cluster deployed on the API Server;

[0062] The Job Controller is primarily responsible for: 1) generating job description files and submitting them to the API Server. Since the scheduler runs on the Master node, and the scheduler-related configuration files are also located on the Master node, the job can run on the Master node; 2) managing job status. If a job fails, it should be retried, and error information will be recorded for troubleshooting; 3) maintaining the job's RBAC information to ensure that the job has permission to access the API Server's API; and 4) managing job status, including maintaining status information and handling status transitions such as failure retries.

[0063] The Jobs component is mainly responsible for executing the logic of upgrading the scheduler. Since the scheduler is a static Pod, the scheduler description file in the manifest folder needs to be modified.

[0064] The Job Controller and Jobs components are chosen in this invention because the startup of static Pods may fail and health checks are required. The status of the scheduler container group can be obtained through the Kubernetes API. If the scheduler upgrade fails, a rollback operation can be performed to restore the configuration file and roll back the upgrade operation, thereby ensuring the reliability of the entire upgrade process.

[0065] Kubernetes Jobs are a type of Manifest configuration file used to define and manage one-off tasks in Kubernetes. Manifest configuration files are written in YAML or JSON format and define the behavior and configuration of Kubernetes objects. In this case, a Kubernetes Job is a Kubernetes object used to define a one-off task or unit of work. Therefore, Kubernetes Jobs can be defined, created, and managed through Manifest configuration files. Users can use Manifest configuration files to define the Job's name, description, execution strategy, dependencies, etc., and submit them to Kubernetes for management and scheduling.

[0066] The Kubernetes Jobs generated by this invention include images with update logic and use nodeSelector or nodeName to restrict the bound nodes. Since it is a highly available Kubernetes cluster, the Job Controller will use a rolling update mechanism to update the scheduler to avoid the cluster scheduling function becoming unavailable due to simultaneous scheduler updates.

[0067] Step S3: The Kubelet in the Kubernetes cluster detects the new Job configuration file, and the rolling update mechanism starts the Pod corresponding to the Job configuration file and executes the update scheduler logic;

[0068] Kubelet runs on nodes in a Kubernetes cluster and is responsible for managing container runtimes and communicating with the master node. When Kubelet detects a new Job configuration file, it analyzes the contents of the file and creates and starts a new Pod based on the defined Pod layout and policies.

[0069] A Job configuration file is a YAML or JSON format configuration file used to define a Kubernetes Job. When Kubelet detects a new Job configuration file, it will start the corresponding Pod and execute the tasks in the container based on the information in the configuration file.

[0070] Scheduler updates include changes to parameters such as the scheduler image, startup parameters, and scheduler configuration.

[0071] The specific steps of the execution logic of this invention are as follows: 1) Back up the scheduler-related configuration; 2) Update the scheduler configuration and scheduler-related manifest files; 3) Wait for the new scheduler to start. Successful startup of the new scheduler indicates successful task execution. If the new scheduler fails to start, a rollback operation is triggered, and the backed-up scheduler configuration is used to roll back to the old scheduler.

[0072] Step S4: Check the Job status and verify the update results.

[0073] The high-availability Kubernetes cluster in step S1 includes 3 Master nodes.

[0074] The specific steps of step S2 include:

[0075] Step S201: Obtain Master node information;

[0076] Master node information includes: 1) Master node address and port; 2) Kubernetes version information; 3) Information related to the Kubernetes cluster, such as the cluster name, version, number of nodes, and network configuration.

[0077] 4) Resource information available on the Master node, such as CPU, memory, and storage space; 5) Plugin and extension information; 6) Security-related information, such as SSL / TLS certificates and authentication configurations; 7) Other custom Master node information.

[0078] Step S202: Generate Job description information and restrict the bound nodes;

[0079] Step S203: Submit the task according to the different gray-scale strategies.

[0080] The specific methods for restricting the bound nodes in step S202 include:

[0081] Step S2021: Use nodeSelector to limit the execution scope of the Job for nodes with Label annotations;

[0082] Step S2022: For clusters without labels, query the list of master nodes via API, and then limit the execution scope of the Job by nodeName.

[0083] The specific steps of step S203 include:

[0084] Step S2031: Determine the grayscale strategy to be used based on requirements and strategies;

[0085] A canary release strategy is a release strategy that achieves a smooth upgrade by gradually switching from one version to another. This method allows old and new code to coexist, thus controlling release risks and reducing the impact on the production environment. In canary releases, feature switching technology is often used to implement more complex and flexible release strategies.

[0086] Step S2032: Create a Kubernetes Job using a YAML or JSON configuration file;

[0087] Step S2033: Build a new Docker image using a Dockerfile, add tags to the new Docker image, and push the built Docker image to an accessible DockerRegistry;

[0088] A Docker image is a form of storage that can be understood as a copy of data or an application. Specifically, a Docker image is a lightweight, executable software container that contains the environment and dependencies required to run an application. It can be managed and scheduled like a Pod or Service. In a Kubernetes cluster, each node runs the Docker engine, which can be used to create, run, and manage Docker containers.

[0089] The specific steps to build a Docker image:

[0090] (1) Create a container based on the Ubuntu image and enter interactive mode;

[0091] (2) Inside the container, perform the file creation operation;

[0092] (3) Execute `exit` to exit the container and view the container information;

[0093] (4) Build a new image using the docker commit command.

[0094] Step S2034: In the Kubernetes Jobs configuration file, update the container image reference to point to the new Docker image, and update the deployment target and port number configuration parameters according to the canary deployment strategy;

[0095] Step S2035: Submit the updated Kubernetes Jobs to the Kubernetes cluster deployed on the APIServer using the kubectl command or the Kubernetes API.

[0096] The specific steps of step S3 include:

[0097] Step S301: Detect the new Job configuration file, analyze the file content, and create and start the new Pod according to the defined Pod layout and strategy;

[0098] A Pod is a basic abstraction in Kubernetes, representing a containerized instance running in a cluster. A Pod can contain one or more containers that share the same network, storage, and process space. When a Kubelet launches a Pod, it creates and starts the container based on the information in the Pod definition and executes the tasks within the container.

[0099] Step S302: Add a rolling update mechanism. In the rolling update mechanism, Kubelet adds new Pods to the Kubernetes cluster and replaces or deletes old Pods.

[0100] Steps to add a rolling update mechanism:

[0101] (1) Define the rolling update strategy: a) Determine the method of rolling updates; b) Define the Pod version or image tag to be used in each rolling update; c) Determine the order and dependencies of rolling updates to ensure a smooth transition between tasks;

[0102] (2) Implement the rolling update unit: a) Add a rolling update unit to the Job Controller module, which is responsible for managing the rolling update process; b) Interact with the Kubernetes API to obtain and update the status information of Jobs and Pods; c) According to the defined rolling update strategy;

[0103] (3) Define the rolling update process: a) Define the initialization and cleanup steps of the rolling update; b) Define how to handle the status and dependencies of tasks during the rolling update process;

[0104] (4) Perform rolling updates: a) Perform rolling update operations according to the defined rolling update strategy and process; b) Interact with the Kubernetes API to create, start, stop or delete Pods; c) Continuously monitor the status and events of Pods during the rolling update process according to the defined rolling update strategy to ensure the smooth progress of the update.

[0105] (5) Error handling and rollback mechanism: a) Implement an error handling mechanism to detect and handle errors or abnormal situations during the rolling update process; b) In case of errors or failures, consider rolling back to previous versions or performing other necessary recovery operations.

[0106] Step S303: Launch the Pod corresponding to the Job configuration file;

[0107] Step S304: Start the Pod, and the container executes the corresponding update scheduler logic.

[0108] The specific steps in step S4 include:

[0109] Step S401: Use the Kubernetes API or the kubectl command to obtain the status of the updated Job;

[0110] Step S402: Analyze the obtained Job status information and check for errors or anomalies;

[0111] If a failure occurs, a retry should be performed and the error message should be recorded for troubleshooting. Once all jobs have been successfully executed, it indicates that the cluster scheduler update is complete.

[0112] Step S403: Verify the updated scheduler running status according to the definitions in the Job configuration file;

[0113] Step S404: Verify the update results, perform performance testing and verification operations;

[0114] Step S405: Clean up unnecessary temporary files or resources, and continuously monitor the scheduler's performance and the cluster's status.

[0115] The status information in step S402 includes: the Job's name, description, execution strategy, and dependencies.

[0116] Example 2

[0117] Please see Figure 4Another embodiment of the present invention provides a method for automatically updating a Kubernetes scheduler, characterized by comprising:

[0118] Job Controller module, Jobs module

[0119] The Job Controller module is used to generate job task description files and submit them to the API Server.

[0120] The Jobs module is used to execute the logic of the upgrade scheduler.

[0121] The Job Controller module includes: a status management unit, a task scheduling unit, a task execution unit, and an update management unit.

[0122] The status management unit is used to maintain the status information of the Job;

[0123] The task scheduling unit is responsible for determining the specific tasks and order of Job execution based on the defined execution strategy and dependencies.

[0124] The task execution unit is used to interact with the Kubernetes API to create, start, and monitor Pods to execute tasks;

[0125] The update management unit is used to analyze new Job configuration files, gradually introduce new versions according to the rolling update mechanism, and coordinate the rolling upgrade process of tasks.

[0126] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the claims. All of these variations are within the protection scope of the present invention.

Claims

1. A method for automatically updating a Kubernetes scheduler, characterized in that, include: Step S1: Configure the ApiServer virtual machine and deploy a highly available Kubernetes cluster; Step S2: Configure the Job Controller, use the Job Controller to generate Kubernetes Jobs on the Master node and submit them to the Kubernetes cluster deployed on the API Server; Step S3: The Kubelet in the Kubernetes cluster detects the new Job configuration file, and the rolling update mechanism starts the Pod corresponding to the Job configuration file and executes the update scheduler logic; Step S4: Check the Job status and verify the update results; The specific steps of step S3 include: Step S301: Detect the new Job configuration file, analyze the file content, and create and start the new Pod according to the defined Pod layout and strategy; Step S302: Add a rolling update mechanism. In the rolling update mechanism, Kubelet adds new Pods to the Kubernetes cluster and replaces or deletes old Pods. Step S303: Launch the Pod corresponding to the Job configuration file; Step S304: Start the Pod, and the container executes the corresponding update scheduler logic.

2. The method for automatically updating the Kubernetes scheduler as described in claim 1, characterized in that, The high-availability Kubernetes cluster in step S1 includes 3 Master nodes.

3. The method for automatically updating the Kubernetes scheduler as described in claim 2, characterized in that, The specific steps of step S2 include: Step S201: Obtain Master node information; Step S202: Generate Job description information and restrict the bound nodes; Step S203: Submit the task according to the different gray-scale strategies.

4. The method for automatically updating the Kubernetes scheduler as described in claim 3, characterized in that, The specific methods for restricting the bound nodes in step S202 include: Step S2021: Use nodeSelector to limit the execution scope of the Job for nodes with Label annotations; Step S2022: For clusters without labels, query the list of master nodes via API, and then limit the execution scope of the Job by nodeName.

5. The method for automatically updating the Kubernetes scheduler as described in claim 4, characterized in that, The specific steps of step S203 include: Step S2031: Determine the grayscale strategy to be used based on requirements and strategies; Step S2032: Create a Kubernetes Job using a YAML or JSON configuration file; Step S2033: Build a new Docker image using a Dockerfile, add tags to the new Docker image, and push the built Docker image to an accessible Docker Registry; Step S2034: In the Kubernetes Jobs configuration file, update the container image reference to point to the new Docker image, and update the deployment target and port number configuration parameters according to the canary deployment strategy; Step S2035: Submit the updated Kubernetes Jobs to the Kubernetes cluster deployed on the APIServer using the kubectl command or the Kubernetes API.

6. The method for automatically updating the Kubernetes scheduler as described in claim 5, characterized in that, The specific steps of step S4 include: Step S401: Use the Kubernetes API or the kubectl command to obtain the status of the updated Job; Step S402: Analyze the obtained Job status information and check for errors or anomalies; Step S403: Verify the updated scheduler running status according to the definitions in the Job configuration file; Step S404: Verify the update results, perform performance testing and verification operations; Step S405: Clean up unnecessary temporary files or resources, and continuously monitor the scheduler's performance and the cluster's status.

7. The method for automatically updating the Kubernetes scheduler as described in claim 6, characterized in that, The status information in step S402 includes: the Job's name, description, execution strategy, and dependencies.

8. The method for automatically updating the Kubernetes scheduler as described in claim 7, characterized in that, The method further includes: The Job Controller generates a description file for the job task and submits it to the API Server. Use Jobs to execute the logic of the upgrade scheduler.

9. A method for automatically updating a Kubernetes scheduler as described in claim 8, characterized in that, The Job Controller includes the following steps: Maintain the job's status information; Based on the defined execution strategy and dependencies, determine the specific tasks and order in which the Job is executed; Call the Kubernetes API to create, start, and monitor Pods to execute tasks; analyze new Job configuration files, gradually introduce new versions according to the rolling update mechanism, and coordinate the rolling upgrade process of tasks.

Images