Multi-cluster cloning system

Abstract

The invention relates to an orchestrator in a cloud computing environment, configured to: receive, from a manager, cloning instructions to designate (108) resources within an initial working environment, the designated resources defining an initial deployment of a service; receive, from the manager, a constraint associated with the cloning instructions; collect, in real time, information regarding use of individual resources from a plurality of data processing clusters, the information being obtained with a granularity sufficient to allow analysis of the use of each individual resource; and identify (110), taking into account the received cloning instructions, the received constraint and the collected information altogether, target resources in at least one new working environment with a view to cloning the designated resources, thereby enabling a new deployment of the service that complies with the constraint.

Description

Multi-cluster cloning system

[0001] The invention lies in the field of information and communications technologies, and more specifically in the field of telecommunications system architectures based on virtualized functions hosted in a cloud computing environment.

[0002] The state of the art includes systems that use containerization technologies, such as Docker, and container orchestration technologies, such as Kubernetes.

[0003] These systems are designed to deploy applications and services on data processing agglomerations, or "clusters", by distributing them across multiple working environments, or "clouds".

[0004] However, these existing systems do not provide means to replicate configurations of services or applications deployed on one cloud to another.

[0005] Furthermore, they also do not provide a suitable mechanism to reconfigure routing following a topology change that would be induced by such replication. Summary

[0006] The invention aims to improve the situation.

[0007] Thus, according to one aspect, there is provided an orchestrator in a cloud computing environment, configured to:receive from a manager a cloning instruction to designate a resource within an initial communication infrastructure, the designated resource defining an initial deployment of a service,receive from the manager a constraint associated with the cloning instruction,collect information on a use of individual resources from a plurality of data processing agglomerations, the information being obtained with sufficient granularity to allow an analysis of the use of each individual resource, andidentify, taking into account both the received cloning instruction, the received constraint and the collected information, a target resource in at least one new communication infrastructure for cloning the designated resource,thus allowing a new deployment of the service respecting the constraint.,

[0008] The orchestrator's configuration allows efficient management of service cloning based on real-time analysis of available resources, taking into account the provided cloning instructions and constraints. This provides increased flexibility in service deployment, enabling precise and targeted cloning of the necessary resources, thus optimizing resource utilization and compliance with associated constraints.

[0009] There is also provided, according to another aspect, a manager of at least one service in a cloud computing environment, the manager being configured to:detect a trigger event resulting from an application of a service management strategy,define a constraint associated with the trigger event,send, following the detection of the trigger event, a cloning instruction to an orchestrator, the cloning instruction allowing the orchestrator to designate a resource in an initial communication infrastructure, defining an initial deployment of the service, andsend the defined constraint to the orchestrator, the constraint allowing the orchestrator to identify, in at least one new communication infrastructure, a target resource for cloning the designated resource, thus allowing a new deployment of the service respecting the constraint.

[0010] Thus, the manager is able to trigger a cloning process based on specific events and send cloning instructions and constraints to the orchestrator. This enables proactive management of services, providing a rapid and adapted response to changes in their working environment.

[0011] Also provided in another aspect is a cloning system in a cloud computing environment, the system comprising an orchestrator and a manager defined for example as above. The system may further comprise a virtual service configured as a routing device so as to redirect, upon completion of a cloning operation, traffic from an initial deployment of a service to the new deployment of the service, transparently to the orchestrator and the manager.

[0012] The proposed cloning system enables efficient and transparent replication of deployed services. The virtual routing service, in particular, provides a seamless transition between the original and new deployments, minimizing service interruptions. The virtual routing service can also help ensure optimal distribution of requests between different deployments in the case of partial redirection.

[0013] The various aspects thus mentioned participate in a general cloning control structure and each contribute to a dynamic and optimized management of the resources hosting services in the cloud computing environment. Indeed, by triggering cloning according to the specific constraints of each service, taking into account the characteristics of the service to be cloned and the network conditions, and by performing a dynamic update of the routing according to the topology changes, the various aspects mentioned offer a capacity for adaptation and reactivity in the face of variations in demand and network conditions.Thus, when an incident occurs on a service hosted in an initial working environment, the aspects thus mentioned make it possible to trigger and implement the cloning of this service to a new working environment, while taking into account constraints relating, for example, to security and / or quality of service. This makes it possible to ensure continuity of service even in cases, for example, of a failure or a sudden increase in demand for the service in question.

