Cloud gateway containerized management system and method, storage medium and program product

Abstract

The present application provides a cloud gateway containerized management system and method, storage medium and program product, which belongs to the field of cloud native. The system includes a network hook component, a controller component, a data storage component and a service node, and a container running a cloud gateway application is deployed on the service node; the network hook component receives a first management request from a user account for a service node, and determines whether the number of available containers is less than a preset number, the number of available containers is the number of available containers on the service node after the first management request is executed, and the preset number is the minimum number of available containers on the service node; when the number of available containers is greater than the preset number, the first management request is stored in the data storage component; the controller component obtains the first management request from the data storage component, and manages the container on the service node in response to the first management request. When the present application applies the native Kubernetes system to the cloud gateway service, it can ensure the number of available containers.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a cloud gateway containerized management system and method, storage medium, and program product. Background Art

[0002] As the traffic aggregation center of the cloud network, the cloud gateway provides services such as traffic management, security protection, load balancing, protocol conversion, and identity authentication for various products in the cloud network. With the development of cloud native technology, containerization has become the development trend of cloud gateways. With the application of microservice architecture and the implementation of Kubernetes, containerized applications will run easy-to-migrate and lightweight workloads in the Pod of the Kubernetes cluster, and multiple Pods will jointly provide services. When the Pod is abnormal, high availability can be achieved by restarting the service.

[0003] However, compared with microservices, cloud gateway services have the characteristics of heavy load, slow startup, and high reliability requirements. They cannot start and stop services frequently and quickly. Therefore, when the native Kubernetes system is applied to the cloud gateway service, the number of available Pods cannot be guaranteed. Summary of the invention

[0004] The embodiment of the present application provides a cloud gateway container management system and method, storage medium and program product, which can ensure the number of available containers when the native Kubernetes system is applied to the cloud gateway service. The technical solution is as follows:

[0005] In a first aspect, a cloud gateway containerized management system is provided, the system comprising: a network hook component, a controller component, a data storage component and a service node, at least one container is deployed on the service node, and a cloud gateway application is run in the container;

[0006] The network hook component is used to receive a first management request from a user account for the service node, determine whether the number of available containers is less than a preset number, the number of available containers being the number of available containers on the service node after the first management request is executed, and the preset number being the minimum number of available containers on the service node; when the number of available containers is greater than the preset number, store the first management request in the data storage component;

[0007] The controller component is used to obtain the first management request from the data storage component, and manage the container on the service node in response to the first management request.

[0008] In a second aspect, a cloud gateway container management method is provided, the method applying the cloud gateway container management system according to the first aspect, the method comprising:

[0009] The network hook component receives a first management request from a user account for the service node, determines whether the number of available containers is less than a preset number, the number of available containers being the number of available containers on the service node after the first management request is executed, and the preset number being the minimum number of available containers on the service node; when the number of available containers is greater than the preset number, stores the first management request in the data storage component;

[0010] The controller component obtains the first management request from the data storage component, and manages the container on the service node in response to the first management request.

[0011] In a third aspect, an electronic device is provided, comprising a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the cloud gateway containerization management method described in the second aspect.

[0012] In a fourth aspect, a computer-readable storage medium is provided, in which at least one computer program is stored. When the at least one computer program is executed by a processor, the cloud gateway container management method described in the second aspect can be implemented.

[0013] In a fifth aspect, a computer program product is provided, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the cloud gateway container management method described in the second aspect can be implemented.

[0014] The beneficial effects of the technical solution provided by the embodiment of the present application are:

[0015] The cloud gateway containerized management system provided by the embodiment of the present application includes a network hook component and a controller component. After receiving the first management request from the user account for the service node, the network hook component can determine whether the number of available containers on the service node after the execution of the first management request is less than a preset number, and the preset number is the minimum number of available containers on the service node. If the number of available containers is less than the preset number, the first management request is intercepted. If the number of available containers is greater than the preset number, the first management request is stored in the data storage component, so that after the controller component obtains the first management request from the data storage component, the container on the service node can be managed. By intercepting the management request that may cause the number of available containers on the service node to be less than the minimum number of available containers through the network hook component, the number of available containers on the service node can be guaranteed when the native Kubernetes system is applied to the cloud gateway service, thereby improving the availability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0017] Figure 1 This is an architectural diagram of a traditional cloud gateway device management platform;

[0018] Figure 2 This is an architecture diagram of the cloud gateway container management system provided by related technologies;

[0019] Figure 3 This is an architecture diagram of a cloud gateway containerized management system provided in an embodiment of the present application;

[0020] Figure 4 is a schematic diagram of the management process of the network hook component of an embodiment of the present application;

[0021] Figure 5 It is a schematic diagram of a state flow mechanism arranged based on a controller component in an embodiment of the present application;

[0022] Figure 6 This is a flow chart of an embodiment of the present application for accurately reducing and upgrading a container;

[0023] Figure 7 It is a flowchart of an embodiment of the present application for managing the life cycle of a container based on a controller component;

[0024] Figure 8 It is a flow chart of a cloud gateway container management method provided by an embodiment of the present application;

[0025] Fig. 9 A structural block diagram of an electronic device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0027] It can be understood that the terms "each", "multiple", and "any" used in the embodiments of the present application include two or more, each refers to each of the corresponding multiple, and any refers to any one of the corresponding multiple. For example, the multiple words include 10 words, and each word refers to each of the 10 words, and any word refers to any one of the 10 words.

