Introduction Kubernetes

Training Kubernetes

Qu’est-ce que Kubernetes ?

Qu’est-ce qu’un conteneur ?

Un conteneur est une unité atomique de logiciel qui contient le code, les dépendances et la configuration d’une application spécifique. Les conteneurs vous permettent de diviser des applications monolithiques en services individuels qui constituent la solution. En réarchitecturant votre application, vous pouvez déployer ces services distincts via des conteneurs.

Par exemple, chacune des applications dans la solution de suivi de drones :

Le concept de conteneur vous offre trois avantages majeurs :

• Un conteneur est immuable : la nature immuable d’un conteneur lui permet d’être déployé et exécuté de manière fiable avec le même comportement d’un environnement de calcul à un autre. Une image de conteneur testée dans un environnement d’assurance qualité est la même que celle déployée en production.

• Un conteneur est léger : vous pouvez vous représenter un conteneur comme une image de machine virtuelle, mais plus petite. Une image de machine virtuelle est normalement installée sur un hôte physique. L’image contient à la fois le système d’exploitation et l’application que vous souhaitez exécuter. En revanche, un conteneur n’a pas besoin d’un système d’exploitation, uniquement de l’application. Le conteneur s’appuie toujours sur le système d’exploitation installé sur l’hôte pour les services spécifiques au noyau. Les conteneurs sont moins gourmands en ressources et plusieurs conteneurs peuvent être installés sur le même environnement de calcul.

• Le démarrage du conteneur est rapide : les conteneurs peuvent démarrer en quelques secondes au lieu de quelques minutes, comme une machine virtuelle.

Qu’est-ce que la gestion des conteneurs ?

Un conteneur n’a pas le même cycle de vie. Il est déployé, démarré, arrêté et détruit comme il se doit. Ce cycle de vie rend les conteneurs jetables et impacte sur la façon dont les développeurs et les équipes des opérations informatiques doivent réfléchir à la gestion des grands déploiements de conteneurs.

Le processus de déploiement, de mise à jour, d’analyse et de suppression de conteneurs présente de nombreux défis.

Qu’est-ce qu’une orchestration de conteneurs ?

L’orchestration de conteneurs est un concept qui décrit toutes les tâches que vous ou un système exécutez pour gérer les conteneurs. Un orchestrateur de conteneurs est un système qui déploie et gère des applications conteneurisées. L’orchestrateur répond également de manière dynamique aux modifications apportées à l’environnement pour augmenter ou diminuer les instances déployées de l’application managée.

Qu’est-ce qu’une application native Cloud ?

Une application native Cloud est une application conçue et créée pour tirer parti des services tels que la mise à l’échelle automatique, les mises à jour propagées, l’auto-adaptation et les autres tâches mentionnées ci-dessus. Il s’agit d’applications qui s’exécutent et sont gérées dans une plateforme d’orchestration telle que Kubernetes. Une application native Cloud ne se limite pas à s’exécuter dans des environnements cloud public ou privé, car elle peut également être exécutée dans un cloud hybride et dans des centres de données locaux.

Qu’est-ce qu’une application de microservices ?

Une application de microservices est une application conçue et structurée comme des services de collaboration faiblement couplés. Ces services sont déployés séparément les uns des autres afin de simplifier la conception et la maintenance des applications volumineuses. Les services communiquent généralement sur des API RESTful ou des services Advance Message Queueing Protocol (AMQP) activés. Une application de microservices conçue constitue une partie importante des applications natives Cloud.

Qu’est-ce que Kubernetes ?

Kubernetes est une plateforme open source extensible et portable permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des charges de travail conteneurisées. Kubernetes simplifie la complexité de la gestion des conteneurs en vous fournissant une configuration déclarative pour orchestrer les conteneurs dans différents environnements de calcul. Cette plateforme d’orchestration vous offre la même facilité d’utilisation et la même flexibilité qu’avec les offres PaaS (Platform as a service) et IaaS (Infrastructure as a service).

Avantages offerts par Kubernetes

Les avantages offerts par l’utilisation de Kubernetes sont basés sur l’abstraction des tâches, qui sont les suivantes :