[0014] Also provided is a method for orchestrating resources in a cloud computing environment, the method comprising the following steps implemented by an orchestrator:receiving from a manager a cloning instruction to designate a resource within an initial communication infrastructure, the designated resource defining an initial deployment of a service,receiving from the manager a constraint associated with the cloning instruction,collecting information on a use of individual resources from a plurality of data processing agglomerations, the information being obtained with sufficient granularity to allow an analysis of the use of each individual resource, andidentifying, taking into account both the received cloning instruction, the received constraint and the collected information,a target resource in at least one new communication infrastructure for the purpose of cloning the designated resource, thus enabling a new deployment of the service respecting the constraint.,

[0015] This resource orchestration process provides a systematic and automated method for cloning services, taking into account deployment constraints and real-time resource utilization. This enables better resource management and greater efficiency in service deployment.

[0016] Optionally, the information collected comes from proxies integrated into the data processing agglomerations and associated with resources forming a plurality of candidate communication infrastructures, and the new communication infrastructure is chosen from the plurality of candidate communication infrastructures.

[0017] This helps facilitate the orchestrator's identification of appropriate targets for cloning designated resources and creating the new working environment for the new service deployment. This contributes to optimal resource allocation, thus improving system efficiency and performance.

[0018] There is also provided a method for managing a service in a cloud computing environment, the method comprising the following steps implemented by a manager: detecting a triggering event resulting from an application of a service management strategy, defining a constraint associated with the triggering event, sending, following detection of the triggering event, a cloning instruction to an orchestrator, the cloning instruction allowing the orchestrator to designate a resource in an initial communication infrastructure, defining an initial deployment of the service, and sending the defined constraint to the orchestrator, the constraint allowing the orchestrator to identify, in at least one new communication infrastructure, a target resource for cloning the designated resource, thus allowing a new deployment of the service respecting the constraint.

[0019] This service management process provides a proactive method for cloning and deploying services based on the detection of specific events. This enables a rapid and adaptive response to changes in the working environment, improving service resilience and availability.

[0020] Optionally, the method further comprises the following step implemented by the manager: collecting information provided by the orchestrator on a use of a set of resources including, at least, the resource defining the initial deployment of the service, and in which the detection of the triggering event is based on the information obtained.

[0021] Real-time collection of resource usage information by the manager enables accurate detection of triggering events. This increases the accuracy of service management and responsiveness to changes.

[0022] Optionally, the detection of the triggering event relates to an application of a policy including at least one optimization criterion chosen from load sharing, resilience, security, availability, cost, energy and / or environmental impact.

[0023] The ability to detect a triggering event based on a variety of policies, particularly those mentioned here, provides increased flexibility and adaptability in service management.

[0024] Optionally, the aforementioned methods further comprise the following step implemented by the orchestrator or the manager: transmitting information concerning a topology modification following the cloning to a virtual service configured as a routing device, the transmitted information allowing the virtual service to redirect, at the end of the cloning, traffic from the initial deployment of the service to the new deployment of the service, in a transparent manner for the orchestrator and the manager.

[0025] The information transmitted by the orchestrator or manager allows for transparent redirection of traffic, which helps improve service continuity.

[0026] Also provided is a computer program comprising instructions which, when the program is implemented by a processor, result in one of the aforementioned methods being implemented.

[0027] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analyzing the attached drawings, in which: Fig. 1

[0028] illustrates a resource management and cloning process according to an example implementation. Fig. 2

[0029] represents an initial state of a system comprising two clusters before implementing a cloning process. Fig. 3

[0030] represents an example of the final state of the system after implementing a cloning process, reflecting changes in the clusters. Fig. 4 Fig. 5

[0031] and each represent a different example of the final state of the system after implementing a different cloning process, reflecting different changes in the clusters. Fig. 6 Fig. 7 Fig. 8

[0032] , and schematically illustrate a detailed process for updating a routing following cloning of a service, through different successive states of the clusters concerned, in an example implementation. Fig. 9

[0033] illustrates a series of exchanges between different elements to update a routing at the end of a cloning procedure, according to an example implementation Fig. 10

