{"id":81130,"date":"2020-05-11T01:42:39","date_gmt":"2020-05-10T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo"},"modified":"2020-05-11T01:42:39","modified_gmt":"2020-05-10T23:42:39","slug":"kubernetes-open-source-protiv-vendorskogo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo","title":{"rendered":"Kubernetes : open source contre propri\u00e9taire","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour, je m'appelle Dmitry Krasnov. Cela fait plus de cinq ans que je m'occupe de l'administration des clusters Kubernetes et de la construction d'architectures microservices complexes. Au d\u00e9but de cette ann\u00e9e, nous avons lanc\u00e9 un service de gestion de clusters Kubernetes bas\u00e9 sur Containerum. Profitant de l'occasion, je vais expliquer ce qu'est exactement Kubernetes et en quoi l'int\u00e9gration avec un fournisseur diff\u00e8re de l'open source.<\/b><\/p>\n

Pour commencer, qu'est-ce que Kubernetes<\/a><\/noindex>. C'est un syst\u00e8me de gestion des conteneurs sur un grand nombre d'h\u00f4tes. En grec, cela se traduit d'ailleurs par \u00ab pilote \u00bb ou \u00ab barreur \u00bb. Initialement d\u00e9velopp\u00e9 par Google, il a ensuite \u00e9t\u00e9 transmis \u00e0 la Cloud Native Computing Foundation, une organisation internationale \u00e0 but non lucratif qui regroupe les principaux d\u00e9veloppeurs mondiaux, les utilisateurs finaux et les fournisseurs de technologies de conteneur. <\/p>\n

\"Kubernetes
\n<\/a><\/noindex><\/p>\n

G\u00e9rer un grand nombre de conteneurs <\/h3>\n

\nVoyons maintenant ce que sont ces conteneurs. Ce sont des applications avec tout leur environnement \u2013 principalement, les biblioth\u00e8ques dont d\u00e9pend le bon fonctionnement du programme. Tout cela est emball\u00e9 dans des archives et pr\u00e9sent\u00e9 sous forme d'image, qui peut \u00eatre ex\u00e9cut\u00e9e ind\u00e9pendamment du syst\u00e8me d'exploitation, test\u00e9e, et plus encore. Mais il y a un probl\u00e8me : g\u00e9rer des conteneurs sur un grand nombre d'h\u00f4tes est tr\u00e8s difficile. C'est pourquoi Kubernetes a \u00e9t\u00e9 cr\u00e9\u00e9. <\/p>\n

L'image d'un conteneur repr\u00e9sente une application plus ses d\u00e9pendances. L'application, ses d\u00e9pendances et l'image du syst\u00e8me de fichiers de l'OS sont r\u00e9parties dans diff\u00e9rentes parties de l'image, appel\u00e9es couches. Les couches peuvent \u00eatre r\u00e9utilis\u00e9es pour diff\u00e9rents conteneurs. Par exemple, une couche de base Ubuntu peut \u00eatre utilis\u00e9e pour toutes les applications de l'entreprise. Lors du lancement des conteneurs, il n'est pas n\u00e9cessaire de conserver de nombreuses copies de cette couche de base sur l'h\u00f4te. Cela permet d'optimiser le stockage et la distribution des images.<\/p>\n

Lorsque nous souhaitons ex\u00e9cuter une application \u00e0 partir d'un conteneur, les couches n\u00e9cessaires se superposent pour former un syst\u00e8me de fichiers superpos\u00e9. Une couche d'\u00e9criture est ajout\u00e9e par-dessus, qui est supprim\u00e9e lorsque le conteneur s'arr\u00eate. Cela garantit qu'\u00e0 chaque lancement du conteneur, l'application dispose toujours du m\u00eame environnement, qui ne peut \u00eatre modifi\u00e9. Cela assure la reproductibilit\u00e9 de l'environnement sur diff\u00e9rents syst\u00e8mes d'exploitation h\u00f4tes. Que ce soit Ubuntu ou CentOS, l'environnement sera toujours identique. De plus, le conteneur est isol\u00e9 de l'h\u00f4te gr\u00e2ce aux m\u00e9canismes int\u00e9gr\u00e9s au noyau Linux. Les applications dans le conteneur ne voient pas les fichiers ni les processus de l'h\u00f4te et des conteneurs voisins. Cette isolation des applications par rapport \u00e0 l'OS h\u00f4te offre une couche de s\u00e9curit\u00e9 suppl\u00e9mentaire. <\/p>\n

Pour g\u00e9rer les conteneurs sur l'h\u00f4te, il existe de nombreux outils. Le plus populaire d'entre eux est Docker. Il permet d'assurer l'ensemble du cycle de vie des conteneurs. Cependant, il fonctionne uniquement sur un seul h\u00f4te. Si la gestion de conteneurs sur de nombreux h\u00f4tes est n\u00e9cessaire, Docker peut rendre la vie des ing\u00e9nieurs difficile. C'est pourquoi Kubernetes a \u00e9t\u00e9 cr\u00e9\u00e9.<\/p>\n

La demande pour Kubernetes r\u00e9side pr\u00e9cis\u00e9ment dans sa capacit\u00e9 \u00e0 g\u00e9rer des groupes de conteneurs sur de nombreux h\u00f4tes comme s'il s'agissait d'entit\u00e9s uniques. La popularit\u00e9 du syst\u00e8me est due \u00e0 la possibilit\u00e9 de construire des op\u00e9rations DevOps, o\u00f9 Kubernetes est utilis\u00e9 pour ex\u00e9cuter les processus de ce m\u00eame DevOps.<\/p>\n

\"Kubernetes
\n
\nFigure 1. Repr\u00e9sentation sch\u00e9matique du fonctionnement de Kubernetes<\/i><\/p>\n

Automatisation compl\u00e8te<\/h3>\n

\nDevOps, en principe, repr\u00e9sente l'automatisation du processus de d\u00e9veloppement. En gros, les d\u00e9veloppeurs \u00e9crivent du code, qui est ensuite t\u00e9l\u00e9charg\u00e9 dans un r\u00e9f\u00e9rentiel. Ce code peut ensuite \u00eatre automatiquement compil\u00e9 dans un conteneur avec toutes les biblioth\u00e8ques, test\u00e9 et 'd\u00e9ploy\u00e9' \u00e0 l'\u00e9tape suivante - Staging, puis imm\u00e9diatement en Production.<\/p>\n

Avec Kubernetes, DevOps permet d'automatiser ce processus de mani\u00e8re presque \u00e0 ne demander aucune intervention des d\u00e9veloppeurs. Cela acc\u00e9l\u00e8re consid\u00e9rablement la construction, car le d\u00e9veloppeur n'a pas besoin de le faire sur son ordinateur \u2014 il \u00e9crit simplement un morceau de code, le pousse dans le d\u00e9p\u00f4t, puis un pipeline se d\u00e9clenche, qui peut inclure le processus de construction, de test et de d\u00e9ploiement. Cela se produit pour chaque commit, assurant ainsi un test continu.<\/p>\n

L'utilisation de conteneurs garantit que tout l'environnement de ce programme sera d\u00e9ploy\u00e9 en production exactement comme il a \u00e9t\u00e9 test\u00e9. Cela \u00e9vite les probl\u00e8mes du type \u00ab les versions \u00e9taient diff\u00e9rentes en test et en production, et maintenant tout est tomb\u00e9 \u00bb. \u00c9tant donn\u00e9 qu'aujourd'hui nous avons une tendance vers l'architecture microservices, o\u00f9 au lieu d'une \u00e9norme application, il y a des centaines de petites, la gestion manuelle n\u00e9cessiterait un grand nombre d'employ\u00e9s. C'est pourquoi nous utilisons Kubernetes.<\/p>\n

<\/p>\n

Avantages, avantages, avantages<\/h3>\n

<\/b>
\nEn ce qui concerne les atouts de Kubernetes en tant que plateforme, il pr\u00e9sente des avantages significatifs en mati\u00e8re de gestion de l'architecture microservices. <\/p>\n