Method for deploying a service in a distributed environment

Abstract

The invention relates to a method for deploying a service in a distributed environment, comprising deploying a plurality of software components of the service in a plurality of virtualisation units. The method, which is implemented within a management node, comprises: - instantiating (E1), within the virtualisation units, monitoring components configured to output metrics associated with the virtualisation units and / or with the deployed software components; - recording (E2), within a configuration file, interconnection data relating to interconnections between some of the software components, associating at least one identifier of one virtualisation unit and at least one identifier of another virtualisation unit; - instantiating (E3), within the management node, a control loop for implementing, in an operating phase of said service, iterations for checking compliance with predefined technical criteria, as a function of the metrics and the interconnection data.

Description

A process of deploying a service in a distributed environment.

[0001] The invention lies in the field of automated deployment of services on a set of computing resources. More particularly, the present invention relates to automated deployment techniques in a distributed environment, which make it possible to continuously guarantee compliance with predefined technical specifications during operation of the service, in order to ensure its nominal operation. Prior art

[0002] Many communication networks use virtualized functions instantiated on virtualization nodes hosted in virtual machines or in servers grouped into clusters, or "clusters" within data centers. In the remainder of the document, reference is made to virtualization nodes hosted in servers, but it is understood that the teaching of this document also applies to the case of virtualization nodes hosted in virtual machines.

[0003] An example of managing the instantiation of virtualized functions is known as "Kubernetes". A Kubernetes architecture comprises at least one cluster of virtualization nodes. Such a cluster of virtualization nodes comprises at least a first node called a management node, or "Kubernetes master node", and a plurality of computing nodes, or "Kubernetesworkernode" intended to instantiate virtualized functions.

[0004] The management node includes, among other things, a database called ETCD which consists of a dynamic configuration register of the computing nodes.

[0005] A compute node comprises a plurality of virtualization units or "pods." Each virtualization unit is provided with resources to execute one or more software components. A software component, when executed, contributes to the implementation of a virtualized service or function.

[0006] The ETCD database embedded in the management node stores in reference files a list of virtualization units to be instantiated as well as parameters to be taken into account when instantiating a service or virtualized functions.

[0007] The management node regularly reads the contents of these files, compares them with the virtualization units being instantiated and adds or removes virtualization units in order to adapt their quantity to that indicated in these reference files.

[0008] Since the ETCD database is also accessible by a virtualization node deployment entity, the latter regularly reads the contents of these files, compares the capacity of the deployed virtualization nodes with the capacity required by the virtualization units being instantiated and adds or removes virtualization nodes in order to adapt their quantity to needs.

[0009] Deploying a virtualization node on a computer server involves, for example, downloading a file containing an operating system and a set of applications necessary for deploying the virtualization node to a computer server, then starting the computer server using the downloaded file.

[0010] It is also possible to deploy multiple virtualization nodes on a single computer server using virtual machines. In this case, once the file is uploaded to the computer server, a virtual machine is started using the uploaded file.

[0011] In an effort to reduce operating costs and improve the flexibility of network infrastructures, cloud computing architectures are most often distributed or multi-site architectures in which the servers hosting the virtualization nodes belonging to the same cluster of nodes can be located on separate and distant geographical sites. Thus, certain virtualized functions requiring, for example, low latency, tend to be executed by virtualization units deployed in servers located at the edge of communications networks, i.e., as close as possible to the user terminals requiring a given service, while virtualized functions that are less demanding in terms of latency but process large volumes of data are instead instantiated in centralized data centers, generally of a larger size.

[0012] While they generally integrate load balancing mechanisms (such as, for example, a mechanism known as “Horizontal Pod Autoscaling”, which allows the number of virtualization units installed on all virtualization nodes to be automatically adapted according to a current load level associated with the deployed service), the Kubernetes architecture and other existing automated service deployment solutions do not currently offer means of continuously guaranteeing the satisfaction of predefined technical constraints (egimposed in advance by a user operating the service), in terms, for example, of minimum resources to be allocated or network performance to be respected during the service's operating phase, particularly when this service is to be deployed in a distributed environment, with software components distributed over infrastructures potentially located on separate and distant geographical sites.

