Container-based computer system for managing resources in an orchestration system and method thereof

Abstract

Embodiments of present disclosure provide container-based computer system (200) and method (300) for managing resources in an orchestration system (1000). Computational resource information regarding states in lifecycle of application are stored and computational resources are assigned by identifying a change in computational resource requirement of a workload (302) due to transition in states of the application. The computational resources are assigned by identifying workload (302-A) with available computational resource which is released and assigned to another workload (308-B).

Description

[0001] CONTAINER-BASED COMPUTER SYSTEM FOR MANAGING RESOURCES IN AN ORCHESTRATION SYSTEM AND METHOD THEREOF

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to a field of container-based computer system for managing resources in an orchestration system. More particularly, it relates to management of resources in the container-based computational system.

[0004] BACKGROUND

[0005] A platform for container orchestration enables developers to easily build and develop containerised applications and services. With these platforms, it becomes easy to scale, schedule and monitor containers and they also provide a complete control over the customization of the containerised application and services.

[0006] For example, Kubernetes is an extremely popular open-source container orchestration system for software deployment, scaling and overall management. It is a de-facto standard for large scale software applications and may be adopted for developing and delivering software for 5G Core, Cloud-RAN, Network Management, Licensing and many others. Kubernetes is an extensible by design and comes in different variations, either accessible in a public cloud or in premises for example, RedHat Openshift. Different versions of Kubernetes may also be optimized for different industries, for example, telecom, by modifying the workloads and including components catering to the requirement of the telecom industry.

[0007] In Kubernetes containers may be bundled into pods and such pods represent smallest manageable unit of computational resources, for example, Central Processing Unit, CPU, Random Access Memory, RAM, other storage etc. Pods are usually generated from a template included in a workload, for example, Stafefulset, Deployment, Job etc., and the pods may be scheduled on a computing node by a scheduler and then managed by an agent called kubelet which drives the container runtime.

[0008] In view of the design of the Kubernetes, the resources of the pods were first immutable, so the only way to cope with any changing computational resource requirements were Horizontal Pod Autoscaling, HPA and Vertical Pod Autoscaling, VPA. In the HPA, a new pod cloned from a given specification is added or removed to a pool of pods sharing a same template. While, in the VPA, the specification itself is changed with respect to the change in the computational resource requirement.

[0009] Large-scale applications usually are subject to time-varying requirements, e.g. daily or seasonal variations of traffic, increasing number of users in time for successful use- case, etc. Therefore, it is essential for an application owner to properly provision the computing infrastructure required both in constrained-resources environments and in public clouds where resources are practically unlimited. It is therefore very important to provide the required computing infrastructure to prevent overspending and have a reliable solution for handling the change of computational resource requirement.

[0010] SUMMARY

[0011] Though HPA and VPA are widely used, however, both the HPA and the VPA share a common problem which requires starting a new pod and wait forthe new pod to be ready. The problem may not be a severe problem for cloud-native services, i.e. the services designed from beginning to be scalable, fast to become ready, possibly stateless, etc., however, the problem may be significant for monolithic applications that are very slow to come up. Since the monolithic applications may include legacy systems, e.g. based on frameworks like JBoss / Wildfly, that were just containerized, the requirement of slow pod restart may correspond to a higher risk of service unavailability.

[0012] Kubernetes has also introduced a new degree of freedom with respect to resource management which is called as, "in-place-resource-resize" where the pod may be resized without necessarily restarting it. This feature of "in-place-resource- resize" may allow to resize the application according to the load, saving the restart time on slow pods. However, at the moment of writing, this feature of "in-place-resource-resize" is not exploited to perform autoscaling of the applications.

[0013] Even if the VPA may be enhanced to exploit in-place-resource-resize, the VPA may still not be able to cope with a situation where the requests of two workloads need to be both increased and one of such requests need to be terminated and rescheduled to a node with enough free resources. There is a need for an improved method for managing resources in an orchestration system that leads to a reduction of computational resource footprint with minimal or no impact on application performance and resilience.

[0014] It is therefore an object of the present disclosure to provide a container-based computer system and a method for managing computational resources in an orchestration system to mitigate, alleviate, or eliminate all or at least some of the above-discussed drawbacks of presently known solutions.

