JP7092736B2 - Dynamic routing using container orchestration services - Google Patents

Description

This disclosure relates to handling load balancing of applications running in the cloud.

Some cloud integration systems may struggle to load balance message exchanges, for example, when too many integration scenarios run on a single runtime node. Existing techniques for distributing integration scenarios across multiple nodes face limitations in dynamically defining routing information. Dispersion of integration scenarios can be done in many ways. For example, some traditional systems use separate runtimes such as NGINX or another load balancer to route for web applications. A separate instance can be installed in a distributed system and its configuration can run in a separate system, but this has the disadvantage that the separate system must be maintained and updated. .. The use of separate runtimes can interfere with the platform and create problems that must be resolved with additional complexity.

This disclosure generally describes computer implementation methods, software, and systems for using techniques to achieve distribution of integration scenarios within the cloud. One computer implementation method is to deploy the integration flow (iFlow) as a resource by a cloud integration system, and to allocate the resource to one or more pods by a container orchestration service, and pod synchronization. The step of copying the iFlow definition mapped to the resource into the corresponding pod by the agent (pod sync agent) and the unique label to the pod based on the iFlow deployed in the pod by the pod sync agent. It includes a step of allocating and a step of creating a service as an endpoint for a resource with a rule that redirects the call to one or more pods containing the resource by the cloud integration system.

Each of the above implementations and the other implementations may optionally include one or more of the following features alone or in combination. In particular, one implementation can include all of the following features:

In the first aspect, which can be combined with any of the previous aspects, the method uses a cloud integration system to receive a request to call a service for a particular resource and a rule to make the request. Request low-load pods with a unique label, a step to determine the specific pod to direct to, a step to determine the current load of the pod containing a specific resource by the cloud integration system, and a unique label. Further includes steps to transfer.

In the second aspect, which can be combined with any of the previous embodiments, the low load is based on one or more of the central processing unit (CPU) utilization or memory utilization.

In a third aspect, which can be combined with any of the previous aspects, determining the current load of the pod containing a particular resource is performed by the load balancer.

A fourth aspect, which can be combined with any of the previous embodiments, further comprises using a pod synchronization agent to maintain information about the resources running on each pod.

A fifth aspect, which can be combined with any of the previous aspects, further comprises performing load balancing of resources running on the pod.

In the sixth aspect, which can be combined with any of the above aspects, load balancing uses a container orchestration service that accesses a uniform resource locator (URL) that exposes the endpoint to the service.

Details of one or more implementations of this subject matter herein are described in the accompanying drawings and in the description below. Other features, aspects, and advantages of this subject will become apparent from the description, drawings, and claims.

It is a block diagram of an exemplary environment for deploying resources. It is a block diagram of an exemplary environment for handling load balancing of an application running in the cloud. It is a flowchart of an exemplary method for deploying a resource. It is a flowchart of an exemplary method for handling a service request. A flowchart of an exemplary method for allocating resources to new or other available pods using a scaling module. It is a flowchart of an exemplary method for allocating a resource to a new pod. FIG. 3 is a block diagram of an exemplary computer system used to provide computer functionality related to the algorithms, methods, functions, processes, flows, and procedures described described herein.

This disclosure generally describes computer implementation methods, software, and systems for handling load balancing of applications running in the cloud. For example, techniques can be used to provide a way to route requests to an application. With these techniques, you can use services that expose endpoints to the outside world, as well as pods that provide run-time instances. You can deploy one or more resources to each pod. The techniques described in the present disclosure may include mechanisms that can be extended to add new resource types and the like. Labels can be used as markers for pod instances, and each label defines the routing associated with the service.

The techniques described in this disclosure can leverage native techniques to solve routing challenges in integrated scenarios. For example, the same integration scenario can be deployed to multiple pods for scaling out (or load handling) of the integration scenario. Integration scenarios can be treated as resources from the perspective of container orchestration services and can be deployed to one or more pod instances. You can assign a label to each pod instance after the integration scenario is deployed as a resource. Label information can be used to identify which pod instances can be used to route requests.

