https://youtu.be/NChhdOZV4sY


Kubernetes : à quoi ça sert ?

Le principal intérêt de Kubernetes est de permettre aux entreprises de se focaliser sur la façon dont ils veulent que les applications fonctionnent, plutôt que sur des détails spécifiques d’implémentation. Grâce aux abstractions permettant de gérer des groupes de containers, les comportements dont ils ont besoin sont dissociés des composants qui les fournissent.

Kubernetes permet ainsi d’automatiser et de simplifier plusieurs tâches. Tout d’abord, on peut citer le déploiement d’applications multi-container. De nombreuses applications résident dans plusieurs containers (base de données, front end web, serveur de cache…), et les microservices sont également développés sur ce modèle. Généralement, les différents services sont liés par API et des protocoles web.

Cette approche présente des avantages sur le long terme, mais demande beaucoup de travail sur le court terme. Kubernetes permet de réduire les efforts nécessaires. L’utilisateur indique à Kubernetes comment composer une application à partir d’un ensemble de containers, et la plateforme prend en charge le déploiement et assure la synchronisation des composants entre eux.

Cet outil simplifie aussi le scaling d’applications containerisées. En effet, les applications ont besoin d’être mises à l’échelle pour suivre la demande et optimiser l’usage des ressources. Kubernetes permet d’automatiser cette mise à l’échelle. La plateforme permet aussi le déploiement continu de nouvelles versions d’applications, éliminant les temps de maintenance. Ses mécanismes permettent de mettre à jour les images de containers et même de revenir en arrière en cas de problème.

Kubernetes et ses APIs permettent aussi le networking des containers, la découverte de service et le stockage. Enfin, n’étant pas liée à un environnement ou à une technologie cloud spécifique, Kubernetes peut être lancé dans n’importe quel environnement : cloud public, stacks privés, hardware physique ou virtuel… il est même possible de mixer les environnements.



Kubernetes : Comment ça marche ?

Kubernetes est un système de gestion de conteneurs. Le but du logiciel n’est donc pas de créer les conteneurs, simplement de les gérer. Pour y parvenir, Kubernetes a recours à l’automatisation des processus. Les développeurs peuvent ainsi procéder plus facilement aux tests, à la maintenance ou à la publication des applications. L’architecture Kubernetes comporte une hiérarchie claire :

Un cluster Kubernetes doit avoir un master : le système qui commande et contrôle toutes les autres machines du cluster. Un cluster Kubernetes hautement disponible réplique les fonctions du master sur les différentes machines, mais seul un master à la fois exécute le controller-manager et le scheduler.

Chaque cluster contient des nodes Kubernetes. Il peut s’agir de machines physiques ou virtuelles. Les noeuds quant à eux exécutent des pods : les objets Kubernetes les plus basiques pouvant être créés ou gérés. Chaque pod représente une seule instance d’une application ou d’un processus en cours d’exécution sur Kubernetes, et se constitue d’un ou plusieurs containers. Tous les containers sont lancés et répliqués en groupe dans le pod. Ainsi, l’utilisateur peut se concentrer sur l’application plutôt que sur les containers.

Le controller est une autre abstraction permettant de gérer la façon dont les pods sont déployés, créés ou détruits. En fonction des différentes applications à gérer, il existe différents pods. Une autre abstraction est le service, qui permet d’assurer la persistance des applications même si les pods sont détruits. Le service décrit la façon dont un groupe de pods peut être accédé via le réseau.

On dénombre d’autres composants clés de Kubernetes. Le scheduler répartit les workloads entre les nodes pour assurer l’équilibre entre les ressources, et garantir que les déploiements correspondent aux besoins des applications. Le controller manager quant à lui assure que l’état du système (applications, workloads…) correspond à l’état désiré défini dans les paramètres de configuration Etcd.

Toutes les semaines, ce sont plus 2 milliards de conteneurs qui sont déployés par Google via Borg, plateforme connue comme étant la grande sœur de Kubernetes.

C’est d’ailleurs son développement qui a servi de fondation à la technologie Kubernetes.

Google est donc passé maître dans l’art d’utiliser les conteneurs pour ses workloads de production et des services comme Gmail, Search, Apps ou Maps tournent tous dans des conteneurs.

Kubernetes permet d’éliminer de nombreux processus manuels liés au déploiement et à la mise à l’échelle des applications conteneurisées.