[0015] This and other objects are achieved by means of a container-based computer system, and a method defined in the appended claims. The term exemplary is in the present context to be understood as serving as an instance, example or illustration.

[0016] According to a first aspect of the present disclosure, a container-based computer system is provided. The container-based computer system comprises a data processing unit arranged to execute the instructions stored in a non-transitory computer readable medium, an application manager communicatively coupled to the data processing unit and arranged to store computational resource information regarding one or more states in a lifecycle of an application having a plurality of states. The container-based computer system further comprises a plurality of workloads each having at least one container, wherein the at least one container is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application, and a scheduler communicatively coupled to the data processing unit and arranged to assign computational resources, wherein the assigning of computational resources comprises identify for each workload a change in a computational resource requirement of the workload due to a transition from a first to a second state of the states in the lifecycle of the application, identify at least one workload from the plurality of workloads having at least one container with available computational resource in the second state, wherein the available computational resource is released by the at least one container during the transition from the first to the second state and assign the available computational resource released by the at least one container to at least one other container in another workload of the plurality of workloads.

[0017] Optionally, at least one other container is a container having an increased computational resource requirement in the second state. Optionally, at least one other container is arranged to request for the available computational resource from the at least one container releasing the computational resource during the transition.

[0018] Optionally, the scheduler is configured to assign the computational resources during the runtime of the application.

[0019] Optionally, the each workload is associated to a specification defining the computational resource requirement associated to the workload and wherein the scheduler is further configured to determine an updated specification for the at least that workload comprising the container releasing the available computational resource, wherein said updated specification is determined based on the computational resource requirement of the at least one other container of the another workload in in the second state and resize the at least one workload having the at least one container releasing the available computational resource according to the updated specifications.

[0020] Optionally, the scheduler is further configured to pair, the at least one workload from the plurality of workloads having the at least one container releasing the available computational resource with the workload having the at least one other container having the increased computational resource requirement.

[0021] Optionally, the at least one container of each workload is scheduled at one or more computing nodes in the orchestration system.

[0022] Optionally, the available resources released by the at least one workload having the at least one container is assigned to the at least one other container in another workload at a same computing node from the one or more computing nodes.

[0023] Optionally, the workload having the at least one container releasing the computational resource and the another workload of the plurality of workloads having the at least one container to which the available computational resource are assigned the second state.

[0024] Optionally, the available computational resource released by the least container is assigned to the at least one other container without restarting the plurality of workloads. According to a second aspect of the present disclosure, a computer implemented method performed through a container-based computer system for managing computational resources in an orchestration system is provided. The method comprises storing, through an application manager communicatively coupled to a data processing unit, computational resource information regarding one or more states in a lifecycle of an application having a plurality of states, and assigning, through a scheduler communicatively coupled to the data processing unit, computational resources to a plurality of workloads each having at least one container, wherein the at least one container is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application. The assigning of computational resources comprises identifying for each workload a change in a computational resource requirement of the workload due to a transition from a first to a second state of the states in the lifecycle of the application, identify at least one workload from the plurality of workloads having at least one container with available computational resource in the second state, wherein the available computational resource is released by the at least one container during the transition from the first to the second state and assign the available computational resource released by the at least one container to at least one other container in another workload of the plurality of workloads.

[0025] According to a third aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions. The computer program is loadable into a data processing unit and configured to cause execution of the method according to the first and second aspects when the computer program is run by the data processing unit.

[0026] Some embodiments disclosed herein have one or more of the following advantages:

[0027] - Reduction computational resource footprint with decreased or no impact on application performance and resilience.

[0028] - Reassigning computational resources released after successful pod downsizing in a same node that needs extra resources for a specific application state.

[0029] - Reassigning computational resources without affecting containers which do not need resizing.

[0030] - Dynamically assigning available computational resources released by a pod by a scheduler to another pod. - Backward compatible behavior, i.e. the component implementing the method can be disabled / uninstalled and the system works as per the state of the art losing the benefits described previously

[0031] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

[0034] Fig. 1 discloses a wireless communication system according to some examples;

[0035] Fig. 2 is a schematic block diagram illustrating an example container-based computer system for managing computational resources in an orchestration system;