Benefits of the techniques described in this disclosure may include: Using the technology provided by the platform means that additional runtimes, such as by using NGINX instances, do not have to be deployed. This can reduce maintenance and development effort, as the platform only has to do the routing process. Each integration flow can act as an extended platform resource, allowing you to manage the integration flow individually using platform-native constructs and application programming interfaces (APIs). The integration flow can be scaled individually or automatically scaled by the platform. Lifecycle behaviors such as create, delete, and auto-resume can be managed as well as platform resources such as pods. Concepts such as rolling updates and zero downtime can also be extended to the integration flow. The integration flow is a virtual resource managed by the platform and is therefore not directly linked to the platform's system resources, so it is possible to scale the integration flow independently of other system resources such as pods and virtual machines. can. Scaling can help achieve maximum density on available system resources.

Figure 1 is a block diagram of an exemplary environment 100 for deploying resources. Environment 100 provides a cloud integration system 102 that can receive requests from the client / requesting system 104, for example to deploy an integration flow (iFlow) and put that iFlow into a pod instance (as a resource). include. The client / requesting system 104 can include any system that sends the request to the cloud integration system 102. For example, the client / requesting system 104 can include a client 106 used by user 108. The network 110 can connect the client / requesting system 104 to the cloud integrated system 102. In some implementations, the network 110 may include some or all of the cloud integration system 102. The interface 111 can receive a request received from the client / requesting system 104 through the network 110.

The cloud integration system 102 includes a container orchestration service 112 that is configured to handle the life cycle of a container instance. The cloud integration system 102 can also perform services such as routing, scaling, and API publishing. The cloud integration system 102 can handle the received request to deploy the iFlow and put the iFlow into the pod instance (as a resource).

The routing analysis module 114 can use the information related to the pods to determine which pod the request should be sent to. To support the load balancing performed by the platform, route analysis can be used to analyze the traffic on each integration flow and pod. As a result of the analysis, metrics are generated and further resource optimizations are made, such as increasing or decreasing the integration flow using the content orchestration service or triggering the movement of the integration flow from one pod to another. obtain. The scaling module 116 can determine when more pods should be added.

API 118 can be provided as an extension or service of the container orchestration service 112. The API can enable pod identification of labeled resources, including supporting queries to different pods and to pod synchronization agents. An exemplary query could be a query to identify the pod in which the resource is running. The API can enable pod submissions, including connecting to a pod to send a request after identifying where the request should be sent. You can use the endpoint API to manage the locations where external systems can communicate requests.

The deployed pod / container component 120 can be configured to parse the resources in the pod and generate labels for the resources. The deployed pod / container component 120 includes the deployed resource / iFlow122 datastore and at least one pod synchronization agent 124. The pod synchronization agent 124 can return a response to the container orchestration service 112 when a pod identification is sent. Pod Sync Agent 124 can also manage information related to connections back to the endpoint API.

Memory 126 contains an iFlow definition 128 data store for deployed pods. At least one processor 130 can perform the processing functions of the cloud integrated system 102. For example, at least one processor 130 can execute instructions for interface 111 and container orchestration service 112 (including its components).

Figure 2 is a block diagram of an exemplary environment 200 for handling load balancing of applications running in the cloud. For example, environment 200 can include operations corresponding to environment 100.

The load balancer 202 can perform load balancing of integration scenarios running in the cloud, for example. The load balancer 202 can interface with the container orchestration service 206 using the load balancing agent 204 (eg catchall.sap.io / *). The container orchestration service 206 can be implemented as, for example, the container orchestration service 112. The container orchestration service 206 shall be implemented, at least in part, using a relational database management system (RDBMS) service that can expose endpoints using uniform resource locators (URLs) to service 214. Can be done. For example, the container orchestration service 206 may expose endpoints 208, 210, and 212, corresponding to services 216, 218, and 220, respectively.

Service 214 can provide access to pod 222. Pods 222a-222c can act as ports or worker sets. Documents 224a-224c can represent iFlow, and each of the ports can have different labels (eg, aa, bb, and cc) associated with the resources provided by service 214 (eg, aa, bb, and cc). Service 216 "AA" corresponds to the label "aa" and so on). Label lists 226a-226c can identify labels, and thus resources, within each of the pods 222. For example, the labels "aa" and "bb" are contained within label list 226a, which are labels for resources running on pod 222a. The pod synchronization agents 228a-228c in pods 222a-222c, respectively, can handle pod 222 synchronization, including keeping track of the label corresponding to the resource running on the pod. Pod 222 can be implemented, for example, as a deployed pod / container component 120.

FIG. 3 is a flowchart of an exemplary method 300 for deploying a resource. Method 300 can be performed by the cloud integration system 102. For the sake of clarity, the following description generally describes Method 300 in the context of FIGS. 1 and 2.

