Kubernetes application multi-copy fixed IP automatic deployment method and system

Abstract

The invention provides a Kubernetes application multi-copy fixed IP automatic deployment method and system, and the method comprises the steps: receiving a user deployment instruction which at least appoints a network address field and the number of deployed copies; according to the network address field and the number of the deployed copies, an independent and unused IP address is pre-allocated for each copy before deployment is executed; a corresponding NAD configuration file is generated for each pre-distributed IP address, a workload template specified by a user is loaded, a plurality of customized workload templates added with network annotations are copied and generated according to the number of deployed copies, and the network annotations are used for associating the corresponding NAD configuration files; and assembling the NAD configuration file and the customized workload template into a Chart package conforming to a Helm specification for automatic deployment. According to the method and the device, the IP management of pre-allocation before deployment, fixation in a life cycle and full-process automation of multiple copies of the application is realized, and static export and versioning management of configuration are supported at the same time.

Description

Technical Field

[0001] This application relates to the field of cloud-native application technology, and in particular to a method and system for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses. Background Technology

[0002] With the rapid development of cloud computing and cloud-native technologies, containerized deployment has become the mainstream paradigm for enterprise application delivery. Kubernetes (K8s), as the de facto standard in container orchestration, is widely used in the deployment and management of distributed applications. In actual production scenarios, the multi-replica deployment of many critical business applications (such as distributed databases, middleware clusters, and industrial control services) relies on fixed IP addresses to ensure the stability of service access, thereby enabling core functions such as inter-node communication, authentication, and data synchronization.

[0003] Currently, implementing multi-replica fixed IP deployment of applications on the Kubernetes platform mainly relies on StatefulSet with Headless Service, manually configured Multus CNI, or cloud platform-specific solutions. However, the core feature of the StatefulSet with Headless Service solution is assigning a stable network identifier and persistent storage to each replica. But when a replica restarts, migrates, or the cluster network topology changes, the IP address corresponding to its Pod may still change, failing to meet scenarios requiring strong IP address consistency. While manually configuring Multus CNI can achieve true IP fixation, each replica requires a separate NAD resource creation and manual association, which is cumbersome and prone to deployment failures due to configuration errors, making it unsuitable for large-scale deployments. Cloud platform-specific solutions can provide customized fixed IP deployment schemes, but they heavily rely on specific network plugins or services from specific cloud vendors, lacking cross-platform versatility.

[0004] In summary, existing solutions all have significant technical limitations and struggle to meet the demands of large-scale, automated, and cross-platform deployments. Therefore, there is an urgent need for a technical solution that can be deeply integrated into the Kubernetes deployment process, enabling automated pre-allocation and binding of fixed IP addresses, and supporting cross-platform and large-scale deployments to address the pain points of existing technologies. Summary of the Invention

[0005] In view of this, this application proposes a method and system for automated deployment of multiple replicas of Kubernetes applications using fixed IPs. This method enables pre-allocation of IPs before deployment, fixed IPs throughout the application's lifecycle, and fully automated IP management. It also supports static export and version management of configurations.

[0006] Firstly, this application provides a method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses, including: Receive user deployment instructions, wherein the deployment instructions specify at least a network address range and the number of deployment replicas; Based on the network address range and the number of deployed replicas, a unique, unused IP address is pre-assigned to each replica before deployment execution; For each pre-allocated IP address, a corresponding NAD configuration file is generated. The user-specified workload template is loaded, and multiple customized workload templates with added network annotations are generated according to the number of deployment replicas. These network annotations are used to associate with the corresponding NAD configuration file. The NAD configuration file and customized workload template are assembled into a Helm-compliant Chart package for automated deployment.