[0036] Fig. 3 is a flowchart illustrating example steps for a method for managing computational resources in an orchestration system;

[0037] Fig. 4A provides an example flow of resource identification, affinity identification and pod resizing in offline and runtime scenario;

[0038] Fig. 4B provides an example flow of resource identification, affinity identification and pod resizing in an optional offline and runtime scenario;

[0039] Fog. 5 shows an example of Central Processing Unit, CPU consumption by multiple pods and corresponding states of an application;

[0040] Fig. 6A shows an implementation example of a pod-resizing phase for a Helm application;

[0041] Fig. 6B shows an implementation example of a pod-resizing phase for a service mesh application; and

[0042] Fig. 7 discloses an example computing environment according to some embodiments. DETAILED DESCRIPTION

[0043] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The apparatus and methods disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

[0044] The terminology used herein is for the purpose of describing particular aspects of the disclosure only and is not intended to limit the invention. It should be emphasized that the term "comprises / comprising" when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0045] Embodiments of the present disclosure will be described and exemplified more fully hereinafter with reference to the accompanying drawings. The solutions disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0046] It will be appreciated that when the present disclosure is described in terms of a platform and a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

[0047] Fig. 1 discloses an example wireless communication system 100. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in related to a wireless communication system / wireless network, such as the example wireless communication system 100 described in Fig. 1.

[0048] The wireless communication system 100 may comprise and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network or other similar type of system. In some embodiments, the wireless communication system 100 may be configured to operate according to specific standards or other types of predefined rules of procedures. Thus, particular embodiments of the wireless communication system 100 may implement communication standards, such as, but are not limited to, global system for mobile communications, GSM, universal mobile telecommunications system, UMTS, long term evolution, LTE, and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network, WLAN, standards such as, IEEE 802.11 standards, and / or any other appropriate wireless communication standards, such as, worldwide interoperability for microwave access, WiMax, Bluetooth, Z-Wave and / or ZigBee standards.

[0049] For simplicity, as depicted in Fig. 1, the wireless communication system 100 comprises a container-based computer system 200, a network node 104, and a network 106. The container-based computer system 100 and the network node 104 operate together in order to provide wireless connections in the wireless communication system 100. The network 106 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks, PSTNs, packet data networks, optical networks, wide-area networks, WANs, local area networks, LANs, wireless local area networks, WLANs, wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices (for example, wireless devices and network node).

[0050] The network node 104 may refer to equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with the container-based computer system 200 and / or with other network nodes or equipment in the wireless communication system 100 to enable and / or provide wireless access to the container-based computer system 200 and / or to perform other functions (for example, administration) in the wireless communication system 100. Examples of the network node 104 may include, but are not limited to, access points, APs (for example, radio access points), base stations, BSs (for example, radio base stations, nodeBs, evolved NodeBs, eNBs, new radio, NR, nodes (gNBs), or the like). The BSs may be categorized based on an amount of coverage the BSs provide (or, stated different, their transmit power level) and may then also be referred to as femto BSs, pico BSs, micro BSs, macro BSs. The BS may be a relay node or a relay donor node controlling a relay.

[0051] The container-based computer system 200 may refer to a device capable, configured, arranged and / oroperable to communicate wirelessly with the network node 104 and / orother wireless devices. In some examples, the container-based computer system 200 may include one or more of: computing devices, wireless devices, ultra-low power wireless devices, Internet of Things, loT, devices, and so on.

[0052] Examples of the computing devices may include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over Internet Protocol, IP, VoIP, phone, a wireless local loop phone, a desktop computer, a personal digital assistant, PDA, a wireless camera, a gaming console or device, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment, LEE, a laptop-mounted equipment, LME, a smart device, a wireless customer-premise equipment, CPE, a vehicle- mounted wireless terminal device, and so on.

[0053] It should be understood that the container-based computer system 200 may not be limited to the above-described wireless devices. The container-based computer system 200 may be extended to other wireless devices of different classes or categories providing different services while supporting, for example, Enhanced Mobile Broadband, eMBB, massive Machine-Type Communication, MTC, Ultra-Reliable Low Latency Communication, URLLC, Time Sensitive Networking, TSN, or the like.