Pour faire plus simple, il vous aide à gérer facilement et efficacement des clusters au sein desquels vous aurez rassemblé des groupes d’hôtes exécutant des conteneurs Linux. Ceux-ci pouvant couvrir des hôtes situés dans des clouds publics, privés ou hybrides.

Kubernetes est donc la plateforme parfaite pour héberger les applications cloud-native qui requièrent une mise à l’échelle rapide, comme la diffusion de données en continu et en temps réel via Apache Kafka.

L’utilité des conteneurs

Avant de vous expliquer ce que fait Kubernetes, nous devons vous expliquer ce que sont les conteneurs et pourquoi ils sont si utilisés.

Tout d’abord, demandez à un administrateur qui a géré une multitude de machines virtuelles sans conteneurs de vous expliquer son expérience et il vous dira que c’est un vrai cauchemar.

Avec des conteneurs, c’est différent…

Un conteneur est une mini-machine virtuelle.

Contrairement à toutes les autres machines virtuelles classiques, il ne dispose pas de pilotes ou de périphérique et autres composants, c’est ce qui fait qu’il est plus petit, plus léger, plus rapide, plus efficace et plus simple à gérer.

Quand Amazon Web Service a présenté au public Amazon EC2 en 2008, on ne s’attendait pas à ce que ce portail, permettant de provisionner des serveurs virtuels simplement, allait révolutionner le travail des développeurs et des administrateurs.

La conteneurisation est un moyen d’exécuter des applications sur un système d’exploitation de sorte que l’application soit isolée du reste du système.

Votre application pense qu’elle a sa propre instance de système d’exploitation, alors qu’il y a d’autres conteneurs qui s’exécutent sur le même système.

Il permet d’assurer le déploiement rapide et stable des applications dans n’importe quel environnement informatique.

Les conteneurs ont modifié la façon de développer, de déployer et de maintenir les logiciels c’est pour cela que cette méthode rencontre un vrai succès depuis des années.

Mais cette nouvelle façon de procéder nécessite des outils adaptés pour automatiser le déploiement, le management, le networking, le scaling et la disponibilité des applications basées sur conteneurs.

On les appelle des outils d’orchestration de conteneurs et c’est exactement le rôle de Kubernetes !

Et comme il est open source, il peut être utilisé librement par n’importe qui, n’importe où.
 

Comment fonctionne Kubernetes ?

L’idée principale de Kubernetes est de virtualiser les machines, le stockage et les réseaux.

Il va donc déployer des conteneurs sur toutes sortes de clouds, machines virtuelles ou machines physiques.

Et pour comprendre son mode de fonctionnement, il y a quelques concepts de Kubernetes qu’il faut déjà connaître.

Voilà donc un peu de vocabulaire :

Un nœud peut exécuter plusieurs pods. Ils ont le même contenu partagé, partagent tous l’adresse IP de partage, mais peuvent également en atteindre d’autres via localhost. 

Ils peuvent également partager le stockage, mais n’auront pas besoin de tous fonctionner sur la même machine, car les conteneurs peuvent s’étendre sur plus d’une machine.

Mode de fonctionnement.

Tout d’abord, la principale abstraction sur laquelle repose Kubernetes est le cluster. Il s’agit d’un groupe de machines qui exécute Kubernetes et les conteneurs qu’il gère.

Un cluster doit avoir un master, c’est-à-dire un système qui commande et contrôle toutes les autres machines du cluster.

Chaque cluster contient des nœuds Kubernetes qui peuvent être des machines physiques ou virtuelles.

Les nœuds quant à eux exécutent des pods.

Chaque pod représente une seule instance d’une application ou d’un processus en cours d’exécution sur Kubernetes, et est constitué d’un ou plusieurs conteneurs.

Tous les conteneurs sont lancés et répliqués en groupe dans le pod. vous permettant de vous concentrer sur l’application plutôt que sur les conteneurs.

Le controller quant à lui est une autre abstraction qui permet cette fois de gérer la façon dont les pods sont déployés, créés ou détruits.

Le service est une abstraction qui permet d’assurer la persistance des applications même si les pods sont détruits.

Il décrit la façon dont un groupe de pods peut être accessible via le réseau.

Il existe d’autres composants clés de Kubernetes comme le scheduler qui répartit les workloads entre les nœuds pour assurer l’équilibre entre les ressources, et garantir que les déploiements correspondent aux besoins des applications.