[0007] Therefore, this application provides a method for automated deployment of Kubernetes application replicas with fixed IPs. By pre-allocating independent and unused IPs to each replica before deployment, replacing the traditional method of dynamically allocating IPs after Pod startup, this method ensures that the IP address of each replica is accurately determined before deployment, solving the problems of uncontrollable IP addresses and error-prone deployment results. Furthermore, by automatically generating NAD (Network Attachment Definition) configuration files bound to fixed IPs and batch-customizing workload templates associated with NADs, this method replaces the tedious manual generation of NADs and addition of network annotations, significantly reducing labor costs and improving the efficiency of fixed IP configuration. Additionally, by assembling all configurations into a Chart package conforming to the Helm specification, without modifying the core components of the Kubernetes cluster or the Multus CNI source code, this method is compatible with mainstream K8s versions and the Helm ecosystem, improving the versatility and compatibility of the solution. This application achieves a one-click conversion from user input to a deployable Chart package, significantly improving deployment efficiency, reliability, and consistency, laying a solid foundation for subsequent automated deployment.

[0008] Optionally, the pre-allocation of a unique, unused IP address for each replica specifically includes: The Kubernetes client interface is used to query the existing NAD resources in the cluster and obtain a list of IP addresses that are already in use within the network address range. Exclude occupied IP addresses from the network address range, filter out unused IPs equal to the number of deployed replicas, and allocate them to each replica in ascending order of address or according to preset rules.

[0009] As described above, by querying the occupied IPs of existing NAD resources in the cluster through the Kubernetes client interface, the system can accurately identify and exclude used IPs within the target address range, ensuring that all pre-allocated IPs are in an unused state. This fundamentally avoids problems such as Pod startup failure and network communication anomalies caused by duplicate IP allocation. Furthermore, by allocating IPs in ascending order of address or according to preset rules, the correspondence between replicas and IPs has a clear pattern, making it easier for operations and maintenance personnel to quickly locate the IP address corresponding to the replica, and reducing the difficulty of troubleshooting and configuring network policies after deployment.

[0010] Optionally, after assembling into a Chart package conforming to the Helm specification, the following further steps are included: The Chart package is statically exported as a file and saved to the local file system.

[0011] As described above, by adding a static export function, the dynamically generated Chart package containing all the specific IP information is permanently saved, which makes the complete configuration of this deployment version-managed, archived, audited or distributed offline. This not only meets the requirements of enterprise-level deployment for traceability and compliance, but also makes it possible to deploy in scenarios without network connection or requiring strict consistency (such as production environment rollback, multi-cluster synchronization).

[0012] Optionally, the automated deployment specifically includes: The Chart package is deployed by calling standard Helm installation commands to complete the automated deployment of multiple replicas of Kubernetes applications on fixed IPs.

[0013] As described above, the standard Helm install command is used to deploy the Chart package, reusing Helm's native deployment, upgrade, rollback, and verification capabilities. This eliminates the need to develop a separate deployment execution module, reducing the development and maintenance costs of the solution.

[0014] Optionally, the user deployment command is received via an extended Helm command-line tool that adds preprocessing logic before the standard Helminstall command and supports at least the following parameters: Specify the network address range, the number of replicas, and the file path of the workload template.

[0015] As described above, by extending the Helm command-line tools (such as creating an `minstall` command) and integrating preprocessing logic, complex processes such as IP pre-allocation, configuration generation, and chart assembly are encapsulated into a single command entry point, replacing traditional step-by-step manual operations and significantly improving deployment efficiency. Simultaneously, through explicit command-line parameters (address range, number of replicas, template path), core configurations can be flexibly adjusted to adapt to the deployment needs of different business scenarios without modifying the underlying code.

[0016] Optionally, the workload template supports Deployment, StatefulSet, Job, or Pod resource types in Kubernetes; the network annotation uses the standard annotation key of Multus CNI, and the value is the name of the corresponding NAD configuration file.

[0017] As described above, the workload template supports mainstream Kubernetes workload types such as Deployment, StatefulSet, Job, and Pod, adapting to the fixed IP deployment requirements of different business scenarios, including stateless, stateful, and one-off tasks. By adopting the standard annotation keys of Multus CNI (k8s.v1.cni.cncf.io / networks), it ensures that network annotations can be correctly recognized and parsed by the Multus plugin, avoiding IP binding failures due to non-standard annotation formats and improving the reliability of fixed IP configuration.

[0018] Optionally, the assembly process of the Chart package includes: Create a Chart object in memory using the Helm Golang SDK, and write the NAD configuration file and customized workload template to the templates directory of the Chart object.