[0013] For some critical applications, however, compliance with such technical constraints may prove essential, as a failure or even a simple slowdown of the service can sometimes have significant undesirable consequences, particularly when user security depends on the proper functioning of the service. Even for less critical applications, there is a risk that users will turn away from a service in the event of repeated degradation of the user experience, if the minimum resources to ensure normal operation of the service are not continuously guaranteed.

[0014] The present invention aims to resolve all or part of the drawbacks mentioned above.

[0015] The present technique makes it possible to propose a solution aimed at remedying certain drawbacks of the prior art. According to one aspect, the present technique relates to a method for automated deployment of a service in a distributed environment, comprising the deployment of a plurality of software components of said service on a plurality of virtualization units within said distributed environment. According to the general principle of the proposed invention, such a method, implemented within a management node of the distributed environment, comprises:

[0016] - instantiating, within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit;

[0017] - recording, within a configuration file, at least one interconnection data between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0018] - the instantiation, within said management node, of a control loop for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, as a function of said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

[0019] In this way, the conditions are met to allow the implementation of a control loop in a distributed environment, thanks to an advanced solution for the automated deployment of containerized applications which includes complementary mechanisms allowing on the one hand to obtain, via monitoring components, metrics at the level of the different containers deployed in the distributed environment, but also on the other hand to make the link between these different containers and therefore these different metrics, by means of interconnection data recorded at the level of a common configuration file. In this way, the control loop has all the information allowing it to control compliance with predefined technical specifications during the operation phase of the service, even when this service is deployed in a distributed environment.

[0020] In a particular embodiment, said instantiation of at least one monitoring component within at least one of said virtualization units is implemented jointly or concomitantly with the deployment of at least one of said software components on said virtualization unit.

[0021] In this way, the control loop is operational as soon as the service is deployed, and the continuous monitoring of compliance with the predefined technical criteria is operational from the outset, that is to say as soon as the service becomes available to its users.

[0022] In a particular embodiment, said software components, said interconnections between software components, and said technical criteria are defined within a declarative type file, said deployment being carried out according to the content of said declarative type file.

[0023] In this way, the deployment of the service and an associated control loop is particularly simple to implement for an operator of said service, since it is sufficient to declare within a simple file, via key-value type entries, the containers to be deployed, the links which exist between some of these containers, and the objectives to be guaranteed for chosen technical criteria (expressed for example in the form of minimum and / or maximum values ​​to be respected) in relation to the declared containers and links.

[0024] In a particular embodiment, said recording of interconnection data within the configuration file and said instantiation of the control loop are initiated upon request from a dedicated application, based on data collected by said dedicated application following the deployment of said software components and the instantiation of said monitoring components on said virtualization units.

[0025] In this way, the operations of obtaining, selecting and formatting data relevant to the operation of the control loop are facilitated, thanks to the use of an application specifically developed for this purpose.

[0026] In a particular embodiment, at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one resource allocated for the implementation of at least one of said software components.

[0027] According to a particular characteristic of this embodiment, said at least one technical criterion representative of at least one allocated resource belongs to the group comprising:

[0028] -a minimal amount of disk space;

[0029] -a minimum amount of RAM;

[0030] -a minimum amount of processor availability.

[0031] In a particular embodiment, at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one target performance for the implementation of at least one interconnection link between said software components.

[0032] According to a particular characteristic of this embodiment, said at least one technical criterion representative of at least one target performance belongs to the group comprising:

[0033] - maximum latency on said interconnection link between said software components;

[0034] - maximum jitter on said interconnection link between said software components;

[0035] - a maximum rate of data loss on said interconnection link between said software components.

[0036] In this way, it is possible to ensure that minimum resources and performance are guaranteed for optimal operation of the service, both at an intra-container level (i.e. within each container) and at an inter-container level (i.e. in interactions between containers).

[0037] In a particular embodiment, said method comprises, prior to or at the start of each control iteration of said control loop, a step of verification, within said configuration file, by said monitoring components, of a current validity of said interconnection data between software components.

[0038] In this way, any changes to the configuration of the deployed service are detected quickly, allowing for on-the-fly reconfiguration of the control loop and monitoring components if necessary. This ensures optimal continuous operation of the control loop.

[0039] In a particular embodiment, said method comprises, when at least one of said predefined technical criteria is not respected, the execution of a corrective action in connection with at least one of said software components and / or at least one of said virtualization units.