[0054] In the wireless communication system 100, the network node 104 and the container-based computer system 200 are connected through 3GPP 5G core network where specific network services and operations are provided through software components called network functions (NFs). The wireless communication system 100 hosts large scale applications.

[0055] The Large-scale applications usually are subject to time-varying requirements, e.g. daily or seasonal variations of traffic, increasing number of users in time for successful use- case, etc. Therefore, it is essential for an application owner to properly provision the computing infrastructure required both in, constrained-resources environments and in public clouds where resources are unlimited. It is therefore very important to provide the required computing infrastructure to prevent overspending and have a reliable solution for handling the computational resource requirement change in the Kubernetes.

[0056] Though Horizontal Pod Autoscaling, HPA and Vertical Pod Autoscaling, VPA are widely used in Kubernetes open-source orchestration system, however, both the HPA and the VPA share a common problem which requires starting a new pod and wait for the new pod to be ready. The problem may not be a severe problem for cloud-native services, i.e. the services designed from beginning to be scalable, fast to become ready, possibly stateless, etc., however, the problem may be significant for monolithic applications that are very slow to come up. Since the monolithic applications may include legacy systems, e.g. based on frameworks like JBoss / Wildfly, that were just containerized, the requirement of slow pod restart may correspond to a higher risk of service unavailability.

[0057] Thus, the present disclosure enables the wireless communication network 100, the network node 104 and the container-based computer system 200 to implement the container-based computer 200 for managing computational resources without affecting, or at least reducing the effect of pod restarts and an overall utilization of computational resource infrastructure increases without compromising reliability of the application.

[0058] Fig. 2 is a schematic block diagram illustrating an example container-based computer system 200 for managing computational resources in an orchestration system 1000 is provided. The container-based computer system 200 comprises a data processing unit 204 arranged to execute the instructions stored in a non-transitory computer readable medium 202. The container-based computer system 200 comprises an application manager 206 communicatively coupled to the data processing unit 204 and arranged to store computational resource information regarding one or more states in a lifecycle of an application having a plurality of states.

[0059] The container-based computer system 200 further comprises a plurality of workloads 208 each having at least one container 210. The at least one container 210 is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application. Examples of the one or more states include, designing, development, testing, monitoring, deployment and other similar states.

[0060] The container-based computer system 200 further comprises a scheduler 212 communicatively coupled to the data processing unit 204 and arranged to assign computational resources. The scheduler 212 is further configured to identify for each workload 208 a change in a computational resource requirement of the workload 208 due to a transition from a first state to a second state of the plurality of states in the lifecycle of the application. The scheduler 212 is further configured to identify at least one workload 208-A from the plurality of workloads 208 having at least one containers, for example, with available computational resource in the second state. The available computational resource is released by the at least one container 3 during the transition from the first to the second state and assign the available computational resource released by the at least one container 3 to at least one other container 5, for example in another workload 208-B of the plurality of workloads 208.

[0061] Optionally, the at least one other container 6 is a container having an increased computational resource requirement in the second state.

[0062] Optionally, the at least one other container 6 is arranged to request for the available computational resource from the at least one container 6 releasing the computational resource during the transition.

[0063] Optionally, the scheduler 212 is configured to assign the computational resources during a runtime of the application.

[0064] Optionally, the each workload 208 is associated to a specification defining the computational resource requirement associated to the workload 208 and optionally the scheduler 212 is further configured to determine an updated specification for the at least that workload 208- A comprising the container 3 releasing the available computational resource. The updated specification is determined based on the computational resource requirement of the at least one other container 6 of the another workload 208-B in in the second state and resize the at least one workload 208-A having the at least one container 3 releasing the available computational resource according to the updated specifications.

[0065] Optionally, the scheduler 212 is further configured to pair, the at least one workload 208-A from the plurality of workloads 208 having the at least one container 3 releasing the available computational resource with the workload 208-B having the at least one other container 6 having the increased computational resource requirement.

[0066] Optionally, the at least one container 210 of each workload 208 is scheduled at one or more computing nodes 3000 in the orchestration system 1000. Optionally, the available resources released by the at least one workload having the at least one container is assigned to the at least one other container in another workload at a same computing node from the one or more computing nodes.