[0028] It should be noted that the user account information (including but not limited to user account device information, user account 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 account 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 the relevant countries and regions, and provide corresponding operation entrances for the user account to choose to authorize or refuse.

[0029] Before executing the embodiments of the present application, the terms involved in the embodiments of the present application are first explained.

[0030] Cloud Gateway: A forwarding node of the data center gateway type, which is the convergence point of traffic.

[0031] Containerization: A software development and deployment technique that packages an application and its dependencies into a self-contained, portable container, ensuring that it runs consistently in a variety of environments.

[0032] Kubernetes: abbreviated as k8s, an open source system for container orchestration that automates the deployment, expansion, and management of containerized applications, helping to manage complexity in scenarios with a large number of containers.

[0033] CRD (Custom Resource Definition): is a mechanism used in Kubernetes to extend the API (Application Programming Interface), allowing user accounts to define new resource types without modifying the Kubernetes source code or creating a custom API server. User-defined resources must follow the schema defined in the CRD and contain specific configuration information. Through CRD user accounts can create custom resource objects in the Kubernetes cluster, which can be namespace-scoped or cluster-scoped, depending on the definition of the CRD.

[0034] Operator: An architecture that uses Kubernetes CRD and the Controller pattern to monitor the status of custom resources and automatically perform a series of operations. The working principle of Operator can be summarized in several steps:

[0035] 1. Custom Resources (CRD): The Operator first needs to define one or more custom resources, which represent the configuration and state of the application or service to be managed.

[0036] 2. Implement a custom controller: The controller is the core of the Operator and is responsible for monitoring specified resources. When the resource status changes, the controller will adjust according to the current status and expected status of the resource to ensure that the application or service is in the correct state.

[0037] 3. Automated operation logic: The controller will encode the service logic of application management, such as upgrade, backup, recovery and other operations. These logics may have required manual intervention in the past, but now they can be completed automatically.

[0038] API Server: It is the gateway of the Kubernetes cluster. It is the middle touchpoint that all user accounts, automation, and components in the Kubernetes cluster can access. API Server performs all API operations and is responsible for storing API objects to the persistent storage backend.

[0039] ETCD is an open source distributed key-value storage system, mainly used to save and manage key data in distributed systems. The main functions of ETCD include:

[0040] 1. Configuration management: ETCD can manage Kubernetes configuration data, status data, and metadata to ensure the consistency of the system status.

[0041] 2. Service discovery: ETCD can store service registration information and support service discovery scenarios.

[0042] 3. Data consistency: The consistency and reliability of data are guaranteed by the Raft protocol. Each node stores a complete key-value storage space, supporting horizontal expansion and high availability of data.

[0043] RBAC (Role-Based Access Control) is an effective access control method for implementing enterprise security policies. The basic idea of ​​RBAC is that various permissions for system operations are not directly granted to specific user accounts, but a role set is established between the user account set and the permission set. Each role corresponds to a set of corresponding permissions. Once a user account is assigned an appropriate role, the user account has all the operation permissions of this role. The advantage of this is that you don't have to assign permissions every time you create a user account. You only need to assign the corresponding role to the user account. In addition, the permission changes of roles are much less than the permission changes of user accounts. This will simplify the permission management of user accounts and reduce system overhead.

[0044] GatewayCluster is a cluster configuration mode that allows user accounts to modify the parameters of an existing automated cluster (group or site level) and add or remove gateways.

[0045] Grayscale upgrade, also known as grayscale release, refers to a release method that can smoothly transition between black and white. A / B testing can be performed on it, that is, some user accounts continue to use product feature A, and some user accounts start to use product feature B. If the user accounts have no objection to B, then gradually expand the scope and migrate all user accounts to B. Grayscale release can ensure the stability of the overall system. Problems can be discovered and adjusted during the initial grayscale to ensure their impact.

[0046] Cloud native is a new software development and deployment approach that aims to build and run scalable, elastic, observable, and maintainable applications in a cloud computing environment. The core of cloud native is to design applications as elastic and scalable microservices and deploy them in containers for easy management and rapid deployment. Cloud native applications typically use modern development, deployment, and automation tools such as DevOps, continuous delivery, and automated testing to achieve efficient development and deployment processes. The design concept of cloud native is closely related to cloud computing technology, and can make full use of the resource pool, elastic expansion, and automated management features provided by cloud computing to improve the reliability, scalability, and flexibility of applications and reduce the cost of development and deployment. Cloud native applications usually have better performance, higher availability, and better user account experience, and are the mainstream application development and deployment method in the cloud computing era.

[0047] Cloud-native applications have the following characteristics:

[0048] Container-based: Use container technology to package, deploy, and run applications. Containers can improve the portability and flexibility of applications.

[0049] Microservices architecture: Split an application into multiple small, independent services, each of which can be deployed and scaled independently.

[0050] Automated deployment and expansion: Using DevOps technology to automate application deployment and expansion can quickly respond to service demand and traffic changes.

[0051] Elasticity and reliability: Application elasticity and reliability are achieved through automated container orchestration and service governance mechanisms, which can quickly respond to failures and restore services.

[0052] Open standards and interoperability: Use open standards and interoperability to enable applications to run across platforms and cloud vendors, reducing application dependencies and migration costs.

[0053] Cloud-native applications are usually implemented using technologies such as Kubernetes, Docker, and Service Mesh, which can provide rich functions and service support, such as container orchestration, service discovery, load balancing, automatic scaling, etc. Currently, cloud-native has become a trend in cloud computing and application development.

[0054] Cloud gateway devices mimic the functions of disk arrays, block-based devices or file servers. They are usually placed at the customer's site and serve as a bridge between local storage systems and cloud storage services. They support multiple public clouds and multiple protocols. As a key component for data circulation and integration, as well as an important tool for security protection and traffic management, cloud gateways play an important role in the following aspects: 1. Seamless integration of cloud storage services: Cloud gateway devices allow user accounts to seamlessly integrate existing storage systems with cloud storage services. Since public cloud storage providers usually communicate through Internet protocols such as RESTful APIs on HTTP (Hypertext Transfer Protocol) rather than traditional storage area networks or network attached storage protocols, cloud gateway devices can translate these protocol differences, allowing local storage systems to smoothly access cloud storage. 2. Improve data transmission efficiency: Cloud gateway devices not only simplify the data transmission process, but also provide load balancing functions, which can efficiently distribute data transmission tasks to multiple servers, thereby improving overall data transmission efficiency and stability. 3. Enhanced security: Cloud gateway devices usually have multi-layer security protection mechanisms, including encrypted transmission protocols, access control policies, and firewalls. These security measures ensure the security and integrity of data during transmission and prevent data from being stolen or tampered with. 4. Support for multiple use cases: Cloud gateway devices support a variety of usage scenarios, including but not limited to backup to cloud object storage, failover and recovery, active or long-term archiving, file synchronization and sharing, and data storage for cloud analysis. These features make cloud gateway devices valuable in terms of data protection, service continuity, and data utilization. 5. Easy to expand and deploy: Cloud gateway devices are easy to install and deploy. User accounts can start from the smallest scale and easily expand the scale of devices according to actual needs. This flexibility enables cloud gateway devices to adapt to enterprise environments of different sizes and needs. Traditional cloud gateway devices are directly built based on physical devices or switches, and cloud gateway devices are managed based on a centralized management and control system. See Figure 1The management platform of traditional cloud gateway devices includes a management and control system and a storage database. The management and control system can realize resource management and service orchestration management of cloud gateway devices. Resource management includes device grouping management, device online and offline, etc. Service orchestration management includes routing configuration distribution, traffic management and other functions. However, the platform does not have elastic expansion and contraction capabilities, and the manual intervention expansion cycle is long, and it cannot cope with sudden attacks, traffic peaks and other scenarios. For stability considerations, several machines must be built in each region as primary and backup, which is costly.

[0055] With the development of cloud native technology, applications are gradually being containerized. Usually, containerized applications will run easy-to-migrate, lightweight workloads in Pods of Kubernetes clusters, with multiple Pods providing services together. When a Pod fails, high availability can be achieved by restarting the service. In order to achieve elastic expansion and contraction of cloud gateway devices and reduce the management cost of cloud gateway devices, the native Kubernetes system can be applied to the gateway service, and the cloud gateway can be containerized through the cloud gateway containerization management system. See Figure 2 It shows a cloud gateway container management system provided by the related technology, see Figure 2 The system includes an API server, a scheduler, ETCD and multiple service nodes. The API server is used to receive management requests sent by user accounts and store the received management requests in ETCD; the scheduler is used to schedule the Pod to a specific service node after the management request is stored in ETCD.

[0056] However, compared with microservices, gateway services have the characteristics of heavy load, slow startup, and extremely high reliability requirements. They cannot start and stop services frequently and quickly, which makes the application of native Kubernetes systems to gateway services face many challenges. For example, when the gateway Pod restarts abnormally, it is necessary to first perform an offline operation to clear the traffic, but the pre-deletion hook function of the native Kubernetes system is executed within a certain period of time. Once the scheduled time is exceeded, it will be forced to restart, resulting in traffic loss. In addition, in scenarios such as scaling down and upgrading, the number of available containers is required to be greater than the minimum available number, but native Kubernetes does not have this ability and cannot guarantee that the number of available containers is greater than the minimum available number. In addition, during the upgrade process, native Kubernetes does not have the ability to accurately upgrade a Pod, nor can it implement grayscale upgrades of cloud gateway products.

[0057] To address the problems of applying the native Kubernetes system to the containerized cloud gateway, related technologies provide two solutions:

[0058] The first solution, based on the Deployment component

[0059] The Deployment component is a controller resource in Kubernetes and the most common management component for cloud-native applications. It is mainly used to manage stateless applications. The Deployment component provides declarative updates to ensure that the expected state of the application is consistent with the actual state. Through the Deployment component, user accounts can define Pod templates and the expected number of Pod replicas. Kubernetes automatically creates and manages these Pods based on this definition. However, in the cloud gateway scenario, the Deployment component has the following problems:

[0060] 1) When managing Pods, all Pod-related parameters need to be provided to the user account, which is defined by the user account. This causes the resource definition to be completely exposed to the user account, and the user account can modify the Pod resource definition at will, reducing the reliability of the system.