[0034] illustrates a series of exchanges between different elements to implement a cloning procedure, according to an example of implementation.

[0035] The present disclosure relates to a cloning system that operates in a cloud computing environment, specifically in telecommunications systems. This cloning system provides a means of replicating configurations supporting deployed services.

[0036] In this document, the term "service" is used broadly to encompass a service itself, one or more microservices, or even a complete application. An "application" is a set of software functionalities that address a specific need. An application may be composed of one or more services or microservices that work together to provide the overall functionality. It should be noted that the distinction between a "service" and a "microservice" is primarily based on the scale and functional division of an application's software architecture. A service is a self-contained functional unit that can cover a broad set of functionalities and can either form part of a larger application or be used by multiple applications. A microservice is smaller and is usually responsible for a specific functionality of an application.

[0037] It is important to note that the cloning system described here concerns the duplication and transfer of both "content" and "container". On the one hand, with respect to the "content", the cloning system can be configured to copy a running software, application, service or microservice into an initial resource. For example, specific microservices or Point of Delivery (POD) configurations can thus be cloned from an initial working environment to a new working environment. On the other hand, with respect to the "container", the cloning system can be configured to prepare a target communication infrastructure to receive the cloned content. For example, in order to clone a resource from one location to another, the necessary infrastructure regarding data processing and storage can be replicated to accommodate the cloned content.

[0038] The term "communications infrastructure," as used in this document, refers to the physical and software support that enables communication and the sharing of resources and services. This infrastructure may include data processing and storage systems, servers and networks, data centers, cloud systems, telecommunications equipment, etc. It may refer to the communications infrastructure within a specific organization, such as an internal network of computers and servers, or to a broader infrastructure, such as a telecommunications network or the cloud.

[0039] The cloning system can be configured to efficiently handle both aspects of cloning—both content and container—making it particularly relevant for operators and enterprises looking to improve the efficiency and security of their applications in container and microservices environments.

[0040] The cloning system includes an orchestrator and a manager.

[0041] The orchestrator, in the cloud computing environment, is designed to receive from the manager one or more cloning instructions, possibly serialized. The interpretation of this or these instructions by the orchestrator allows it to designate one or more resources defining an initial deployment of a service within an initial communication infrastructure (or initial working environment). In addition, the orchestrator receives from the manager a constraint associated with this or these cloning instructions.

[0042] The orchestrator is also capable of collecting one or more pieces of information about the use of individual resources from various data processing agglomerations. This or these pieces of information are obtained with sufficient granularity to allow a detailed analysis of the use of each individual resource.

[0043] Collecting information about resource usage in the communications infrastructure can be done in a variety of ways, depending on the specific context. It can be done in real time, meaning that information is collected and analyzed as it is generated. This method allows for rapid response to changes in resource usage and can be useful for real-time resource management. Alternatively, a dynamic approach to information collection can be adopted. In this context, dynamic refers to the ability to adapt to changes in the cloning system or communications infrastructure, by modifying the frequency or type of information collected depending on the circumstances.For example, the orchestrator can be configured to collect information more frequently when an increase in resource usage is detected, or to collect specific types of information in response to certain events or conditions. Finally, information collection can also be done in response to a notification. In this case, the orchestrator is configured to collect information when certain conditions are met, or when certain notifications are received. For example, a notification can be issued when a resource's usage reaches a certain threshold, triggering the orchestrator to collect information. These information collection methods are not mutually exclusive and can be used in conjunction.

[0044] Taking into account the cloning instruction(s), the received constraint, and the gathered information(s), the orchestrator can then identify one or more target resources in at least one new communication infrastructure. This enables cloning of the designated resource(s), thereby facilitating a new deployment of the service that meets the specified constraint.

[0045] The manager plays a key role in triggering the cloning process. It is able to detect a triggering event resulting from the application of a service management strategy. Such a management strategy can aim to optimize or co-optimize different criteria such as load sharing, resilience, security, cost management, energy management, environmental impact, etc. Following the detection of this event, the manager defines a constraint associated with the event and sends cloning instructions to the orchestrator.

[0046] These instructions allow the orchestrator to designate resources in the initial working environment, thus defining an initial deployment of the service. The manager also sends the defined constraint to the orchestrator, which allows the latter to identify, in at least one new working environment, target resources for cloning.