[0019] As described above, by creating Chart objects in memory and writing them to configuration files using the Helm Golang SDK, there is no need to write the configuration files to the local disk first and then read them. This reduces disk I / O operations, speeds up Chart assembly, shortens the overall deployment process, and strictly follows the Helm specification to write the configuration files to the templates directory. This ensures that the generated Chart package fully conforms to the Helm standard and is compatible with Helm's native template rendering, variable substitution, and other functions, avoiding deployment anomalies caused by non-standard Chart formats.

[0020] Secondly, this application provides a fixed-IP automated deployment system for multiple replicas of Kubernetes applications, including: A receiving module is used to receive user deployment instructions, wherein the deployment instructions specify at least a network address range and the number of deployment replicas; The pre-allocation module is used to pre-allocate an independent, unused IP address for each replica before deployment execution, based on the network address range and the number of deployed replicas. The configuration module is used to generate a corresponding NAD configuration file for each pre-allocated IP address, load the user-specified workload template, and copy and generate multiple customized workload templates with added network annotations according to the number of deployment replicas. These network annotations are used to associate with the corresponding NAD configuration file. An assembly module is used to assemble the NAD configuration file and customized workload template into a Chart package that conforms to the Helm specification for automated deployment.

[0021] Thirdly, this application provides a computing device, the computing device comprising: processor; Memory, used to store one or more programs; When the processor executes one or more programs, it enables the processor to implement the above-described method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses.

[0022] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a computer, implements the aforementioned method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses.

[0023] These and other aspects of this application will become more apparent in the description of the following embodiments(s). Attached Figure Description

[0024] Figure 1 A flowchart illustrating a method for automated deployment of multiple replicas of a Kubernetes application using a fixed IP address, provided in an embodiment of this application; Figure 2 A flowchart illustrating another method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses, provided in an embodiment of this application; Figure 3 This application provides a structural diagram of a fixed IP automated deployment system for multiple replicas of Kubernetes applications. Figure 4 This is a structural diagram of a computing device provided in an embodiment of this application.

[0025] It should be understood that the dimensions and shapes of the block diagrams in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of this application. The relative positions and inclusion relationships between the block diagrams presented in the structural diagrams are only schematic representations of the structural relationships between the block diagrams, and are not intended to limit the physical connection methods of the embodiments of this application. Detailed Implementation

[0026] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0028] The solutions provided in this application will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] This application proposes a method and system for automated deployment of multiple replicas of Kubernetes applications using fixed IPs. It is applicable to scenarios with strong IP stability requirements, such as distributed databases, middleware clusters, and industrial control services. It achieves pre-allocation of IPs before deployment, fixed IPs throughout their lifecycle, and fully automated IP management. It also supports static export and version management of configurations.

[0030] like Figure 1 As shown, this application provides a method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses. This method is based on the Golang development language and is implemented using the Helm Golang SDK, Kubernetes client-go SDK, and Multus CNI plugin. (Refer to...) Figure 1 As shown, the method includes: S110: Receive user deployment instructions.

[0031] In this embodiment, a user deployment command can be received through an extended Helm command-line tool, and the user deployment command can be parsed to obtain the network address range and the number of deployed replicas specified in the deployment command.

[0032] The extended Helm command-line tools (such as Helm minstall) are developed based on the Helm Golang SDK. They add preprocessing logic before the standard Helm install command and include several parameters, such as the `--network-cidr` parameter to specify the network address range, the `--replicas` parameter to specify the number of replicas, and the `--workload-template` parameter to specify the workload template file path. An example of this extended Helm command-line tool is as follows: helm minstall mysql-ha \ --network-cidr=192.168.200.0 / 28 \ --replicas=3 --workload-template=. / mysql-deployment.yaml \ --save-chart=. / generated-mysql-chart \ --namespace=prod-db The command line means: deploy an application named mysql-ha, assign fixed IPs to 3 replicas from the 192.168.200.0 / 28 network segment (16 IPs in total), use . / mysql-deployment.yaml as the basic template, save the final generated Chart package to the . / generated-mysql-chart directory, and deploy it to the prod-db namespace.