At 302, the cloud integration system deploys iFlow as a resource. For example, the container orchestration service 112 may deploy iFlow as a resource (which will later be labeled "aa").

At 304, the container orchestration service allocates resources to one or more pods. As an example, the container orchestration service 112 can deploy a resource (which will later be labeled "aa") to pod 222a.

At 306, the pod synchronization agent copies the iFlow definition mapped to the resource into the corresponding pod. As an example, pod synchronization agent 124 can copy iFlow definition 128 to pod 222a.

At 308, the Pod Sync Agent assigns each resource a unique label based on the iFlow deployed within the pod. For example, Pod Synchronization Agent 124 can assign the resource the label "aa".

At 310, the cloud integration system creates a service with a rule that redirects a call to one or more pods containing the resource as an endpoint to the resource. As an example, the container orchestration service 112 can create a service 216 corresponding to a resource with the label "aa".

In some implementations, Method 300 may further include steps for load balancing. For example, load balancing can be used to balance the load of resources running on pod 222. The steps for load balancing will be described with reference to Figure 4.

FIG. 4 is a flow chart of an exemplary method 400 for handling service requests. Method 400 may be performed by the cloud integration system 102. For the sake of clarity, the following description generally describes Method 400 in the context of FIGS. 1 and 2.

At 402, the cloud integration system receives a request to call a service for a particular resource. For example, the cloud integration system 102 can receive a request from the client / requesting system 104 to service the currently running iFlow.

In 404, the cloud integration system uses rules to determine the specific pod to which the request is directed. For example, the cloud integration system 102 can determine which pod 222 is currently running the resource labeled "aa".

At 406, the cloud integration system determines the current load on the pod containing a particular resource. As an example, the load balancer 202 can determine the load on the pod 222 running the resource labeled "aa". The load may be based on one or more of CPU usage or memory usage.

At 408, a cloud integration system can use a unique label to forward requests to low-load pods. As an example, the load balancer 202 can forward a request to the pod 222b if the pod 222b has a lighter load than the other pods 222.

FIG. 5 is a flow chart of an exemplary method 500 for allocating resources to new or other available pods using the scaling module. Method 500 may be performed by the cloud integration system 102. For the sake of clarity, the following description generally describes Method 500 in the context of FIGS. 1 and 2.

At 502, the cloud integration system deploys iFlow as a resource with a scale factor X. For example, the cloud integration system 102 can deploy iFlow as one of the deployed resources / iFlow122.

At 504, the scaling module allocates iFlow resources to X pods. For example, scaling module 116 can assign iFlow to X pods.

In 506, the scaling module allocates affected resources to new or other available pods to match the scaling factor. For example, if any pod crash that affects an iFlow resource is detected, scaling module 116 can allocate the resource to other pods.

FIG. 6 is a flow chart of an exemplary method 600 for allocating resources to new pods. Method 600 can be performed by the cloud integration system 102. For the sake of clarity, the following description generally describes Method 600 in the context of FIGS. 1 and 2.

At 602, the cloud integration system deploys iFlow as a resource with an autoscale factor. For example, the autoscale factor can represent the initial number of pods for the initial deployment of iFlow by the cloud integration system 102.

At 604, the individual iFlow loads and traffic are analyzed by the routing analysis module and the loads and traffic are scaled to X. For example, the scaling module 116 can determine X after analyzing the traffic on an individual iFlow.

In 606, the scaling module allocates iFlow resources to X pods. As an example, scaling module 116 can update deployed pods / containers 120 to allocate iFlow resources to X existing pods.

In the 608, the scaling module triggers the platform scaler in the container orchestration service to create a new pod. For example, the container orchestration service 112 scaling module 116 may be triggered to create a new pod within the deployed pod / container 120.

At 610, the scaling module assigns iFlow resources to newly created pods. For example, after a new pod is created, scaling module 116 can allocate iFlow resources to the new pod and update the deployed pod / container 120.

The techniques described in this disclosure can be used to manage the integration flow and deliver it within the runtime integration engine. The integration flow can be used in place of the dynamic run-time content provided for the corresponding dynamic run-time engine, for example using the examples listed in Table 1.

FIG. 7 is a block diagram of an exemplary computer system 700 used to provide computer functionality related to the algorithms, methods, functions, processes, flows, and procedures described described herein.