[0047] The cloning system may also include a virtual service configured as a routing device. Upon completion of a cloning operation, this service redirects traffic from an initial deployment of a service to a new deployment of the service, transparently for the orchestrator and the manager. This allows for a smooth and efficient transition between the initial deployment and the new deployment, thus contributing to service continuity.

[0048] In summary, the proposed cloning system provides an efficient solution for replicating the configurations required for services and applications deployed in a distributed cloud computing environment. It enables fine-grained and coordinated resource management, agile response to trigger events, and seamless transition to new service and application deployments. It addresses the challenges of resource distribution, reconfiguration, and redundancy.

[0049] In cloud resource management, distributing services, applications, and data across different computing environments is a major challenge, especially when these resources come from different providers. Until now, the lack of a suitable cloning system complicated resource distribution, reconfiguration, and redundancy operations. The proposed cloning system solves this technical problem by providing an efficient solution for configuring services and applications deployed in a distributed environment.

[0050] In addition to facilitating configuration replication, the cloning system also addresses other important needs. It provides simplified and secure access to functions and microservices, enabling the replication of data access logic and associated security management. This is extremely beneficial for operators and enterprises looking to improve the efficiency and security of their applications and services in container and microservice environments.

[0051] The cloning system can be applied in a wide variety of environments, including the management of distributed computing systems, the deployment of radio access networks in telecommunications systems, and the deployment of distributed configurations across multiple sites, with multiple actors and zones, and possibly replicas distributed across multiple data centers, such configurations being likely to support varied functional sets.

[0052] Regardless of the specific working environment of a given service to be cloned – whether it is a single node, a set of servers, a specific geographic area or an IP subnet – the cloning system is designed to adapt to these different contexts.

[0053] Before proceeding further in describing the invention, it is important to clarify some terms specific to cloud computing environments.

[0054] In these environments, the basic hosting unit is often called a "container." These containers are lightweight software units that encapsulate the code and all its dependencies, allowing an application to run reliably from one computing environment to another.

[0055] To manage these containers, a solution called Kubernetes, K8S, is frequently used. Kubernetes is a system that facilitates the deployment, scaling, and management of containerized applications.

[0056] In the Kubernetes architecture, containers are grouped into "pods," which are the basic unit representing an application deployment. Multiple pods can be grouped into a "node," which symbolizes a server. These nodes are then grouped into "clusters," which are sets of servers that work together and can be thought of as a single system.

[0057] In the context of Kubernetes, a cluster consists of a group of "Masters" and Nodes. Masters are the components of the Kubernetes cluster that provide the control interface for the cluster, and manage pod scheduling, failure detection and management, and deployment of new versions of applications. Nodes, on the other hand, are the servers that run applications and provide the runtime environment for containers.

[0058] To manage network communications between containers in an application deployed on a Kubernetes cluster, auxiliary containers, known as sidecar proxies, are attached to each of the application's main containers. Sidecar proxies are responsible for intercepting and managing network communications. Each sidecar proxy acts as an intermediary between the main container it is attached to and the rest of the network. To enhance security, sidecar proxies can include functions such as request and response validation, authorization and identity management, and monitoring and alerting on anomalies.

[0059] ISTIO is an example of a commonly used, open-source service mesh that provides a uniform way to connect, manage, and secure microservices using sidecar proxies.

[0060] We will now describe a particular embodiment of the cloning system in the context of a Kubernetes platform. It goes without saying that a person skilled in the art is capable of transposing the implementations described in this document to the context of any other container management platform. Regardless of the platform used, the operations implemented by the cloning system make it possible to facilitate the management and coordination of resources between different computing environments.

[0061] In the following description, like reference numerals designate identical elements or elements having similar functions.

[0062] In the context of the cloning process described here, it is important to emphasize that two modes of triggering cloning are considered: the “orchestrator” mode and the “proxy” mode.

[0063] The main difference between the "orchestrator" mode and the "proxy" mode lies in the way the cloning is triggered and the dynamics of reaction to the state of the resources.

[0064] In the "orchestrator" mode, cloning initiation is primarily controlled by a central orchestrator based on user preferences and policy rules defined by the telecom operator. These preferences and rules are defined in advance, and the orchestrator uses this information to manage resources and trigger the cloning process. Actions are therefore largely predetermined and depend on the planning and strategy defined by the operator's rules.

