stockage SSD redondant ultra-rapide

10 faits fondamentaux sur Kubernetes que vous ne connaissiez pas

Kubernetes est une tendance croissante. Ces derniÚres années, la technologie K8S a connu une ascension rapide, passant d'un petit projet open source de Google au projet principal de la Cloud Native Computing Foundation (CNCF).

Aujourd'hui, de nombreuses organisations et entreprises l'utilisent pour automatiser la gestion des applications conteneurisées. Mais il y a encore beaucoup de questions autour de Kubernetes, dans cet article, je vais essayer de répondre aux plus populaires.

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.

 

Écrit par

Matthieu Robin PDG de Hidora
Matthieu ROBIN
29/04/2019

Matthieu Robin est le CEO de Hidora, un leader stratĂ©gique expĂ©rimentĂ©, un ancien administrateur systĂšme qui a gĂ©rĂ© et configurĂ© plus d'environnements manuellement que quiconque sur la planĂšte et aprĂšs avoir compris que cela pouvait ĂȘtre fait en quelques clics a crĂ©Ă© Hidora SA. Il intervient rĂ©guliĂšrement lors de confĂ©rences et aide les entreprises Ă  optimiser leurs processus mĂ©tier grĂące Ă  DevOps. Suivez-le sur Twitter @matthieurobin.