• Le déploiement de conteneurs.
• L’auto-adaptation des conteneurs. Par exemple, le redémarrage de conteneurs qui échouent ou remplacent des conteneurs.
• La mise à l’échelle dynamique du nombre de conteneurs d’application en fonction de la demande.
• Les mises à jour propagées et les restaurations automatiques de conteneurs.
• La gestion du stockage.
• La gestion du trafic.
• La gestion et le stockage des informations sensibles, comme les noms d’utilisateur et les mots de passe.

Considérations relatives à Kubernetes

Kubernetes vous permet de considérer votre centre de données comme un grand ordinateur. Vous n’avez pas à vous soucier de l’endroit et du mode de déploiement de vos conteneurs, mais uniquement du déploiement et de la mise à l’échelle de vos applications selon vos besoins. Toutefois, cette façon de voir peut être légèrement trompeuse, car il existe quelques aspects à prendre en compte :

• Kubernetes n’est pas une offre PaaS complète. Il fonctionne au niveau du conteneur et offre uniquement un ensemble commun de fonctionnalités PaaS.
• Kubernetes n’est pas monolithique. Il ne s’agit pas d’une application simplement installée. Les aspects, tels que le déploiement, la mise à l’échelle, l’équilibrage de charge, la journalisation et la supervision, sont tous facultatifs. Il vous incombe de trouver la solution la mieux adaptée à vos besoins pour gérer ces aspects.
• Kubernetes ne limite pas les types d’applications qui peuvent s’exécuter sur la plateforme. Si votre application peut s’exécuter dans un conteneur, elle peut s’exécuter sur Kubernetes. Toutefois, vos développeurs doivent comprendre des concepts tels que l’architecture des microservices afin d’optimiser l’utilisation des solutions conteneurisées.
• Kubernetes ne fournit pas d’intergiciels, d’infrastructures de traitement de données, de bases de données, de caches ni de systèmes de stockage de clusters. Tous ces éléments sont exécutés en tant que conteneurs ou dans le cadre d’une autre offre de service.

Fonctionnement de Kubernetes

Une installation Kubernetes correctement configurée dépend de la bonne compréhension de l’architecture du système Kubernetes. Vous pouvez examiner ici tous les composants qui composent une installation Kubernetes.

Qu’est-ce qu’un cluster de calcul ?

Un cluster est un ensemble d’ordinateurs configurés pour fonctionner ensemble et constituant un système unique. Les ordinateurs configurés dans le cluster effectuent généralement le même type de tâches. Par exemple, héberger des sites web, des API ou exécuter un travail gourmand en calcul.

Un cluster utilise un logiciel centralisé responsable de la planification et du contrôle de ces tâches. Les ordinateurs d’un cluster qui exécutent les tâches sont appelés nœuds et les ordinateurs qui exécutent le logiciel de planification sont appelés masters ou plans de contrôle.

Architecture de Kubernetes

En rappel de ce qui précède, un orchestrateur est un système permettant de déployer et de gérer des applications. Vous avez également appris qu’un cluster est un ensemble d’ordinateurs qui fonctionnent ensemble et constituent un système unique. Utilisez Kubernetes comme le logiciel d’orchestration et de cluster pour déployer vos applications et répondre aux modifications des besoins en ressources de calcul.

Un cluster Kubernetes contient au moins un maître et un ou plusieurs nœuds. Les instances du nœud et maître peuvent être des appareils physiques, des machines virtuelles ou des instances dans le cloud. Le système d’exploitation hôte par défaut dans Kubernetes est Linux, avec un support par défaut pour les charges de travail sur Linux.

Observons à présent les nœuds maître et Worker et le logiciel qui s’exécute sur chacun plus en détail. Comprendre le rôle de chaque composant et où chaque composant s’exécute dans un cluster est utile lors de l’installation de Kubernetes.

Le maître Kubernetes

Le nœud maître Kubernetes, également appelé plan de contrôle dans un cluster Kubernetes, exécute une collection de services qui gère la fonctionnalité d’orchestration dans Kubernetes. Tous les services Kubernetes peuvent s’exécuter dans une seule configuration de nœud maître. Dans le cadre d’un apprentissage, l’utilisation d’un seul maître dans votre environnement de test est utile dans le but d’explorer la fonctionnalité Kubernetes.

