Distributed command execution method and device based on Kubernetes

Abstract

The invention relates to the technical field of cloud computing, and particularly provides a distributed command execution method and device based on Kubernetes, and the device is divided into a user interface layer, a business logic layer and a service adaptation layer. Command line analysis and result display are carried out in the user interface layer; the business logic layer performs target screening and task execution scheduling; the service adaptation layer is provided with a Kubernetes adapter and an SSH adapter, the Kubernetes adapter obtains cluster information through a Kubernetes API (Application Program Interface), and a Pod name prefix and a target matched with a node name are filtered by using regularization; and the SSH adapter multiplexes a cienodes interface of the KubernetesClient to obtain IP (Internet Protocol) information of the node, and the name of the node is matched through regularization. Compared with the prior art, safe and efficient batch management of Kubernetes cluster resources can be realized, and a standardized solution is provided for operation and maintenance automation in a cloud native environment.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and specifically provides a distributed command execution method and apparatus based on Kubernetes. Background Technology

[0002] With the rapid development of cloud computing and containerization technologies, Kubernetes has become the de facto standard for orchestrating and managing cloud-native applications and is widely used in enterprise production environments. However, in the daily operation and maintenance of large-scale Kubernetes clusters, traditional operating methods face significant efficiency bottlenecks and security challenges.

[0003] Currently, Kubernetes cluster operations and maintenance mainly rely on the kubectl command-line tool or dashboard interface for single-point operations. This approach has significant shortcomings in large-scale cluster scenarios: First, batch operations on multiple nodes or across namespaces require writing complex scripts or loop commands, which not only have high development and maintenance costs but also low execution efficiency. Second, the lack of a unified execution auditing mechanism makes it difficult to meet the compliance requirements of industries such as finance and telecommunications. Third, traditional methods cannot effectively control concurrency, which can easily put excessive pressure on the cluster control plane. In addition, the heterogeneous management of physical nodes and container resources in a hybrid cloud environment also increases the complexity of operations and maintenance.

[0004] Existing solutions such as Ansible and SaltStack configuration management tools support batch operations, but suffer from steep learning curves and insufficient integration with the native Kubernetes API. Meanwhile, the Kubectl plugin mechanism is limited by its single-threaded execution mode, failing to fully utilize the computing power of modern multi-core CPUs. Furthermore, the stringent security requirements of enterprise-level production environments present multiple challenges to traditional operations and maintenance methods, such as direct SSH login to nodes, regarding key management and access control.

[0005] Against this backdrop, there is an urgent need for a cluster operation and maintenance tool that is deeply integrated with Kubernetes, supports intelligent resource filtering, has efficient concurrent execution capabilities, and meets security audit requirements. Summary of the Invention

[0006] This invention addresses the shortcomings of the prior art by providing a highly practical distributed command execution method based on Kubernetes.

[0007] A further technical objective of this invention is to provide a reasonably designed, secure, and applicable distributed command execution device based on Kubernetes.

[0008] The technical solution adopted by this invention to solve its technical problem is:

[0009] The distributed command execution method based on Kubernetes is divided into a user interface layer, a business logic layer, and a service adaptation layer.

[0010] Command line parsing and result display are performed within the user interface layer;

[0011] The business logic layer performs target filtering and task execution scheduling;

[0012] The service adaptation layer includes a Kubernetes adapter and an SSH adapter. The Kubernetes adapter obtains cluster information through the Kubernetes API and uses regular expressions to filter targets that match the Pod name prefix and node name.

[0013] The SSH adapter reuses the cienodes interface of KubernetesClient to obtain node IP information and matches the node name using regular expressions.

[0014] Furthermore, the user interface layer includes a command-line parsing module and a result display module. The command-line parsing module creates a parent parser containing common parameters and extends the dedicated parameter parsers for Pod and Node modes by inheriting from the parent parser through argparse.ArgumentParser. It uses add_subparsers() to achieve automatic splitting of pod / node modes and captures the user's selection through dest='mode'.

[0015] Furthermore, the result display module adopts multi-channel output, console output, and output to a file configured through the logging module. The output results are output in a fixed format including timestamp, hostname, and execution result. Old logs are cleaned up before each run.

[0016] Furthermore, the business logic layer sets up a target filtering engine module and an execution scheduler. The target filtering engine module adopts a three-level filtering strategy to achieve target positioning. The first level matches the node name using regular expressions. If the match is successful, the second level matches the pod prefix. If the match is unsuccessful, it is skipped and the next match is performed. If the second level matches the pod prefix successfully, the pod status is matched. Otherwise, it is skipped.