[0040] In this way, any detection of non-compliance with one of the predefined technical criteria triggers an immediate reaction from the system, aimed at restoring compliance with said criterion as quickly as possible. Thus, the conditions for normal operation of the service are continuously guaranteed.

[0041] In a particular embodiment, at least one of said predefined criteria is associated with the operation of said service.

[0042] In a particular embodiment, said service is a cloud radio access network (CRAN), and said software components comprise at least one radio unit (RU), at least one distributed unit (DU), and at least one centralized unit (CU).

[0043] In this way, the implementation of mechanisms allowing compliance with the high performance requirements associated with the operation of a cloud radio access network is greatly facilitated, and the risks of failure or desynchronization of the different elements of such a service are significantly reduced.

[0044] According to another aspect, the invention relates to a device for deploying a service in a distributed environment, comprising means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment. Such a device implements a management node of said distributed environment and comprises:

[0045] - means for instantiating, within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit;

[0046] - means for recording, within a configuration file, at least one item of interconnection data between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0047] - means for instantiating, within said management node, a control loop for the implementation, in an operating phase of said service, of at least one iteration of checking compliance with at least one predefined technical criterion, as a function of said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

[0048] Such a device can of course have the various characteristics relating to the deployment method according to the invention, which can be combined or considered in isolation. Thus, the characteristics and advantages of this device are the same as those of the deployment method and are not detailed further.

[0049] According to another aspect, the proposed invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, comprising program code instructions for executing the method as described above in any of its embodiments, when this method is executed on a computer.

[0050] The proposed invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the method as described above, in any of their embodiments.

[0051] Such a recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive or a hard disk.

[0052] On the other hand, such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program contained therein is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0053] The various embodiments mentioned above can be combined with each other to implement the invention. Figures

[0054] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which:

[0055] schematically presents the main steps of a method for deploying a service, in a particular embodiment of the proposed technique;

[0056] presents a sequence diagram illustrating the deployment of a cloud access network service within a Kubernetes architecture, in a particular embodiment of the proposed technique;

[0057] presents an example of the content of a file declaring technical criteria to be guaranteed during the operational phase of a service, in a particular embodiment of the proposed technique;

[0058] describes a simplified architecture of a management node for implementing the proposed technique, in a particular embodiment of the proposed technique. Detailed description of the invention General principle

[0059] The technique described below overcomes some of the above-mentioned drawbacks.

[0060] In all figures in this document, elements and steps of the same nature are designated by the same numerical reference.

[0061] According to a first aspect, the present technique relates to a method for automated deployment of a service in a distributed environment. The term "service" is understood here in the broad sense, and includes for example, by way of illustration and not limitation, the implementation of one or more virtualized applications and / or functions allowing the provision of a set of functionalities. By "distributed environment", is also meant in the context of this document an environment in which the various resources which serve as support for the implementation of the service in question are distributed across a plurality of servers, server clusters and / or data centers not necessarily located in the same geographical location (in the context of a Kubernetes architecture, such an environment can be described as "multi-cluster").Typically, the deployment of the service in such an environment includes the deployment of a plurality of software components of this service on a plurality of virtualization units within the distributed environment. This distribution of the software components, and therefore of the processing, however makes performance control operations more complex, as conventional solutions for automated deployment of containerized applications, such as Kubernetes for example, do not natively integrate mechanisms to guarantee at all times the availability of the resources (CPU, RAM, etc.) allocated to each virtualization unit or minimum performance (for example network performance, energy performance, etc.) to be respected for data exchanges between the different software components of the service.The proposed technique relates more particularly to improvements to these existing solutions for automated deployment of containerized applications, making it possible to overcome these drawbacks.

[0062] Thus, the general principle of the proposed technique, illustrated in relation to the, is based on an improved deployment process, enriched with new steps introduced below, including, at the level of a distributed environment management node:

[0063] - the instantiation E1, in the virtualization units within which the different software components of the service to be deployed are implemented, of monitoring components configured to deliver at least one metric associated with the virtualization unit and / or the software component considered;

[0064] - the E2 recording, within a configuration file, of at least one interconnection data between interconnected software components for the implementation of the service to be deployed, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0065] - the E3 instantiation, within the management node, of a control loop for the implementation, in an operating phase of the service, of at least one iteration of control of compliance with predefined technical criteria associated with the operation of the service, based on the metrics delivered by the monitoring components and the interconnection data recorded within the configuration file.

