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 CEO 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.