[0061] 2) When scaling down or upgrading Pods, no custom selection strategy is provided, and user accounts cannot randomly select Pods for scaling down or upgrading.

[0062] 3) The native Kubernetes system uses a rolling upgrade method, that is, after deleting the old version of the Pod container, a new version of the Pod container is created, resulting in the inability to save the original Pod's naming, network, and disk resources;

[0063] 4) The pre-deletion hook function of the native Kubernetes system is executed within a certain period of time. Even if the execution fails within a certain period of time, the Pod will be forced to restart, causing traffic loss of the Pod and making the Pod lifecycle management unreliable.

[0064] The second solution, based on the CloneSet component

[0065] The CloneSet component is a resource management component that can manage stateless applications. The CloneSet component provides a lot of enhancements based on the Deployment component, which can implement in-place upgrades of Pods to retain various resources of the original Pods. However, in the cloud gateway scenario, the CloneSet component has the following disadvantages:

[0066] 1) When managing Pods, all Pod-related parameters need to be provided to the user account, which is defined by the user account. This causes the resource definition to be completely exposed to the user account, and the user account can modify the Pod resource definition at will, reducing the reliability of the system.

[0067] 2) It is impossible to achieve grayscale upgrades and coexistence of multiple versions, and it is impossible to adapt to the flexible version requirements of the cloud gateway.

[0068] 3) Without any availability protection measures, the user account can delete all Pods by scaling down.

[0069] In summary, the solutions currently provided by relevant technologies cannot solve the problems existing in cloud gateway containerization scenarios.

[0070] In order to solve these problems, the embodiment of the present application builds a cloud gateway container management system based on CRD+Operator, which includes a webhook component (Webhook), a controller component (Controller), etc. The webhook component intercepts the management request sent by the user account to the API Server, and provides functions such as version conversion, parameter verification, and container availability protection; the controller component is responsible for actual resource management, and provides functions such as copy management, in-place upgrade, grayscale upgrade, availability protection, and lifecycle hooks for Pod containers. Among them, copy management refers to managing Pod containers in a cluster. In-place upgrade refers to adding a new version of the Pod container while keeping the computing resources, storage resources and other resources of the Pod container unchanged. Since the native Kubernetes system is a rolling upgrade, the old version of the Pod container is deleted and a new version of the Pod container is created, resulting in the preservation of different versions of the Pod container. In view of the version problem existing in the native Kubernetes system, the embodiment of the present application adopts an in-place upgrade method, and adds a new version of the Pod container while keeping the computing resources, storage resources and other resources of the Pod container unchanged, so that not only the old version of the Pod container can be saved, but also the new version of the Pod container can be saved, so as to achieve the coexistence of multiple versions. Grayscale upgrade means that when upgrading the version of a Pod container, you can first upgrade the version of some Pod containers, and then gradually upgrade all Pod containers. In view of the problems existing in the relevant technology, the following will be explained in combination with the network hook component and the controller component.

