Method for automatically updating kubernetes scheduler

Abstract

The present invention belongs to the field of Kubernetes cloud platforms. Disclosed is a method for automatically updating a Kubernetes scheduler. The method specifically comprises: configuring an API server virtual machine, and deploying a high-availability Kubernetes cluster; configuring a job controller, using the job controller to generate Kubernetes jobs of master nodes, and submitting the Kubernetes jobs to the Kubernetes cluster deployed by an API server; Kubelet in the Kubernetes cluster detecting a new job configuration file, pulling up, by means of a rolling update mechanism, a pod corresponding to the job configuration file, and executing a scheduler update logic; and checking the states of the jobs, and verifying an update result. Thus, state management and rollback in case of failure in task deployment of the scheduler are achieved, and the impact caused by an update failure is reduced.

Description

A method for automatically updating the Kubernetes scheduler

[0001] This application claims priority to Chinese patent application number 202311722392.8, filed on December 14, 2023, entitled “A Method for Automated Update of Kubernetes Scheduler,” the entire text of which is hereby incorporated by reference. Technical Field

[0002] The present application relates to the technical field of Kubernetes cloud platform, and in particular to a method for automatically updating a Kubernetes scheduler. Background Art

[0003] Currently, production environments are generally deployed with a single scheduler to avoid resource competition caused by the lack of shared state between multiple schedulers. The scheduler is an important functional component in the operating system, primarily responsible for scheduling tasks or processes in the system to individual CPUs (Central Processing Units) for execution. The Kubernetes scheduler is deployed as a static Pod and managed by the kubelet daemon. When the manifest configuration file changes, the kubelet will re-start the scheduler container group, so the configuration file must be manually changed during updates to trigger the startup of a 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 content. However, this method lacks task status management and is difficult to handle with a large number of nodes.

[0004] For example, a Chinese patent with authorization announcement number CN111352717B discloses a method for implementing a custom Kubernetes scheduler, characterized by storing Pod events in a queue and filtering out Pods that do not need to be scheduled based on the "schedulerName" field in the Pod resource YAML configuration; specifying the configuration of binding Pods created by an application to a specified working node; formatting the administrator-configured Pod binding node configuration and submitting it to the Etcd cluster; submitting Statefulset resources to the Kubernetes cluster; and determining whether the Pod needs to be scheduled. This invention relates to the field of container orchestration technology. In this method for implementing a custom Kubernetes scheduler, when a Pod is rebuilt, the Pod created by the Statefulset will still be scheduled to run on the node, ensuring that the data Pod mounted on the working node can still be read. When a specified Pod is to be bound to a new working node, the binding configuration is modified through the container cloud platform. The custom scheduler will bind the Pod to the new working node based on the new binding configuration of the Pod, thus meeting actual usage requirements.

[0005] For example, the Chinese patent application with the publication number CN116841718A discloses a physical resource scheduling method and scheduler based on Kubernetes. The present invention includes: obtaining the scheduling information in the Kubernetes cluster, the scheduling information includes the Pod information of the Pod to be scheduled and the 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 the scheduling evaluation model, and obtaining the evaluation information of the Pod to be scheduled when it is scheduled to the current node output by the scheduling evaluation model; preferably, scheduling the Pod to be scheduled based on the evaluation information corresponding to each node. This method introduces the load information of the current node, avoids the situation where the physical resources on the node are abnormal due to only considering hardware resources, ensures the safe operation of the Kubernetes cluster, and improves the stability of the Kubernetes cluster.

[0006] The above existing technologies all have the following problems: 1) they cannot be automated or scaled, 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

[0007] In response to the shortcomings of the existing technology, the present invention proposes a method for automatically updating the Kubernetes scheduler. The scheduler is updated based on the Job method, and a description file of the job task is generated. The job task is only run on the Master node. In addition, a rolling update scheduler and a scheduler update rollback guarantee mechanism are added to reduce the impact of the update process on the stability of the cluster.

[0008] To achieve the above object, the present invention provides the following technical solutions:

[0009] A method for automating updates to a Kubernetes scheduler, including:

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