[0067] Optionally, the workload 208-A having the at least one container 3 releasing the computational resource and the another workload 208-B of the plurality of workloads 208 having the at least one other container 6 to which the available computational resource are assigned are in the second state. The workload 208-A releasing the computational resource and the workload 208-B getting the computational resource need to be in same state from the plurality of states of the application, here the same state is the second state.

[0068] Optionally, the available computational resource released by the least container 3 is assigned to the at least one other container 6 without restarting the plurality of workloads 208.

[0069] The proposed container-based computer system 200 leads to a reduction of the computational resource footprint with minimal or no impact on performance of the application and resilience. This is possible because the computational resources released after successful downsizing of the at least one workload 208-A from the plurality of workloads 208 may be reassigned to the at least one workload 208-B in a same node 3000 that needs extra computational resources for that specific application state, the second state. The reduction of the resource footprint corresponds to delivering / renting / powering a less expensive computing node.

[0070] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the disclosure. Fig. 3A shows a flowchart illustrating steps for a computer implemented method 300 performed through the container-based computer system 200 for managing computational resources in the orchestration system 1000 according to some embodiments.

[0071] At step 302, the method 300 comprises storing computational resource information regarding one or more states in a lifecycle of an application having a plurality of states. The storing is performed through the application manager 206 communicatively coupled to the data processing unit 204.

[0072] At step 304, the method 300 comprises assigning computational resources to a plurality of workloads each having at least one container. The at least one container is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application. The assigning is performed through the scheduler 212.

[0073] At step 306, the method 300 assigns the computational resources comprises identifying for each workload, a change in a computational resource requirement of the workload due to a transition from a first to a second state of the states in the lifecycle of the application.

[0074] At step 308, the method 300 provides identifying at least one workload from the plurality of workloads having at least one container with available computational resource in the second state. The available computational resource is released by the at least one container during the transition from the first to the second state.

[0075] At step 310, the method 300 provides assigning the available computational resource released by the at least one container to at least one other container in another workload of the plurality of workloads.

[0076] Fig. 4A provides an example flow of resource identification, affinity identification and pod resizing in offline and runtime scenario according to some embodiments of the method 300 executed through container-based computer system 200.

[0077] Fig. 4A shows the flow for Kubernetes open-source container orchestration system (hereafter referred as Kubernetes) considered here as the orchestration system 1000. In the Kubernetes, the workloads are referred as pods.

[0078] At step 402, the application manager 206 performs the states identification in the lifecycle of an application and computational resource identification for each state from a plurality of states in the lifecycle of an application. Here Central Processing Unit, CPU and memory are considered as the computational resource.

[0079] A plurality of containers belonging to a Pod in the Kubernetes may require different amounts of the CPU and memory depending on a current state from the plurality of states of the application which is referred as the computational resource requirement. The purpose of the step 402 providing "states and resource identification" phase is to define, manually or automatically, the states of the application lifecycle. Each state is then associated with the required computational resources by all the containers or a subset of containers from all the containers.

[0080] For example, during the states and resource identification phase, step 402, the application manager 206 determines that a container A in a Pod X requires 100m CPU when the application is in a "first" state and the container A in the Pod X requires 500m CPU when the application is in a "second" state.

[0081] At step 404, an affinity identification or pairing or workloads, here the pairing of the pods, is performed where all the pods in the Kubernetes are arranged in subsets exploiting an opposite computational resource consumption patterns, for example the computational resource consumption by other pods, to decrease per-node total computational resource consumption across all the stated of the application. One simplest implementation consists in associating such subset of the pods to labels (which are key-value pairs as per the computational resource requirement) and exploiting standard Kubernetes mechanisms like pod affinities / pod pairing. For example pod affinities, amount of computational resources exhausted by a set of pods and anti-affinities, for example amount of computational resources exhausted by an opposite set of pods may be paired.

[0082] During the resizing of the workloads as discussed above, herein resizing of the pods, the purpose of the "pod resizing" phase, step 406, is to change the pods specifications according to the transition in the states of the application.