[0066] In other words, mechanisms are provided not only to set up a control loop to ensure compliance with technical specifications imposed, for example, by a user operating the service, but also to ensure that this control loop has all the data necessary to carry out this control, namely:

[0067] - data (eg measurements) associated with the operation of each software component or virtualization unit within which it is deployed, thanks to the instantiation in each of these virtualization units of dedicated monitoring components to deliver such metrics; and

[0068] - data which can be qualified as synchronization data, in that they make it possible to establish a link between software components which, although interconnected for the implementation of the service, do not necessarily have knowledge of their respective existence, of the existence of monitoring components other than their own, and / or of the resources on which they are deployed, thanks to a pooling of at least part of this information within a shared configuration file available at the level of a management node.

[0069] According to the general principle described above, the control loop thus has access to correlated information received from the various software components and monitoring components that are dependent on each other and interconnected, which allows it to operate in a distributed environment.

[0070] According to a particular characteristic, the mechanisms previously described can be implemented as soon as the service is deployed in the distributed environment, in other words jointly or concomitantly with the deployment of the software components of this service in the distributed environment.

[0071] Alternatively, according to another particular characteristic, their implementation can also be disjointed from the software component deployment phase. Steps E1, E2 and E3 introduced previously are then implemented in a later phase, in relation to a service already deployed or potentially already operated, possibly at the request of a third-party entity authorized – for example by delegation of a certification authority – to request the deployment of such control mechanisms from the management node. Presentation of a particular embodiment

[0072] In the remainder of the document, the invention is described in more detail using the example of the automated deployment of a cloud radio access network, or Cloud-RAN (Cloud Radio Access Network in English), of a communications network. The proposed solution is in fact particularly interesting in the context of the deployment of such a service, for several reasons.

[0073] First, the deployment of a cloud radio access network is generally implemented at the edge of a communication network, which implies a departure from traditional architectures often implemented at a single geographical site, in favor of architectures distributed over a larger territory, which corresponds to a type of architecture targeted by the proposed technique. The software components of the cloud radio access network – which comprise at least one radio unit RU, at least one distributed unit DU, and at least one centralized unit CU – are thus generally required to be deployed on distributed sites. In addition, a unique association between a CU and a DU as well as between a DU, an RU and an antenna must be instantiated.The introduction and consideration of interconnection data, as proposed with the present technique, allows simplified management of this type of distributed architecture, by allowing, via the sharing of a common configuration file, the exchange of configuration data between the different containers allowing the deployment of the cloud access network, and more particularly the sharing of the addressing information of the containers comprising the CU, DU and RU entities. In this way, the DU is able to know the IP address of the RU, the DU is able to know the IP address of the CU, etc.

[0074] Secondly, for optimal operation of such a cloud radio access network, subject to high performance requirements, compliance with rigorous technical constraints is required. For example, in terms of network performance, it is necessary for the distributed unit DU to permanently maintain a connection with a latency of less than one millisecond (for a one-way trip) with a radio unit RU, a higher latency being likely to lead to desynchronization of the different elements of the cloud radio access network, and therefore to compromise the proper operation of this service. Similarly, it is necessary to ensure compliance with a minimum resource allocation for the implementation of the different constituent elements of the cloud radio access network, in order to avoid any failure of the service.

[0075] Illustrates a sequence diagram corresponding to a particular embodiment of the present technique, in which the DEP deployment of such a cloud radio access network is implemented via a Kubernetes orchestration solution (it being understood that the general principle presented and the steps described below remain substantially the same for the deployment of services other than a Cloud-RAN and / or via automated deployment solutions for containerized applications other than Kubernetes).

[0076] In the particular embodiment illustrated, the deployment DEP of the cloud access network is initiated following the uploading or detection, within a management node NG of the distributed environment, in a step 1, of a declarative type file FD, the content of which describes the software components to be deployed, the interconnections between some of these software components, and technical criteria (or specifications) to be guaranteed when these software components are in operation, i.e. in a subsequent phase of operation EXP of the service. An example of an extract of the content of such a file for the deployment of a Cloud-RAN is illustrated in relation to the. More particularly, such a file FD lists software components 31 to be deployed (in this case, for the deployment of a cloud access network, CUs, DUs and RUs) as well as technical characteristics to be guaranteed in relation to these software components.