[0011] Step S2: Configure the Job Controller, use it to generate Kubernetes Jobs for the Master node, and submit them to the Kubernetes cluster deployed by the ApiServer.

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

[0013] Step S4: Check the Job status and verify the update result.

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

[0015] Specifically, the specific steps of step S2 include:

[0016] Step S201: Obtain Master node information;

[0017] Step S202: Generate job description information and restrict bound nodes;

[0018] Step S203: Submit tasks according to different grayscale strategies.

[0019] Specifically, the specific method for limiting the bound nodes in step S202 includes:

[0020] Step S2021: Use nodeSelector to limit the job execution scope for nodes marked with Label;

[0021] Step S2022: For clusters without Label annotation, query the master node list through the API, and then limit the execution scope of the Job by nodeName.

[0022] Specifically, the specific steps of step S203 include:

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

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

[0025] Step S2033: Build a new Docker image using the Dockerfile, add a tag to the new Docker image, and push the built Docker image to an accessible Docker Registry;

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

[0027] Step S2035: Use the kubectl command or the Kubernetes API to submit the updated Kubernetes Jobs to the Kubernetes cluster deployed by the ApiServer.

[0028] Specifically, the specific steps of step S3 include:

[0029] Step S301: Detect a new Job configuration file, analyze the file content, and create and start a new Pod based on the defined Pod layout and strategy;

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

[0031] Step S303: Start the Pod corresponding to the Job configuration file;

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

[0033] Specifically, the specific steps of step S4 include:

[0034] Step S401: Use the Kubernetes API or kubectl command to obtain the updated job status;

[0035] Step S402: Analyze the acquired Job status information to check whether there are any errors or exceptions;

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

[0037] Step S404: Verify the update result, perform a test and verification operation;

[0038] Step S405: Clean up temporary files or resources that are no longer needed, and continuously monitor the performance of the scheduler and the status of the cluster.

[0039] Specifically, the status information in step S402 includes: the name, description, execution strategy, and dependencies of the job.

[0040] Specifically, a method for automatically updating a Kubernetes scheduler is characterized by comprising: a Job Controller module, a Jobs module,

[0041] The Job Controller module is used to generate a job description file and submit it to the ApiServer;

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

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

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

[0045] The task scheduling unit is responsible for determining the specific tasks and order of job execution based on the defined execution strategy and dependencies;

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

[0047] The update management unit is used to analyze the new Job configuration file, gradually introduce the new version according to the rolling update mechanism, and coordinate the rolling upgrade process of the task.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] 1. The present 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 work costs.

[0050] 2. This paper proposes a method for automatically updating the Kubernetes scheduler. It implements the scheduler upgrade logic 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.

[0051] 3. This invention proposes a method for automatically updating the Kubernetes scheduler, adding job status management, grayscale update, and operation rollback functions. The update process is more reliable and reduces the impact of update failures. At the same time, the update method adopts automated update, which is suitable for large-scale update scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] FIG1 is a flow chart of a method for automatically updating a Kubernetes scheduler according to the present invention;

[0053] FIG2 is a system analysis flow chart of a method for automatically updating a Kubernetes scheduler according to the present invention;

[0054] FIG3 is a diagram illustrating the overall solution architecture of a method for automatically updating a Kubernetes scheduler according to the present invention;

[0055] FIG4 is a system architecture diagram of a method for automatically updating a Kubernetes scheduler according to the present invention. DETAILED DESCRIPTION

[0056] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, it should be noted that in the description of the present invention, the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings, which are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as a limitation on the present invention. In addition, the terms "No. 1", "No. 2" and "No. 3" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. The present invention will be further explained below in conjunction with specific embodiments.

[0057] Example 1

[0058] Referring to Figures 1-3, an embodiment of the present invention provides a method for automatically updating a Kubernetes scheduler, comprising the following steps:

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

[0060] Kubernetes cluster is an open source platform for automating and managing containerized applications, including Master nodes and worker nodes. It supports automation, high availability, elasticity and portability, enabling developers to easily deploy and scale applications. By defining resource objects such as Deployment and Service, container orchestration and load balancing can be achieved.