Le fait qu’un nœud maître exécute un logiciel spécifique pour conserver l’état du cluster n’exclut pas l’exécution d’autres charges de travail de calcul par le nœud maître. Néanmoins, il est généralement souhaitable de s’assurer d’exclure l’exécution des charges de travail non-critiques et des applications utilisateur par le maître.

Le nœud Kubernetes

Un nœud dans un cluster Kubernetes est le lieu d’exécution de vos charges de travail de calcul. Chaque nœud communique avec le plan de contrôle via le serveur API pour l’informer des changements d’état sur le nœud.

Services s’exécutant dans un plan de contrôle

Les services suivants composent le plan de contrôle dans un cluster Kubernetes.

• Le serveur API
• Le magasin de stockage
• Le Scheduler
• Le gestionnaire de contrôleurs
• Le gestionnaire de contrôleurs du cloud

Qu’est-ce qu’un serveur API ?

Nous pouvons concevoir le serveur API comme serveur frontal du plan de contrôle dans votre cluster Kubernetes. Toutes les communications entre les composants dans Kubernetes passe par cette API. Par exemple, en tant qu’utilisateur, vous utilisez une application de ligne de commande appelée kubectl. Cette dernière vous permet d’exécuter des commandes sur le serveur API de votre cluster Kubernetes. Le composant qui fournit cette API est appelé le kube-apiserver. Vous pouvez alors déployer plusieurs instances de ce composant pour prendre en charge la mise à l’échelle dans votre cluster.

Cette API expose une API RESTful qui vous permet de publier des commandes ou des fichiers de configuration basés sur YAML. YAML est une norme de sérialisation des données contrôlable de visu pour les langages de programmation. Les fichiers YAML permettent de définir l’état prévu de tous les objets dans un cluster Kubernetes.

Qu’est-ce que le magasin de stockage ?

Le magasin de stockage est un magasin de persistance utilisé par votre cluster Kubernetes pour stocker la configuration complète d’un cluster Kubernetes. Kubernetes utilise un magasin clé-valeur fiable distribué à haute disponibilité appelé, etcd. Ce magasin clé-valeur stocke l’état actuel ainsi que l’état souhaité de tous les objets au sein de votre cluster.

N’oubliez pas que etcd n’est pas responsable de la sauvegarde de données et qu’il vous incombe de vous assurer qu’un plan de sauvegarde efficace est en place pour sauvegarder les données etcd.

Dans un cluster Kubernetes de production, l’aide Kubernetes officielle consiste à avoir de trois à cinq instances répliquées de la base de données etcd pour une haute disponibilité.

Qu’est-ce que le Scheduler ?

Le Scheduler est le composant responsable de l’affectation des charges de travail sur tous les nœuds. Le Scheduler analyse le cluster à la recherche de conteneurs nouvellement créés et les attribue à des nœuds.

Qu’est-ce que le gestionnaire de contrôleurs ?

Le gestionnaire de contrôleurs est chargé de lancer et d’analyser les contrôleurs configurés pour un cluster par le biais du serveur d’API.

Kubernetes utilise des contrôleurs pour suivre l’état des objets dans le cluster. Chaque contrôleur s’exécute dans une boucle sans fin d’exécution lors de la surveillance et de la réponse aux événements du cluster. Par exemple, il existe des contrôleurs pour analyser les nœuds, les conteneurs, les points de terminaison, etc.

Le contrôleur communique avec le serveur d’API pour déterminer l’état de l’objet. Si l’état actuel de l’objet est différent de l’état souhaité, le contrôleur effectue une action pour garantir l’état souhaité.

Qu’est-ce que le gestionnaire de contrôleurs de cloud ?

La fonction du gestionnaire de contrôleurs de cloud consiste à intégrer les technologies de cloud sous-jacentes dans votre cluster lorsque le cluster s’exécute dans un environnement cloud tel qu’Azure ou un des autres fournisseurs de cloud. Ces services peuvent être des équilibreurs de charge, des files d’attente, le stockage, etc.

Services s’exécutant da

ns un nœud

Les services suivants constituent un nœud dans un cluster Kubernetes.

• kubelet
• Kube Proxy
• Runtime de conteneur

Qu’est-ce que kubelet ?

kubelet est l’agent qui s’exécute sur chaque nœud du cluster. Il analyse les demandes de travail à partir du serveur d’API et vérifie que l’unité de travail demandée est en cours d’exécution et saine.