[0077] According to a particular characteristic, these technical criteria can be divided into two main categories: a first category 32 comprising criteria representative of allocated resources to be guaranteed for the implementation of the software component considered (or of the virtualization unit on which it is instantiated), and a second category 33 comprising criteria representative of target performances to be guaranteed for the implementation of at least one interconnection link between the software component considered and at least one other software component or another entity (for example an antenna) involved in the implementation of the service to be deployed.

[0078] By way of non-limiting examples, the first category 32 includes at least one of the following criteria:

[0079] - a minimum amount of processor availability 321 to be guaranteed;

[0080] - a minimum amount of 322 RAM to be guaranteed;

[0081] - a minimum amount of 323 disk space to be guaranteed.

[0082] By way of non-limiting examples, the second category 33 includes for example at least one of the following criteria:

[0083] - a maximum latency of 341 to be guaranteed on the interconnection link considered;

[0084] - a maximum jitter of 342 to be guaranteed on the interconnection link considered;

[0085] - a maximum data loss rate 343 to be guaranteed on the interconnection link considered.

[0086] In addition to the preceding examples 341, 342 and 343 relating more particularly to criteria representative of target network performances, the second category 33 can also include performance criteria of other types, not represented on the, such as for example:

[0087] - a maximum energy consumption to be guaranteed (for example a maximum electrical consumption in watts per hour) for data exchanges on the interconnection link considered;

[0088] - energy efficiency to be guaranteed for data exchanges on the interconnection link considered;

[0089] - a maximum occupancy rate to be guaranteed for at least one packet or request buffer zone used for data exchanges on the interconnection link in question;

[0090] - a minimum and / or maximum packet or request buffer zone size to be guaranteed for data exchanges on the interconnection link in question;

[0091] - a minimum and / or maximum value to be guaranteed for at least one parameter associated with the support of a transport sub-function (for example a number of HARQ contexts on a satellite link, or of multiple paths “multipath”, etc.) on the interconnection link considered.

[0092] [Rectified according to rule 91, 20.01.2025]The declaration file also describes the interconnection links 34 to which the technical criteria of the second category 33 are attached. Thus, in the example of the extract from the FD file for the deployment of a cloud access network type service, interconnection links 34 between CU and DU, between DU and RU, and between RU and antenna are declared. As illustrated in the, several interconnections with the same software component can be declared within such an FD file: thus, in the FD file extract provided as an example, the CU is declared as being interconnected with a DU, but also with another entity identified by an identifier “Other-Target-ID”, different technical network performance criteria can be associated with each of these interconnection links.

[0093] In the context of a deployment orchestrated by Kubernetes, the declarative FD file takes, for example, the form of a custom resource definition file ("CustomResources"), the content of which is injected into the ETCD database by the NG management node, in step 2 of the.

[0094] Upon detection, in step 3, of these personalized resources in the ETCD database, various mechanisms are triggered by a Kubernetes OP1 operator implemented within the NG management node as part of this technique.

[0095] More specifically, the operator OP1, called the deployment operator, creates a configuration file FC, in a step 4. This configuration file, substantially empty at this stage of the process, is intended to serve as a location for saving configuration information during the deployment phase DEP, which will subsequently be used in the operation phase EXP of the service to correlate the various data received and carry out the various operations for controlling the technical criteria to be guaranteed. In the context of a Kubernetes deployment, such a file may for example take the form of an object of the “ConfigMap” type.

[0096] In steps 5, 5' and 5", the deployment operator OP1 then proceeds not only to deploy the various CL software components of the service on virtualization units UV of the distributed environment, but also, concomitantly or jointly with this deployment, to instantiate, within these virtualization units, the associated CS monitoring components. Typically, for the deployment of a cloud access network (Cloud-RAN) type service, CL software components of type CU, DU and RU and associated CS monitoring components are deployed on virtualization units UV_CU, UV_DU and UV_RU within computing nodes NC located in three distinct geographical areas, i.e.respectively in RC regional data spaces ("RegionalClouds" in English), EC end data spaces ("Edge Clouds" in English), and FEC border data spaces ("Far Edge Clouds" in English), such spaces being notably defined by the O-RAN alliance ("Open Radio Access Network" in English). When they are instantiated, the various CS monitoring components are notably configured so as to be able to access in read / write mode the FC configuration file previously created in step 4.