[0083] The pod resizing results in technical effect which provides stranded / available computational resources released by a pod are dynamically assigned by the scheduler to another pod without, or reducing the effect of, pod restarts and an overall utilization of computational resource infrastructure increases without compromising reliability of the application. In Fig. 4A, the step 402, "states and resource identification" and the step 404, "the pod labeling" phases happen before the application is delivered to a customer, referred herein as offline, while the step 406 "pod resizing" phase happens at a runtime of the application.

[0084] In Fig. 4B, each of step 402, "states and resource identification" and the step 404, "the pod labeling" may be performed continuously during the runtime of the application, while collecting real usage of the computational resources for identifying new states of the application. In Fig. 4B, the pods might be rescheduled to other nodes to exploit the affinities and anti-affinities for managing the computational resources in the orchestration system.

[0085] The method 300 leverages a feature available in popular container orchestration systems including in-place-pod-update for example, Kubernetes 1.27 and is based on standard Kubernetes practices like pod labeling and the Kubernetes Operator pattern. With the proposed method 300, there is no need of any modification in the Kubernetes control plane or kubelet etc.

[0086] Fig. 5 shows an example computational resource consumption 500 by multiple pods, i.e., four pods comprising podl, pod2, pod3 and pod4, and corresponding states of the application. Fig. 5 shows CPU consumption as the computational resource consumption by the four pods, constituting an application, for each of state 1 and state 2 of the application.

[0087] Vertical boxes in Fig. 5 represent the states of the application. In this example there are two states state#l and state#2. The states may be defined manually by an application architect (e.g. "normal operation", "backup and restore", "performance collection") or might have been inferred by automatic processing.

[0088] For every application state, statel and the state 2, dotted lines represent a request for the computational resource, herein CPU requests by one of the pods from the four pods having an increased demand of the computational resource. The CPU requests may typically be chosen high enough to accommodate the CPU consumption while meeting the Key Performance Indicators, but not too high to prevent unnecessary resource allocation on the node. The CPU request might have been defined manually by the application architect or found by some automatic means (typically via the VPA Recommender or data-driven algorithms). Fig. 5 shows the pod resizing and the assigning of the CPU computational resource, as the CPU requests, represented by dotted lines, changes from the state 1 to the state 2 and then again from the state 1 to the state 2 for each pod of the four pods.

[0089] Table 1 below shows the CPU requests in the state 1 and the state 2 of the application:

[0090] Table 1

[0091] It is assumed here that there are two computing nodes. The scheduler provides the pod allocation to nodes resulting in the minimum total CPU reserved on all the node across all the states of the application.