[0065] This mode provides particularly predictable resource management, as actions are based on established rules and preferences. It is best suited for stable environments where resource demands are predictable and operator policy is well-defined.

[0066] In proxy mode, the cloning process is triggered in response to internal node events, which may be related to reaching or exceeding a predetermined resource utilization threshold. Thus, cloning is triggered more dynamically, in response to the actual resource status. Sidecar proxies play an active role in detecting events and passing information to the orchestrator.

[0067] This mode provides more dynamic and responsive resource management, as actions are based on the current state of resources and defined thresholds.

[0068] It is more suitable for dynamic and uncertain environments, where resource usage can vary rapidly or unpredictably.

[0069] It is important to note that the choice between orchestrator and proxy mode will depend on the specific environment, operator requirements, and workload characteristics. In some cases, a combination of both modes can be used to take advantage of the benefits of each.

[0070] Illustrates a resource management and cloning process using the “orchestrator” mode.

[0071] User preferences and telecom operator policy rules are established at block (102) by Business Support Systems / Operations Support Systems (BSS / OSS). Such computer systems are used by telecom operators to manage their networks. The telecom operator policy may relate to various aspects, including load sharing and / or resilience.

[0072] In the "orchestrator" mode, the manager can apply the preferences and / or rules established in the block (102) by sending service requests, i.e. instructions, to the orchestrator which executes them and thus triggers a cloning process.

[0073] In block (104), the available resources are checked. This action is performed by a platform, called "Cloud Gateway", CG, in English, which facilitates secure access to cloud services and by the orchestrator, as a system that manages the execution and interaction between tasks and services.

[0074] At block (106), the orchestrator determines whether or not the available resources allow the received service requests to be applied. If not, due to a lack of available resources as revealed at block (104), no cloning is implemented.

[0075] When sufficient resources are available to allow the service requests to be applied, the resources to be cloned are identified at block (108). These can be entire clusters, worker nodes, pods, applications, etc.

[0076] At block (110), destination resources are identified. The destination resources are intended to host clones of the resources identified at block (108).

[0077] These resources are likely to include nodes performing various processing tasks, called “Processing Node”, PN, nodes performing more specifically processing tasks related to the operation of the network, called “Network Processing Node”, NPN, in English, as well as terminals or user equipment, called “User Equipment”, UE, in English.

[0078] At block (112), cloning is performed and at block (114), the service routing information is updated. These last two tasks can be implemented by Kubernetes or by ISTIO. Regardless of the trigger mode chosen, cloning simplifies and secures access to the functions or microservices forming a given application or a given service, by reproducing the data access logic and the associated security.

[0079] In proxy mode, sidecar proxies play a crucial role in triggering a cloning operation. Unlike orchestrator mode, which triggers cloning based on predetermined instructions, proxy mode dynamically responds to the internal conditions of each node. Thus, cloning triggered through proxy mode allows for greater adaptability and responsiveness to internal node conditions.

[0080] To clarify, resource usage thresholds are set for each node, taking into account various factors such as the number of requests per second, request size, power consumption, and RAM usage. When one of these thresholds is reached or exceeded, an event is triggered at the affected container level.

[0081] Information from this event can then be passed to the orchestrator by the container's sidecar proxy. This can also be relayed to the manager. The orchestrator and / or manager then use these events to determine the appropriate actions to take, potentially including a cloning process similar to that of the "orchestrator" mode as reflected in blocks (108) to (114) of the. Here, so-called "source" sidecar proxies play a dual role: they detect events at the source nodes and can request the orchestrator to trigger the cloning. The source sidecar proxies can also trigger the cloning themselves and then inform the orchestrator.

[0082] Upon receiving the information from the source sidecar proxies, the orchestrator can then designate destination resources either itself or following a dialogue with another orchestrator or with other so-called "destination" sidecar proxies, which are associated with the resources that will host the clones of the services and / or configurations. The cloning is then performed and the service routing information is updated in the same way as indicated in blocks (112) and (114) of the. To facilitate communication during this process, new communication channels are set up, for example by the orchestrator, between the source and destination sidecar proxies, as well as between the source sidecar proxies and the masters associated with the destination resources.The orchestrator acts as a pivot in this complex network, associating each source and destination sidecar proxy with a group of identified resources hosting the services or applications to be cloned. This association can notably rely on the use of decentralized identifiers, known as "Decentralized IDs" (DIDs).

