Multi-cluster cloning system

Abstract

An orchestrator in a cloud computing environment, configured to: receive cloning instructions from a manager 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 on the 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, and identify (110), taking into account both the cloning instructions received, the constraint received and the information collected, target resources in at least one new working environment for cloning the designated resources, thus allowing a new deployment of the service respecting the constraint.Figure from the summary: Figure 1.

Description

Title of the invention: Multi-cluster cloning system Technical field

[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. Prior art

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

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

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

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

[0006] The invention aims to improve the situation.

[0007] According to one aspect, there is thus proposed 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, 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, and identify, 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 with a view to cloning the designated resource, thus enabling a new deployment of the service respecting the constraint.

[0008] By virtue of its configuration, the orchestrator makes it possible to efficiently manage the cloning of services based on a real-time analysis of the available resources, and taking into account the cloning instructions and constraints provided. This provides increased flexibility in service deployment, enabling precise and targeted cloning of the required resources, thereby optimizing resource utilization and compliance with associated constraints.

[0009] Also provided, according to another aspect, is 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, 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 send 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 allows 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 deployment and the new deployment, thus minimizing service interruptions. The virtual routing service can also contribute, in the case where the redirection is partial, to ensuring optimal distribution of requests between the different deployments.

[0013] The various aspects thus mentioned participate in a general cloning control structure and each contribute to dynamic and optimized management of the resources hosting services in the cloud computing environment. Indeed, thanks to the triggering of 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 performing a dynamic update of the routing according to changes in topology, the various aspects mentioned provide 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 of orchestrating resources in a cloud computing environment, the method comprising the following steps implemented by an orchestrator: 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, 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, and identify, taking into account both the cloning instruction received, the constraint received and the information collected, a target resource 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.

[0015] This resource orchestration method provides a systematic and automated method for cloning services, which takes into account deployment constraints and real-time resource utilization. This allows for 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 thus helps to facilitate the identification by the orchestrator of appropriate targets for cloning the designated resources and creating the new working environment for the new deployment of the service. This contributes to an optimal distribution of resources, thus improving the efficiency and performance of the system.

[0018] Also provided is a method of managing a service in a cloud computing environment, the method comprising the following steps performed by a manager: 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, the cloning instruction allowing the orchestrator to designate a resource in an initial communication infrastructure, defining an initial deployment of the service, and send 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 method provides a proactive method for cloning and deploying services based on the detection of specific events. This allows for a rapid and adaptive response to changes in the working environment, improving the resilience and availability of services.

[0020] Optionally, the method further comprises the following step implemented by the manager: collect information provided by the orchestrator on the 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 herein, provides increased flexibility and adaptability in service management.

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

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

[0026] Also provided is a computer program comprising instructions which, when the program is implemented by a processor, lead to the implementation of one of the aforementioned methods. Brief description of the drawings

[0027] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l

[0028] [Fig.l] illustrates a resource management and cloning process according to an exemplary embodiment. Fig. 2

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

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

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

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

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

[0034] [Fig. 10] illustrates a series of exchanges between different elements to implement a cloning procedure, according to an exemplary embodiment. Description of the embodiments

[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 understood to mean 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 breakdown 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 generally responsible for a specific functionality of an application.

[0037] It is important to note that the cloning system described herein relates to the duplication and transfer of both "content" and "container". On the one hand, with respect to the "content", the cloning system may be configured to copy software, an application, a service or a microservice running in an initial resource. For example, specific microservices or Point of Delivery (POD) configurations may 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 may 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 data processing and storage infrastructure may be replicated to accommodate the cloned content.

[0038] The term "communications infrastructure", as used herein, 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 also relate to the communications infrastructure within an organization specific, such as an internal network of computers and servers, or 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 seeking to improve the efficiency and security of their applications in container and microservices environments.

[0040] The cloning system notably comprises 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 on 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] Gathering information about resource usage in the communication infrastructure can be done in various ways, depending on the specificity of the context. It can be done in real time, meaning that information is collected and analyzed as it is generated. This method allows for rapid reaction to changes in resource usage and can be useful for real-time resource management. Alternatively, a dynamic approach to information gathering can be adopted. In this context, dynamic refers to the ability to adapt to changes in the cloning system or communication 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 usage reaches a certain threshold, triggering the orchestrator to collect information. These methods of information collection are not mutually exclusive and can be used . jointly.

[0044] Taking into account the cloning instruction(s), the received constraint, and the information(s) collected, the orchestrator can then identify one or more target resources in at least one new communication infrastructure. This allows 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 capable of detecting a triggering event resulting from the application of a service management strategy. Such a management strategy may aim to optimize or co-optimize different criteria such as load sharing, resilience, security, cost management, energy management, environmental impact management, 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, thereby 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, thereby 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 the replication of configurations, the cloning system responds also 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 capable of supporting 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 geographical area or an IP subnet - the cloning system is designed to adapt to these different contexts.

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

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

[0055] For the management of 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 a deployment of an application. 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 the applications and provide the runtime environment for the containers.

[0058] To manage network communications between the containers of an application deployed on a Kubernetes cluster, auxiliary containers, called “sidecar proxies” are attached to each application's main container. 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 Kubemetes platform. It goes without saying that a person skilled in the art is capable of transposing the embodiments set out in this document into 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, identical 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 envisaged: the “orchestrator” mode and the “proxy” mode.

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

[0064] In the "orchestrator" mode, the triggering of cloning is mainly 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. The 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 to 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 events internal to the nodes, which may be related to reaching or exceeding a predetermined threshold in terms of resource usage. Thus, cloning is triggered more dynamically, in response to the actual state of the resources. Sidecar proxies play an active role in detecting events and passing information to the orchestrator.

[0067] This mode provides more dynamic and reactive 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 utilization may vary rapidly or unpredictably.

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

[0070] [Fig.l] illustrates a resource management and cloning process according to the “orchestrator” mode.

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

[0072] In the “orchestrator” mode, the manager can apply the preferences and / or rules established at 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 which 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 disclosed at block (104), no cloning is implemented.

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

[0076] At block (110), destination resources are identified. The destination resources are intended to host the 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 particularly processing tasks linked to the operation of the network, called “Network Processing Node”, NPN, in English, as well as terminals or user equipment, called “User Equipment”, EU, in English.

[0078] In block (112), cloning is performed and in block (114), the service routing information is updated. These last two tasks can be implemented by Kubemetes or by ISTIO. Regardless of the triggering mode chosen, cloning makes it possible to simplify and secure 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 the “proxy” mode, sidecar proxies play a crucial role in triggering a cloning operation. Unlike the “orchestrator” mode, which triggers cloning based on predetermined instructions, the “proxy” mode dynamically responds to the internal conditions of each node. Thus, cloning triggered through the “proxy” mode allows for better adaptability and responsiveness to the internal conditions of the nodes.

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

[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 [Fig.l]. 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 [Fig.l]. 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 serves 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 concerned by the cloning. This association may notably be based on the use of decentralized identifiers, known as “Decentralized IDs”, DIDs, in English.

[0083] [Fig.2] schematically illustrates two Kubernetes clusters (200, 300).

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

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

[0086] In particular, the control plane includes control modules (“Controllers”) responsible for monitoring the state of the cluster and performing actions to maintain, or achieve, the desired state. For example, there are control modules for managing deployments, services, replicas, among others. A control module manager (“Controller Manager”) is responsible for executing these control modules.

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

[0088] An API Server is provided to expose the Kubernetes API and serves as the main entry point for interacting with the cluster. A Load Balancer is used to 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 state of the Kubernetes cluster in real time, 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 the deployment of an application, represented by a cube. Some pods of interest, corresponding to specific application deployments, are also represented with sidecar proxies.

[0091] [Fig.3] represents a final state of one of the clusters (200) of [Fig.2] at the end of a cloning procedure of a pod, in an exemplary embodiment. The orchestrator (202) has 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 that same cluster (200) as the destination resource. After that, the cloning procedure was implemented, replicating the first pod (212) into the second pod (222).

[0092] [Fig.4] represents another final state of one of the clusters (200) of [Fig.2] 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 original 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] [Fig. 5] represents another final state of the clusters (200, 300) of [Fig. 2] 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 comply with 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] [Fig.6] schematically shows 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 transfer 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 necessity, 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 aimed at moving this specific service (406) to a another cluster while ensuring continuity of service, several steps are illustrated from [Fig.6] to [Fig.8].