[0017] Furthermore, the execution scheduler first obtains the target node through the get_target method, then distributes the task through the ThreadPoolExector thread pool, and finally monitors the task execution progress through tqdm.

[0018] Furthermore, the Kubernetes adapter employs the kubectl exec mechanism, which executes instructions within the container by constructing the command template kubectl exec -n{namespace}{pod}--{shell}-c"{command}".

[0019] For script files, first copy them to the / tmp directory of the Pod using kubectl cp and then execute them. Use the pre-configured CA certificate / etc / kubernetes / ssl / ca.pem and the node-specific certificate admin-{hostname}.pem to access the Kubernetes API for secure communication.

[0020] Furthermore, the SSH adapter is based on the SSH protocol, uses a pre-configured private key / etc / kubernetes / common / private_key and a specified port to establish a connection, executes commands through SSH command templates, and executes script files after transferring them to the / tmp directory of the node via scp. Interactive verification with StrictHostKeyChecking is disabled to ensure the security of private key authentication.

[0021] A Kubernetes-based distributed command execution device includes: at least one memory and at least one processor;

[0022] The at least one memory is used to store a machine-readable program;

[0023] The at least one processor is used to invoke the machine-readable program to execute a Kubernetes-based distributed command execution method.

[0024] Compared with existing technologies, the Kubernetes-based distributed command execution method and apparatus of the present invention have the following outstanding advantages:

[0025] This invention can improve cluster management efficiency by 5-10 times while reducing the risk of operational errors by more than 80%. It is particularly suitable for the efficient and secure operation and maintenance needs of large-scale production clusters in industries such as finance and telecommunications, and provides reliable cloud-native infrastructure management guarantees for enterprises' digital transformation. Attached Figure Description

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

[0027] Figure 1 This is an architecture diagram of a distributed command execution method based on Kubernetes;

[0028] Figure 2 This is a flowchart illustrating a distributed command executor based on Kubernetes. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] The following is a preferred embodiment:

[0031] like Figure 1-2 As shown, the Kubernetes-based distributed command execution method in this embodiment is divided into a user interface layer, a business logic layer, and a service adaptation layer.

[0032] The user interface layer includes a command-line parsing module (argparse) and a structure display module;

[0033] The command-line parsing module (argparse) creates a parent parser containing common parameters (-c / --concurrency, -t / --type, etc.) and extends the parent parser to special parameter parsers for Pod mode (-p / --pod, etc.) and Node mode (--sshport). It uses add_subparsers() to achieve automatic routing between pod and node modes and captures the user's selection by dest='mode'.

[0034] Implement three functions:

[0035] (1) Parameter validation and default value injection;

[0036] (2) Supports subcommand routing (pod / node mode);

[0037] (3) Provide interactive command commands.

[0038] The results display module adopts a multi-channel output design, including console output and output to a file configured through the logging module. The output results are displayed in a fixed format, including timestamp (DATE_FORMAT), hostname, and execution result. Old logs are cleaned up before each run.

[0039] Implement 3 functions:

[0040] (1) Formatted output to the console;

[0041] (2) Persistent storage of log files

[0042] (3) Supports displaying results using the --show-result parameter.

[0043] The business logic layer includes a target filtering engine module and an execution scheduler;

[0044] The target filtering engine module uses a three-level filtering strategy to achieve accurate target location. The first level matches node names using regular expressions. If a match is successful, the second level matches the pod prefix. If a match is unsuccessful, the process is skipped and the next match is performed. If the second level matches the pod prefix successfully, the pod status is matched; otherwise, the process is skipped.

[0045] Three functions were implemented:

[0046] (1) Matching via regular expressions;

[0047] (2) Prefix filtering algorithm;

[0048] (3) Node / pod cache manager.

[0049] The execution scheduler first obtains the target node (or pod name) through the get_target method, then distributes the task through the ThreadPoolExector thread pool, and finally monitors the task execution progress through tqdm.

[0050] Three functions were implemented:

[0051] (1) Thread controller (ThreadPoolExecutor);

[0052] (2) Task Queue Manager;

[0053] (3) Progress display (tqdm).

[0054] The service adaptation layer includes a Kubernetes adapter and an SSH adapter;

