Qu’est-ce que Kubernetes ?
Kubernetes est un système d’orchestration de clusters. Il a été conçu dès le départ pour être un environnement permettant de créer des applications distribuées à partir de conteneurs.
La principale tâche de Kubernetes est de construire et de gérer des systèmes distribués.
L’objectif de Kubernetes est de simplifier l’organisation et la programmation de votre application par le biais de la flotte. À un niveau élevé, il s’agit du système d’exploitation de votre cluster.
En gros, cela vous permet de ne pas vous soucier des machines spécifiques du centre de données qui exécutent les composants de votre application.
En outre, il fournit des primitives communes pour tester et répliquer votre application sur ces machines. Ainsi que des services pour connecter votre application à des microservices afin que chaque couche de votre application soit séparée des autres couches et que vous puissiez les faire évoluer / les mettre à jour / les maintenir indépendamment les unes des autres.
Bien que vous puissiez exécuter un grand nombre de ces fonctions au niveau de l’application, ces solutions sont généralement ponctuelles et peu fiables. Il est bien préférable de séparer les problèmes lorsque le système d’orchestration est responsable de l’exécution de l’application, et que vous ne pensez qu’au code de votre application.
Pourquoi Kubernetes est abrégé en k8s ?
Vous êtes-vous déjà demandé pourquoi Kubernetes a appelé le K8S ? Essayons de le découvrir ensemble !
Les « numéronymes » sont apparus à la fin des années 80. Il y a beaucoup d’histoires différentes sur la façon dont les gens ont commencé à les utiliser.
Mais toutes ces histoires partagent la même idée : pour simplifier la communication, les employés des entreprises informatiques ont commencé à utiliser des formes numérisées pour raccourcir les mots : en prenant la première et la dernière lettre et en mettant entre elles un certain nombre d’autres lettres.
Par exemple, le terme « i18n » est dérivé de son orthographe : la lettre « i » plus 18 lettres plus la lettre « n ». Il en va de même pour Kubernetes, « k » plus 8 lettres plus la lettre « s ».
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 :
- Dans Kubernetes, la découverte de services est intégrée, c’est-à-dire que lorsqu’un nouveau service apparaît, un nom de domaine unique lui est attribué et les autres services peuvent obtenir des informations sur ce service dans etcd.
- Le deuxième point est que Kubernetes offre des manifestes flexibles pour le déploiement d’applications qui support différentes stratégies de déploiement d’applications conteneurisées. Kubernetes dispose d’un déploiement canari support pour les tests a/b. Il existe également des contrôles de santé intégrés et une surveillance basée sur Prometheus.
- Kubernetes utilise une stratégie de mise à jour continue pour déployer les mises à jour des versions des pods. La stratégie de mise à jour continue permet d’éviter les temps d’arrêt de l’application en maintenant certaines instances en fonctionnement à tout moment pendant l’exécution des mises à jour. Lorsque les nouveaux pods de la nouvelle version de déploiement sont prêts à gérer le trafic, le système les active d’abord et n’arrête les anciens qu’ensuite.