kubelet est responsable de l’analyse des nœuds. Il doit s’assurer que les conteneurs planifiés sur chaque nœud s’exécutent comme prévu. kubelet gère uniquement les conteneurs créés par Kubernetes et n’est pas responsable de la replanification du travail à exécuter sur d’autres nœuds si le nœud actuel ne peut pas exécuter le travail.

Qu’est-ce que Kube Proxy ?

Kube Proxy est responsable du réseau en cluster local et s’exécute sur chaque nœud. Il incombe à Kube Proxy de s’assurer que chaque nœud possède une adresse IP unique. Kube Proxy implémente également des règles pour décrypter le routage et l’équilibrage de charge du trafic à l’aide de IPTABLES et IPVS. Kube Proxy ne fournit pas de services DNS en soi. Un module complémentaire de cluster DNS basé sur coreDNS est recommandé et installé par défaut.

Qu’est-ce que le runtime de conteneur ?

Le runtime de conteneur est le logiciel sous-jacent qui exécute des conteneurs sur un cluster Kubernetes. Le runtime est chargé de la récupération (fetch), du démarrage et de l’arrêt des images de conteneur. Kubernetes prend en charge plusieurs runtimes de conteneur, y compris, mais sans s’y limiter, Docker, RKT, l’interface du runtime de conteneur O, Containerd et Frakti. Le support de nombreux types de runtime de conteneur est basé sur l’interface du runtime de conteneur (CRI). Le CRI est une conception de plug-in qui fournit une interface de runtime de conteneur et permet à Kubelet de communiquer avec le runtime de conteneur disponible.

Comment interagir avec un cluster Kubernetes

Kubernetes fournit un outil en ligne de commande appelé kubectl que vous utilisez pour gérer votre cluster. Utilisez kubectl pour envoyer des commandes au plan de contrôle du cluster ou pour récupérer (fetch) des informations sur tous les objets Kubernetes via le serveur d’API.

kubectl utilise un fichier de configuration pour inclure les informations de configuration permettant d’identifier un Cluster, un Utilisateur et un Contexte.

La configuration Cluster vous permet de spécifier un nom de cluster, des informations de certificat et le point de terminaison de l’API de service associé au cluster. Cette définition vous permet de vous connecter à plusieurs clusters à partir d’une seule station de travail.

La configuration Utilisateur vous permet de spécifier les utilisateurs et leurs niveaux d’autorisations lors de l’accès aux clusters configurés.

La configuration Contexte vous permet de regrouper les clusters et les utilisateurs à l’aide d’un nom convivial. Par exemple, vous pouvez avoir un « cluster de dév. » et un « cluster de prod. » pour identifier vos clusters de développement et de production.

Vous pouvez configurer kubectl pour vous connecter à plusieurs clusters en fournissant le contexte approprié dans le cadre de la syntaxe de la ligne de commande.

Pods Kubernetes

Les charges de travail exécutées sur Kubernetes sont des applications conteneurisées. Toutefois, contrairement à un environnement Docker, vous ne pouvez pas exécuter de conteneurs directement sur Kubernetes. Vous empaquetez le conteneur dans un objet Kubernetes. Cet objet est appelé Pod. Il s’agit du plus petit objet que vous pouvez créer dans Kubernetes.

Un pod représente une instance unique d’une application. Un seul pod peut également regrouper un ou plusieurs conteneurs. Toutefois, un pod ne contient généralement pas de multiples de la même application.

Un pod contient des informations sur le stockage partagé et la configuration du réseau, ainsi qu’une spécification sur la façon d’exécuter ses conteneurs empaquetés. Utilisez des modèles de pods pour définir les informations sur les pods qui s’exécutent dans votre cluster. Les modèles de pods sont des fichiers codés en YAML à réutiliser et à inclure dans d’autres objets pour gérer des déploiements de pods.

Le cycle de vie d’un pod Kubernetes

Les pods Kubernetes ont un cycle de vie distinct qui a un impact sur la façon dont vous déployez, exécutez et mettez à jour les pods.

Vous commencez par envoyer le manifeste YAML du pod au cluster. Une fois soumis et rendu persistant dans le cluster, le fichier manifeste définit l’état souhaité du pod. Le Scheduler planifie le pod sur un nœud sain avec suffisamment de ressources pour exécuter le pod.