[0033] S120: Based on the network address range and the number of deployed replicas, pre-allocate a unique, unused IP address for each replica before deployment execution.

[0034] In this step, based on the network address range and number of deployed replicas specified in the above deployment instructions, a query request can be sent to the Kubernetes cluster through the Kubernetes client interface (such as the Kubernetes client-go SDK) to obtain all resources of type NetworkAttachmentDefinition (NAD) under the prod-db namespace and resolve their IP address information. If 192.168.200.1 and 192.168.200.5 are found to be occupied, the occupied IP addresses (192.168.200.1 and 192.168.200.5) can be excluded from the network address range 192.168.200.0 / 28. An unused IP address equal to the number of deployed replicas can be selected, and each replica can be assigned an IP address in ascending order of address or according to a preset rule. For example, the allocation result could be: Replica 1: 192.168.200.2, Replica 2: 192.168.200.3, Replica 3: 192.168.200.4.

[0035] S130: Generate a corresponding NAD configuration file for each pre-allocated IP address, load the user-specified workload template, and copy and generate multiple customized workload templates with added network annotations according to the number of deployment replicas.

[0036] In this step, a NADYAML file required by the Multus CNI plugin is generated for each pre-assigned IP address. This NADYAML configuration file contains the pre-assigned IP address. Then, the user-specified workload template is loaded from the specified workload template file path, and three customized workload templates (Deployment YAML files) are generated according to the number of deployment replicas. These templates are named mysql-2, mysql-3, and mysql-4, respectively, and network annotations are added to each template to point to their corresponding NADYAML files.

[0037] In some embodiments, the specified workload template supports mainstream Kubernetes workload types such as Deployment, StatefulSet, Job, and Pod, adapting to the fixed IP deployment requirements of different business scenarios such as stateless, stateful, and one-off tasks. By adopting the Multus CNI standard annotation key (k8s.v1.cni.cncf.io / networks), it ensures that network annotations can be correctly recognized and parsed by the Multus plugin, avoiding IP binding failures due to non-standard annotation formats.

[0038] S140: Assemble the NAD configuration file and customized workload template into a Chart package that conforms to the Helm specification for automated deployment.

[0039] In this step, based on the generated NAD configuration file and customized workload template, a new Chart object can be created in memory using a Chart assembler (such as the Helm Golang SDK), and its Chart.yaml metadata can be set. Then, the three NAD YAML files and three customized Deployment YAML files generated in the previous steps are all placed into the templates virtual directory of this Chart object. At this point, a Chart package containing six Kubernetes resource definitions with complete internal relationships is ready in memory.

[0040] In some embodiments, if the user specifies the `--save-chart` parameter, the system will serialize the in-memory Chart structure into a file and save it to the specified directory `. / generated-mysql-chart`. This directory contains a standard, independently distributable Helm Chart. This static export function enables the complete configuration of this deployment to be version-managed, archived, audited, or distributed offline. This not only meets the traceability and compliance requirements of enterprise-level deployments but also makes deployment possible in scenarios without network connectivity or requiring strict consistency (such as production environment rollback or multi-cluster synchronization).

[0041] During deployment, the Helm SDK can be invoked to execute the standard Helm install command (Helm install). This first renders the Chart template files in the templates directory into a complete and standard Kubernetes Manifest. This Manifest covers the three NAD configuration files and three customized workload templates generated above. Then, the client-go SDK is used to call the standardized Kubernetes API to submit this Manifest to the cluster. The Helm command-line tool automatically identifies the dependency logic between resources and creates all resources in the templates directory of the Chart in sequence according to this dependency logic: first, three NetworkAttachmentDefinition resources are created, followed by three Deployment resources, to achieve automated deployment with multiple replicas.

[0042] In some embodiments, after deployment is complete, the IP allocation of the application replicas can be queried and displayed through the Kubernetes client-go SDK to verify the deployment completion status.

[0043] The following reference Figure 2 The preprocessing and standard deployment processes shown in the flowchart illustrate the specific implementation process of the fixed IP automated deployment method for multiple replicas of Kubernetes applications provided in this application.