[0083] Schematically illustrates two Kubernetes clusters (200, 300).

[0084] Each cluster is composed of a group of Masters and several nodes.

[0085] The Masters group forms a control plan responsible for the management and coordination of the different elements of the cluster.

[0086] Specifically, the control plane includes controllers that are responsible for monitoring the cluster's state and performing actions to maintain, or achieve, the desired state. For example, there are controllers to manage deployments, services, replicas, and more. A controller manager is responsible for executing these controllers.

[0087] Other components of the control plane play specific roles.

[0088] An API Server is intended to expose the Kubernetes API and serves as the main entry point for interacting with the cluster. A Load Balancer helps distribute the load of incoming traffic to different services by distributing traffic between cluster nodes or between pods running on different nodes. A Scheduler is responsible for assigning pods to cluster nodes based on defined resource requirements, constraints, and policies. A database called ETCD stores the real-time state of the Kubernetes cluster, including information about nodes, pods, services, configurations, etc. It makes this information readable and writable by all cluster components in real-time.

[0089] It is considered that at a given instant, the entire control plane of a given cluster (200, 300), or at least one of its components, such as the control module manager, a specific control module, the API server, the load balancer, or the scheduler, plays the role of an orchestrator (202, 302) implementing a cloning procedure.

[0090] Each cluster also has several nodes (210, 220, 230, 310, 320, 330) which themselves contain pods. Each pod corresponds to an application deployment, represented by a cube. Some pods of interest, corresponding to specific application deployments, are also represented with sidecar proxies.

[0091] The represents a final state of one of the clusters (200) of the at the end of a cloning procedure of a pod, in an exemplary embodiment. The orchestrator (202) first identified a first pod (212) located in a first node (210) of the cluster (200) as the original resource. The orchestrator then designated a second pod (222) located in a second node (220) of this same cluster (200) as the destination resource. After this, the cloning procedure was implemented, replicating the first pod (212) in the second pod (222).

[0092] The represents another final state of one of the clusters (200) of the at the end of a cloning procedure of a node, in another exemplary embodiment. The orchestrator (202) first identified a first node (220) of the cluster (200) as the origin resource. The orchestrator then designated a second node (230) of this same cluster (200) as the destination resource. After this, the cloning procedure was implemented, replicating the pods of the first node (220) in the second node (230).

[0093] The represents another final state of the clusters (200, 300) of the at the end of a cloning procedure of a pod and a node, in another exemplary embodiment. The orchestrator (202) located in a first cluster (200) has first identified, in the first cluster (200), a first pod (212) to be cloned, as well as a first node to be cloned (210), this first pod (212) and this first node (210) constituting a set of original resources. It can be assumed here that the orchestrator (202) was not able to identify destination resources in the first cluster for a cause related to any internal event of the first cluster and / or to respect an external constraint. The orchestrator (202) then instead communicated with another orchestrator (302) located in a second cluster (300) to successfully identify, in the second cluster, a second node (330) and a second pod (322) as the destination resource set.After that, the cloning procedure was implemented, replicating the first node (210) into the second node (330) and the first pod (212) into the second pod (322).

[0094] Schematically depicts the routing of a request to a specific service (406) associated with a given application (408) in a cluster environment (400) that is part of an ISTIO-based mesh environment. In this framework, the cluster (400) includes a sidecar proxy (404) and a namespace (402) that encapsulates the specific service (406) and the given application (408). The sidecar proxy (404) serves as an intermediary, facilitating the forwarding of incoming requests to the target service.

[0095] It should be noted that using an ISTIO-based mesh environment for this process is not a requirement, but rather a preferred option due to its ability to facilitate routing and failover between different services and clusters. Other mesh environments could also be used, provided they have the necessary capabilities to perform the steps described below.

[0096] In the context of an operation to move this specific service (406) to another cluster while ensuring service continuity, several steps are illustrated from there to there.