Le controller manager quant à lui assure que l’état du système (applications, workloads…) correspond à l’état désiré qui a été défini dans les paramètres de configuration Etcd.

Pourquoi utiliser Kubernetes ?

Le principal intérêt de Kubernetes est de vous permettre de vous focaliser sur la façon dont vous voulez que les applications fonctionnent, plutôt que sur des détails spécifiques d’implémentation.

Grâce aux abstractions qui permettent de gérer des groupes de conteneurs, les comportements dont ils ont besoin sont dissociés des composants qui les fournissent.

Kubernetes permet d’automatiser et de simplifier plusieurs tâches, mais il permet également de :

Comme avec toutes les machines virtuelles les conteneurs peuvent rencontrer des problèmes qui doivent être suivis et gérés.

Par exemple quand une entreprise de cloud public vous facture le temps processeur ou le stockage vous devez être sûr qu’il n’y a pas de machines orphelines qui tournent pour rien ou à contrario de fournir automatiquement plus de mémoire quand une machine en a besoin et de les alléger lorsque la charge le permet.

Et bien tout cela c’est de l’orchestration et c’est là que Kubernetes va jouer son rôle.

Kubernetes pour prendre des mesures concrètes pour améliorer votre sécurité informatique.

La sécurité des conteneurs peut-être complexe, car elle comporte plusieurs couches.

Kubernetes va vous permettre avec ses outils d’orchestration et de gestion de déployer des conteneurs à grande échelle.

En effet, ses outils vous permettent de créer des services applicatifs sur plusieurs conteneurs, de planifier leur exécution dans un cluster, de les mettre à l’échelle et de gérer leur intégrité.

Kubernetes doit pouvoir s’intégrer aux services de mise en réseau, de stockage, de sécurité et de télémétrie, pour fournir une infrastructure de conteneurs complète.

Une application de conteneurs Linux classique les traite comme des machines virtuelles rapides et efficaces. Mais si vous évoluez vers un environnement de production avec de nombreuses applications, vous allez avoir besoin de plusieurs conteneurs colocalisés qui fonctionnent ensemble pour fournir des services individuels.

Et forcément, votre infrastructure se complexifie au fur et à mesure où le nombre de conteneurs dans votre environnement augmente.

Quelle différence entre Docker et Kubernetes ?

Docker a largement contribué à la démocratisation de conteneurs Linux.

Il n’a pas créé la technologie, mais il a construit un ensemble d’outils et d’API qui ont rendu les conteneurs beaucoup plus faciles à gérer et il est arrivé au moment où l’industrie cherchait un moyen de mieux gérer le Cloud et ses workloads Web.

Docker c’est aussi une société qui a contribué à un ensemble divers d’outils de gestion des cycles de vie des conteneurs.

Docker est d’ailleurs le conteneur le plus populaire.

On compare souvent les deux, Docker et Kubernetes, à tort, car en fait ils sont complémentaires.

Là où Docker Swarm gère le cycle de vie des conteneurs Linux, Kumbernetes fonctionne en complément et gère l’orchestration.

L’un n’est pas une alternative à l’autre. Bien au contraire, Kubernetes peut fonctionner sans Docker et Docker peut fonctionner sans Kubernetes. Mais ils peuvent grandement bénéficier l’un de l’autre.

Docker est un logiciel autonome qui peut être installé sur n’importe quel ordinateur pour exécuter des applications conteneurisées. Il permet d’exécuter, de créer et de gérer des conteneurs sur un seul système d’exploitation.

Mais si Docker est installé sur un groupe d’hôtes (différents systèmes d’exploitation), vous pouvez tirer parti de Kubernetes.

Ces nœuds, ou hôtes Docker, peuvent être des serveurs sans système d’exploitation ou des machines virtuelles. 

Comme nous l’avons vu plus haut, Kubernetes vous permet d’automatiser le provisionnement de conteneurs, la mise en réseau, l’équilibrage de charge, la sécurité et la mise à l’échelle sur tous ces nœuds à partir d’une seule ligne de commande ou du tableau de bord. 

Mais quelle nécessité d’avoir plusieurs nœuds ?

Tout d’abord pour rendre l’infrastructure plus robuste.

Votre application sera en ligne, même si certains des nœuds sont hors ligne.