[0044] Reference Figure 2 As shown, the implementation of a fixed IP automated deployment method for multiple replicas of Kubernetes applications provided in this embodiment mainly relies on the following core modules: Helm Extended Command Module: Serving as the entry point for user interaction, this module extends the Helm command-line tool and provides the `minstall` command. Internally, this command calls the preprocessing engine and is responsible for parsing user input parameters.

[0045] Preprocessing engine: The core of this application, responsible for coordinating all subsequent preprocessing steps. It starts after receiving the mmemert command and executes a series of logic such as IP allocation, configuration generation, and chart assembly.

[0046] Cluster Status Query Tool: Utilizes the k8s.io / client-go library to establish a connection with the target Kubernetes cluster API server, and is responsible for querying the existing network configuration resources within the cluster to provide a basis for IP allocation decisions.

[0047] IP Allocator: Implements the IP allocation algorithm, calculates and allocates a list of deterministic and conflict-free IP addresses based on the user-specified address range (CIDR) and the number of replicas, combined with the cluster's already used IP information.

[0048] Configuration generator: Contains two sub-generators: NAD Generator: Generates a NetworkAttachmentDefinition (NAD) YAML configuration file conforming to the Multus CNI specification based on the assigned IP address.

[0049] Workload generator: Loads the user-provided raw workload YAML template, copies and renames it, injects specific network annotations into its Pod template, and binds it to the corresponding NAD.

[0050] Chart Assembler: Using the helm.sh / helm / v3 SDK, a structured HelmChart object is created in memory, and all generated NAD configurations and customized workload configuration files are populated into it as templates. The complete Chart package can be persisted to disk.

[0051] Standard deployment executor: After preprocessing, it calls the standard Install command of the Helm SDK to deploy the assembled Chart package to the Kubernetes cluster, completing the final installation of the application.

[0052] Based on the aforementioned core modules, the specific implementation of this application embodiment includes a preprocessing process and a standard deployment process. The preprocessing process includes: The minstall command is executed via the Helm extended command module, and the specified network address range and number of deployed replicas contained in the command are parsed. The preprocessing engine sends a query request to the cluster via client-go to obtain all resources of type NetworkAttachmentDefinition under the prod-db namespace and parses the IP address information in its spec.config field. Assume that 192.168.200.1 and 192.168.200.5 are already in use. The IP allocator, excluding the already occupied IP addresses 192.168.200.1 and 192.168.200.5 from the specified 192.168.200.0 / 28 network segment, then allocates the first three available IP addresses in ascending address order. The allocation results are: Replica 1: 192.168.200.2, Replica 2: 192.168.200.3, Replica 3: 192.168.200.4; The NAD generator generates a NAD configuration file required by the Multus CNI plugin for each assigned IP address, which contains the pre-assigned IP address. The workload generator reads the user-provided workload template (mysql-deployment.yaml). Assuming it defines a Deployment named mysql, the workload generator will first copy and generate three customized workload templates (Deployment YAML files), named mysql-2, mysql-3, and mysql-4 respectively. Then, it adds network annotations to each Deployment, pointing to the corresponding NAD configuration file. The Chart assembler creates a new Chart object in memory, sets its Chart.yaml metadata, and then puts the three NAD YAML files and three customized Deployment YAML files generated in the above steps into the templates directory of the Chart object. At this point, a Chart package containing six Kubernetes resource definitions and complete internal relationships is ready in memory. The `--save-chart` parameter determines whether to save the temporarily generated Chart object to the local file system. If the user specifies the `--save-chart` parameter, the system will serialize the Chart structure in memory into a file and save it to the specified directory.

[0053] After completing the above preprocessing steps, the standard deployment process can be executed using the standard Helm installation command. The preprocessing engine calls the Helm SDK to execute the standard Helm installation command (Helm install), first rendering the Chart template files in the templates directory into a complete, standard Kubernetes manifest. This manifest includes the three NAD configuration files and three customized workload templates generated above. Then, the client-go SDK calls the standardized Kubernetes API to submit this manifest to the cluster. The Helm command-line tool automatically identifies the dependency logic between resources and creates all resources in the templates directory of the Chart according to this logic: first, three NetworkAttachmentDefinition resources are created, followed by three Deployment resources. The Multus CNI plugin binds fixed IPs through added network annotations and starts the Pods, thus completing the automated deployment of multiple replicas.