[0071] In response to the problem in the related technology that user accounts can arbitrarily modify Pod resource definitions, the controller component provided in the embodiment of the present application provides a custom interface, which adopts the GatewayCluster mode. Through this interface, the necessary parameters for Pod resource management can be provided to the user account, and the actual Pod resource definition can be hidden. While enabling the user account to define the cloud gateway container cluster resources, it avoids the user account from accidentally modifying the Pod resources.

[0072] In order to address the problem of inaccurate management in related technologies, through the custom interface provided by the controller component, user accounts can scale in and upgrade specified containers, thereby accurately scaling down and upgrading container resources and achieving coexistence of multiple versions.

[0073] In response to the problem of lack of available number protection in related technologies, protection can be provided at multiple levels. For management requests sent by external user accounts, a network hook component is used to intercept management requests that may cause the number of available containers to be less than the minimum available number. For internal operations, a controller component can be used to intercept operations that may cause the number of available containers to be less than the minimum available number. Through top-down and bottom-up protection measures, strong and reliable container availability protection can be provided, intercepting any requests and operations that may cause insufficient container availability, and ensuring that the number of available containers in the cloud gateway cluster meets the requirements.

[0074] To address the unreliable Pod lifecycle management problem in related technologies, the controller component provides a strong and reliable pre-deletion hook capability to ensure that routing convergence, offline operations, and other operations are completed before the cloud gateway container is deleted.

[0075] In addition, the controller component also provides Pod resource status orchestration capabilities, allowing user accounts to orchestrate state transfer mechanisms for different states of Pod resources, thereby ensuring that the resources requested by the user account are consistent with the actual resources of the cloud gateway cluster. In particular, after the controller component is accidentally restarted, the orchestrated state transfer mechanism ensures that operations can continue to be executed, improving the reliability and high availability of the service.

[0076] In summary, the system provided by the embodiment of the present application can enhance the elastic scheduling, upgrade orchestration, and reliability protection capabilities of the gateway service, reduce the reliability risks brought by containerized flexible scheduling, and ensure the stability of the gateway service.

[0077] This application embodiment provides a cloud gateway container management system, see Figure 3 The system provided by the embodiment of the present application includes: a network hook component, a controller component, a data storage component, and a service node, etc. At least one container is deployed on each service node, and a cloud gateway application is running in each container.

[0078] Among them, the network hook component is used to receive the first management request of the user account for the service node, and the first management request is used to manage the container on the service node, and the management includes any one of the operations of creation, upgrading, shrinking, expanding, and deleting. In order to ensure the availability of the gateway service, after receiving the first management request, the network hook component will also obtain the minimum number of available containers on the service node, that is, the preset number, which can be set by the user account. After receiving the first management request, the network hook component will also calculate the number of available containers, which is the number of available containers on the service node after executing the first management request. Then, the network hook component determines whether the number of available containers is less than the preset number. When the number of available containers is less than the preset number, the network hook component intercepts the first management request; when the number of available containers is greater than or equal to the preset number, the network hook component stores the first management request to the data storage component, and the data storage component can be ETCD, etc. The controller component is used to obtain the first management request from the data storage component, and manage the container on the service node in response to the first management request.

[0079] The embodiment of the present application intercepts management requests that may cause the number of available containers on the service node to be less than a preset number (i.e., the minimum number of available containers on the service node required by the user account) through a network hook component, thereby ensuring that the number of available containers is greater than or equal to the preset number in any scenario such as upgrade, reduction, deletion, etc., regardless of how the number of available containers changes, thereby ensuring that the gateway service is available at any time.

[0080] Generally speaking, the user account obtains the cloud gateway service through the interface provided by the cloud gateway service cluster. For the interface for accessing the cloud gateway, the format of its interface parameters may be updated. For example, the parameter name originally provided to the user account is parameter A, and now the parameter name is changed to parameter B. In order to ensure the stability of the configuration version of the cloud gateway and avoid the stability risk caused by excessive configuration changes of the user account, a version conversion mechanism can be added to the network hook component to make the new version parameters compatible with the old version parameters, which is convenient for the user account to use. By providing a version conversion mechanism, no matter how the CRD format stored in ETCD changes, the format in the first management request sent by the user account can remain unchanged. In addition, the format of the interface parameters is different for different types of management requests. Therefore, in order to better perform subsequent operations according to the type of the first management request, the network hook component can determine the type of the first management request after receiving the first management request. Among them, the type of the first management request includes a first type and a second type. The first type refers to a request type that does not cause a reduction in the number of available containers on the service node, such as a create request, etc.; the second type refers to a request type that can cause a reduction in the number of available containers on the service node, such as a shrink request, a delete request, an upgrade request, etc.

[0081] In a possible implementation, when it is determined that the type of the first management request is the first type, the network hook component converts the parameters in the first management request to obtain the second management request. When the network hook component converts the parameters in the first management request to obtain the second management request, the parameter value of the parameter before the update can be obtained from the first management request, and then the parameter value of the parameter before the update is filled into the corresponding position of the parameter after the update to obtain the second management request. For example, if the parameter format before the update is parameter A and the parameter format after the update is parameter B, the parameter value of parameter A can be obtained from the first management request, and then the parameter value can be filled into the corresponding position of parameter B to obtain the second management request. Further, after obtaining the second management request, the network hook component will also verify the parameters in the second management request, and after the parameters in the second management request pass the verification, the second management request will be stored in the data storage component. By verifying the parameters passed in by the user account, it is prevented that the user account passes in illegal parameters and causes errors, and error information can also be returned synchronously, which is convenient for user account troubleshooting.

[0082] In another possible implementation manner, when the type of the first management request is the second type, an operation of determining whether the number of available containers is less than a preset number may be performed.

[0083] Figure 4 The process of the network hook component judging the first management request and performing different operations according to the judgment result is shown in FIG. Figure 4 , when receiving the first management request sent by the user account, the type of the first management request is determined. If the first management request is a creation request, the first management request is converted to a version (i.e., the parameters in the first management request are converted) to obtain a second management request, and then the parameters in the second management request are verified. If the parameters in the second management request pass the verification, the second management request is stored in ETCD; if the parameters in the second management request pass the verification, the second management request is rejected (i.e., the second management request is intercepted). If the first management request is any one of an upgrade request, a shrink request, a deletion request, etc., the number of available containers is obtained, and it is determined whether the number of available containers is greater than the minimum available number (i.e., the preset number). If the number of available containers is greater than or equal to the minimum available number, the first management request is stored in ETCD. If the number of available containers is less than the minimum available number, the first management request is rejected (i.e., the first management request is intercepted).