The computer 702 shown is a server, desktop computer, laptop / notebook computer, wireless data port, smartphone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, or compute. It is intended to include any computing device, such as any other suitable processing device, including physical and / or virtual instances of the ing device. In addition, the computer 702 includes input devices such as keypads, keyboards, touch screens, or other devices capable of receiving user information, and digital data, visual or audio information (or a combination of information). The computer may include an output device or a graphical user interface (GUI) that conveys information related to the operation of the computer 702.

The computer 702 serves (or plays a role) as a client, network component, server, database or other persistence, or any other component of the computer system for performing the subject matter described in this disclosure. Combination) can be fulfilled. The illustrated computer 702 is communicably coupled to the network 730. In some implementations, one or more components of the computer 702 are configured to operate within an environment that includes a cloud computing-based local environment, a global environment, or another environment (or a combination of environments). It's okay.

At a high level, the computer 702 is an electronic computing device capable of receiving, transmitting, processing, storing, or managing data and information related to the subject matter described. According to some implementations, the computer 702 may include application servers, email servers, web servers, caching servers, streaming data servers, business intelligence (BI) servers, or other servers (or combinations of servers). Well, it may be communicatively combined with it.

Computer 702 may respond to a request by receiving a request from a client application (eg, running on another computer 702) over network 730 and processing the request in an appropriate software application. can. In addition, the request is sent to computer 702 from an internal user (eg, from a command console, or by any other suitable access method), from an external or third party, from other automated applications, and any other suitable entity. , Personal, system, or computer.

Each of the components of computer 702 can communicate using system bus 703. In some implementations, any or all of the components of computer 702, which are hardware or software (or a combination of hardware and software), with each other or with interface 704 (or a combination of both) and API 712. Alternatively, service layer 713 (or a combination of API 712 and service layer 713) may be used to interface via system bus 703. API712 may include specifications for routines, data structures, and object classes. API712 may be computer language independent, computer language dependent, may refer to a complete interface, may refer to a single function, or even a set of APIs. You may be. Service layer 713 provides software services to computer 702, or any other component communicably coupled to computer 702 (whether illustrated or not). The functionality of computer 702 may be accessible to all service consumers using this service layer. Software services such as those provided by service layer 713 provide defined reusable business functionality through defined interfaces. For example, the interface may be software written in Java®, C ++, or any other suitable language that provides data in Enhanced Markup Language (XML) format or other suitable format. API 712 or service layer 713 is illustrated as an integrated component of computer 702, but in an alternative implementation, it is communicably coupled to another component of computer 702, or computer 702 (whether or not it is illustrated). It may be illustrated as a stand-alone component with respect to other components (regardless of whether or not). In addition, any or all parts of API 712 or Service Layer 713 may be implemented as child modules or submodules of another software module, enterprise application, or hardware module without departing from the scope of this disclosure. You may.

Computer 702 includes interface 704. Although shown as a single interface 704 in FIG. 7, more than one interface 704 may be used depending on the specific needs, desires, or specific implementation of the computer 702. Interface 704 is used by computer 702 to communicate with other systems (whether illustrated or not) in a distributed environment connected to network 730. In general, interface 704 comprises logic encoded in software or hardware (or a combination of software and hardware) that can operate to communicate with network 730. More specifically, the interface 704 may be one or more communication-related so that the network 730 or the hardware of the interface can operate to communicate physical signals inside and outside the computer 702 shown. It may be equipped with software that supports the communication protocol of.

Computer 702 includes processor 705. Although shown as a single processor 705 in FIG. 7, more than one processor may be used according to the specific needs, desires, or specific implementation of computer 702. In general, the processor 705 executes instructions and manipulates data in order to perform the operation of the computer 702 and any algorithms, methods, functions, processes, flows, and procedures described in the present disclosure.

Computer 702 also includes memory 706, which holds data for computer 702, or other components (whether illustrated or not) that can be connected to network 730 (or a combination of both). For example, the memory 706 can be a database that stores data consistent with the present disclosure. Although shown as a single memory 706 in FIG. 7, more than one memory may be used depending on the specific needs, desires, or specific implementations of the computer 702, and the functionality described. The memory 706 is illustrated as an integrated component of the computer 702, but in an alternative implementation, the memory 706 may be external to the computer 702.