[0092] Taking the simplified data of Error! Reference source not found, as input, the affinity identification phase (pairing of the pods) is shown in Error! Reference source not found.. The associations / pairing (pod#l, pod#2) and (pod#3, pod#4) decreases a maximum computational resource reservation across all the states for all the nodes. Maximum resource reservation on nodes (A,B) is respectively (1.5, 1.6).

[0093] Table 2

[0094] The pairing of the workloads may also be mapped to Kubernetes labels which may then be used to influence the scheduler in addition to the usual computational constraints.

[0095] Fig. 6A and Fig. 6B shows the requests for the available computational resource by the at least one other containers in the Kubernetes operator. The request refers to the CPU resource request available for each state of the application and a set of labels in the Kubernetes that influence a node placement for a subsets of pods. Fig. 6A and Fig. 6B shows two possible implementations, both based on the Kubernetes operator.

[0096] Fig. 6A shows an implementation of the pod-resizing phase (discussed above) for helm-based applications, considered here as the application, which is one of the most popular package manager for Kubernetes. In step 602, Helm tracks the lifecycle of its releases via secrets. Information in these secrets may be mapped to infer application states like "uninstalling", "deployed", "installing", in step 604. Therefore, at step 606, a state-driven resizing operator, the scheduler, watches the secrets and performs an in-place-resource-resize accordingly. As an example, a use-case is therefore to speed up startup of the whole Helm application by giving more computational resources to slow, heavy pods until the deployment of the Helm is completed and then releasing the computational resources that are no longer necessary for regular operation of the application. Such in-place-resource-resize and the assigning and releasing of the pods in for the Helm application may be performed through the method 300 as discussed above by the container-based computational system 200.

[0097] Fig. 6B shows another implementation of the container-based computational system 200 that addresses applications using a Service Mesh. A Service Mesh is a communication layer that improves the security, resiliency, and observability of a distributed system. The service mesh layer intercepts calls made by the various services belonging to the service Mesh and exposes the application via a Gateway. In step 608, the Gateway is configured to capture the Northbound Interface, NBI calls that are mapped to the states of the application like "perform Backup and Restore", "perform this heavy task X", "collect all performance", etc. A use case of the container-based computational system 200 is therefore to rebalance the computational resources to pods according to the state / status of the application via an in-place-resource- resize through the scheduler to meet the KPI while minimizing the overall footprint in the computational resource utilization, as shown in step 610.

[0098] In Fog. 6B there is one "proxy" per microservice belonging to the mesh (though other implementations of the Service Mesh dataplane are possible). It is also possible to infer the states of application by consuming internal API calls via the Service Mesh Proxies.

[0099] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors, DSPs, special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, RAM, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0100] Fig. 7 illustrates an example-computing environment 700 implementing a container-based computer system 200 and a method 300 as shown in Figs. 2, and 3 for managing resources in an orchestration system 1000. As depicted in Fig. 7, the computing environment 700 comprises at least one data processing module 706 that is equipped with a control module 702 and an Arithmetic Logic Unit (ALU) 704, a plurality of networking devices 708 and a plurality Input output, I / O devices 710, a memory 712, a storage 714. The data processing module 706 may be responsible for implementing the platform and method described in Figs. 2 and 3 respectively. For example, the data processing module 706 in some embodiments be equivalent to the controlling circuitry of the platform described above in conjunction with Figs. 2 and 3. The data processing module 706 is capable of executing software instructions stored in memory 712. The data processing module 706 receives commands from the control module 702 in order to perform its processing. Further, any logical and arithmetic operations involved in the execution of the instructions are computed with the help of the ALU 704.

[0101] The computer program is loadable into the data processing module 706, which may, for example, be comprised in an electronic apparatus (such as the platform). When loaded into the data processing module 706, the computer program may be stored in the memory 712 associated with or comprised in the data processing module 706. According to some embodiments, the computer program may, when loaded into and run by the data processing module 706, cause execution of method steps according to, for example, any of the methods illustrated in Figs. 2 and 3, or otherwise described herein.

[0102] The overall computing environment 700 may be composed of multiple homogeneous and / or heterogeneous cores, multiple CPUs of different kinds, special media and other accelerators. Further, the plurality of data processing modules 1206 may be located on a single chip or over multiple chips.

[0103] The algorithm comprising of instructions and codes required for the implementation are stored in either the memory 712 or the storage 714 or both. At the time of execution, the instructions may be fetched from the corresponding memory 712 and / or storage 714, and executed by the data processing module 706.

[0104] In case of any hardware implementations various networking devices 708 or external I / O devices 710 may be connected to the computing environment to support the implementation through the networking devices 708 and the I / O devices 710.

[0105] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in Fig. 7 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

CLAIMS1. A container-based computer system (200) for managing resources in an orchestration system (1000), the container-based computer system (200) comprising: a data processing unit (204) arranged to execute the instructions stored in a non-transitory computer readable medium (202); an application manager (206) communicatively coupled to the data processing unit (204) and arranged to store computational resource information regarding one or more states in a lifecycle of an application having a plurality of states; a plurality of workloads (302) each having at least one container (304), wherein the at least one container (304) is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application; a scheduler (210) communicatively coupled to the data processing unit (204) and arranged to assign computational resources, wherein the assigning of computational resources comprises: identify for each workload (302) a change in a computational resource requirement of the workload (302) due to a transition from a first to a second state of the states in the lifecycle of the application; identify at least one workload (302-A) from the plurality of workloads (302) having at least one container (304-A) with available computational resource in the second state, wherein the available computational resource is released by the at least one container (304-A) during the transition from the first to the second state; and assign the available computational resource released by the at least one container (304-A) to at least one other container (304-B) in another workload of the plurality of workloads (302-B).

2. The container-based computer system according to claim 1, wherein the at least one other container is a container having an increased computational resource requirement in the second state.