Ensuite pour rendre votre application plus évolutive : si la charge de travail augmente, vous n’aurez qu’à créer simplement plus de conteneurs et/ou ajoutez plus de nœuds à votre cluster Kubernetes.

Kubernetes automatise le processus de mise à l’échelle, de gestion, de mise à jour et de suppression des conteneurs.

Et si Docker est au cœur de la conteneurisation, il nous permet d’avoir en premier lieu des conteneurs.

En principe, Kubernetes peut fonctionner avec n’importe quelle technologie de conteneurisation.

Mais les deux options les plus populaires avec lesquelles Kubernetes peut s’intégrer sont rkt et Docker. 4

Mais Docker a pu déployer beaucoup plus d’efforts pour perfectionner son intégration avec Kubernetes, bien plus que toute autre technologie de conteneurisation.

D’ailleurs, Docker Inc., a réalisé l’ampleur que Kubernetes avait prise au point de livrer avec sa propre distribution Kubernetes son logiciel Docker for Desktop (MacOS et Windows).

Donc, si vous étiez hésitant à l’idée d’adopter Kubernetes pour votre produit basé sur Docker, ce dernier point devrait dissiper tous vos doutes.

Les deux projets se sont rencontrés et ont énormément bénéficié de leur symbiose.

Les conteneurs sont une avancée incroyable, car ils permettent de penser les services et les systèmes d’une manière complètement nouvelle et surtout numérique.

Kubernetes a donc de beaux jours devant lui et ne cessera de s’améliorer encore dans l’avenir.

FIDESIO vous accompagne dans la création de votre site Internet grâce à ses équipes de développeurs spécialisés dans les dernières technologies.

Notre agence Web est capable de répondre à tous vos besoins et d’élaborer une véritable stratégie digitale.

En quoi Kubernetes est-il différent de Docker Swarm ?

Docker Swarm a été créé par Docker Inc et s’est développé comme un orchestrateur pour Docker. Kubernetes a été créé à l’origine par Google pour un usage interne (le projet Borg), et maintenant tout le monde Open Source y travaille. Docker Swarm est un système fermé.

Tous deux tentent de résoudre le même problème : l’orchestration de conteneurs sur un grand nombre d’hôtes. Il s’agit de deux systèmes fondamentalement similaires, mais il existe tout de même des différences.

Kubernetes se développe beaucoup plus rapidement et occupe la majeure partie du marché (Kubernetes 51% et Docker Swarm 11%).
Docker Swarm est moins évolutif, il n’y a pas de support intégré pour l’équilibrage de charge, ce que K8S possède. En fait, Docker Swarm ne propose qu’une seule méthode d’équilibrage de charge, qui repose sur l’ouverture d’un port fixe pour chaque service sur chaque serveur inclus dans le cluster.
Contrairement à Docker Swarm, K8S offre une implémentation intégrée pour l’équilibrage de charge interne (est-ouest) et externe (nord-sud). L’équilibrage interne est assuré par l’objet Service et permet d’atteindre, à partir d’une application dans un cluster, toutes les instances vivantes d’une autre application en se référant à l’objet Service. Le Service est un équilibreur de charge interne, qui sait à chaque instant quel backend de l’application est vivant et lequel ne fonctionne pas et envoie les requêtes uniquement aux répliques vivantes.

L’équilibrage de charge externe dans Kubernetes est assuré par le concept NodePort (ouverture d’un port fixe sur l’équilibreur de charge), ainsi que par la primitive LoadBalancer intégrée, qui peut créer automatiquement un équilibreur de charge sur le site cloud si Kubernetes fonctionne dans un environnement cloud , par exemple AWS, Google Cloud, MS Azure, OpenStack, Hidora, etc. Docker Swarm ne fait pas support Auto-Scaling. Ni l’auto-scaling des conteneurs, ni l’auto-scaling des nœuds.

Kubernetes prend en charge toutes les mises à l’échelle automatiques possibles : mise à l’échelle verticale grâce à Vertical Pod Autoscaler, mise à l’échelle automatique horizontale des applications (Horizontal Pod Autoscaler), ainsi que la mise à l’échelle automatique du cluster lui-même (le nombre de nœuds) basée sur Cluster AutoScaler. Cluster Autoscaler ne fonctionne que si vous exécutez Kubernetes sur le site cloud.
Docker Swarm a des difficultés avec la surveillance, vous pouvez surveiller les conteneurs uniquement à l’aide d’outils propriétaires. Le stockage persistant pour les applications à état n’est pas pris en charge de manière native par Docker Swarm. Vous devez travailler avec un système de stockage en réseau, qui n’est pas adapté à tous les types de charges de travail.