[0097] In steps 6, 6' and 6'', installation and / or deployment information generated by Kubernetes following the deployment of the CL software components and the CS monitoring components on the different virtualization units UV_CU, UV_DU and UV_RU are collected by a dedicated application APP. Such information, transmitted by the CS monitoring components to the APP application, includes for example data associated with the NC compute nodes, the UV_CU, UV_DU and UV_RU virtualization units, the software components and / or the monitoring components themselves. This data includes for example identifiers generated for these different entities, IP addresses (possibly associated with ports) assigned to them and at which they can be contacted, etc.

[0098] The dedicated application APP is then responsible for filtering and formatting the relevant data for the implementation of a control loop among this collected information, then requesting from the management node NG the recording in the FC configuration file previously created of this relevant data in a step 7. The filtering consists for example of sorting the collected information to keep only that related to the technical criteria to be controlled, and the formatting to transcribe this relevant data in a format compatible with the FC configuration file and subsequently interpretable by the different entities requested for the control (control loop operator, monitoring components, etc.).In this way, information generated following the deployment of the CU, DU and RU software components is associated and centralized in a single location, which allows synchronization between this information, useful for the implementation of a BC control loop created subsequently, in particular for carrying out inter-entity control (the different deployed components not having knowledge of each other's existence, for example the CS monitoring component of the CU is not aware of the existence of the CS monitoring component of the DU, the CS monitoring component of the DU is not aware of the existence of the CS monitoring component of the RU, etc.).Also, step 7 makes it possible, for example, to associate at least one identifier of a virtualization unit, of a software component and / or of a monitoring component with at least one identifier respectively of another virtualization unit, of another software component and / or of another monitoring component, at least a portion of said identifiers being allocated following the deployment of the service.

[0099] In a step 8, the dedicated application APP also requests the creation of the control loop BC from the management node NG. The control loop BC is for example implemented using a Kubernetes object of type "ClosedLoop" whose parameters are recorded in a step 9 in the ETCD database. These parameters typically include dependency parameters between the virtualization units (i.e. the interconnection links) and a list of technical criteria to be controlled (i.e. the allocated resources and / or target performances to be guaranteed). In a step 10, a Kubernetes OP2 control loop operator implemented within the management node NG detects these parameters (which can take the form of Kubernetes custom resources) in the ETCD database, which finalizes the operations of instantiating the control loop BC, which is then operational.

[0100] At this stage, the initial DEP deployment phase according to the present technique can be considered complete, and an EXP exploitation phase of the service can begin, corresponding to use of the service in question under continuous control of the BC control loop.

[0101] In this EXP operating phase, the BC control loop repeatedly implements iterations to check compliance with the predefined criteria declared in the FD declarative file, based on the metrics delivered by the monitoring components and the interconnection data recorded in the FC configuration file.

[0102] Each control iteration more specifically includes steps 11 to 16 of the, detailed below.

[0103] Firstly, in steps 11, 11' and 11'', the various CS monitoring components carry out a verification, within the FC configuration file, of a current validity of the interconnection data between software components. Such a verification aims to ensure that the configuration is still the expected one, in particular that the affiliations made between CU, DU, RU, and other elements, for example of antenna type A, remain valid. Indeed, an event related to a deployed component – ​​for example a software or hardware problem – could have led to the need to redeploy this component, and therefore to lead to a modification of its configuration, in which case it is necessary to reconfigure the BC control loop before being able to use it. In other words, in these steps 11, 11' and 11'', the CS monitoring components use the FC configuration file to configure or possibly reconfigure their monitoring processes.

[0104] In order to adapt to these possible parameter changes, in step 12, the control loop operator OP2 continuously monitors the modifications made to the “ClosedLoop” type object in the ETCD database.

[0105] Once these checks and possible adaptations have been carried out, effective control of the predefined technical criteria is implemented.

[0106] First, in steps 13, 13' and 13", the CS monitoring components measure and / or collect various data, in order to deliver various metrics associated with the virtualization units or the software components. As illustrated in the, these metrics can be of the intra-entity or inter-entity type, the intra-entity metrics being for example related to currently allocated resources (RAM, CPU, disk space, etc.) within an entity (typically a virtualization unit UV_CU or UV_DU or UV_RU), and the inter-entity metrics being for example related to current performances on an interconnection link between entities (typically between two virtualization units, between UV_CU and UV_DU, or between UV_DU and UV_RU or even between UV_RU and Antenna A).

[0107] In steps 14, 14' and 14'', the CS monitoring components report these different metrics by updating their data in the "ClosedLoop" object of the ETCD database.

[0108] Based on these metrics, the control loop operator OP2 can assess whether all the technical criteria predefined in the declarative file FD are met. If not (i.e. if at least one of these criteria is not met), the control loop operator OP2 triggers, in steps 15, 15' and 15", at least one corrective action related to at least one of said software components and / or at least one of said virtualization units, so that compliance with all the technical criteria is again verified.

[0109] Such corrective actions include, by way of purely illustrative and non-limiting examples, an increase in the RAM or processor capacity available on a virtualization unit, an increase in the number of computing nodes and / or virtualization units, a redistribution of software components across the various available infrastructures to reduce potential problems related to concurrent access to the processor or RAM, in particular when several services are deployed and operated concurrently, etc.

[0110] In a particular embodiment, in an optional step 16, the control loop operator OP2 transmits to the dedicated application APP trace data of the control operations carried out (e.g. the values ​​of certain key metrics, the corrective actions taken, etc.), for the implementation of possible subsequent additional processing. The dedicated application APP can thus, for example, expose this data via one or more application programming interfaces (APIs), so that it can be used by third-party tools.

[0111] Although it is described previously in embodiments related to the deployment of a cloud access network, the present technique is however not limited to such use, which is given solely for illustrative purposes. The proposed technique is indeed of particular interest for the deployment in a distributed environment of any containerized application that must meet high performance requirements. Thus, many use cases are conceivable, in particular in industrial systems involving numerous interconnected devices, in which the system's reaction time is a critical factor for ensuring the safety of people, and for which fast processing times and very low latencies are therefore required at all times.This could involve, for example, urgently shutting down the operation of one or more machine tools if a potentially remote decision-making body detects, based on data collected by a network of cameras and other sensors, that the physical integrity of a user is threatened.

[0112] The proposed technique, in its general principle and its different embodiments, can also be implemented in connection with other solutions for automated deployment of containerized applications than Kubernetes.

[0113] Furthermore, alternatives for implementing some of the steps described in connection with the may be considered, in other embodiments of the present technique.

[0114] For example, direct input via a human-machine interface made available to an operator user can be considered instead of using the FD declarative file introduced in relation to step 1, to communicate to the management node the information relating to the software components to be deployed, to the possible interconnections between some of these software components, and to the technical criteria to be guaranteed.

[0115] Similarly, alternatives to the use of a dedicated application (the APP application) may be considered in relation to steps 6, 6', 6'', 7 and 8 previously described, the operations implemented within the framework of these steps being able, according to a particular characteristic, to be managed directly by the NG management node, for example by means of a new Kubernetes synchronization operator.

[0116] In certain embodiments, steps 11, 11' and 11'' of verifying, within the configuration file FC, a current validity of the interconnection data between software components may possibly be optional, or at the very least not be implemented at each iteration of the control loop BC but at a lower frequency (for example every two, ten, or one hundred iterations). Device

[0117] According to another aspect, the proposed technique also relates to a device for deploying a service in a distributed environment, capable of carrying out the method previously described in any of its embodiments. Such a device comprises means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, these deployment means being implemented via a management node of said distributed environment implemented in said device. This device further comprises the following means, implemented by said management node:

[0118] - means for instantiating, within one of said virtualization units, a monitoring component configured to deliver at least one metric associated with said virtualization unit and / or said software component deployed on said virtualization unit;

[0119] - means for recording, within a configuration file, at least one item of interconnection data between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0120] - means for instantiating, within said management node, a control loop for the implementation, in an operating phase of said service, of at least one iteration of checking compliance with at least one predefined technical criterion, as a function of said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