Fonctionnement des déploiements Kubernetes

Options de déploiement de pods

Il existe plusieurs options pour gérer le déploiement de pods dans un cluster Kubernetes lors de l’utilisation de kubectl. Vous pouvez utiliser l’une des quatre définitions de type d’objet pour déployer un ou des pods. Ces fichiers utilisent YAML pour décrire l’état prévu du pod ou des pods qui seront déployés.

Modèles de pods

Vous utilisez un modèle de pod pour déployer des pods manuellement. N’oubliez pas qu’un pod déployé manuellement n’est pas relancé après l’échec, il est supprimé ou terminé.

Contrôleurs de réplication

Un contrôleur de réplication utilise des modèles de pods et définit un nombre spécifique de pods qui doivent s’exécuter. Le contrôleur vous permet d’exécuter plusieurs instances du même pod et garantit que tous les pods spécifiés sont toujours en cours d’exécution sur un ou plusieurs nœuds du cluster. Un contrôleur de réplication remplace les pods lancés de cette façon avec les nouveaux pods, s’ils échouent, sont supprimés ou terminés.

Jeux de réplicas

Les jeux de réplicas remplacent le contrôleur de réplication comme méthode préférée pour déployer des réplicas. Un jeu de réplicas contient les mêmes fonctionnalités qu’un contrôleur de réplication. Toutefois, il comprend une option de configuration supplémentaire pour inclure une valeur de sélecteur.

Un sélecteur permet au jeu de réplicas d’identifier tous les pods en cours d’exécution sous celui-ci. Cette fonctionnalité vous permet de gérer des pods étiquetés avec la même valeur que celle du sélecteur, mais qui ne sont pas créées avec le jeu de réplicas.

Déploiements

Un déploiement crée un objet de gestion un niveau plus élevé qu’un jeu de réplicas. Les mises à jour de la gestion du déploiement vous permettent de gérer la façon dont vous mettez à jour les pods dans un cluster.

Supposons que vous avez cinq instances de votre application déployées dans votre cluster. Cinq pods exécutent la version 1.0.0 de votre application.

i vous décidez de mettre à jour votre application manuellement, vous pouvez terminer tous les pods, puis lancer de nouveaux pods exécutant la version 2.0.0 de votre application. Avec cette stratégie, votre application subira des temps d’arrêt.

À la place, vous devez exécuter une mise à jour propagée dans laquelle vous lancez des pods qui exécutent la nouvelle version de votre application avant de terminer les pods qui exécutent l’ancienne version de votre application. Les mises à jour propagées lancent un pod à la fois au lieu d’utiliser tous les pods les plus anciens en même temps. Les déploiements respectent le nombre de réplicas configurés dans la section des informations sur le jeu de réplicas. Il veille à conserver le nombre de pods spécifiés dans le jeu de réplicas lorsqu’il termine les vieux pods et lance de nouveaux pods.

Par défaut, les déploiements fournissent une stratégie de mise à jour propagée lors de la mise à jour de pods. Vous avez également la possibilité d’utiliser une stratégie de recréation. Cette stratégie terminera des pods avant d’en lancer de nouveaux.

Les déploiements vous fournissent également une stratégie de restauration que vous pouvez exécuter à l’aide de kubectl.

Les déploiements utilisent des fichiers de définition basés sur YAML et facilitent la gestion des déploiements. Gardez à l’esprit que les déploiements vous permettent d’appliquer toutes les modifications apportées à votre cluster. Déployez, par exemple, de nouvelles versions d’une application, en mettant à jour des étiquettes, en exécutant d’autres réplicas de vos pods, et ainsi de suite.

Considérations sur le déploiement

Kubernetes a des exigences spécifiques sur la façon dont vous configurez la mise en réseau et le stockage pour un cluster. La façon dont vous configurez ces deux aspects affecte vos décisions concernant l’exposition de vos applications sur le réseau de cluster et le stockage des données.

Mise en réseau Kubernetes

Supposons que vous avez un cluster avec un maître et deux nœuds. Lorsque vous ajoutez des nœuds à Kubernetes, une adresse IP est affectée automatiquement à chaque nœud à partir d’une plage de réseau privé interne. Par exemple, supposons que votre plage de réseau locale est 192.168.1.0/24.