3. The container-based computer system according to any of the preceding claims, wherein the at least one other container is arranged to request for the available computational resource from the at least one container releasing the computational resource during the transition.

4. The container-based computer system according to any of the preceding claims, wherein the scheduler is configured to assign the computational resources during a runtime of the application.

5. The container-based computer system according to any of the preceding claims, wherein the each workload is associated to a specification defining the computational resource requirement associated to the workload and wherein the scheduler is further configured to: determine an updated specification for the at least that workload comprising the container releasing the available computational resource, wherein said updated specification is determined based on the computational resource requirement of the at least one other container of the another workload in in the second state; and resize the at least one workload having the at least one container releasing the available computational resource according to the updated specifications.

6. The container-based computer system according to claims 1 or 3, wherein the scheduler is further configured for: pairing, the at least one workload from the plurality of workloads having the at least one container releasing the available computational resource with the workload having the at least one other container having the increased computational resource requirement.

7. The container-based computer system according to any of the preceding claims, wherein the at least one container (304) of each workload is scheduled at one or more computing nodes (200) in the orchestration system (1000).

8. The container-based computer system according to claim 7 , wherein the available resources released by the at least one workload having the at least one container is assigned to the at least one other container in another workload at a same computing node from the one or more computing nodes.

9. The container-based computer system according to any of the preceding claims, wherein the workload having the at least one container releasing the computational resource and the another workload of the plurality of workloads having the at least one container to which the available computational resource are assigned the second state.

10. The container-based computer system according to any of the preceding claims, wherein the available computational resource released by the least container is assigned to the at least one other container without restarting the plurality of workloads.

11. A computer implemented method (300) performed through a container-based computer system (200) for managing resources in an orchestration system (1000), the method (300) comprising: storing, through an application manager (206) communicatively coupled to a data processing unit (204), computational resource information regarding one or more states in a lifecycle of an application having a plurality of states; assigning, through a scheduler (210) communicatively coupled to the data processing unit (204), computational resources to a plurality of workloads (302) each having at least one container (304), wherein the at least one container (304) is associated to a corresponding computational resource requirement for each state of the one or more states in the lifecycle of the application, wherein the assigning of computational resources comprises: identify for each workload (302) a change in a computational resource requirement of the workload (302) due to a transition from a first to a second state of the states in the lifecycle of the application; identify at least one workload (302-A) from the plurality of workloads (302) having at least one container (304-A) with available computational resource in the second state, wherein the available computational resource isreleased by the at least one container (304-A) during the transition from the first to the second state; and assign the available computational resource released by the at least one container (304-A) to at least one other container (304-B) in another workload of the plurality of workloads (302-B).

12. The method according claim 11, wherein the at least one other container is a container having an increased computational resource requirement in the second state.

13. The method according to any of the claims 11-12, comprising: request, through the at least one other container, the available computational resource from the at least one container releasing the computational resource during the transition.

14. The method according to any of the claims 11-13, comprising: assign, through the scheduler, the computational resources during a runtime of the application.

15. The method according to any of the claims 11-14, comprising: determine through the scheduler, an updated specification for the at least that workload comprising the container releasing the available computational resource, wherein the each workload is associated to a specification defining the computational resource requirement associated to the workload, wherein said updated specification is determined based on the computational resource requirement of the at least one other container of the another workload in in the second state; and resize the at least one workload having the at least one container releasing the available computational resource according to the updated specifications.

16. The method according to claims 11 or 14, further comprising: pairing, through the scheduler, the at least one workload from the plurality of workloads having the at least one container releasing the available computationalresource with the workload having the at least one other container having the increased computational resource requirement.

17. The method according to any of the claims 11-16, wherein the at least one container (304) of each workload is scheduled at one or more computing nodes (200) in the orchestration system (1000).

18. The method according to claim 17, wherein the available resources released by the at least one workload having the at least one container is assigned to the at least one other container in another workload at a same computing node from the one or more computing nodes.

19. The method according to any of the claims 11-18, wherein the workload having the at least one container releasing the computational resource and the another workload of the plurality of workloads having the at least one container to which the available computational resource are assigned the second state.

20. The method according to any of the claims 11-19, wherein the available computational resource released by the least container is assigned to the at least one other container without restarting the plurality of workloads.

Images