[0084] In an embodiment of the present application, the controller component may also provide a configuration interface, which is in GatewayCluster mode. The GatewayCluster is the mode in which the configuration interface is located in a cloud gateway scenario when a user account can customize container resources in the cloud gateway. In GatewayCluster mode, the configuration interface may hide specific container definitions such as resource requirements, volume mounts, affinity, and taint configurations, and only provide necessary configuration parameters so that the user account generates a first management request based on the necessary configuration parameters to define and manage the cloud gateway container, thereby avoiding erroneous modification and use of uncertain parameters by the user account and improving overall reliability.

[0085] In the embodiment of the present application, the configuration interface is also used to provide a resource status orchestration control, which is used by the user account to orchestrate the state flow mechanism for container resources. Among them, the states of container resources include Creating, ScalingOut, ScalingIn, Updating, Waiting, Deleting and Running states.

[0086] Figure 5 It shows the state transfer mechanism that the user account arranges for the container resources based on the resource state arrangement control, see Figure 5, after receiving the container resource creation request, based on the creation request, the container resource creation operation is performed, and GatewayCluster is in the initialization state. Shared resources (vip in the figure) are allocated to GatewayCluster, and then the expansion operation is performed. GatewayCluster is in the expansion state. After the expansion is completed, the container resources are in the waiting state. At this time, GatewayCluster is not ready. After the container resources are prepared, the container resources are run, and GatewayCluster is in a steady-state operation state. During the operation of container resources, the number of available containers of container resources is monitored. If the number of available containers is less than the expected number of replicas (that is, the minimum available number), the expansion operation of container resources is performed; if the number of available containers is greater than the expected number of replicas, the reduction operation of container resources is performed, and GatewayCluster is in the reduction state. After the reduction is completed, GatewayCluster is in the operation state. During the operation of container resources, if the container corresponding to the container identifier needs to be deleted, the deletion operation of container resources is performed, and GatewayCluster is in the deletion state. During the operation of container resources, if you want to upgrade the image of container resources to the desired image, you will perform the update operation of container resources. GatewayCluster is in the process of upgrading. After the upgrade is completed, the container resources are in the waiting state and GatewayCluster is not ready yet.

[0087] Based on the resource transfer mechanism arranged by the user account, when the first management request is received and the resources of the cloud gateway container cluster need to change, the controller component maps the resource status to the above-mentioned Creating, ScalingOut, ScalingIn, Updating, Waiting, Deleting and Running states, and monitors the state changes of the container resources based on the resource transfer mechanism, thereby ensuring that the container resources processed based on the first management request are consistent with the actual container resources. Furthermore, if the controller component is restarted, the processing status of the container resources can be maintained according to the resource transfer mechanism.

[0088] In an embodiment of the present application, the necessary configuration parameters may include a container identifier of at least one container. When the first management request is any one of an upgrade request, a shrink request or a deletion request for a target container, the user account selects a target container identifier of a target container from the container identifier of at least one container. The target container is a container to be upgraded, shrunk or deleted. The number of the target container is at least one, which may be the container identifier of all containers on the service node or the container identifier of some containers. The embodiment of the present application does not specifically limit this. The first management request generated based on the target container identifier selected by the user account includes the target container identifier of the target container, so that the container on the service node can be accurately managed in the future. For example, if the first management request is an upgrade request, then based on the target container identifier in the first management request, the target container can be upgraded, so that multi-version coexistence and grayscale upgrade can be achieved, and the reliability of the gateway service is improved. When all containers in the cluster are upgraded, the image version of the cluster can be changed. For another example, if the first management request is a shrink request or a deletion request, then based on the target container identifier in the first management request, the target container can be deleted, so as to achieve shrinkage of the specified container.

[0089] Figure 6 Shows the upgrade process for a specified Pod, see Figure 6 , M service nodes are deployed in the cluster, and N containers are running on the M service nodes, among which Pod1, Pod2 and Pod3 are running on service node 1, Pod1, Pod2 and Pod3 are running on service node 2, ..., Pod1, Pod2 and Pod3 are running on service node M, and the image version of N containers is V1. If the user wants to perform a grayscale upgrade on the containers in the cluster, based on the node identifiers of the M service nodes and the identifiers of the N containers provided by the configuration interface, the user account can select Pod2 on service node 2, Pod2 and Pod3 on service node M, so as to upgrade the versions of Pod2 on service node 2, Pod2 and Pod3 on service node M from V1 to V2.

[0090] In another embodiment of the present application, the necessary configuration parameters also include lifecycle management parameters, which are used to instruct the controller component to execute a specified hook script before performing a shrinking operation or a deletion operation on the target container, and to delete the target container after the specified hook script is successfully executed. In the scenario of shrinking or deleting the target container, the user account configures the lifecycle management parameters for the target container to be deleted, that is, the pre-deletion hook, to ensure that the operation to be performed by the target container can be performed smoothly, thereby avoiding traffic loss.

[0091] Optionally, in order to better monitor the operations in the target container, before executing the specified hook script, a status mark can be added for each operation to be performed by the target container, and the added status mark can be stored in the data storage component, and the status mark includes unfinished execution and completed execution. By executing the specified hook script, the controller component can obtain the status mark of each operation to be performed by the target container from the data storage component. When the status marks of the operations to be performed by the target container are all completed, the specified hook function returns the execution result of successful execution. After receiving the execution result of successful execution returned by the specified hook script, the controller component deletes the target container. When there is an operation with a status mark of unfinished execution in the operations to be performed by the target container, the specified hook script waits for the operation to be performed. After the operation is completed, the specified hook script returns the execution result of successful execution. After receiving the execution result of successful execution returned by the specified hook script, the controller component deletes the target container. In addition, if the controller component is restarted during operation, the status mark of the operations to be performed by each container can be obtained from the data storage component by executing the specified hook script. If any container has an unexecuted operation, the container can be controlled to continue to execute the operation to avoid the loss of container traffic.