[0061] The present invention prepares 4 virtual machines configured with 4 core CPUs and 8G memory to deploy a highly available Kubernetes cluster.

[0062] Step S2: Configure the Job Controller, use it to generate Kubernetes Jobs for the Master node, and submit them to the Kubernetes cluster deployed by the ApiServer.

[0063] The Job Controller is mainly responsible for: 1) generating a description file for the job task and submitting it to the ApiServer. Since the scheduler runs on the Master node, the scheduler-related configuration files are also located on the Master node, so the job can run on the Master node; 2) taking on the function of job status management. If the job status fails, it should be retried. At the same time, the error information will be recorded to facilitate problem investigation; 3) maintaining the RBAC information of the job to ensure that the job has access to the API of the ApiServer; 4) managing the job status, responsible for the maintenance of status information, and the flow of status such as failure and retry.

[0064] 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.

[0065] The present invention selects the Job Controller and Jobs components 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.

[0066] Kubernetes Jobs are a type of Manifest configuration file used to define and manage one-time tasks in Kubernetes. Manifest configuration files are files written in YAML or JSON format that define the behavior and configuration of Kubernetes objects. In this case, a Kubernetes Job is a Kubernetes object used to define a one-time 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, and more, and submit them to Kubernetes for management and scheduling.

[0067] The Kubernetes Jobs generated by this invention contain a mirror of the update logic and use nodeSelector or nodeName to limit 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 simultaneous updates of the scheduler that would cause the cluster scheduling function to be unavailable.

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

[0069] Kubelet runs on nodes in the Kubernetes cluster and is responsible for managing the container runtime 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 strategy.

[0070] 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 pulls up the corresponding Pod based on the information in the configuration file and executes the tasks in the container.

[0071] Scheduler updates include changes to scheduler images, startup parameters, and scheduler configuration parameters.

[0072] The specific steps of the execution logic of the present invention are: 1) backing up the scheduler configuration; 2) updating the scheduler configuration and scheduler-related manifest files; 3) waiting for the new scheduler to start. If the new scheduler starts successfully, the task is successful. If the new scheduler fails to start, a rollback operation is triggered, using the backed-up scheduler configuration to roll back to the old scheduler.

[0073] Step S4: Check the Job status and verify the update result.

[0074] In step S1, the high-availability Kubernetes cluster includes three Master nodes.

[0075] The specific steps of step S2 include:

[0076] Step S201: Obtain Master node information;

[0077] 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; 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 configuration; 7) Other customized Master node information.

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

[0079] Step S203: Submit tasks according to different grayscale strategies.

[0080] The specific method for restricting the bound nodes in step S202 includes:

[0081] Step S2021: Use nodeSelector to limit the job execution scope for nodes marked with Label;

[0082] Step S2022: For clusters without Label annotation, query the master node list through the 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 grayscale release strategy is a release strategy that achieves smooth upgrades by gradually switching from one version to another. This approach allows new and old code to coexist, thereby controlling release risks and reducing the impact on the production environment. In grayscale releases, feature toggles are 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 the Dockerfile, add a tag to the new Docker image, and push the built Docker image to an accessible Docker Registry;

[0088] A Docker image is a storage format that can be thought of 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 and 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] Specific steps to build a Docker image:

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

[0091] (2) Create a file inside the container;

[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 reference to the container image to point to the new Docker image, and update the configuration parameters of the deployment target and port number according to the grayscale strategy;

[0095] Step S2035: Use the kubectl command or the Kubernetes API to submit the updated Kubernetes Jobs to the Kubernetes cluster deployed by the ApiServer.

[0096] The specific steps of step S3 include:

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

[0098] A Pod is a fundamental 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 the Kubelet launches a Pod, it creates and starts the container based on the information in the Pod definition and executes the tasks in the container.

[0099] Step S302: Add a rolling update mechanism. In this 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 rolling update method; b) Define the Pod version or image label to be used in each rolling update; c) Determine the order and dependencies of the rolling updates to ensure smooth transitions 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 the Job and Pod; c) According to the defined rolling update strategy;

[0103] (3) Define the rolling update process: a) Define the initialization and cleanup steps for 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) When encountering errors or failures, consider rolling back to the previous version or performing other necessary recovery operations.