[0121] La represents, in a schematic and simplified manner, the structure of such a device, in a particular embodiment. The device according to the proposed technique comprises for example a memory 41 consisting of a buffer memory M, a processing unit 42, equipped for example with a microprocessor μP, and controlled by the computer program Pg 43, implementing steps of the method for automated deployment of a service in a distributed environment according to at least one embodiment of the invention. To this end, the device also comprises at least one communication interface (for example an Ethernet communication interface), allowing it to receive and transmit messages from and to other equipment present in the distributed environment and contributing to the implementation of a service to be deployed.

[0122] Upon initialization, the code instructions of the computer program 43 are loaded into the buffer memory before being executed by the processor of the processing unit 42. The processing unit 42 detects at input E, for example, the presence of a declarative type file, the content of which describes software components to be deployed for the implementation of a service in a distributed environment, possible interconnections between some of these software components, and technical criteria to be guaranteed when these software components are in operation, that is to say in a subsequent phase of operation of the service.

[0123] The microprocessor of the processing unit 42 then carries out the steps of the method for automated deployment of the service in the distributed environment, according to the instructions of the computer program 43. More particularly, on the basis of the data contained in the declarative file received as input E, the processing unit 42 carries out operations complementary to the raw deployment of said service, comprising the instantiation of monitoring components associated with the software components of the service, the recording of interconnection data between said software components in a configuration file.The processing unit 42 finally instantiates, at output S, a control loop for the implementation, in a subsequent phase of operation of said service, of at least one iteration of control of compliance with predefined technical criteria associated with the operation of said service, carried out on the basis of metrics delivered by said monitoring components and as a function of the interconnection data recorded in said configuration file.