[0054] In summary, the fixed IP automated deployment method for multiple replicas of Kubernetes applications provided in this application pre-allocates an independent and unused IP for each replica before deployment, replacing the traditional method of dynamically allocating IPs after Pod startup. This ensures that the IP address of each replica can be accurately determined before deployment, solving the problems of uncontrollable IP addresses and error-prone deployment results. Furthermore, by automatically generating NAD configuration files bound to fixed IPs and batch customizing workload templates associated with NADs, the tedious operation of manually generating NADs and adding network annotations is replaced, significantly reducing labor costs and improving the efficiency of fixed IP configuration. Additionally, by assembling all configurations into a Chart package conforming to the Helm specification, without modifying the core components of the Kubernetes cluster or the Multus CNI source code, it is compatible with mainstream K8s versions and the Helm ecosystem, improving the versatility and compatibility of the solution. This application achieves a one-click conversion from user input to a deployable Chart package, significantly improving deployment efficiency, reliability, and consistency, laying a solid foundation for subsequent automated deployment.

[0055] like Figure 3As shown, this application also provides a fixed IP automated deployment system for multiple replicas of Kubernetes applications. This system can be used to implement any step of the above-described method for automated deployment of multiple replicas of Kubernetes applications using a fixed IP, and its optional embodiments. (Refer to...) Figure 3 As shown, the system includes a receiving module 210, a pre-allocation module 220, a configuration module 230, and an assembly module 240.

[0056] The receiving module 210 receives user deployment instructions, which specify at least a network address range and the number of deployment replicas. The pre-allocation module 220 pre-allocates an independent, unused IP address for each replica before deployment, based on the network address range and the number of deployment replicas. The configuration module 230 generates a corresponding NAD configuration file for Multus CNI for each pre-allocated IP address, which contains the pre-allocated IP address. It loads user-specified workload templates, copies and generates multiple customized workload templates with added network annotations according to the number of deployment replicas, and these network annotations are used to associate with the corresponding NAD configuration files. The assembly module 240 assembles the NAD configuration files and customized workload templates into a Chart package conforming to the Helm specification for automated deployment.

[0057] It should be understood that the systems or modules in the embodiments of this application can be implemented by software, for example, by computer programs or instructions having the above-described functions. The corresponding computer programs or instructions can be stored in the internal memory of the terminal, and the processor reads the corresponding computer programs or instructions from the memory to implement the above functions. Alternatively, the systems or modules in the embodiments of this application can also be implemented by hardware. Or, the systems or modules in the embodiments of this application can also be implemented by a combination of a processor and software modules.

[0058] It should be understood that the processing details of the system or module in the embodiments of this application can be found by referring to... Figures 1-2 The descriptions of the embodiments and related extended embodiments shown will not be repeated in this application.

[0059] Figure 4 This is a structural diagram of a computing device 1000 provided in an embodiment of this application. The computing device 1000 includes: a processor 1010, a memory 1020, a communication interface 1030, and a bus 1040.

[0060] It should be understood that Figure 4 The communication interface 1030 in the computing device 1000 shown can be used to communicate with other devices.

[0061] The processor 1010 can be connected to the memory 1020. The memory 1020 can be used to store the program code and data. Therefore, the memory 1020 can be a storage unit inside the processor 1010, an external storage unit independent of the processor 1010, or a component that includes both the storage unit inside the processor 1010 and the external storage unit independent of the processor 1010.

[0062] Optionally, the computing device 1000 may also include a bus 1040. The memory 1020 and communication interface 1030 can be connected to the processor 1010 via the bus 1040. The bus 1040 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 1040 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0063] It should be understood that in the embodiments of this application, the processor 1010 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 1010 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0064] The memory 1020 may include read-only memory and random access memory, and provides instructions and data to the processor 1010. A portion of the processor 1010 may also include non-volatile random access memory. For example, the processor 1010 may also store device type information.