[0106] Step S303: Start 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 kubectl command to obtain the updated job status;

[0110] Step S402: Analyze the acquired Job status information to check whether there are any errors or exceptions;

[0111] If it fails, try again and record the error information for easy troubleshooting. When all jobs are successfully executed, the cluster scheduler update is complete.

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

[0113] Step S404: Verify the update result, perform a test and verification operation;

[0114] Step S405: Clean up temporary files or resources that are no longer needed, and continuously monitor the performance of the scheduler and the status of the cluster.

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

[0116] Example 2

[0117] Referring to FIG. 4 , another 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 a job description file and submit it to the ApiServer;

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

[0121] The Job Controller module includes: a state 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 the new Job configuration file, gradually introduce the new version according to the rolling update mechanism, and coordinate the rolling upgrade process of the task.

[0126] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also change, modify, replace and modify the above-mentioned embodiments without departing from the scope of protection of the purpose of the present invention and the claims, and all of these are protected by 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 for the Master node and submit them to the Kubernetes cluster deployed by the ApiServer; Step S3: The Kubelet in the Kubernetes cluster detects the new Job configuration file, and the rolling update mechanism pulls up the Pod corresponding to the Job configuration file and executes the update scheduler logic; Step S4: Check the Job status and verify the update result.

2. A method for automatically updating a Kubernetes scheduler as claimed in claim 1, characterized in that: In step S1, the high-availability Kubernetes cluster includes three Master nodes.

3. A method for automatically updating a 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 bound nodes; Step S203: Submit tasks according to different grayscale strategies.

4. A method for automatically updating a Kubernetes scheduler as claimed in claim 3, characterized in that: The specific method for limiting the bound nodes in step S202 includes: Step S2021: Use nodeSelector to limit the execution scope of the Job for nodes marked with Label; Step S2022: For clusters without Label annotation, query the master node list through the API, and then limit the execution scope of the Job through nodeName.

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

6. A method for automatically updating a Kubernetes scheduler as claimed in claim 5, characterized in that: The specific steps of step S3 include: Step S301: Detect a new Job configuration file, analyze the file content, and create and start a new Pod according to the defined Pod layout and strategy; Step S302: Add a rolling update mechanism, in which Kubelet adds new Pods to the Kubernetes cluster and replaces or deletes old Pods; Step S303: pull up the Pod corresponding to the Job configuration file; Step S304: Start the Pod, and the container executes the corresponding update scheduler logic.

7. A method for automatically updating a Kubernetes scheduler as claimed in claim 6, characterized in that: The specific steps of step S4 include: Step S401: Use the Kubernetes API or kubectl command to obtain the updated Job status; Step S402: Analyze the acquired Job status information to check whether there is any error or abnormality; Step S403: Verify the updated scheduler running status according to the definition in the Job configuration file; Step S404: verify the update result, perform a test and verification operation; Step S405: Clean up temporary files or resources that are no longer needed, and continue to monitor the performance of the scheduler and the status of the cluster.

8. A method for automatically updating a Kubernetes scheduler as claimed in claim 7, characterized in that: The status information in step S402 includes: the name, description, execution strategy, and dependencies of the job.

9. A method for automatically updating a Kubernetes scheduler as claimed in claim 8, characterized in that: include: Job Controller module, Jobs module, The Job Controller module is used to generate a job task description file and submit it to the ApiServer; The Jobs module is used to execute the logic of upgrading the scheduler.

10. A method for automatically updating a Kubernetes scheduler as claimed in claim 9, characterized in that: The Job Controller module includes: a state management unit, a task scheduling unit, a task execution unit, and an update management unit. The state management unit is used to maintain the state information of the Job; The task scheduling unit is responsible for determining the specific tasks and order of the Job execution according to the defined execution strategy and dependency relationship; The task execution unit is used to interact with the Kubernetes API to create, start and monitor Pods to execute tasks; The update management unit is used to analyze the new Job configuration file, gradually introduce the new version according to the rolling update mechanism, and coordinate the rolling upgrade process of the task.

Images