[0097] An intermediate step of this operation is illustrated where the specific service (406) is duplicated in a new destination cluster (500). The destination cluster (500) also includes a sidecar proxy (504) and a namespace (502) that contains the clone of the specific service (506). A virtual service (410) is created in the original cluster (400) and acts as a mini-router. Two destination rules (412, 512), one in the original cluster and one in the destination cluster, are established and configured in the virtual service (410) with respective weights of 100% and 0%.

[0098] At this point, the virtual service (410) directs all incoming requests only to the original service (412) in the original cluster (400), leaving the new service (512) in the destination cluster (500) waiting to receive traffic.

[0099] Illustrates the final stage of service migration. At this point, the weights previously defined in the virtual service (410) are reversed, i.e., the destination rule (412) in the original cluster now has a weight of 0%, while the destination rule (512) in the destination cluster has a weight of 100%.

[0100] This means that all incoming requests are now routed to the cloned service (506) in the destination cluster (500). This failover process can be performed in a controlled and reversible manner if necessary, thus ensuring a high level of reliability and security.

[0101] Finally, once the original service (406) is no longer needed, it can be safely deleted, along with its corresponding destination rule (412), leaving only the cloned service (506) in the destination cluster (500). The virtual service (410) remains operational as a mini-router, ready for future service migration operations.

[0102] Illustrates in detail the interactions between an end user, the virtual service (410), the destination rules (412, 512) and services A (406) and B (506) in the context of a routing update. The numbers associated with each arrow indicate the sequential order of the exchanges. The interactions described allow for efficient redirection of traffic between the different services, illustrating the flexibility and control offered by the invention.

[0103] In the context of a first exchange occurring in a situation corresponding to the, an incoming request (602) is initiated by the end user and addressed to the virtual service (410) in the originating cluster (400). The virtual service, through the active destination rule (412) and according to the currently defined weights, routes this request (604) then (606) to the originating service (406) located in the same cluster (400). The originating service (406) then responds (608) to the request and sends this response to the end user.

[0104] The weight change (610) is then issued by the end user to the virtual service (410). This adjustment is necessary to initiate the transition of request routing from the original service (406) to the cloned service (506).

[0105] A second exchange occurring in a situation corresponding to la highlights the effect of this weight change. A new incoming request (612) from the end user is routed to the virtual service (410). This time, given the readjusted weights, the request is redirected (614) to the destination rule (512) in the destination cluster (500), which then routes the request (616) to the cloned service (506). The cloned service (506) responds (618) to the request and returns this response to the end user.

[0106] Illustrates a series of exchanges between control planes, nodes, and sidecar proxies involved in implementing a resource cloning procedure from an origin node (210) to a destination node (330), as illustrated in, in an example implementation.

[0107] A first exchange illustrates the sending of an initial request (702) from the orchestrator (202) located in the origin cluster (200) to the orchestrator (302) located in the destination cluster (300). After receiving the request, the orchestrator in the destination cluster sends a confirmation (ACK) of receipt (704) to the orchestrator in the origin cluster. This first exchange triggers the actual cloning process.

[0108] In a second exchange, the originating node (210) is cloned (706) into the destination node (330). The latter then sends a confirmation (ACK) of successful cloning (708) to the originating node.

[0109] In a third exchange, the destination cluster orchestrator verifies the success of the cloning (710) by sending a request to the origin cluster orchestrator. In response, the origin cluster orchestrator sends an ACK of the cloning success (712) to the destination cluster orchestrator.

[0110] Finally, a test message (714) is sent from a sidecar proxy located in a pod on the original node (210) to a sidecar proxy located in a pod on the cloned node (330). This indicates that the cloning process completed successfully and the two affected pods can now communicate.

[0111] It thus illustrates a practical implementation of a cloning procedure in which a continuous dialogue between the elements involved ensures a precise and controlled implementation of the cloning.

[0112] Although the present invention has been described in detail with reference to certain preferred embodiments, various modifications and variations may be made without departing from the scope of the invention as defined in the appended claims. For example, the described procedures may be performed in a different order, elements may be added or deleted, and features of different embodiments may be combined as appropriate.

[0113] Furthermore, although aspects of the invention may be described as a process, device, system, procedure, or method, it is noted that the invention may also cover computer memory in the form of a computer-readable medium having encoded program instructions, which, when executed by a computer, enable the processes, devices, systems, procedures, or methods described herein to be carried out.

Claims