[0065] When the computing device 1000 is running, the processor 1010 executes the computer execution instructions in the memory 1020 to perform the operation steps of the above method.

[0066] It should be understood that the computing device 1000 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the other operations and / or functions of each module in the computing device 1000 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0067] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0068] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0069] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0070] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0071] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0072] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0073] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0074] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0075] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device.

[0076] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0077] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0078] It should be noted that the embodiments described in this application are merely some embodiments, not all embodiments. The components of the embodiments of this application typically described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the above detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0079] The terms "first, second, third, etc." or similar terms such as module A, module B, module C, etc., used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that a specific order or sequence may be interchanged where permitted so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0080] In the above description, the labels indicating the steps do not necessarily mean that the steps will be executed. They may include intermediate steps or be replaced by other steps. Where permissible, the order of the steps may be interchanged or executed simultaneously.

[0081] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0082] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0083] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present application has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, all of which fall within the scope of protection of the present invention.

Claims

1. A method for automated deployment of multiple replicas of Kubernetes applications using fixed IP addresses, characterized in that: include: Receive user deployment instructions, wherein the deployment instructions specify at least a network address range and the number of deployment replicas; Based on the network address range and the number of deployed replicas, a unique, unused IP address is pre-assigned to each replica before deployment execution; For each pre-allocated IP address, a corresponding NAD configuration file is generated. The user-specified workload template is loaded, and multiple customized workload templates with added network annotations are generated according to the number of deployment replicas. These network annotations are used to associate with the corresponding NAD configuration file. The NAD configuration file and customized workload template are assembled into a Helm-compliant Chart package for automated deployment.

2. The method according to claim 1, characterized in that, The pre-allocation of a unique, unused IP address to each replica specifically includes: The Kubernetes client interface is used to query the existing NAD resources in the cluster and obtain a list of IP addresses that are already in use within the network address range. Exclude occupied IP addresses from the network address range, filter out unused IPs equal to the number of deployed replicas, and allocate them to each replica in ascending order of address or according to preset rules.

3. The method according to claim 1, characterized in that, After assembling into a Chart package conforming to the Helm specification, it also includes: The Chart package is statically exported as a file and saved to the local file system.

4. The method according to claim 1, characterized in that, The automated deployment specifically includes: The Chart package is deployed by calling standard Helm installation commands to complete the automated deployment of multiple replicas of Kubernetes applications on fixed IPs.

5. The method according to claim 1, characterized in that, The user deployment instructions are received via an extended Helm command-line tool that adds preprocessing logic before the standard Helm install command and supports at least the following parameters: Specify the network address range, the number of replicas, and the file path of the workload template.

6. The method according to claim 1, characterized in that, The workload template supports Deployment, StatefulSet, Job, or Pod resource types in Kubernetes; the network annotation uses the standard annotation key of Multus CNI, and the value is the name of the corresponding NAD configuration file.

7. The method according to claim 1, characterized in that, The assembly process of the Chart package includes: Create a Chart object in memory using the Helm Golang SDK, and write the NAD configuration file and customized workload template to the templates directory of the Chart object.

8. A fixed-IP automated deployment system for multiple replicas of Kubernetes applications, characterized in that, include: A receiving module is used to receive user deployment instructions, wherein the deployment instructions specify at least a network address range and the number of deployment replicas; The pre-allocation module is used to pre-allocate an independent, unused IP address for each replica before deployment execution, based on the network address range and the number of deployed replicas. The configuration module is used to generate a corresponding NAD configuration file for each pre-allocated IP address, load the user-specified workload template, and copy and generate multiple customized workload templates with added network annotations according to the number of deployment replicas. These network annotations are used to associate with the corresponding NAD configuration file. An assembly module is used to assemble the NAD configuration file and customized workload template into a Chart package that conforms to the Helm specification for automated deployment.

9. A computing device, characterized in that, include: processor; Memory, used to store one or more programs; When the processor executes one or more programs, the processor implements a fixed IP automated deployment method for multiple replicas of Kubernetes applications as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a computer, the computer program implements a fixed IP automated deployment method for multiple replicas of a Kubernetes application as described in any one of claims 1 to 7.

Images