[0055] The Kubernetes adapter obtains cluster information through the Kubernetes API ( / api / v1 / pods and / apis / cie.inspur.com / v1 / cienodes), using regular expressions to filter targets matching Pod name prefixes and node names. It employs the kubectl exec mechanism, executing commands within containers using the command template `kubectl exec -n{namespace}{pod}--{shell}-c "{command}"`. For script files, they are first copied to the Pod's ` / tmp` directory using `kubectl cp` before execution. Secure communication is ensured by using a pre-configured CA certificate (` / etc / kubernetes / ssl / ca.pem`) and a node-specific certificate (`admin-{hostname}.pem`) to access the Kubernetes API.

[0056] It includes three functions:

[0057] (1) API request encapsulation module (requests);

[0058] (2) kubectl command generation module;

[0059] (3) Certificate Management Module.

[0060] The SSH adapter reuses the cienodes interface of KubernetesClient to obtain node IP information and matches node names using regular expressions. Based on the SSH protocol, it establishes a connection using a pre-configured private key ( / etc / kubernetes / common / private_key) and a specified port (default 6233). Command execution is achieved through SSH command templates; script files are first transferred to the node's / tmp directory via scp before execution. StrictHostKeyChecking is disabled to avoid interactive authentication, relying on private key authentication for security.

[0061] This module contains three functions:

[0062] (1) Connection pool management;

[0063] (2) Key authentication processor;

[0064] (3) Command transmission channel.

[0065] Based on the above method, the Kubernetes-based distributed command execution device in this embodiment includes: at least one memory and at least one processor;

[0066] The at least one memory is used to store a machine-readable program;

[0067] The at least one processor is used to invoke the machine-readable program to execute a Kubernetes-based distributed command execution method.

[0068] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed command execution method based on Kubernetes, characterized in that, It is divided into a user interface layer, a business logic layer, and a service adaptation layer; Command line parsing and result display are performed within the user interface layer; The business logic layer performs target filtering and task execution scheduling; The service adaptation layer includes a Kubernetes adapter and an SSH adapter. The Kubernetes adapter obtains cluster information through the Kubernetes API and uses regular expressions to filter targets that match the Pod name prefix and node name. The SSH adapter reuses the cienodes interface of KubernetesClient to obtain node IP information and matches the node name using regular expressions.

2. The distributed command execution method based on Kubernetes according to claim 1, characterized in that, The user interface layer contains a command-line parsing module and a result display module. The command-line parsing module creates a parent parser containing common parameters and extends the special parameter parsers for Pod mode and Node mode by inheriting from the parent parser through argparse.ArgumentParser. It uses add_subparsers() to achieve automatic flow distribution between pod / node mode and captures the user selection through dest='mode'.

3. The distributed command execution method based on Kubernetes according to claim 2, characterized in that, The results display module uses multi-channel output, console output, and output to a file configured through the logging module. The output results are displayed in a fixed format, including timestamps, hostnames, and execution results. Old logs are cleaned up before each run.

4. The distributed command execution method based on Kubernetes according to claim 3, characterized in that, The business logic layer sets up a target filtering engine module and an execution scheduler. The target filtering engine module adopts a three-level filtering strategy to achieve target positioning. The first level matches the node name using regular expressions. If the match is successful, the second level matches the pod prefix. If the match is unsuccessful, it is skipped and the next match is performed. If the second level matches the pod prefix successfully, the pod status is matched. Otherwise, it is skipped.

5. The distributed command execution method based on Kubernetes according to claim 4, characterized in that, The execution scheduler first obtains the target node through the get_target method, then distributes the task through the ThreadPoolExector thread pool, and finally monitors the task execution progress through tqdm.

6. The distributed command execution method based on Kubernetes according to claim 5, characterized in that, The Kubernetes adapter uses the kubectl exec mechanism, which executes instructions inside the container by constructing the command template kubectl exec -n{namespace}{pod}--{shell}-c"{command}". For script files, first copy them to the / tmp directory of the Pod using kubectl cp and then execute them. Use the pre-configured CA certificate / etc / kubernetes / ssl / ca.pem and the node-specific certificate admin-{hostname}.pem to access the Kubernetes API for secure communication.

7. The distributed command execution method based on Kubernetes according to claim 6, characterized in that, The SSH adapter is based on the SSH protocol and uses a pre-configured private key / etc / kubernetes / common / private_key and a specified port to establish a connection. Command execution is achieved through SSH command templates, and script files are first transferred to the / tmp directory of the node via scp before execution. Interactive verification with StrictHostKeyChecking is disabled to ensure the security of private key authentication.

8. A distributed command execution device based on Kubernetes, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to perform the method according to any one of claims 1 to 7.

Images