Docker Swarm ne fonctionne qu’avec les conteneurs Docker. Alors que K8S peut fonctionner avec de nombreuses options d’exécution de conteneurs, comme Docker, Rocket, ContainerD, et d’autres. Ceci est très important car il n’y a pas de dépendance vis-à-vis de fonctionnalités spécifiques de Docker (certaines d’entre elles ne sont disponibles que dans Docker EE).

Pourquoi avez-vous besoin de l’orchestration des conteneurs ?

Déployez des applications sur des serveurs sans vous soucier de serveurs spécifiques.
Vous avez besoin d’orchestrateurs de conteneurs lorsque vous disposez d’une application microservice composée de plusieurs services, eux-mêmes composés de conteneurs. Et il y a une autre partie – les serveurs sur lesquels cette application peut s’exécuter.

L’orchestrateur de conteneurs effectue de nombreuses tâches. La première tâche consiste à placer initialement les conteneurs de votre application sur le nombre requis de serveurs, en tenant compte de la charge des serveurs, afin d’éviter que le conteneur n’atteigne le serveur surchargé, et en considérant également les besoins en mémoire et en processeur pour un conteneur particulier.

Faire évoluer l’application horizontalement vers le haut et vers le bas.
Il existe un autre scénario, lorsqu’une application doit être mise à l’échelle horizontalement, c’est-à-dire qu’il faut ajouter d’autres conteneurs du même type.

L’orchestrateur de conteneurs se charge d’augmenter ou de diminuer la taille des applications en tenant compte des ressources consommées sur chaque serveur cible, ainsi que des besoins en ressources de chaque application.

Dans ce cas, l’orchestrateur peut support les principes dits d’affinité et d’anfi-affinité. Ce dernier permet de garantir que, par exemple, tous les conteneurs du même type seront lancés de manière garantie sur des serveurs physiques différents.

Restaurer l’application si le serveur sur lequel elle fonctionnait tombe en panne.
C’est ce qu’on appelle l’auto-réparation ou la reprogrammation du conteneur.
Si le serveur tombe en panne, vous devez restaurer correctement l’application. K8S peut surveiller chaque conteneur/pod d’application pour voir si ce conteneur/pod est vivant ou non. Et si ce n’est pas le cas, Kubernetes le redémarre.

En fait, dans K8S, cette fonction s’appelle « maintenir le bon nombre de répliques ».

Dans le cas de Kubernetes, vous pouvez dire, je veux avoir 5 conteneurs de mon WordPress, et K8S s’assurera que vous avez toujours 5 conteneurs.

Si soudainement il y a moins de 5 conteneurs, Kubernetes lancera un nouveau conteneur pour maintenir la quantité. Ceci est important pour le traitement de l’application et la prévision de la charge.

K8S surveille également l’état des serveurs sur lesquels l’application est exécutée, et si le serveur est mort, il reprogrammera tous ses conteneurs sur d’autres serveurs.

Comment K8S se compare-t-il à OpenStack ?

Kubernetes est conçu pour gérer l’orchestration des conteneurs, et OpenStack est initialement conçu pour gérer les machines virtuelles. En d’autres termes, OpenStack est utilisé pour gérer les infrastructures virtuelles traditionnelles, et Kubernetes pour les conteneurs.

Il s’agit de deux systèmes différents, qui sont tous deux des systèmes Open Source, développés par la communauté. La différence est que Kubernetes a été développé à l’origine par Google pendant longtemps sous le nom de Borg et pendant cette période, il est devenu un service stable, même la première version était riche en fonctionnalités et assez stable.

OpenStack a été développé presque à partir de zéro par la communauté et OpenStack est très fragmenté.

La communauté et environ 30 entreprises différentes créent leurs propres versions. K8S est plus comme Apple, et OpenStack est plus comme Android.

Les frais généraux et les délais de mise sur le marché pour l’exploitation de Kubernetes en production sont beaucoup plus faibles qu’avec OpenStack.