[0097] [Fig.7] illustrates an intermediate step of this operation 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 the traffic.

[0099] [Fig.8] illustrates the final stage of service migration. At this stage, 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] [Fig.9] illustrates in detail the interactions between an end user, the virtual service (410), destination rules (412, 512), and services A (406) and B (506) as part 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 [Fig.7], 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 change in weights (610) is then issued by the end user to the virtual service (410). This adjustment is necessary to initiate the transition of the routing of requests from the original service (406) to the cloned service (506).

[0105] A second exchange occurring in a situation corresponding to [Fig.8] 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, taking into account 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] [Fig. 10] 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 [Fig.5], in an example implementation.

[0107] A first exchange illustrates the transmission 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 orchestrator of the destination cluster verifies the success of the cloning (710) by sending a request to the orchestrator of the originating cluster. In response, the latter sends a confirmation (ACK) of the success of the cloning (712) to the orchestrator of the destination cluster.

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

[0111] [Fig. 10] 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 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 disclosures. attached instructions. For example, the procedures described may be performed in a different order, elements may be added or deleted, and features of different embodiments may be combined as appropriate.

[0113] Further, although aspects of the invention may be described as a process, device, system, procedure, or method, it is appreciated 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

Claims

1. 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 communications 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, and identify (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.,

2. Manager of at least one service in a cloud computing environment, the manager being configured to: detect a triggering event resulting from an application of a service management strategy, define a constraint associated with the triggering event, send, 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 send 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.

3. 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.

4. The cloning system of claim 3, further comprising a virtual service (410) configured as a routing device so as 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.

5. 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, and identifying (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.,

6. Method according to claim 5, in which the information collected comes from proxies (404, 504) integrated in 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.

7. A method of 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.

8. 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 in which the detection of the triggering event is based on the information obtained.

9. Method according to claim 7 or 8, in which 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.

10. 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.

11. A 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