Chaque pod déployé se voit attribuer un IP d’un pool d’adresses IP. Par exemple, supposons que votre configuration utilise une gamme de réseaux 10.32.0.0/12.

Par défaut , les pods et les nœuds ne peuvent pas communiquer entre eux à l’aide de ses différentes plages d’adresses IP.

Pour compliquer encore les choses, souvenez-vous que les pods sont temporaires. L’adresse IP du pod est temporaire et ne peut pas être utilisée pour se reconnecter à un pod nouvellement créé. Cette configuration a un impact sur la façon dont votre application communique avec ses composants internes, ainsi que sur la façon dont vous et les services interagissez avec elle en externe.

Pour simplifier la communication, Kubernetes s’attend à ce que vous configuriez la mise en réseau de telle sorte que :

• les pods puissent communiquer les uns avec les autres sur les nœuds sans traduction d’adresses réseau (NAT)
• les nœuds puissent communiquer avec tous les pods et inversement sans traduction d’adresses réseau (NAT)
• les agents sur un nœud puissent communiquer avec tous les nœuds et les pods

Kubernetes offre plusieurs options de mise en réseau que vous pouvez installer pour configurer la mise en réseau. Par exemple, Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T, Weave Net, etc.

Services

Un Service est un objet Kubernetes qui fournit une mise en réseau stable pour les pods. Un service Kubernetes permet d’activer la communication entre les nœuds, les pods et les utilisateurs internes et externes de votre application sur le cluster.

Kubernetes attribue un service à une adresse IP à la création comme un nœud ou un pod. Ces adresses sont attribuées à partir d’une plage d’adresses IP de cluster de service. Par exemple, 10.96.0.0/12. Un Service reçoit également un nom DNS basé sur le nom du service ainsi qu’un port IP.

Pour prendre en charge ces scénarios, vous pouvez configurer trois types de services pour exposer les composants de votre application.

Comment grouper les pods

Les adresses IP de pods changent de manière à ce que les contrôleurs les recréent et vous pouvez avoir un nombre quelconque de pods en cours d’exécution. La gestion des pods par adresse IP n’est pas pratique.

Un Service vous permet de cibler et de gérer des pods spécifiques dans votre cluster à l’aide d’étiquettes du sélecteur. Vous définissez l’étiquette du sélecteur dans une définition de service pour qu’elle corresponde à l’étiquette du pod définie dans le fichier de définition du pod.

Par exemple, supposons que vous avez plusieurs pods en cours d’exécution. Seuls certains d’entre eux sont des pods frontaux et vous souhaitez définir un service LoadBalancer qui cible uniquement les pods frontaux. Vous pouvez appliquer votre Service pour exposer ces pods en référençant l’étiquette du pod comme valeur de sélecteur dans le fichier de définition du Service. Le Service ne regroupera alors que les pods qui correspondent à l’étiquette. Si un pod est supprimé et recréé, le nouveau pod est automatiquement ajouté au groupe de service à l’aide de son étiquette correspondante.

Stockage Kubernetes

Kubernetes utilise le même concept de volume de stockage que celui que vous trouvez lorsque vous utilisez Docker. Les volumes Docker sont moins gérés que les volumes Kubernetes, étant donné que les durées de vie du volume Docker ne sont pas gérées. La durée de vie du volume Kubernetes est une durée de vie explicite qui correspond à la durée de vie du pod. Cette correspondance de durée de vie signifie qu’un volume présente les conteneurs qui s’exécutent dans le pod. Toutefois, si le pod est supprimé, c’est donc le volume.

Kubernetes fournit des options pour approvisionner un stockage persistant avec l’utilisation de PersistentVolumes. Vous êtes également autorisé à demander un stockage spécifique pour les pods à l’aide de PersistentVolumeClaims.

Ces deux options sont à prendre en compte lors du déploiement de composants d’application nécessitant un stockage persistant, comme des files d’attente de messages et des bases de données.

Exercice K8s

TP k8s

Quand utiliser Kubernetes

Vous souhaitez utiliser Kubernetes quand votre entreprise :

• développe des applications en tant que microservices
• développe des applications en tant qu’applications natives Cloud
• déploie des microservices à l’aide de conteneurs
• met à jour les conteneurs à l’échelle
• nécessite une gestion centralisée du stockage et de la mise en réseau des conteneurs