En même temps, OpenStack gère les machines virtuelles, par exemple, KVM, Kubernetes peuvent fonctionner au-dessus d’OpenStack et c’est un scénario typique pour les fournisseurs cloud .

Kubernetes est-il uniquement destiné aux applications sans état ?

Kubernetes n’est pas seulement adapté aux applications sans état. Un exemple d’application sans état est généralement constitué par les applications web qui exécutent une fonction, fournissent des pages HTTP et ne stockent pas elles-mêmes leurs états.

Il a été conçu à l’origine pour les applications sans état et support pour les applications avec état était très limité et peu fiable.

Kubernetes prend en charge le concept de volume persistant et de réclamations de volume persistant. Il prend également en charge différents types de volumes, comme les stockages de blocs qui peuvent être montés sur des pods en mode exclusif, ainsi que les stockages de fichiers qui peuvent être montés sur plusieurs pods simultanément en utilisant le protocole NFS, par exemple.

Par conséquent, vous pouvez placer en toute sécurité des bases de données ou des files de messages persistantes dans Kubernetes.

Puis-je l’utiliser pour un déploiement hybride Cloud ? Multi-Cloud?

Initialement, K8S ne pouvait être déployé que dans un seul centre de données et le travail en mode hybride n’était pas disponible.

Ensuite, la fédération Kubernetes a été développée, ce qui a permis d’organiser un scénario hybride lorsqu’il y a plusieurs clusters Kubernetes dans différents centres de données qui sont contrôlés à partir d’un seul panneau de contrôle.

En fait, l’un des clusters devient le cluster fédéré principal et le panneau de contrôle hybride cloud y est installé. Grâce à lui, vous pouvez gérer les déploiements dans plusieurs clusters éloignés les uns des autres.

Mais c’est également possible dans le scénario multicloud . Supposons que vous ayez un cluster sur site, un cluster sur Amazon, un autre sur Google Cloud, tous seront pris en charge.

Dans le cas de plusieurs fournisseurs cloud , il n’est pas nécessaire d’adapter l’application pour travailler à la fois avec plusieurs clusters distants qui travaillent chez Google, Amazon, car le Kubernetes interprétera correctement les annotations dans leurs ressources pour chaque cloud.

Le projet de fédération Kubernetes v1 est en développement depuis longtemps et il est dans une impasse, la fédération Kubernetes v2 est en cours de développement, qui fonctionne fondamentalement d’une manière différente avec un hybride cloud.

Dois-je gérer un équilibreur de charge externe pour exécuter mes applications dans Kubernetes ?

Dans le cas de Docker Swarm, il était nécessaire de gérer un équilibreur de charge externe afin d’équilibrer la charge.

K8S contient un équilibrage automatique de la charge basé sur le concept des services et, en outre, un contrôleur d’entrée qui prend en charge l’équilibrage de la charge par nom et chemin DNS.

De nombreuses options sont prises en charge, il y a également une intégration avec l’équilibreur de charge cloud , si vous travaillez quelque part sur Amazon, google cloud ou open-stack, il y a une intégration prête à l’emploi avec ces équilibreurs de charge.

Quelle est la différence entre une cosse et un conteneur ?

Le problème est que les personnes qui viennent du monde de Docker ne travaillent qu’avec des conteneurs.

Ils essaient de transférer les connaissances qu’ils ont acquises en utilisant Docker Swarm et les conteneurs pour travailler avec Kubernetes. Mais cela ne fonctionne pas de cette façon. Dans Kubernetes, l’unité de contrôle est le pod, pas le conteneur.

Un pod est un groupe d’un ou plusieurs conteneurs qui remplissent la même fonction, c’est-à-dire qu’il s’agit d’un composant d’une seule application. Kubernetes gère les pods, les met à l’échelle et surveille leur état. L’application dans Kubernetes est mise à l’échelle par le nombre de pods, mais pas de conteneurs.

Dans un pod, il y a le plus souvent un conteneur, mais il peut y en avoir plusieurs et cet ensemble de conteneurs est fixé de manière rigide. À l’intérieur d’un pod, les conteneurs ne changent pas d’échelle, ce qui doit être pris en compte lors de la conception des applications.

Comment Kubernetes simplifie-t-il le déploiement de conteneurs ?

Plusieurs avantages que Kubernetes offre d’emblée :

N’hésitez pas à nous contacter. info@ sogesti.ch