An orchestrator (202, 302) in a cloud computing environment, configured to:receive from a manager a cloning instruction to designate (108) a resource (210, 212, 220, 406) within an initial communication infrastructure, the designated resource defining an initial deployment of a service,receive from the manager a constraint associated with the cloning instruction,collect information on a usage of individual resources from a plurality of data processing agglomerations (200, 300, 400, 500), the information being obtained with sufficient granularity to allow an analysis of the usage of each individual resource, andidentify (110), taking into account both the received cloning instruction, the received constraint and the collected information, a target resource (222, 230, 322, 330, 506) in at least one new communication infrastructure in view of a cloning of the designated resource,thus allowing a new deployment of the service respecting the constraint., A manager of at least one service in a cloud computing environment, the manager being configured to:detect a trigger event resulting from an application of a service management strategy,define a constraint associated with the trigger event,send, following detection of the trigger event, a cloning instruction to an orchestrator (202, 302), the cloning instruction allowing the orchestrator to designate (108) a resource (210, 212, 220, 406) in an initial communication infrastructure, defining an initial deployment of the service, andsend the defined constraint to the orchestrator, the constraint allowing the orchestrator to identify (110), in at least one new communication infrastructure, a target resource (222, 230, 322, 330, 506) for cloning the designated resource, thus allowing a new deployment of the service respecting the constraint. A cloning system in a cloud computing environment, the system comprising an orchestrator (202, 302) according to claim 1 and a manager according to claim 2. The cloning system of claim 3, further comprising a virtual service (410) configured as a routing device to redirect, upon completion of a cloning operation, traffic from the initial deployment of a service (406) to the new deployment of the service (506), transparently to the orchestrator and the manager. A method of orchestrating resources in a cloud computing environment, the method comprising the following steps implemented by an orchestrator (202, 302):receiving from a manager a cloning instruction (108) to designate a resource (210, 212, 220, 406) within an initial communication infrastructure, the designated resource defining an initial deployment of a service,receiving from the manager a constraint associated with the cloning instruction,collecting information on a use of individual resources from a plurality of data processing agglomerations (200, 300, 400, 500), the information being obtained with sufficient granularity to allow an analysis of the use of each individual resource, andidentifying (110), taking into account both the received cloning instruction, the received constraint and the collected information, a target resource (222, 230, 322, 330,506) in at least one new communication infrastructure with a view to cloning the designated resource, thus enabling a new deployment of the service respecting the constraint., The method of claim 5, wherein the collected information comes from proxies (404, 504) integrated into the data processing agglomerations and associated with resources forming a plurality of candidate communication infrastructures, and the new communication infrastructure is chosen from the plurality of candidate communication infrastructures. A method for managing a service in a cloud computing environment, the method comprising the following steps implemented by a manager: detecting a triggering event resulting from an application of a service management strategy, defining a constraint associated with the triggering event, sending, following detection of the triggering event, a cloning instruction to an orchestrator (202, 302), the cloning instruction allowing the orchestrator to designate (108) a resource (210, 212, 220, 406) in an initial communication infrastructure, defining an initial deployment of the service, and sending the defined constraint to the orchestrator, the constraint allowing the orchestrator to identify (110), in at least one new communication infrastructure, a target resource (222, 230, 322, 330, 506) for cloning the designated resource, thus allowing a new deployment of the service respecting the constraint. The method of claim 7, further comprising the following step implemented by the manager: collecting information provided by the orchestrator (202, 302) on a use of a set of resources including, at least, the resource defining the initial deployment of the service, and wherein the detection of the triggering event is based on the information obtained. Method according to claim 7 or 8, wherein the detection of the triggering event relates to an application of a policy including at least one optimization criterion chosen from load sharing, resilience, security, availability, cost, energy and / or environmental impact. Method according to one of claims 5 to 9, further comprising the following step implemented by the orchestrator (202, 302) or the manager: transmitting information concerning a topology modification following the cloning to a virtual service (410) configured as a routing device, the transmitted information allowing the virtual service to redirect, at the end of the cloning, traffic from the initial deployment of the service to the new deployment of the service (506), in a transparent manner for the orchestrator and the manager. Computer program comprising instructions which, when the program is implemented by a processor, lead to implementing the method according to one of claims 5 to 10.

Images