Application 707 is an algorithmic software engine that provides functionality according to a particular need, desire, or specific implementation of computer 702, especially with respect to the functionality described herein. For example, application 707 can work as one or more components, modules, applications, and so on. Further, the application 707 is illustrated as a single application 707, but may be implemented on the computer 702 as multiple applications 707. In addition, application 707 is illustrated as integrated with computer 702, but in an alternative implementation, it may be external to computer 702.

There may be any number of computers 702 associated with or outside the computer system that houses the computers 702, and each computer 702 communicates over network 730. Moreover, the terms "client", "user", and other suitable terms may be used interchangeably as appropriate without departing from the scope of the present disclosure. Further, the present disclosure contemplates that many users may use one computer 702, or one user may use multiple computers 702.

In some implementations, the environment and system components described above may include, for example, blade servers, general purpose personal computers (PCs), Macintoshes, workstations, UNIX-based workstations, or any other suitable device. , Any computer or processing device. In other words, the present disclosure is intended for computers other than general-purpose computers, as well as computers that do not use conventional operating systems. In addition, the components include Linux®, UNIX®, Windows, Mac OS®, Java®, Android®, iOS, or any other suitable operating system. , May be adapted to run any operating system. According to some implementations, the component may include an email server, a web server, a caching server, a streaming data server, and / or other suitable server and may be communicably coupled with it.

The processor used in the environment and system described above may be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another suitable component. In general, each processor can execute instructions and manipulate data to perform the actions of various components. Specifically, each processor sends a request and / or data to a component of the environment and receives data from the component of the environment, such as in communication between an external device, an intermediate device, and a target device. You can perform the functionality you need.

The components, environments, and systems described above may include one or more memories. Memory may include, but is not limited to, any type of memory or database module, such as magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other. It may take the form of volatile and / or non-volatile memory, including suitable local or remote memory components. Memory includes caches, classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, repositories that store business and / or dynamic information, as well as target devices, intermediate devices, and so on. Stores various objects or data, including any other appropriate information, including any parameters, variables, algorithms, instructions, rules, constraints, and for references to it related to the purpose of the external device. good. Other components in memory are also possible.

Regardless of the particular implementation, the "software" is a tangible medium (appropriately temporary or non-temporary) that, when executed, is capable of operating at least to perform the processes and operations described herein. It may include the above computer-readable instructions, firmware, wired and / or programmed hardware, or any combination thereof. In fact, each software component is any suitable computer language, including C, C ++, Java®, Visual Basic, Assembler, Perl®, any suitable version of 4GL, and others. And may be described or described in whole or in part. The software may instead include some submodules, third party services, components, libraries, etc. as appropriate. Conversely, the features and functionality of different components can be combined into a single component as appropriate.

The device can be any, such as a smartphone, tablet computing device, PDA, desktop computer, laptop / notebook computer, wireless data port, one or more processors within these devices, or any other suitable processing device. Compute devices can be included. For example, the device may be an input device such as a keypad, touch screen, or other device capable of receiving user information, as well as information related to the environment and system components described above, including digital data and visual information. It may be equipped with an output device, or a computer, including a GUI. The GUI interfaces with at least a portion of the environment and system described above for any suitable purpose, including generating a visual display of a web browser.

The figures above and the accompanying descriptions show exemplary processes and computer-implementable techniques. The environment and system described above (or their software or other components) may use, implement, or perform any suitable technique for performing these tasks and other tasks. Can be planned. These processes are for illustrative purposes only, and any suitable timing, including the techniques described or similar techniques in parallel, individually, in parallel, and / or in combination. It will be understood that it may be carried out in. In addition, many of the operations in these processes may occur simultaneously, in parallel, in parallel, and / or in a different order than shown. In addition, the process may have additional behavior, less behavior, and / or different behavior as long as the method remains appropriate.

In other words, although the present disclosure has been described in terms of certain embodiments and generally relevant methods, those of ordinary skill in the art will appreciate the modifications and permutations of these implementations and methods. Become. Accordingly, the above description of exemplary implementations does not define or limit the present disclosure. Other modifications, substitutions, and modifications are possible without departing from the spirit and scope of the present disclosure.