[0092] The embodiment of the present application adds a status identifier for the operation to be executed by the container, which not only makes it easier to query the execution status of the operation to be executed by the container, but also ensures that the unexecuted operations can continue to be executed according to the execution status of the operations after the controller component is accidentally restarted, thereby avoiding container traffic loss.

[0093] Figure 7 This shows the management process of a specified Pod based on the pre-deletion hook, see Figure 7 , after receiving the user account's scaling down and deletion operations on the specified Pod, the controller component adds status marks to each operation in the specified Pod, and then executes the pre-deletion hook. If the pre-deletion hook is executed successfully, after receiving the successful execution result returned by the pre-deletion hook, the specified Pod is deleted. If the pre-deletion hook is not executed successfully, the pre-deletion hook waits for the operation to be executed, returns the successful execution result after the execution is completed, and then deletes the specified Pod based on the successful execution result. If the controller component restarts unexpectedly, the pre-deletion hook can be executed to obtain the status marks of each operation in the specified Pod, so as to continue to execute the unfinished operation based on the status marks of each operation.

[0094] In another embodiment of the present application, the controller component can also monitor the operation on the service node. If it is detected that the operation on the service node is a specified operation, that is, an operation that can cause the number of available containers to be less than a preset number, the specified operation on the service node is intercepted. By detecting the operation within the cluster, the number of available containers in the cluster can be protected.

[0095] In another embodiment of the present application, the system further includes an interface server, which may be an AIP server, and the interface server is configured to receive the first management request and send the first management request to the network hook component.

[0096] In another embodiment of the present application, the system further includes: a permission verification component. The permission verification component may be an RBAC component, and the permission verification module may verify the operation permission of the user account, and the operation permission refers to verifying whether the operation requested by the user account is a direct operation on the container resource. If the operation requested by the user account is a direct operation on the container resource, it is determined that the user account has not passed the verification, and then the response to the first management request is rejected; if the operation requested by the user account is not a direct operation on the container resource, it is determined that the user account has passed the verification, and the first management request is sent to the interface server.

[0097] The embodiment of the present application can strictly limit the user account's operation on container resources by setting up a permission verification module. By using the permission verification module in conjunction with the network hook component and the controller component, in any scenario such as user account upgrade, reduction, deletion, etc., no matter how the number of containers changes, it can be ensured that the number of available containers is greater than or equal to the minimum available number, ensuring that the service is available at any time.

[0098] The embodiment of the present application customizes the GatewayCluster resource definition to hide the actual Pod definition, thereby avoiding the problem of the related technical solution directly exposing the specific Pod definition and preventing the user account from being modified by mistake. In addition, the embodiment of the present application implements the specified scaling down and upgrading of the Pod, avoiding the problem that the related technical solution cannot be managed in a refined manner, and can achieve refined scaling down, grayscale upgrading and coexistence of multiple versions of the Pod. In addition, the embodiment of the present application provides a strong and reliable available number protection, intercepts any operation that may cause insufficient available numbers, avoids the problem of no available number protection in the related technical solution, and ensures that the number of available copies of the cluster meets the requirements. In addition, the embodiment of the present application provides a strong and reliable lifecycle hook, which ensures that the hook script is executed before deleting the Pod, avoiding the problem of unreliable lifecycle control in the related technical solution, and ensuring operations such as monitoring or going offline before deletion.

[0099] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present application, which will not be described one by one here.

[0100] See also Figure 8 , the present application embodiment provides a cloud gateway container management method, the method is applied Figure 3 The cloud gateway containerized management system shown in the figure, the method flow provided by the embodiment of the present application includes:

[0101] 801. The controller component provides a configuration interface, where the configuration interface is used to provide necessary configuration parameters so that a user account generates a first management request based on the necessary configuration parameters.

[0102] In the embodiment of the present application, the configuration interface provides necessary configuration parameters, based on which the user account can generate a first management request, thereby achieving parameter hiding, orchestration of the state flow mechanism of container resources, accurate scaling down and deletion of specified containers, lifecycle hook management, etc. This will be described in detail below.

[0103] Among them, parameter hiding: the configuration interface provides the GatewayCluster mode. The GatewayCluster mode is a customized Pod management custom resource definition for the cloud gateway scenario provided in the embodiment of the present application. Compared with the native Pod management solution, GatewayCluster hides specific Pod definitions such as resource requirements, volume mounting, affinity, and taint configuration from the user account. The user account only needs to pass the necessary cloud gateway configuration information, and GatewayCluster can generate the necessary definitions and manage the cloud gateway container based on this information. At the same time, it also avoids the user account's accidental modification and use of uncertain parameters, thereby improving overall reliability.

[0104] State transfer mechanism based on actual cluster resources: Based on the configuration interface provided by the controller component, the specific control plane process can be orchestrated to obtain the state machine transfer mechanism of container resources. Whenever the state of cluster resources changes, the controller component can map the requested resource state to any state such as Creating, ScalingOut, ScalingIn, Updating, Waiting, Deleting and Running, so as to perform resource management based on the state transfer mechanism to ensure that the cloud gateway resources requested by the user account are consistent with the actual cloud gateway resources. In addition, even if the controller component is restarted, the processing status of the resources can be maintained based on the state machine transfer mechanism.

[0105] Precise Pod Scaling and Upgrading: Based on the configuration interface provided by the controller component, you can also implement designated scaling down and upgrading of Pods. Specified scaling down means that a user account can scale down any specified number of specific Pods, thereby achieving refined management of Pod scaling down. Specified upgrading means that a user account can upgrade any specified number of specific Pods to a specific version, thereby easily achieving multi-version coexistence and grayscale upgrades. When all Pods in the cluster are upgraded, the image version of the cluster can be changed, so that in subsequent expansion operations, the image version in the expanded Pod can be guaranteed to be a specific version.

[0106] Strong and reliable lifecycle hooks: The configuration interface provided by the controller component can also achieve reliable lifecycle management. The user account can configure a pre-deletion hook for the specified Pod, so that the pre-deletion hook is executed before the specified Pod is deleted, and the specified Pod will be deleted only after the pre-deletion hook returns a successful execution result. In addition, before executing the pre-deletion hook, you can add status identifiers to each operation to be performed by the specified Pod, so that the execution status of each operation can be monitored according to the status identifier of each operation. Even if the controller component is restarted unexpectedly, it can ensure that the unfinished operations in the specified Pod continue to execute.

