Brevet FR3154829A1 — publié le 20250502

Procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds par un nœud de calcul appartenant à une deuxième grappe de nœuds. L'invention concerne une solution d’orchestration d’une pluralité de grappes de nœuds permettant à un nœud de calcul d’une première grappe de nœuds d’accéder à une tâche exécutée dans un nœud de calcul appartenant à une deuxième grappe de nœuds. A l’heure actuelle, il est difficile pour un nœud de calcul d’une première grappe de nœuds d’accéder à une tâche exécutée dans un nœud de calcul appartenant à une deuxième grappe de nœuds particulièrement lorsque les deux grappes de nœuds ne sont pas co-localisées. La présente solution permet un tel accès en introduisant un nœud de supervision permettant un dialogue transparent et fluide entre grappes de nœuds. Figure pour l’abrégé : Fig. 2 Procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds par un nœud de calcul appartenant à une deuxième grappe de nœuds. La présente demande appartient au domaine général de l’informatique en nuage ou « cloud-computing ». Elle concerne plus particulièrement un procédé de gestion de l’accès à une tâche exécutée dans un conteneur instancié dans une première grappe de nœuds par un nœud d’une autre grappe de nœuds. Depuis plusieurs années, les réseaux de télécommunication utilisent des fonctions virtualisées hébergées dans des serveurs, ou nœuds, regroupés en grappes, ou « clusters », donnant naissance à l’informatique en nuage. Une solution d’orchestration de ces grappes de nœuds est connue sous l’appellation Kubernetes. La FIG. 1 présente de manière simplifiée l’architecture d’une grappe de nœuds 1 conforme à la solution Kubernetes. La grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11 i , i , N étant un entier naturel. Le nœud de gestion 10 comprend un contrôleur 101, un module API ( Application Programming Interface ou interface de programmation d’applications) 102 et une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs 11 i . Un nœud de calcul 11 i comprend M conteneurs ou « pods » 110 j , j , M étant un entier naturel. Chaque conteneur 110 j est doté de ressources permettant l’exécution d’une ou de plusieurs tâches. Une tâche lorsqu’elle est exécutée contribue à la mise en œuvre d’un service ou d’une fonction réseau, telle qu’une fonction DHCP ( Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple. Dans un souci de réduction des coûts et d’amélioration de la flexibilité des infrastructures réseaux, les architectures d’informatique en nuage sont le plus souvent des architectures multi-sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés c’est-à-dire déployés dans des sites distincts. Par exemple un nœud de gestion 10 et deux nœuds de calcul 11 1 , 11 2 d’une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs 11 3 , 11 4 , 11 5 sont quant à eux situés sur un site B distant. Pour des raisons de flexibilité, les services ou les fonctions réseau déployés dans une première grappe de nœuds peuvent être amenés à être parallèlement déployés dans des grappes de nœuds distinctes lesquelles sont parfois opérées par un fournisseur différent. Une telle situation se présente le plus souvent lors d’une montée en charge de ce service ou de cette fonction réseau dans un contexte où la grappe de nœuds dans laquelle ce dernier est déployé ne peut assurer une telle montée en charge seul car ses ressources sont limitées ou ne répondent pas aux besoins requis pour assurer une telle montée en charge. Afin de permettre une continuité dans l’exécution du service ou de la fonction réseau lorsque que différentes tâches afférentes à ce service ou à cette fonction réseau sont exécutées dans des conteneurs instanciés dans des nœuds de calcul appartenant à des grappes de nœuds différentes, le nœud maître d’une première grappe de nœuds est doté d’un module d’accès dont la fonction est de maintenir à jour une base de données des adresses réseau affectées à chaque conteneur au sein de la première grappe de nœuds. Ce module d’accès, lui-même doté d’une adresse réseau destinée à être utilisée pour communiquer avec des conteneurs instanciés dans d’autres grappes de nœuds, gère les échanges de données entre les différents nœuds de calcul de la première grappe de nœuds et les nœuds de calcul des autres grappes de nœuds impliquées dans la mise en œuvre du service ou de la fonction réseau considéré. Présenté en d’autres termes, le module d’accès permet à un nœud de calcul d’une autre grappe de nœuds dans laquelle le service ou la fonction réseau est également déployée d’accéder à une tâche relative à ce même service ou à cette même fonction réseau exécutée dans un conteneur de la première grappe de nœud en réalisant un lien entre une adresse réseau associée au conteneur exécutant la tâche et un identifiant de la tâche reçu depuis le nœud de calcul appartenant à une autre grappe de nœuds requérant un accès à la tâche. Parallèlement à la gestion de la communication vers d’autres grappes de nœuds, le nœud de gestion dispose d’un module de gestion des communications internes à la première grappe de nœuds. On entend par communications internes à la première grappe de nœuds les échanges de données intervenant entre les différents conteneurs instanciés dans les nœuds de calcul appartenant à la première grappe de nœuds. Pour dialoguer avec un autre conteneur appartenant à la première grappe de nœuds, un premier conteneur utilise un identifiant de connexion, tel qu’un nom de domaine par exemple, interne à la première grappe de nœuds et relatif au conteneur avec lequel il souhaite communiquer, dit identifiant de connexion privé. Un tel identifiant de connexion privé se présente par exemple sous la forme suivante : nomService.nomNamespace.svc.nomCluster.local . La configuration et la gestion des adresses réseau utilisées pour communiquer avec d’autres grappes de nœuds étant réalisées localement au sein d’un nœud de gestion d’une grappe de nœuds donnée, cela rend l’accès par un nœud de calcul appartenant à une autre grappe de nœuds aux informations permettant à ce nœud de calcul d’accéder à une tâche exécutée par un conteneur instancié dans un nœud de calcul de la première grappe de nœuds difficile et cela d’autant plus lorsque le nœud de calcul de la première grappe de nœuds et le nœud de calcul de l’autre grappe de nœuds ne sont pas co-localisés dans un même site. Une telle difficulté d’accès à une tâche donnée peut avoir un impact négatif sur la continuité de service et in fine sur la qualité du service fourni. La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette à un nœud de calcul d’une grappe de nœuds donnée d’accéder de manière fluide et transparente à une tâche exécutée par un conteneur instancié dans un nœud de calcul appartenant à une autre grappe de nœuds particulièrement, mais pas uniquement, lorsque les deux nœuds de calcul ne sont co-localisés. A cet effet, et selon un premier aspect, l’invention concerne un procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de gestion de la première grappe de nœuds et comprenant les étapes suivantes : - obtention de paramètres d’accès à la tâche, - génération d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par le deuxième nœud de calcul pour accéder à la tâche, en fonction de paramètres d'accès autorisant un accès à la tâche par un deuxième nœud de calcul appartenant à une deuxième grappe de nœuds, - transmission, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, d’un message comprenant l’identifiant de connexion public correspondant à la tâche. Il convient de noter que le terme « nœud de supervision » fait référence à une nouvelle entité, qui peut être une entité logicielle et/ou matérielle et dont la fonction est de gérer les interactions entre les nœuds de gestion de différentes grappes de nœuds. Plus spécifiquement, un tel nœud de supervision permet, entre autres, à un nœud de calcul d’une grappe de nœuds donnée d’accéder de manière fluide et transparente à une tâche exécutée par un conteneur instancié dans un nœud de calcul appartenant à une autre grappe de nœuds notamment lorsque les deux nœuds de calcul ne sont pas co-localisés comme cela sera décrit plus en détail dans la suite du présent document. A des fins d’efficacité opérationnelle, mais également dans un but de réduction des coûts de déploiement et de maintenance, un tel nœud de supervision est généralement co-localisé avec les nœuds de gestion des grappes de nœuds qu’il supervise. Ainsi, le procédé selon l’invention permet avantageusement de gérer l’accès à une tâche exécutée par un conteneur instancié dans un nœud de calcul d’une première grappe de nœuds par des nœuds de calcul appartenant à une autre grappe de nœuds de manière transparente. Les paramètres d’accès à une tâche sont, à titre d’exemple, enregistrés manuellement lors de la configuration de la tâche dans le conteneur dans lequel elle est exécutée. Ils peuvent également être fournis avec d’autres instructions relatives à l’exécution de la tâche. Enfin, ils peuvent également évoluer au cours du temps. Dans la suite du présent document, il est à noter que le terme « identifiant de connexion public » couvre aussi bien un nom de domaine, qu’une adresse réseau telle qu’une adresse IP ou tout autre type d’identifiant permettant l’établissement d’une connexion (pour englober DNS, proxy voire adresse IP d'un plan public) Enfin, le terme « conteneur » couvre aussi bien une application logicielle d'exploitation, qu’une machine virtuelle ou qu’un dispositif matériel. Dans des modes particuliers de mise en œuvre, ces paramètres appartiennent à un groupe comprenant : un paramètre autorisant ou non le partage de l’identifiant de connexion public, un paramètre autorisant ou non la transmission de données obtenues lors de l’exécution de la tâche à destination de nœuds de calcul appartenant à une autre grappe de nœuds, et un paramètre autorisant ou non la réception de données en provenance de nœuds de calcul appartenant à une autre grappe de nœuds destinées à être utilisées lors de l’exécution de la tâche. Dans des modes particuliers de mise en œuvre, le procédé comprenant la génération d’une règle d’accès à la tâche au moyen des paramètres d’accès à la tâche, l’application de la règle d’accès déclenche la génération de l’identifiant de connexion public lorsque la règle d’accès autorise l’accès à la tâche par le deuxième nœud de calcul. Comme cela sera décrit plus en détail dans la suite du présent document en référence à des modes de réalisation particuliers de la présente invention, le nœud de gestion de la première grappe de nœuds embarque un nouveau module de gestion des entrées/sorties dont la fonction est de générer des règles d’accès à une tâche donnée en fonction de paramètres d’accès relatifs à cette tâche. Un tel module de gestion des entrées/sorties peut être un module logiciel et/ou matériel. De telles règles d’accès sont régulièrement mises à jour afin de prendre en compte rapidement et de façon dynamique toute évolution des paramètres d’accès à une tâche donnée. La solution objet de la présente invention offre ainsi une grande réactivité contrairement aux solutions de l’état de l’art dans lesquelles toute modification des conditions d’accès à une tâche donnée est entrée manuellement. Ici, la simple réception d’un fichier de mise à jour par le nœud de gestion de la grappe de nœuds permet de mettre à jour les règles d’accès à une tâche pour un ensemble de grappes de nœuds. Dans des modes particuliers de mise en œuvre, l’identifiant de connexion public est associé à une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Un tel serveur mandataire permet de résoudre l’identifiant de connexion public fourni par le deuxième nœud de calcul de la deuxième grappe de nœuds cherchant à accéder à la tâche afin de pouvoir établir une communication entre ce nœud de calcul et le conteneur exécutant la tâche. Dans des modes particuliers de mise en œuvre, le procédé comprend l’émission à destination du nœud de supervision d’une autorisation de résoudre l’identifiant de connexion public. Selon un deuxième aspect, l’invention concerne un procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de supervision de la première grappe de nœuds et d’au moins une deuxième grappe de nœuds et comprenant les étapes suivantes : - réception d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à la deuxième grappe de nœuds pour accéder à la tâche lorsque des paramètres d’accès autorisent un accès à la tâche par le deuxième nœud de calcul, - lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public correspondant à la tâche, association de l’identifiant de connexion public avec une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Dans des modes particuliers de mise en œuvre, le procédé comprend la réception de l’autorisation de résoudre l’identifiant de connexion public en provenance d’un nœud de gestion de la première grappe de nœuds. Selon un troisième aspect, l’invention concerne un procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de calcul d’une deuxième grappe de nœuds et comprenant les étapes suivantes : transmission d’une première demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, réception d’une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public, transmission d’une deuxième demande de résolution de l’identifiant de connexion public à destination du serveur mandataire, réception de données obtenues lors de l’exécution de la tâche. Selon un quatrième aspect, l’invention concerne un procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de supervision d’une première grappe de nœuds et d’au moins une deuxième grappe de nœuds et comprenant les étapes suivantes : au niveau supervision réception d’une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, vérification d’une autorisation de résoudre l’identifiant de connexion public, lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public, transmission à destination du deuxième nœud de calcul, d’une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public. Selon un cinquième aspect, l’invention concerne un procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par le premier nœud de calcul et comprenant les étapes suivantes : réception, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, d’une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, vérification d’une règle d’accès à la tâche générée au moyen de paramètres d’accès à la tâche, lorsque la règle d’accès autorise un accès à la tâche par le deuxième nœud de calcul, résolution de l’identifiant de connexion public, transmission, à destination du deuxième nœud de calcul, de données obtenues lors de l’exécution de la tâche. Selon un sixième aspect, l’invention concerne un nœud de gestion d’une première grappe de nœuds capable de gérer un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de gestion comprenant au moins un processeur configuré pour : obtenir des paramètres d’accès à la tâche, générer un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par le deuxième nœud de calcul pour accéder à la tâche, en fonction de paramètres d'accès autorisant un accès à la tâche par un deuxième nœud de calcul appartenant à une deuxième grappe de nœuds, transmettre, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, d’un message comprenant l’identifiant de connexion public correspondant à la tâche. Selon un septième aspect, l’invention concerne un nœud de supervision d’une première grappe de nœuds et d’au moins une deuxième grappe de nœuds capable de gérer un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de supervision comprenant au moins un processeur configuré pour : recevoir un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à la deuxième grappe de nœuds pour accéder à la tâche lorsque des paramètres d’accès autorisent un accès à la tâche par le deuxième nœud de calcul, lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public correspondant à la tâche, associer l’identifiant de connexion public avec une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Selon un huitième aspect, l’invention concerne un nœud de calcul d’une deuxième grappe de nœuds capable d’accéder à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, le nœud de calcul comprenant au moins un processeur configuré pour : transmettre une première demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, recevoir une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public, transmettre une deuxième demande de résolution de l’identifiant de connexion public à destination du serveur mandataire, recevoir des données obtenues lors de l’exécution de la tâche. Selon un neuvième aspect, l’invention concerne un nœud de calcul d’une première grappe de nœuds capable de donner accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de calcul comprenant au moins un processeur configuré pour : recevoir, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, vérifier une règle d’accès à la tâche générée au moyen de paramètres d’accès à la tâche, lorsque la règle d’accès autorise un accès à la tâche par le deuxième nœud de calcul, résoudre l’identifiant de connexion public, transmettre, à destination du deuxième nœud de calcul, des données obtenues lors de l’exécution de la tâche. Enfin, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de contrôle de la qualité selon l’invention ou d’un procédé de contrôle de l’usure selon l’invention lorsque ledit programme d’ordinateur est exécuté par un ordinateur. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un quatrième aspect, l’invention concerne un ou plusieurs supports d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : FIG. 1 : cette figure représente de manière simplifiée l’architecture d’une grappe de nœuds conforme à l’art antérieur, FIG. 2 : cette figure représente de manière simplifiée une architecture conforme à la solution objet de la présente invention comprenant deux grappes de nœuds, FIG. 3 : cette figure représente les étapes des procédés de gestion de l’accès à une tâche lorsqu’elles sont mises en œuvre par les différents constituants d’une grappe de la première grappe de nœuds 1 et le nœud de supervision 3, FIG. 4 : cette figure représente une première boucle d’orchestration, FIG. 5 : cette figure représente une deuxième boucle d’orchestration, FIG. 6 : cette figure représente les étapes d’un procédé d’accès à la tâche T lorsqu’elles sont mises en œuvre par les différents constituants de la première grappe de nœuds, de la deuxième grappe de nœuds et du nœud de supervision, FIG. 7 : cette figure représente un nœud de gestion apte à mettre en œuvre les différents procédés objets de la présente invention, FIG. 8 : cette figure représente un nœud de supervision apte à mettre en œuvre les différents procédés objets de la présente invention, FIG. 9 : cette figure représente un nœud de calcul appartenant à une grappe de nœuds apte à mettre en œuvre les différents procédés objets de la présente invention. Description détaillée de modes de réalisation de l'invention La FIG. 2 présente de manière simplifiée une architecture conforme à la solution objet de la présente invention comprenant deux grappes de nœuds 1 et 2 supervisées par un nœud de supervision 3. Les éléments déjà décrits en référence à la FIG. 1 conservent les mêmes signes de référence. La première grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11 i , i , N étant un entier naturel. Le nœud de gestion 10 comprend un contrôleur 101, un module API ( Application Programming Interface ou interface de programmation d’applications) 102, une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs 11 i , un module de gestion des entrées/sorties 104 et un serveur de résolution de noms de domaines 105 interne à la première grappe de nœuds 1. Enfin, un nœud de calcul 11 i comprend M conteneurs ou « pods » 110 j , j , M étant un entier naturel. Chaque conteneur 110 j est doté de ressources permettant l’exécution d’une ou de plusieurs tâches. Une tâche lorsqu’elle est exécutée contribue à la mise en œuvre d’un service ou d’une fonction réseau, telle qu’une fonction DHCP ( Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes), DNS ( Domain Name System ) ou SLP ( Service Location Protocol ) par exemple. Un tel nœud de calcul 11 i comprend également un serveur mandataire 1100 dit « proxy SVC » dont la fonction sera décrite plus loin. De manière plus particulière, le module de gestion des entrées/sorties 104 permet de gérer les autorisations d’accès, par un nœud de calcul appartenant à une autre grappe de nœuds, à une tâche exécutée dans l’un des conteneurs 110 j instancié sur un l’un des nœuds de calculs 11 i en entrée et en sortie. Le serveur de résolution de noms de domaines 105 permet de résoudre un identifiant de connexion correspondant à la tâche, dit identifiant de connexion privé, destiné à être utilisé par un autre conteneur 110 i≠j instancié dans le même nœud de calcul 11 i ou dans un autre nœud de calcul 11 h≠i souhaitant accéder à la tâche. Un tel identifiant de connexion privé se présente par exemple sous la forme suivante : service1.namespace.svc.kubernetes1.local . Il est à noter que sur cette FIG. 1 , les nœuds de calculs 11 i appartenant à la première grappe de nœuds 1 ont été représentés comme étant co-localisés. Comme déjà expliqué plus en amont dans le présent document, les nœuds de calculs 11 i appartenant à la première grappe de nœuds 1 peuvent être respectivement situés sur des sites distincts et distants les uns des autres. De manière similaire la première grappe de nœuds 1, la deuxième grappe de nœuds 2 comprend, elle aussi, un premier nœud de gestion 20 et N nœuds de calcul 21 i , i , N étant un entier naturel. Tout comme le nœud de gestion 10 de la première grappe de nœuds 1, le nœud de gestion 20 comprend un contrôleur 201, un module API 202, une base de données 203 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs 21 i , un module de gestion des entrées/sorties 204 et un serveur de résolution de noms de domaines 205 interne à la deuxième grappe de nœuds 2. Le nœud de calcul 21 i comprend M conteneurs ou « pods » 210 j , j , M étant un entier naturel. Chaque conteneur 210 j est doté de ressources permettant l’exécution d’une ou de plusieurs tâches. Un tel nœud de calcul 21 i comprend, lui aussi, un serveur mandataire 2100 dit « proxy SVC ». Le module de gestion des entrées/sorties 204 permet de gérer les autorisations d’accès, par un nœud de calcul appartenant à une autre grappe de nœuds, à une tâche exécutée dans l’un des conteneurs 210 j instancié sur un l’un des nœuds de calculs 21 i en entrée et en sortie. Le serveur de résolution de noms de domaines 205 permet, lui aussi, de résoudre un identifiant de connexion correspondant à la tâche, dit identifiant de connexion privé, destiné à être utilisé par un autre conteneur 210 i≠j instancié dans le même nœud de calcul 21 i ou dans un autre nœud de calcul 21 h≠i souhaitant accéder à la tâche. Un tel identifiant de connexion privé se présente par exemple sous la forme suivante : service3.namespace.svc.kubernetes2.local Comme précédemment décrit en référence à la première grappe de nœuds 1, les nœuds de calculs 21 i appartenant à la deuxième grappe de nœuds 21 ont été représentés, sur la FIG. 1 , comme étant co-localisés, néanmoins, dans certains modes d’implémentation particuliers, les nœuds de calculs 21 i appartenant à la deuxième grappe de nœuds 2 peuvent être respectivement situés sur des sites distincts et distants les uns des autres. Enfin, l’architecture représentée à la FIG. 2 comprend un nœud de supervision 3. Un tel nœud de supervision 3 peut être une entité logicielle et/ou matérielle dont la fonction est de gérer les interactions entre les nœuds de gestion 10 et 20 de différentes grappes de nœuds 1, 2. Plus spécifiquement, un tel nœud de supervision 3 permet, entre autre, à un nœud de calcul 21 i de la deuxième grappe de nœuds 2 d’accéder de manière fluide et transparente à une tâche exécutée par un conteneur 110 j instancié dans un nœud de calculs 11 i appartenant à la première grappe de nœuds 1 notamment, mais pas exclusivement, lorsque les deux nœuds de calcul 11 i et 21 i ne sont pas co-localisés. Dans des modes particuliers de mise en œuvre, un tel nœud de supervision 3 est co-localisé avec les nœuds de gestion 10 et 20 des grappes de nœuds 1 et 2 qu’il supervise. Afin de pouvoir remplir sa fonction de supervision, le nœud de supervision 3 comprend entre autres un module de contrôle d’une autorisation d’accès à une tâche 31, une base de données 32 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de gestion 10 et 20 ainsi que des nœuds de calculs 11 i et 21 i de l’ensemble des grappes de nœuds supervisées, et un serveur de résolution de noms de domaines 33 dont la fonction est de résoudre un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un nœud de calcul 21 i appartenant à la deuxième grappe de nœuds 2 pour accéder à une tâche T exécutée par un conteneur 110 j instancié dans un nœud de calcul 11 i appartenant à la première grappe de nœuds 1. La FIG. 3 représente les étapes des procédés de gestion de l’accès à une tâche lorsqu’elles sont mises en œuvre par les différents constituants d’une grappe de la première grappe de nœuds 1 et le nœud de supervision 3. Dans une étape E1, le contrôleur 101 du nœud de gestion 10 obtient un jeu de paramètres d’accès P T à une tâche T destinée à être exécutée par un conteneur 110 j instancié sur un nœud de calcul 11 i appartenant à la première grappe de nœuds 1. Ce jeu de paramètres d’accès P T comprend trois paramètres : un paramètre SDNS autorisant ou non le partage d’un identifiant de connexion public associé à la tâche T par le nœud de supervision 3, un paramètre AS autorisant ou non la transmission de données depuis le conteneur 110 j exécutant la tâche T à destination d’un nœud de calcul 21 i de la deuxième grappe de nœuds 2 et un paramètre AE autorisant ou non la réception de données émises par le nœud de calcul 21 i de la deuxième grappe de nœuds 2 par le conteneur 110 j exécutant la tâche T. La valeur de chacun de ces paramètres est « vrai » ou « faux », la valeur « vrai » signifiant que le partage de l’identifiant de connexion, la transmission de données et la réception de données sont autorisées, et de manière corollaire, la valeur « faux » signifiant que ces actions ne sont pas autorisées. Dans des modes d’implémentations particuliers, le jeu de paramètres d’accès P T peut être transmis au nœud de gestion 10 par un équipement d’un réseau de télécommunication géré par le même opérateur en télécommunication gérant la première grappe de nœuds 1, par exemple, au sein d’une déclaration de service. Une telle déclaration de service comprend l’ensemble des paramètres nécessaires à la création de la tâche T dans le conteneur 110 j . Un exemple d’une telle déclaration de service est le suivant : apiVersion: v1 kind: Service metadata: namespace: nomNamespace name: nomService spec: type: NodePort SDNS : true/false AS : true/false AE : true/false selector: app: nomDeployment ports: protocol: TCP port: numeroPort targetPort: targetPort nodePort: nodePort La réception de la déclaration de service déclenche la génération de l’identifiant de connexion privé associé à la tâche T par le contrôleur 101 au cours d’une étape E2. Pour rappel, un tel identifiant de connexion privé peut être le suivant : service1.namespace.svc.kubernetes1.local . Dans une étape E3, le contrôleur 101 transmet ensuite, à destination du serveur de résolution de noms de domaines 105, l’identifiant de connexion privé ainsi qu’une adresse réseau, identifiant le conteneur 110 j exécutant la tâche T, et le cas échéant un numéro de port identifiant un port du conteneur 110 j au travers duquel des données relatives à la tâche T peuvent être échangées. Au cours d’une étape E4 qui peut être concomitante ou postérieure à l’étape E3, le contrôleur 101 transmet les valeurs des paramètres SDNS, AS et AE relatifs à la tâche T à destination du module de gestion des entrées/sorties 104 qui génère alors une règle d’accès à la tâche T au moyen de ces valeurs. Une telle règle d’accès à la tâche T est ensuite mémorisée dans la base de données 103 dans une étape E5. Au cours d’une étape E6, une boucle d’orchestration est mise en œuvre par la première grappe de nœuds 1. Une telle boucle d’orchestration est décrite en référence à la FIG. 4 décrite ci-dessous. Une boucle d’orchestration est un processus mis en œuvre dans une grappe de nœuds au cours duquel les conditions d’exécution des tâches exécutées par les nœuds de calcul 11 i sont mises à jour en fonction : d’informations comprises dans la base de données 103 et d’informations sur les conditions d’exécution courantes des tâches par les nœuds de calcul 11 i . Les informations sur les conditions d’exécution courantes des tâches sont remontées par les nœuds de calcul 11 i au contrôleur 101 ou au module API 102. La mise à jour du contenu de la base de données 103 est indépendante de l’exécution d’une boucle d’orchestration. La génération ou la mise à jour d’une règle d’accès à une tâche T impactant l’exécution de la tâche T par les nœuds de calcul 11 i de la première grappe de nœuds 1, la mise en œuvre d’une telle boucle d’orchestration permet de mettre à jour le fonctionnement de la première grappe de nœuds 1. Ainsi, l’exécution d’une boucle d’orchestration permet de prendre en compte les conditions d’accès à la tâche T lors de l’exécution de cette dernière par le nœud de calcul 11 i . A l’issue de l’exécution de la boucle d’orchestration, si cela est prévu par la règle d’accès à la tâche T, cette dernière devient accessible à un nœud de calcul 21 j de la deuxième grappe de nœuds 2. Ainsi, dans une étape G1 le contrôleur 101 transmet une demande d’informations DI relatives à la tâche T à destination du module API 102. Dans une étape G2, le module API 102 transmet la demande d’informations DI, notamment des informations relatives aux règles ou conditions d’accès la tâche T à destination de la base de données 103. Au cours d’une étape G3, la base de données 103 transmet les informations requises au module API 102. Le module API 102 transmet alors ces informations au contrôleur 101 au cours d’une étape G4. Dans une étape G5, le contrôleur 101 transmet une requête RQT en application d’une configuration d’accès déterminée au moyen des informations reçues au module de gestion des entrées/sorties 104 au cours de l’étape G4. Une fois que le module de gestion a appliqué la configuration requise, il transmet un message d’acquittement ACK au contrôleur 101 dans une étape G6. De retour à la FIG. 3 , à l’issue de la mise en œuvre de la boucle d’orchestration, le contrôle 101 génère, dans une étape E7, un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par le nœud de calcul 21 i appartenant à la deuxième grappe de nœuds 2 pour accéder à la tâche T. Un tel identifiant de connexion public peut être, à titre d’exemple, le suivant : service1.namespace.svc.kubernetes1.cluster L’identifiant de connexion public associé à la tâche T ainsi que la règle d’accès à la tâche T sont ensuite transmis respectivement à destination du serveur de résolution de noms de domaines 33 et du module contrôle d’une autorisation d’accès à une tâche 31 tous deux embarqués dans le nœud de supervision 3 dans une étape E8. Dans une étape E9, le serveur de résolution de noms de domaines 33 vérifie auprès du module de contrôle d’une autorisation d’accès à une tâche 31 quelles sont les conditions d’accès à la tâche T: un nœud de calcul 21 j de la deuxième grappe de nœuds 2 est-il autorisé à transmettre et/ou recevoir des données à destination/en provenance du conteneur 110 j exécutant la tâche T ? Lorsqu’il est déterminé qu’un nœud de calcul 21 j de la deuxième grappe de nœuds 2 est autorisé à transmettre et/ou recevoir des données à destination/en provenance du conteneur 110 j exécutant la tâche T, le serveur de résolution de noms de domaines 33 associe l’identifiant de connexion public associé à la tâche T à une adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T au cours d’une étape E10. Une telle correspondance entre l’identifiant de connexion public associé à la tâche T à une adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T est ensuite mémorisée dans la base de données 32 dans une étape E11. Au cours d’une étape E12, une boucle d’orchestration est mise en œuvre par le nœud de supervision 3. Une telle boucle d’orchestration est décrite en référence à la FIG. 5 . Une telle boucle d’orchestration est un processus au cours duquel les conditions de fonctionnement des nœuds de gestions 10, 20 des grappes de nœuds 1,2 supervisées par le nœud de supervision 3 sont mises à jour en fonction : d’informations comprises dans la base de données 32 et d’informations sur les conditions de fonctionnement courantes des nœuds de gestion 10, 20. Les informations sur les conditions d’exécution courantes des tâches sont remontées par les nœuds de gestions 10, 20 à un contrôleur ou à un module API (tous deux non représentés sur les figures) embarqués dans le nœud de supervision 3. La mise à jour du contenu de la base de données 32 est indépendante de l’exécution d’une boucle d’orchestration. La réception d’une règle d’accès à une tâche T et l’association de l’identifiant de connexion public associé à la tâche T à une adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T impactant les interactions entre les différentes grappes de nœuds 1, 2, la mise en œuvre d’une telle boucle d’orchestration permet de mettre à jour le fonctionnement du nœud de supervision 3. A l’issue de l’exécution de la boucle d’orchestration, le nœud de supervision est capable de permettre l’accès à une tâche T par un nœud de calcul 21 j de la deuxième grappe de nœuds 2. Ainsi, dans une étape H1 le contrôleur transmet une demande d’informations DI relatives à la tâche T à destination du module API. Dans une étape H2, le module API transmet la demande d’informations DI, notamment des informations relatives aux règles ou conditions d’accès à la tâche T, à destination du module contrôle d’une autorisation d’accès à une tâche 31. Au cours d’une étape H3, le module contrôle d’une autorisation d’accès à une tâche 31 interroge la base de données 32 afin d’obtenir les conditions d’accès à la tâche T. Après avoir récupérer les conditions d’accès à la tâche T auprès de la base de données 32, le module de contrôle d’une autorisation d’accès à une tâche 31 transmet les informations requises au module API dans une étape H4. Le module API transmet alors ces informations au contrôleur au cours d’une étape H5. Dans une étape H6, le contrôleur transmet, au serveur de résolution de noms de domaine 33,une requête RQT en application d’une configuration d’accès déterminée au moyen des informations reçues au cours de l’étape H5. Une fois que le serveur de résolution de noms de domaine 33 a appliqué la configuration requise, il transmet un message d’acquittement ACK au contrôleur dans une étape H7. A l’issue de l’exécution de la boucle d’orchestration, les différents constituants de la première grappe de nœuds 1 et le nœud de supervision 3 ont été configurés et sont aptes à traiter une demande d’accès à la tâche T émise par un nœud de calcul 21 j de la deuxième grappe de nœuds 2. La FIG. 6 représente les étapes d’un procédé d’accès à la tâche T lorsqu’elles sont mises en œuvre par les différents constituants de la première grappe de nœuds 1, de la deuxième grappe de nœuds 2 et du nœud de supervision 3. Lorsqu’un nœud de calcul 21 j de la deuxième grappe de nœuds 2 souhaite échanger des données avec une tâche T exécutée par un conteneur 110 j instancié sur un nœud de calcul 11 i appartenant à la première grappe de nœuds 1, il met en œuvre une étape F1 au cours de laquelle il émet à destination du serveur de résolution de noms de domaines 205 interne à la deuxième grappe de nœuds 2 une demande de résolution de l’identifiant de connexion public associé à la tâche T service1.namespace.svc.kubernetes1.cluster . Selon un exemple, cet identifiant de connexion est normalisé. Il sera dans ce cas toujours construit de la même façon. Il pourra être renseigné par exemple par un administrateur dans un fichier de configuration de la tâche. Voyant qu’il ne peut pas résoudre l’identifiant de connexion reçu au cours de l’étape F1 puisqu’il ne s’agit pas d’un identifiant de connexion privé spécifique à la deuxième grappe de nœuds 2 mais d’un identifiant de connexion public relatif à une autre grappe de nœuds, le serveur de résolution de noms de domaines 205 transmet alors, dans une étape F2, la demande de résolution de l’identifiant de connexion public associé à la tâche T à destination du serveur de résolution de noms de domaines 33 du nœud de supervision 3 dont dépend la deuxième grappe de nœuds 2. A réception de cette demande de résolution de l’identifiant de connexion, le serveur de résolution de noms de domaines 33 interroge, dans une étape F3, le module de contrôle d’une autorisation d’accès à une tâche 31 afin que ce dernier l’informe de l’existence ou de l’absence d’une autorisation à résoudre l’identifiant de connexion public. En d’autres termes, le module de contrôle d’une autorisation d’accès à une tâche 31 vérifie si la valeur du paramètre SDNS est « vrai », dans ce cas une autorisation de résolution de l’identifiant de connexion public existe, ou si cette valeur est « faux » signifiant, alors, qu’il n’existe pas d’autorisation de résolution de l’identifiant de connexion public ou bien que cette dernière n’est plus valide. Si la valeur du paramètre SDSN rapportée par le module contrôle d’une autorisation d’accès à une tâche 31 est « faux », le procédé d’accès se termine. Si la valeur paramètre SDSN rapportée par le module contrôle d’une autorisation d’accès à une tâche 31 est « vrai », le serveur de résolution de noms de domaines 33 résout l’identifiant de connexion public service1.namespace.svc.kubernetes1.cluster et transmet au serveur de résolution de noms de domaines 205, dans une étape F4, l’adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T avec laquelle il a été associé au cours de l’étape E10 décrite précédemment en référence à la FIG. 3 . A son tour, le serveur de résolution de noms de domaines 205 transmet l’adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T au nœud de calcul 21 j dans une étape F5. Une fois en possession de l’adresse réseau du serveur mandataire 1100 du nœud de calcul 11 i exécutant la tâche T, le nœud de calcul 21 j émet, à destination de ce dernier une demande d’accès à la tâche T, par exemple sous la forme d’une requête https comprenant l’identifiant de connexion public associé à la tâche T dans une étape F6. Voyant que la demande d’accès à la tâche T comprend l’identifiant de connexion public associé à cette dernière, le serveur mandataire 1100 interroge, dans une étape F7, le module de gestion des entrées/sorties 104 afin de déterminer quels sont les conditions d’accès à la tâche T lorsque cet accès est demandé par un nœud de calcul n’appartenant pas à la grappe de nœuds. A réception de cette demande, le module de gestion des entrées/sorties 104 vérifie si la valeur des paramètres AE et AS est « vrai » signifiant qu’un nœud de calcul appartenant à une autre grappe de nœuds peut transmettre, respectivement recevoir, des données à destination, respectivement en provenance, du conteneur 110 j exécutant la tâche T, ou « faux » signifiant alors que le nœud de calcul appartenant à une autre grappe de nœuds ne peut transmettre, respectivement ne peut recevoir, des données à destination, respectivement en provenance, du conteneur 110 j exécutant la tâche T. Si la valeur du paramètre AE et la valeur du paramètre AS rapportées par le module de gestion des entrées/sorties 104 sont toutes deux « faux », le procédé d’accès se termine. Si la valeur d’au moins l’un des paramètres AE ou AS rapportée par le module de gestion des entrées/sorties 104 est « vrai », alors, le procédé se poursuit. A réception d’une information selon laquelle le nœud de calcul 21 j appartenant à la grappe de nœuds 2 peut transmettre et/ou recevoir des données à destination/ en provenance, du conteneur 110 j exécutant la tâche T, le serveur mandataire 1100 remplace l’extension « cluster » de l’identifiant de connexion public service1.namespace.svc.kubernetes1.cluster par l’extension « local » dans une étape F8. Cet identifiant de connexion modifié correspond à l’identifiant de connexion privé service1.namespace.svc.kubernetes1.local . associé à la tâche T au sein de la grappe de nœuds 1. Dans une étape F9, le serveur mandataire 1100 transmet une demande de résolution d’un identifiant de connexion comprenant l’identifiant de connexion privé associé à la tâche T à destination du serveur de résolution de noms de domaines 105. En réponse à cette demande de résolution de l’identifiant de connexion, le serveur de résolution de noms de domaines 105 transmet, à destination du serveur mandataire 1100, l’adresse réseau du conteneur 110 j exécutant la tâche T ainsi que le numéro de port identifiant le port du conteneur 110 j au travers duquel des données relatives à la tâche T peuvent être échangée au cours d’une étape F10. Le serveur mandataire transfère alors la demande d’accès à la tâche T au conteneur 110 j dans une étape F11. En réponse à la réception de cette demande d’accès à la tâche, le conteneur 110 j établit, au cours d’une étape F12, une session de communication avec le nœud de calcul 21 j au cours de laquelle le conteneur 110 j émet et/ou reçoit des données à destination/en provenance du nœud de calcul 21 j . La FIG. 7 représente un nœud de gestion 10, 20 apte à mettre en œuvre les différents procédés objets de la présente invention. Un nœud de gestion 10, 20 peut comprendre au moins un processeur matériel 701, une unité de stockage 702, et au moins une interface 703 de communication, qui sont connectés entre eux au travers d’un bus 704 en plus du module API 102, 202, du contrôleur 101, 201, de la base données 103, 203, un module de gestion des entrées/sorties 104, 204 et un serveur de résolution de noms de domaines 105, 205. Bien entendu, les éléments constitutifs du nœud de gestion 10, 20 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 701 commande les opérations du nœud de gestion 10, 20. L'unité de stockage 702 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 701, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 701, des données intermédiaires de calculs effectués par le processeur 701, etc. Le processeur 701 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 701 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement ( Central Processing Unit ) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 702 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 702 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 703 fournit une interface entre le nœud de gestion 10, 20 et au moins un nœud de calcul 11 i , 21 i appartenant à la même grappe de nœuds que le nœud de gestion 10, 20 ou encore avec un nœud de supervision 3. La FIG. 8 représente un nœud de supervision 3 apte à mettre en œuvre les différents procédés objets de la présente invention. Un nœud de supervision 3 peut comprendre au moins un processeur matériel 801, une unité de stockage 802, et au moins une interface 803 de communication, qui sont connectés entre eux au travers d’un bus 804 en plus du module API, du contrôleur, du module contrôle d’une autorisation d’accès à une tâche 31, de la base données 32, et un serveur de résolution de noms de domaines 33. Bien entendu, les éléments constitutifs du nœud supervision 3 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 801 commande les opérations du nœud de gestion 10. L'unité de stockage 802 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 801, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 801, des données intermédiaires de calculs effectués par le processeur 801, etc. Le processeur 801 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 801 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement ( Central Processing Unit ) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 802 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 802 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 803 fournit une interface entre le nœud supervision 3 et au moins un nœud de gestion 10, 20 appartenant à l’une des grappes de nœuds 1, 2 supervisée par le nœud de supervision 3. La FIG. 9 représente un nœud de calcul 11 i , 21 i appartenant à une grappe de nœuds 1,2 apte à mettre en œuvre les différents procédés objets de la présente invention. Un nœud de calcul 11 i , 21 i peut comprendre au moins un processeur matériel 901, une unité de stockage 902, et au moins une interface 903 de communication, qui sont connectés entre eux au travers d’un bus 904 en plus des M conteneurs 110 j , 210 j et du serveur mandataire 1100, 2100. Bien entendu, les éléments constitutifs du nœud de calcul 11 i , 21 i peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 901 commande les opérations du nœud de gestion 10. L'unité de stockage 802 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 901, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 901, des données intermédiaires de calculs effectués par le processeur 901, etc. Le processeur 901 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 901 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement ( Central Processing Unit ) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 902 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 902 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 903 fournit une interface entre le nœud de calcul 11 i , 21 i et le nœud de gestion 10, 20 de la grappe de nœuds 1, 2 à laquelle il appartient ou encore avec le nœud de supervision 3. Procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de gestion de la première grappe de nœuds et comprenant les étapes suivantes : - obtention de paramètres d’accès à la tâche, - génération d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à une deuxième grappe de nœuds pour accéder à la tâche, en fonction de paramètres d'accès autorisant un accès à la tâche par ledit deuxième nœud de calcul, - transmission, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, d’un message comprenant l’identifiant de connexion public correspondant à la tâche. Procédé de gestion selon la revendication 1 comprenant la génération d’une règle d’accès à la tâche au moyen des paramètres d’accès à la tâche, l’application de la règle d’accès déclenchant la génération de l’identifiant de connexion public lorsque la règle d’accès autorise l’accès à la tâche par le deuxième nœud de calcul. Procédé de gestion selon la revendication 1 ou la revendication 2 dans lequel l’identifiant de connexion public est associé à une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Procédé de gestion selon la revendication 3 comprenant l’émission à destination du nœud de supervision d’une autorisation de résoudre l’identifiant de connexion public. Procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de supervision de la première grappe de nœuds et d’au moins une deuxième grappe de nœuds et comprenant les étapes suivantes : - réception d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à la deuxième grappe de nœuds pour accéder à la tâche lorsque des paramètres d’accès autorisent un accès à la tâche par le deuxième nœud de calcul, - lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public correspondant à la tâche, association de l’identifiant de connexion public avec une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Procédé de gestion selon la revendication 5 comprenant la réception de l’autorisation de résoudre l’identifiant de connexion public en provenance d’un nœud de gestion de la première grappe de nœuds. Procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de calcul d’une deuxième grappe de nœuds et comprenant les étapes suivantes : transmission d’une première demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, réception d’une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public, transmission d’une deuxième demande de résolution de l’identifiant de connexion public à destination du serveur mandataire, réception de données obtenues lors de l’exécution de la tâche. Procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par un nœud de supervision d’une première grappe de nœuds et d’au moins une deuxième grappe de nœuds et comprenant les étapes suivantes : au niveau supervision réception d’une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, vérification d’une autorisation de résoudre l’identifiant de connexion public, lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public, transmission à destination du deuxième nœud de calcul, d’une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public. Procédé d’accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, ledit procédé étant mis en œuvre par le premier nœud de calcul et comprenant les étapes suivantes : réception, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, d’une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, vérification d’une règle d’accès à la tâche générée au moyen de paramètres d’accès à la tâche, lorsque la règle d’accès autorise un accès à la tâche par le deuxième nœud de calcul, résolution d’un identifiant de connexion public, transmission, à destination du deuxième nœud de calcul, de données obtenues lors de l’exécution de la tâche. Nœud de gestion d’une première grappe de nœuds capable de gérer un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de gestion comprenant au moins un processeur configuré pour : - obtenir des paramètres d’accès à la tâche, - générer un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à une deuxième grappe de nœuds pour accéder à la tâche, en fonction de paramètres d'accès autorisant un accès à la tâche par ledit deuxième nœud de calcul, - transmettre, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, d’un message comprenant l’identifiant de connexion public correspondant à la tâche. Nœud de supervision d’une première grappe de nœuds et d’au moins une deuxième grappe de nœuds capable de gérer un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de supervision comprenant au moins un processeur configuré pour : - recevoir un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, destiné à être utilisé par un deuxième nœud de calcul appartenant à la deuxième grappe de nœuds pour accéder à la tâche lorsque des paramètres d’accès autorisent un accès à la tâche par le deuxième nœud de calcul, - lorsque le nœud de supervision dispose d’une autorisation de résoudre l’identifiant de connexion public correspondant à la tâche, associer l’identifiant de connexion public avec une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul. Nœud de calcul d’une deuxième grappe de nœuds capable d’accéder à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds, le nœud de calcul comprenant au moins un processeur configuré pour : transmettre une première demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, à destination d’un nœud de supervision de la première grappe de nœuds et de la deuxième grappe de nœuds, recevoir une adresse réseau d’un serveur mandataire instancié dans le premier nœud de calcul associée à l’identifiant de connexion public, transmettre une deuxième demande de résolution de l’identifiant de connexion public à destination du serveur mandataire, recevoir des données obtenues lors de l’exécution de la tâche. Nœud de calcul d’une première grappe de nœuds capable de donner accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul de la première grappe de nœuds, le nœud de calcul comprenant au moins un processeur configuré pour : recevoir, en provenance d’un deuxième nœud de calcul d’une deuxième grappe de nœuds souhaitant accéder à la tâche, une demande de résolution d’un identifiant de connexion correspondant à la tâche, dit identifiant de connexion public, vérifier une règle d’accès à la tâche générée au moyen de paramètres d’accès à la tâche, lorsque la règle d’accès autorise un accès à la tâche par le deuxième nœud de calcul, résoudre l’identifiant de connexion public, transmettre, à destination du deuxième nœud de calcul, des données obtenues lors de l’exécution de la tâche.