Claims

Method for deploying a service in a distributed environment, comprising deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, said method being implemented within a management node of said distributed environment and characterized in that it comprises: - instantiating (E1), within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit or at least one of said software components deployed on said virtualization unit; - recording (E2), within a configuration file, at least one interconnection data item between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;- the instantiation (E3), within said management node, of a control loop for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, as a function of said at least one metric delivered by at least one of said monitoring components and of said at least one interconnection data recorded within said configuration file.; Method according to claim 1 characterized in that said instantiation of at least one monitoring component within at least one of said virtualization units is implemented jointly or concomitantly with the deployment of at least one of said software components on said virtualization unit. Method according to claim 1 characterized in that said software components, said interconnections between software components, and said technical criteria are defined within a declarative type file, said deployment being carried out according to the content of said declarative type file. Method according to claim 1, characterized in that said recording of interconnection data within the configuration file and said instantiation of the control loop are initiated upon request from a dedicated application, based on data collected by said dedicated application following the deployment of said software components and the instantiation of said monitoring components on said virtualization units. Method according to claim 1, characterized in that at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one resource allocated for the implementation of at least one of said software components. Method according to claim 1, characterized in that at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one target performance for the implementation of at least one interconnection link between said software components. Method according to claim 5, characterized in that said at least one technical criterion representative of at least one allocated resource belongs to the group comprising:- a minimum quantity of disk space;- a minimum quantity of RAM;- a minimum quantity of processor availability. Method according to claim 6, characterized in that said at least one technical criterion representative of at least one target performance belongs to the group comprising:- a maximum latency on said interconnection link between said software components;- a maximum jitter on said interconnection link between said software components;- a maximum data loss rate on said interconnection link between said software components. Method according to claim 1, characterized in that it comprises, prior to or at the start of each control iteration of said control loop, a step of verification, within said configuration file, by said monitoring components, of a current validity of said interconnection data between software components. Method according to claim 1 characterized in that it comprises, when at least one of said predefined technical criteria is not respected, the execution of a corrective action in connection with at least one of said software components and / or at least one of said virtualization units. Method according to claim 1 characterized in that at least one of said predefined criteria is associated with the operation of said service. A method characterized in that said service is a cloud radio access network (CRAN), and in that said software components comprise at least one radio unit (RU), at least one distributed unit (DU), and at least one centralized unit (CU). Device for deploying a service in a distributed environment, comprising means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, said device implementing a management node of said distributed environment and being characterized in that it comprises: - means for instantiating, within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit; - means for recording, within a configuration file, at least one interconnection data item between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;- means for instantiating, within said management node, a control loop for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, as a function of said at least one metric delivered by at least one of said monitoring components and of said at least one interconnection data recorded within said configuration file.; Computer program product downloadable from a communications network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for executing a method according to any one of claims 1 to 12, when executed by a computer.

Images