[0107] In the embodiment of the present application, according to the necessary configuration parameters provided by the configuration interface provided by the controller component, the user account can trigger the generation of the first management request.

[0108] In a possible implementation, when the first management request is a request for reducing capacity, deleting capacity, or upgrading capacity for a target container, the user account may select, based on the container identifier of at least one container included in the necessary configuration parameters, the container identifier of the target container to be reduced, deleted, or upgraded from the container identifiers of at least one container, and obtain the first management request including the container identifier of the target container. Then, in subsequent steps, the user account may reduce capacity, delete, or upgrade the selected target container based on the container identifier of the target container included in the first management request.

[0109] In another possible implementation, when the first management request is a request to shrink or delete the target container, the user account can also associate the lifecycle management parameters with the target container based on the lifecycle management parameters included in the necessary parameters to obtain the first management request including the lifecycle management parameters, and then in subsequent steps, before shrinking or deleting the target container, execute the specified hook script, and delete the target container after the specified hook script is successfully executed.

[0110] 802. The authority verification component receives a first management request sent by a user account, verifies the operation authority of the user account, and sends the first management request to the interface server after the user account passes the verification.

[0111] After the user account generates the first management request based on the controller component, the user account sends the first management request to the permission verification module. After receiving the first management request, the permission verification module verifies the operation permission of the user account. If the user account passes the verification, the first management request is sent to the interface server; if the user account fails the verification, the first management request is intercepted and not forwarded downward.

[0112] 803. The interface server sends the first management request to the network hook component.

[0113] After receiving the first management request, the interface server sends the first management request to the network hook component.

[0114] 804. The network hook component receives a first management request from the user account for the service node, determines whether the number of available containers is less than a preset number, and stores the first management request to the data storage component when the number of available containers is greater than or equal to the preset number.

[0115] In an embodiment of the present application, after receiving a first management request from a user account to a service node, the network hook component determines the type of the first management request. When the type of the first management request is the first type, the network hook component converts the parameters in the first management request to obtain a second management request, verifies the parameters in the second management request, and stores the second management request to the data storage component after the parameters in the second management request pass the verification; when the type of the first management request is the second type, the network hook component performs an operation of determining whether the number of available containers is less than a preset number. When the number of available containers is greater than the preset number, the network hook component stores the first management request to the data storage component; when the number of available containers is less than the preset number, the network hook component intercepts the first management request.

[0116] The embodiment of the present application adds a version conversion mechanism to the network hook component, so that no matter how the CRD format stored in ETCD changes, the format passed in by the user account can remain unchanged, avoiding stability risks caused by excessive configuration changes of the user account, and ensuring the stability of the configuration version of the cloud gateway. In addition, by performing necessary checks on the parameters passed in by the user account, errors caused by illegal parameters passed in by the user account are prevented, and error information can be returned synchronously to facilitate user account troubleshooting. In addition, the network hook component provided in the embodiment of the present application can intercept management requests that may cause the number of available containers to be less than the minimum number of containers before the management request of the user account reaches the data storage component, thereby improving the availability of the service.

[0117] 805. The controller component obtains a first management request from the data storage component, and manages the container on the service node in response to the first management request.

[0118] In an embodiment of the present application, when the first management request is any one of an upgrade request, a reduction request, or a deletion request for a target container, the first management request includes a target container identifier of the target container, and the controller component performs an upgrade operation, a reduction operation, or a deletion operation on the target container in response to the first management request.

[0119] In an embodiment of the present application, when the first management request is a request to reduce or delete the target container, the controller component executes a specified hook script in response to the first management request, and deletes the target container after the specified hook script is successfully executed.

[0120] In an embodiment of the present application, the controller component can also monitor operations within the cluster. When any operation is detected as a specified operation, which refers to an operation that can cause the number of available containers to be less than a preset number, the controller component intercepts the specified operation for the service node.

[0121] Furthermore, the controller component can also monitor the status of each available container in the cluster. When any available container is in an unavailable state, a capacity expansion operation can be performed to ensure that the number of available containers in the cluster is greater than or equal to the minimum available number.

[0122] The embodiment of the present application customizes the GatewayCluster resource definition to hide the actual Pod definition, thereby avoiding the problem of the related technical solution directly exposing the specific Pod definition and preventing the user account from being modified by mistake. In addition, the embodiment of the present application implements the specified scaling down and upgrading of the Pod, avoiding the problem that the related technical solution cannot be managed in a refined manner, and can achieve refined scaling down, grayscale upgrading and coexistence of multiple versions of the Pod. In addition, the embodiment of the present application provides a strong and reliable available number protection, intercepts any operation that may cause insufficient available numbers, avoids the problem of no available number protection in the related technical solution, and ensures that the number of available copies of the cluster meets the requirements. In addition, the embodiment of the present application provides a strong and reliable lifecycle hook, which ensures that the hook script is executed before deleting the Pod, avoiding the problem of unreliable lifecycle control in the related technical solution, and ensuring operations such as monitoring or going offline before deletion.

[0123] Fig. 9 The structure block diagram of an electronic device 900 provided by an exemplary embodiment of the present application is shown. Generally, the electronic device 900 includes: a processor 901 and a memory 902 .

[0124] The processor 901 can be implemented in at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 901 may also include a main processor and a coprocessor, wherein the main processor is a processor for processing data in an awake state; and the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 901 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 901 may also include an artificial intelligence processor, which is used to process computing operations related to machine learning.

[0125] The memory 902 may include one or more computer-readable storage media, which may be non-temporary computer-readable storage media, for example, the non-temporary computer-readable storage media may be CD-ROM (Compact Disc Read-Only Memory), ROM, RAM (Random Access Memory), magnetic tape, floppy disk and optical data storage device, etc. The computer-readable storage medium stores at least one computer program, which can implement the above-mentioned cloud gateway container management method when executed.

[0126] Of course, the above electronic device may also include other components, such as input / output interface, communication component, etc. The input / output interface provides an interface between the processor and the peripheral interface module, and the above peripheral interface module may be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and other devices.

