Cross-Kubernetes cluster service deployment method and device and electronic equipment
By determining the deployment order and batch division of Pods across Kubernetes clusters and generating control logic between batches, the problem of lack of refined control in existing technologies is solved, and flexible and efficient control of cross-cluster service deployment is achieved.
Patent Information
- Application Number
- CN202410289023.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-03-13
- Publication Date
- 2025-09-16
AI Technical Summary
Existing cross-Kubernetes cluster service deployment strategies lack fine-grained control and cannot deliver personalized deployment configurations for multiple Kubernetes clusters.
By determining the deployment order of multiple Pods and dividing the Pods into multiple batches based on the batching strategy of service deployment, and generating control logic between batches, fine-grained control of each batch of Pods is achieved.
It enables refined control of cross-Kubernetes cluster service deployment, improves deployment flexibility and efficiency, and meets security and high availability requirements.
Smart Images
Figure CN120653353A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of service deployment, and more specifically, to a method, apparatus, and electronic device for deploying services across Kubernetes clusters. Background Art
[0002] Kubernetes, abbreviated as K8s, is an open source platform for orchestrating and managing containers. Kubernetes aims to make deploying containerized applications simple and efficient. Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance.
[0003] In some scenarios, an application cluster's services are deployed in a single Kubernetes cluster, relying on Kubernetes native or open-source workloads for fine-grained deployment control. In other scenarios, an application cluster's services are deployed across multiple Kubernetes clusters, meaning they are deployed across Kubernetes clusters. In these scenarios, current deployment strategies can only deliver batch deployment configurations to all Kubernetes clusters, without fine-grained deployment control. Summary of the Invention
[0004] This application provides a service deployment method, device, and electronic device across Kubernetes clusters, which implements refined service deployment across Kubernetes clusters.
[0005] First, this application provides a method for deploying services across Kubernetes clusters, including:
[0006] Determine the deployment order of multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters;
[0007] Based on the deployment order and in accordance with the batching strategy of service deployment, the multiple Pods are divided into multiple batches and control logic between batches is generated;
[0008] Based on the control logic between batches, control the Pod deployment services of each batch.
[0009] In one implementation, the multiple Pods are Pods in multiple regions, and the Pods in the multiple regions are distributed in at least two Kubernetes clusters;
[0010] Determining the deployment order of multiple Pods includes:
[0011] Determine the deployment order of the multiple Pods in each zone.
[0012] In one implementation, the region is an availability zone or a geographical area, and the deployment order is a user-specified order or a default order.
[0013] In one implementation, before determining the deployment order of the multiple Pods, the method further includes:
[0014] Based on the context information of each Kubernetes cluster where all Pods of the service to be deployed are located, all Pods of the service to be deployed are screened to obtain the multiple Pods of the deployable service.
[0015] In one implementation, the inter-batch control logic is used to control the deployment triggering method and / or deployment interval duration between batches.
[0016] In one implementation, dividing the plurality of Pods into a plurality of batches based on the deployment order and in accordance with a batching strategy for service deployment and generating control logic between batches includes:
[0017] Based on the deployment order, the multiple Pods are divided into multiple batches according to the number of each batch in the batch strategy, and the control logic between batches is generated according to the deployment triggering method and / or deployment interval duration between batches in the batch strategy.
[0018] In one implementation, the batch strategy is a user-specified batch strategy or a default batch strategy.
[0019] In one implementation, the control logic between batches is used to control the Pod deployment service of each batch, including:
[0020] According to the control logic between batches, for the Pods of the target batch, the deployment configuration information of the Pods of the target batch is sent to one or more Kubernetes clusters where the Pods of the target batch are located to control the Pod deployment service of the target batch.
[0021] In a second aspect, the present application provides a service deployment device across Kubernetes clusters, including:
[0022] A sequence control module is used to determine the deployment order of multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters;
[0023] A policy control module, configured to divide the plurality of Pods into a plurality of batches based on the deployment order and in accordance with the batching strategy of service deployment, and to generate control logic between batches;
[0024] The deployment module is used to control the Pod deployment services of each batch based on the control logic between batches.
[0025] In one implementation, the multiple Pods are Pods in multiple regions, and the Pods in the multiple regions are distributed in at least two Kubernetes clusters;
[0026] The sequential control module is used to:
[0027] Determine the deployment order of the multiple Pods in each zone.
[0028] In one implementation, the region is an availability zone or a geographical area, and the deployment order is a user-specified order or a default order.
[0029] In one implementation, the sequence control module is further configured to:
[0030] Based on the context information of each Kubernetes cluster where all Pods of the service to be deployed are located, all Pods of the service to be deployed are screened to obtain the multiple Pods of the deployable service.
[0031] In one implementation, the inter-batch control logic is used to control the deployment triggering method and / or deployment interval duration between batches.
[0032] In one implementation, the policy control module is configured to:
[0033] Based on the deployment order, the multiple Pods are divided into multiple batches according to the number of each batch in the batch strategy, and the control logic between batches is generated according to the deployment triggering method and / or deployment interval duration between batches in the batch strategy.
[0034] In one implementation, the batch strategy is a user-specified batch strategy or a default batch strategy.
[0035] In one implementation, the deployment module is configured to:
[0036] According to the control logic between batches, for the Pods of the target batch, the deployment configuration information of the Pods of the target batch is sent to one or more Kubernetes clusters where the Pods of the target batch are located to control the Pod deployment service of the target batch.
[0037] In a third aspect, the present application provides an electronic device, comprising: a memory and a processor;
[0038] The memory is used to store computer programs;
[0039] The processor is configured to execute a computer program stored in the memory, and when the computer program is run, the processor is enabled to execute the method according to the first aspect.
[0040] In a fourth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes the method described in the first aspect.
[0041] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which implements the method described in the first aspect when executed by a processor.
[0042] The service deployment method, device and electronic device across Kubernetes clusters provided in this application control the deployment order of multiple Pods across Kubernetes clusters, divide the multiple Pods into batches, and deploy services for each batch of Pods based on the control logic between batches, thereby achieving refined control of service deployment across Kubernetes clusters. Among them, the sorting of multiple Pods across multiple Kubernetes clusters can be sorting between each Pod, or it can be regional sorting of multiple Pods belonging to different regions. In addition, for the sorted regions, the Pods in the regions can also be sorted, thereby achieving refined control over the deployment order. For the divided batches, the deployment triggering method and / or the deployment interval duration between batches can be controlled, thereby achieving refined control between batches. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.
[0044] Figure 1 This is a flow chart of a service deployment method across Kubernetes clusters provided by an embodiment of the present application;
[0045] Figure 2 This is a high-availability service deployment topology diagram provided in an embodiment of the present application;
[0046] Figure 3 This is a flow chart of a refined deployment control process for high-availability services provided by an embodiment of the present application;
[0047] Figure 4 This is a structural diagram of a service deployment device across Kubernetes clusters provided by an embodiment of the present application;
[0048] Figure 5 It is a schematic block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0049] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0050] The following describes the terms used in the embodiments of the present application.
[0051] Kubernetes: A platform for orchestrating and managing containers.
[0052] Availability Zone: A physical area in the same region with independent power and network. When a failure occurs, the failure is isolated within an availability zone.
[0053] Pod: The resource scheduling and business operation unit in Kubernetes.
[0054] Application instance (AppInstance): A logical unit that manages a group of Pods.
[0055] Application cluster: A collection of Pods that provide the same service and have the same configuration.
[0056] For services deployed across Kubernetes clusters, users may want to have fine-grained control over the service deployment process for security, high availability, and other considerations. For example, for multiple Pods across Kubernetes clusters, users may want to prioritize the deployment of some Pods, or deploy a certain number of Pods simultaneously as a batch. Or, after deploying some Pods, users may want to complete some verification work before deploying other Pods.
[0057] In view of this, an embodiment of the present application proposes a service deployment method across Kubernetes clusters, which controls the deployment order of multiple Pods across Kubernetes clusters, divides multiple Pods into batches, and deploys services for each batch of Pods based on the control logic between batches, thereby realizing refined control of service deployment across Kubernetes clusters.
[0058] Figure 1This is a flow chart of a cross-Kubernetes cluster service deployment method provided by an embodiment of the present application. The execution subject of this method can be a deployment controller. Figure 1 As shown, the method includes:
[0059] S101. Determine a deployment order for multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters.
[0060] The deployment order of multiple pods can be determined by the deployment controller, specified by the user, or set by the default. The default deployment order can also be set by the user. The deployment order can be determined by the deployment controller or the user based on specific requirements, such as load, traffic volume, priority, or security rules. In actual applications, users can specify a specific deployment order based on specific needs.
[0061] Optionally, the multiple Pods in the embodiment of the present application may be Pods in multiple regions, and the Pods in multiple regions are distributed in at least two Kubernetes clusters, wherein the regions may be regions divided according to certain rules or objectives, for example, the regions may be availability zones, or the regions may be geographical areas divided according to geographical locations. The embodiment of the present application does not specifically limit the way of dividing regions.
[0062] Optionally, the deployment order can be a Pod-by-Pod deployment order. For example, if there are six Pods, the deployment order of the multiple Pods in this step can be determined by determining the order among the six Pods. For example, the six Pods are sorted by business volume, with Pods with less business volume deployed first and Pods with more business volume deployed last, to reduce the impact of the service deployment process.
[0063] Optionally, the deployment order may be the deployment order of each region, that is, determining the deployment order of multiple Pods includes: determining the deployment order of each region where the multiple Pods are located. For example, the number of Pods is 6, belonging to 3 regions respectively. In this step, determining the deployment order of multiple Pods may be determining the deployment order between the 3 regions. For example, the 3 regions are sorted according to the load, with the deployment order of the regions with low load being first and the deployment order of the regions with high load being last, so as to reduce the impact of the service deployment process. For example, when the regions are cities, the 3 regions are sorted according to specific city priorities, with the deployment order of cities with low priority being first and the deployment order of cities with high priority being last, so as to reduce the impact of the service deployment process.
[0064] Optionally, when determining the deployment order of each zone where multiple Pods are located, the deployment order of the Pods within each zone can be unrestricted, or the deployment order between the Pods within each zone can be further determined. For example, for each zone, the Pods are sorted according to their priority or importance, with Pods with lower priority or importance deployed first and Pods with higher priority or importance deployed last, to reduce the impact of the service deployment process.
[0065] For the sorting of multiple Pods across multiple Kubernetes clusters, fine-grained control over the deployment order is achieved by sorting each Pod between them, or sorting multiple Pods belonging to different regions, or sorting Pods in regions for already sorted regions.
[0066] Optionally, since the status of each Kubernetes cluster and the status of the external interfaces or external dependencies involved in each Kubernetes cluster change dynamically during the operation of the application cluster, in some cases, there may be some Kubernetes clusters that are abnormal, or some Kubernetes clusters that are globally blocked due to external interfaces being unavailable. Therefore, before deploying the service, you can first filter out the Pods that can be deployed, and then further control and perform refined deployment. That is, before step S101, all Pods of the service to be deployed can be filtered based on the context information of each Kubernetes cluster where all the Pods of the service to be deployed are located, so as to obtain multiple Pods of the service to be deployed. Among them, the context information includes information such as whether the Kubernetes cluster is abnormal, whether the network is globally blocked, etc.
[0067] S102. Based on the deployment order and in accordance with the batching strategy of service deployment, multiple Pods are divided into multiple batches and control logic between batches is generated.
[0068] The batch strategy can be a user-specified batch strategy or a default batch strategy. The inter-batch control logic is used to control how services are deployed for each batch of Pods. Optionally, the inter-batch control logic is used to control the deployment triggering method and / or deployment interval duration between batches. Optionally, based on the deployment order, multiple Pods are divided into multiple batches according to the number of batches in the batch strategy, and the inter-batch control logic is generated according to the inter-batch deployment triggering method and / or deployment interval duration in the batch strategy. Pods in the same batch can belong to different Kubernetes clusters.
[0069] The batching strategy includes the number of batches. For example, the first batch includes one Pod, the second batch includes two Pods, and the third batch includes all remaining Pods. Based on the number of batches and the deployment order of the multiple Pods determined above, the multiple Pods can be divided into multiple batches in sequence.
[0070] The batch strategy includes the deployment trigger method and deployment interval between batches. The inter-batch control logic controls how the next batch deployment is triggered after each batch deployment is completed, based on the deployment interval and specific deployment trigger method. The deployment trigger method and deployment interval between different batches can be different. Deployment triggering can be manual or automatic. Manual triggering means that the user triggers the deployment of the next batch after the current batch deployment is completed. Automatic triggering means that the deployment of the next batch is automatically triggered after the current batch deployment is completed.
[0071] For example, the deployment triggering method between the first and second batches is manual triggering, and the deployment triggering method between the second and third batches and subsequent batches is automatic triggering. The deployment interval between the first and second batches is greater than 15 minutes, and the deployment interval between the second and third batches and subsequent batches is 1 minute. This makes it easy to fully verify whether the service is running normally within a sufficient deployment interval after the first batch deployment is completed, and then manually trigger the deployment of the second batch after verification. After the second batch and subsequent batches are deployed, subsequent batch deployments can be automatically triggered after a shorter deployment interval, thereby improving the degree of automation of deployment and improving deployment efficiency. Through the deployment triggering method and / or deployment interval between batches, fine-grained control between batches is achieved.
[0072] S103. Based on the control logic between batches, control the Pod deployment service of each batch.
[0073] According to the control logic between batches, for the Pods of the target batch, the deployment configuration information of the Pods of the target batch is sent to one or more Kubernetes clusters where the Pods of the target batch are located to control the deployment service of the Pods of the target batch.
[0074] For example, the deployment controller sends the deployment configuration information of the first batch of Pods to one or more Kubernetes clusters where the first batch of Pods are located. After the first batch of Pods is deployed and an interval of 15 minutes, in response to the user's manual operation to trigger the second batch of deployment, the deployment controller sends the deployment configuration information of the second batch of Pods to one or more Kubernetes clusters where the second batch of Pods are located. After the second batch of Pods is deployed and an interval of 1 minute, the deployment controller automatically sends the deployment configuration information of the third batch of Pods to one or more Kubernetes clusters where the third batch of Pods are located, and so on, to control the deployment service of each batch of Pods.
[0075] The cross-Kubernetes cluster service deployment method of the embodiment of the present application controls the deployment order of multiple Pods across the Kubernetes cluster, divides the multiple Pods into batches, and deploys services to each batch of Pods based on the control logic between batches, thereby achieving refined control of cross-Kubernetes cluster service deployment.
[0076] The following uses the example of dividing the Pods in the application cluster into multiple availability zones according to the principle of high availability to illustrate the service deployment method of the embodiment of the present application.
[0077] Figure 2 This is a high-availability service deployment topology diagram provided by an embodiment of the present application. The application cluster is associated with a high-availability configuration, in which the number of pods in each availability zone can be specified. Figure 2 The example uses an application cluster with three availability zones. In this example, an availability zone can represent a single physical machine. AppInstances are configured based on the availability zones of the application cluster. Each availability zone corresponds to an appInstance, and each appInstance is associated with one or more Pods. AppInstances in different availability zones can be distributed within the same Kubernetes cluster or across different Kubernetes clusters, allowing for flexible allocation based on the application cluster configuration.
[0078] When the Figure 2 When performing fine-grained deployment control on high-availability services, refer to Figure 3 The control flow diagram shown. Figure 3 The release controller includes a release sequence controller, a release policy controller and a configuration issuer, wherein the release controller can be called a deployment controller, the release sequence controller can be called a deployment sequence controller, and the release policy controller can be called a deployment policy controller.
[0079] First, the release sequence controller filters all Pods of the deployed service based on the external context, obtains multiple Pods of the deployable service, and determines the deployment order of multiple Pods according to the high availability rules of the service. Figure 3 Taking the deployment order of multiple Pods in each zone as an example, the order is Availability Zone 2, Availability Zone 1, and Availability Zone 3.
[0080] Afterwards, the release policy controller divides multiple Pods into batches and determines the control logic between batches. Figure 3 The Pods in a shaded box are from the same batch. The first batch includes one Pod in Availability Zone 2, the second batch includes another Pod in Availability Zone 2 and one Pod in Availability Zone 1, and the third batch includes two more Pods in Availability Zone 1 and one Pod in Availability Zone 3. The control logic between batches includes: the deployment trigger method between the first and second batches is manual triggering, and the deployment interval is greater than or equal to 15 minutes; the deployment trigger method between the second and third batches is automatic triggering, and the deployment interval is 1 minute.
[0081] Finally, the configuration publisher sends the corresponding deployment configuration information to the Kubernetes cluster where each batch of Pods is located according to the batches determined by the release policy controller and the control logic between batches, the deployment interval duration and the deployment trigger method, thereby controlling the deployment service of each batch of Pods.
[0082] The cross-Kubernetes cluster service deployment method of the embodiment of the present application controls the deployment order of Pods across multiple areas of the Kubernetes cluster, divides the multiple Pods into batches, and deploys services for each batch of Pods based on the control logic between batches, thereby achieving refined control of cross-Kubernetes cluster service deployment.
[0083] Figure 4 This is a schematic diagram of the structure of a service deployment device across Kubernetes clusters provided by an embodiment of the present application. Figure 4 As shown, the cross-Kubernetes cluster service deployment device 400 includes:
[0084] Sequence control module 401, used to determine the deployment order of multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters;
[0085] The policy control module 402 is used to divide multiple Pods into multiple batches based on the deployment order and the batch strategy of service deployment, and generate control logic between batches;
[0086] The deployment module 403 is used to control the Pod deployment service of each batch based on the control logic between batches.
[0087] In one implementation, the multiple Pods are Pods in multiple regions, and the Pods in the multiple regions are distributed in at least two Kubernetes clusters;
[0088] The sequence control module 401 is used to:
[0089] Determine the deployment order of multiple Pods in each zone.
[0090] In one implementation, the region is an availability zone or a geographic region, and the deployment order is a user-specified order or a default order.
[0091] In one implementation, the sequence control module 401 is further configured to:
[0092] Based on the context information of each Kubernetes cluster where all Pods of the service to be deployed are located, all Pods of the service to be deployed are filtered to obtain multiple Pods on which the service can be deployed.
[0093] In one implementation, the control logic between batches is used to control the deployment triggering method and / or the deployment interval duration between batches.
[0094] In one implementation, the policy control module 402 is configured to:
[0095] Based on the deployment order, multiple Pods are divided into multiple batches according to the number of batches in the batch strategy, and the control logic between batches is generated according to the deployment trigger method and / or deployment interval length between batches in the batch strategy.
[0096] In one implementation, the batch strategy is a batch strategy specified by a user or a default batch strategy.
[0097] In one implementation, the deployment module 403 is configured to:
[0098] According to the control logic between batches, for the Pods of the target batch, the deployment configuration information of the Pods of the target batch is sent to one or more Kubernetes clusters where the Pods of the target batch are located to control the deployment service of the Pods of the target batch.
[0099] The device of the embodiment of the present application can be used to execute the service deployment method across Kubernetes clusters in the aforementioned embodiment. Its implementation principle and technical effects are similar and will not be repeated here.
[0100] Figure 5 Schematic block diagram of an electronic device provided in an embodiment of the present application. Figure 5As shown, the electronic device 500 may include at least one processor 501 for implementing the service deployment method across Kubernetes clusters provided in an embodiment of the present application.
[0101] Optionally, the electronic device 500 further includes at least one memory 502 for storing program instructions and / or data. The memory 502 is coupled to the processor 501. The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, and is used for information exchange between devices, units, or modules. The processor 501 may operate in conjunction with the memory 502. The processor 501 may execute program instructions stored in the memory 502. At least one of the at least one memory may be included in the processor.
[0102] Optionally, the electronic device 500 further includes a communication interface 503 for communicating with other devices via a transmission medium, thereby enabling the electronic device 500 to communicate with other devices. The communication interface 503 may be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of implementing transceiver functions. The processor 501 may utilize the communication interface 503 to transmit and receive data and / or information, and to implement the methods provided in the embodiments of the present application. For details, please refer to the detailed description in the preceding embodiments, which will not be repeated here.
[0103] The specific connection medium between the processor 501, the memory 502 and the communication interface 503 is not limited in the embodiment of the present application. Figure 5 In the embodiment, the processor 501, the memory 502 and the communication interface 503 are connected via a bus 504. The bus 504 is Figure 5 The connections between the other components are shown in bold lines, which are only for illustration and not intended to be limiting. The bus can be divided into address bus, data bus, control bus, etc. Figure 5 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.
[0104] It should be understood that the processor in the embodiments of the present application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above-mentioned method embodiment can be completed by hardware integrated logic circuits in the processor or by software instructions. The above-mentioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above-mentioned method.
[0105] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0106] The present application also provides a computer-readable storage medium storing a computer program (also referred to as code or instruction). When the computer program is executed by a processor, the computer executes the method in any of the aforementioned embodiments.
[0107] The present application also provides a computer program product, including a computer program, which implements the method in any of the aforementioned embodiments when executed by a processor.
[0108] The terms "unit," "module," and the like used in this specification may be used to refer to a computer-related entity, hardware, firmware, a combination of hardware and software, software, or software in execution.
[0109] Those skilled in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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. In the several embodiments provided in this application, it should be understood that the disclosed devices, equipment, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, and can be electrical, mechanical, or other forms.
[0110] The units described as separate components may or may not be physically separate, and 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 may be selected to achieve the purpose of the solution of this embodiment according to actual needs.
[0111] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0112] In the above-described embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (program) are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state disk (SSD)).
[0113] If this function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.
[0114] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0115] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.
Claims
1. A service deployment method across Kubernetes clusters, characterized in that: include: Determine the deployment order of multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters; Based on the deployment order and in accordance with the batching strategy of service deployment, the multiple Pods are divided into multiple batches and control logic between batches is generated; Based on the control logic between batches, control the Pod deployment services of each batch.
2. The method according to claim 1, characterized in that The multiple Pods are Pods in multiple regions, and the Pods in the multiple regions are distributed in at least two Kubernetes clusters; Determining the deployment order of multiple Pods includes: Determine the deployment order of the multiple Pods in each zone.
3. The method according to claim 2, characterized in that The region is an availability zone or a geographical area, and the deployment order is an order specified by the user or a default order.
4. The method according to any one of claims 1 to 3, characterized in that Before determining the deployment order of the multiple Pods, the method further includes: Based on the context information of each Kubernetes cluster where all Pods of the service to be deployed are located, all Pods of the service to be deployed are screened to obtain the multiple Pods of the deployable service.
5. The method according to any one of claims 1 to 3, characterized in that The inter-batch control logic is used to control the deployment triggering method and / or deployment interval duration between batches.
6. The method according to claim 5, characterized in that Based on the deployment order and in accordance with the batching strategy of service deployment, the multiple Pods are divided into multiple batches and control logic between batches is generated, including: Based on the deployment order, the multiple Pods are divided into multiple batches according to the number of each batch in the batch strategy, and the control logic between batches is generated according to the deployment triggering method and / or deployment interval duration between batches in the batch strategy.
7. The method according to claim 6, characterized in that The batch strategy is a batch strategy specified by the user or a default batch strategy.
8. The method according to claim 1, characterized in that The control logic between batches controls the Pod deployment service for each batch, including: According to the control logic between batches, for the Pods of the target batch, the deployment configuration information of the Pods of the target batch is sent to one or more Kubernetes clusters where the Pods of the target batch are located to control the Pod deployment service of the target batch.
9. A service deployment device across Kubernetes clusters, characterized in that include: A sequence control module is used to determine the deployment order of multiple Pods, where the multiple Pods are Pods in at least two Kubernetes clusters; A policy control module is used to divide the multiple Pods into multiple batches based on the deployment order and in accordance with the batching strategy of service deployment, and generate control logic between batches, wherein the control logic between batches is used to control the deployment triggering method and / or deployment interval duration between batches; The deployment module is used to control the Pod deployment services of each batch based on the control logic between batches.
10. An electronic device, characterized in that: include: memory and processor; The memory is used to store computer programs; The processor is configured to execute a computer program stored in the memory, and when the computer program is executed, the processor is enabled to execute the method according to any one of claims 1 to 8.
11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 8.
12. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 8 when the computer program is executed by a processor.