100 Illustrative environment
102 Cloud integrated system
104 Client / Requesting System
106 client
108 users
110 network
111 interface
112 Container orchestration service
114 Routing Analysis Module
116 Scaling module
118 API
120 Deployed Pod / Container Component, Deployed Pod / Container
122 Deployed Resources / iFlow
124 Pod Sync Agent
126 memory
128 iFlow definition
130 processor
200 Illustrative environment
202 load balancer
204 Load Balancing Agent
206 Container Orchestration Service
208 endpoint
210 endpoint
212 endpoint
214 Services
216 Services
218 Services
220 service
222 pods
222a pod
222b pod
222c pod
224a-224c Document
226a-226c Label list
228a-228c Pod Sync Agent
300 exemplary method
400 Illustrative method
500 exemplary method
600 Illustrative method
700 Illustrative computer system
702 computer
703 system bus
704 interface
705 processor
706 memory
707 application
712 API
713 Service layer
730 network

Claims (17)

With the cloud integration system, the steps to deploy the integration flow (iFlow) as a resource,
The step of allocating the resource to one or more pods by the container orchestration service,
The step of copying the iFlow definition mapped to the resource by the pod synchronization agent into the corresponding pod, and
A step of assigning a unique label to the pod based on the iFlow deployed within the pod by the pod synchronization agent.
A computer implementation method comprising the step of creating a service as an endpoint to the resource by a rule that directs the call to the one or more pods containing the resource with the label by the cloud integration system. .. The step of receiving a request to call a service of a specific resource by the cloud integrated system, and
Steps to use the rules to determine the specific pod to which the request is directed, and
With the cloud integration system, the steps to determine the current load of the pod containing the particular resource, and
The computer implementation method of claim 1, further comprising the step of transferring the request to a low load pod using a unique label. The computer implementation method of claim 2, wherein the low load is based on one or more of central processing unit (CPU) utilization or memory utilization. The computer implementation method of claim 2, wherein the step of determining the current load of the pod containing the particular resource is performed by a load balancer. The computer implementation method of claim 2, further comprising load balancing the resources running on the pod. The computer implementation method of claim 5 , wherein the load balancing uses the container orchestration service to access a uniform resource locator (URL) that exposes an endpoint to the service. Memory for storing tables containing deployed resources / iFlow and iFlow definitions, and
Deploying iFlow as a resource with a cloud integrated system,
Allocating the resources to one or more pods by the container orchestration service,
Copying the iFlow definition mapped to the resource by the pod synchronization agent into the corresponding pod,
The pod synchronization agent assigns a unique label to the pod based on the iFlow deployed within the pod, and the cloud integration system accommodates the resource with the label. A system comprising a server that performs an operation, including creating a service as an endpoint to the resource, according to a rule that directs calls to multiple pods. The above operation
Receiving a request to call a service of a specific resource by the cloud integrated system,
Using the rules to determine the specific pod to which the request will be directed,
The cloud integration system determines the current load of the pod containing the particular resource.
The system of claim 7 , further comprising forwarding the request to a low load pod using a unique label. The system of claim 8 , wherein the low load is based on one or more of CPU utilization or memory utilization. 8. The system of claim 8 , wherein determining the current load of the pod containing the particular resource is performed by the load balancer. The system of claim 8 , wherein the operation further comprises performing load balancing of resources running on the pod. 11. The system of claim 11 , wherein the load balancing uses the container orchestration service to access a URL that exposes an endpoint to the service. A computer program is an encoded non-temporary computer-readable medium, wherein the program comprises instructions that, when executed by one or more computers, to the one or more computers.
Deploying iFlow as a resource with a cloud integrated system,
Allocating the resources to one or more pods by the container orchestration service
By copying the iFlow definition mapped to the resource by the pod synchronization agent into the corresponding pod,
Assigning a unique label to the pod based on the iFlow deployed within the pod by the pod synchronization agent.
The cloud integration system causes an operation, including creating a service as an endpoint to the resource, by a rule that directs a call to the one or more pods containing the resource with the label . , Non-temporary computer readable media. The above operation
Receiving a request to call a service of a specific resource by the cloud integrated system,
Using the rules to determine the specific pod to which the request will be directed,
The cloud integration system determines the current load of the pod containing the particular resource.
13. The non-temporary computer-readable medium of claim 13 , further comprising forwarding the request to a low load pod using a unique label. The non-temporary computer-readable medium of claim 14 , wherein the low load is based on one or more of CPU utilization or memory utilization. The non-temporary computer-readable medium of claim 14 , wherein the load balancer performs to determine the current load of the pod containing the particular resource. The non-temporary computer-readable medium of claim 14 , wherein the operation further comprises performing load balancing of resources running on the pod.

Images