[0127] Those skilled in the art will understand that Fig. 9 The structure shown in the figure does not constitute a limitation on the electronic device 900, and may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.

[0128] An embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored. When the at least one computer program is executed by a processor, the above-mentioned cloud gateway containerization management method can be implemented.

[0129] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it can implement the above-mentioned cloud gateway container management method.

[0130] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0131] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A cloud gateway container management system, characterized in that: The system comprises: a network hook component, a controller component, a data storage component and a service node, wherein at least one container is deployed on the service node, and a cloud gateway application is running in the container; The network hook component is used to receive a first management request from a user account for the service node, determine whether the number of available containers is less than a preset number, the number of available containers being the number of available containers on the service node after the first management request is executed, and the preset number being the minimum number of available containers on the service node; when the number of available containers is greater than or equal to the preset number, store the first management request in the data storage component; The controller component is used to obtain the first management request from the data storage component, and manage the container on the service node in response to the first management request; The network hook component is further configured to intercept the first management request when the number of available containers is less than the preset number.

2. The system according to claim 1, characterized in that The webhook component is also used to perform the following operations: Determining a type of the first management request; When the type of the first management request is a first type, converting parameters in the first management request to obtain a second management request, verifying the parameters in the second management request, and storing the second management request in the data storage component after the parameters in the second management request pass the verification, the first type refers to a request type that does not cause a reduction in the number of available containers on the service node; When the type of the first management request is a second type, the operation of determining whether the number of available containers is less than a preset number is performed, and the second type refers to a request type that can cause the number of available containers on the service node to decrease.

3. The system according to claim 1, characterized in that The controller component is also used to perform the following operations: A configuration interface is provided, wherein the configuration interface is used to provide necessary configuration parameters so that the user account triggers generation of the first management request based on the necessary configuration parameters, wherein the necessary configuration parameters include a container identifier and lifecycle management parameters of the at least one container.

4. The system according to claim 3, characterized in that When the first management request is any one of an upgrade request, a shrink request, or a deletion request for a target container, the first management request includes a target container identifier of the target container, the target container is all or part of the at least one container, and the target container identifier is selected by the user account from container identifiers of the at least one container.

5. The system according to claim 4, characterized in that When the first management request is a scaling-in request or a deletion request for a target container, the first management request includes the lifecycle management parameter, and the lifecycle management parameter is used to instruct the controller component to execute a specified hook script before performing a scaling-in operation or a deletion operation on the target container, and to delete the target container after the specified hook script is successfully executed.

6. The system according to claim 3, characterized in that The configuration interface is further used to provide a resource status orchestration control, and the resource status orchestration control is used by the user account to orchestrate a state transfer mechanism for container resources to ensure that the container resources processed based on the first management request are consistent with actual container resources.

7. The system according to claim 1, characterized in that The controller component is also used to perform the following operations: A specified operation directed to the service node is intercepted, where the specified operation refers to an operation that can cause the number of available containers to be less than a preset number.

8. The system according to claim 1, characterized in that The system further includes an interface server, wherein the interface server is configured to receive the first management request and send the first management request to the network hook component.

9. The system according to claim 8, characterized in that The system further includes: a permission verification component, wherein the permission verification component is used to perform the following operations: Verifying the operation authority of the user account; If the user account fails to pass the verification, refusing to respond to the first management request; If the user account passes the verification, the first management request is sent to the interface server.

10. A cloud gateway container management method, characterized in that: The method applies the cloud gateway containerized management system described in any one of claims 1 to 9, and the method comprises: The network hook component receives a first management request from a user account for the service node, determines whether the number of available containers is less than a preset number, the number of available containers being the number of available containers on the service node after the first management request is executed, and the preset number being the minimum number of available containers on the service node; and stores the first management request in the data storage component when the number of available containers is greater than or equal to the preset number; The controller component obtains the first management request from the data storage component, and manages the container on the service node in response to the first management request.

11. The method according to claim 10, characterized in that After the network hook component determines whether the number of available containers is less than a preset number, the network hook component further includes: When the number of available containers is less than the preset number, the webhook component intercepts the first management request.

12. The method according to claim 10, characterized in that Before the network hook component determines whether the number of available containers is less than a preset number, the network hook component further includes: The webhook component determines the type of the first management request; When the type of the first management request is a first type, the network hook component converts the parameters in the first management request to obtain a second management request, verifies the parameters in the second management request, and stores the second management request in the data storage component after the parameters in the second management request pass the verification, wherein the first type refers to a request type that does not cause a reduction in the number of available containers on the service node; When the type of the first management request is a second type, the network hook component performs the operation of determining whether the number of available containers is less than a preset number, and the second type refers to a request type that can cause the number of available containers on the service node to decrease.

13. The method according to claim 10, characterized in that Before the network hook component receives the first management request of the user account for the service node, the method further includes: The permission verification component receives the first management request sent by the user account, where the first management request is triggered and generated by the user account based on necessary configuration parameters provided by the controller component, where the necessary configuration parameters include a container identifier and lifecycle management parameters of the at least one container; The permission verification component verifies the operation permission of the user account, and sends the first management request to the interface server after the user account passes the verification; The interface server sends the first management request to the webhook component.

14. The method according to claim 13, characterized in that When the first management request is any one of an upgrade request, a shrink request, or a delete request for a target container, the first management request includes a target container identifier of the target container, and the controller component manages the container on the service node in response to the first management request, including: The controller component performs an upgrade operation, a shrink operation, or a delete operation on the target container in response to the first management request.

15. The method according to claim 14, characterized in that When the first management request is a request to reduce or delete a target container, the controller component manages the container on the service node in response to the first management request, including: The controller component executes a specified hook script in response to the first management request, and deletes the target container after the specified hook script is successfully executed.

16. The method according to claim 10, characterized in that The method further comprises: The controller component intercepts a specified operation directed to the service node, where the specified operation refers to an operation that can cause the number of available containers to be less than a preset number.

17. An electronic device, characterized in that: It comprises a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the cloud gateway container management method as described in any one of claims 10 to 16.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by the processor, it can implement the cloud gateway container management method according to any one of claims 10 to 16.

19. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the cloud gateway container management method according to any one of claims 10 to 16 can be implemented.

Images