Qu’est-ce que Kubernetes? Comment l'orchestration redéfinit le centre de données

Qu’est-ce que Kubernetes ?

Le but de Kubernetes n’est pas immédiatement évident pour quiconque dont la conception de l’objectif et de la fonction d’un centre de données a été établie à l’époque où le système d’exploitation était la plate-forme dont dépendaient tous les logiciels. Kubernetes est le produit d'un réalignement massif et continu des ressources logicielles qui composent collectivement une application réseau. Cet alignement est centré sur un concept appelé charge de travail, qui est un concept large d'un travail effectué par une ou plusieurs applications, ou un ou plusieurs services, sur une multitude de processeurs.

Doit lire: Comment GitHub est devenu le lien de l'automatisation logicielle

Une charge de travail est un travail -- par exemple, gérer un chaîne d'approvisionnement, superviser la logistique, suivre les stocks, faciliter un marché de valeurs mobilières. Kubernetes est devenu le système de contrôle des tâches de l'ère moderne.

"Vous pouvez considérer Kubernetes comme une plate-forme pour les modèles d'application", a expliqué Janet Kuo, ingénieur logiciel chez Google, lors de l'événement. une session de tutoriel à la conférence KubeCon 2017. « Les modèles rendent votre application facile à déployer, à exécuter et à continuer d'exécuter. »

La vertu déclinante des machines virtuelles

Il existe une classe croissante de infrastructure de centre de données qui vise à se concentrer sur la santé et le bien-être des charges de travail plutôt que sur ceux des serveurs. Qu'il s'agisse de processeurs physiques ou de machines virtuelles, les serveurs peuvent tomber en panne. L'impact de cette panne sur la disponibilité et la fonctionnalité de ces charges de travail devrait être minime: elles ne devraient pas sembler affectées du tout.

Jusqu'en 2016, la communauté open source avait mis au point une poignée de méthodologies pour orchestrer les charges de travail pour une disponibilité maximale. En très peu de temps, Kubernetes est devenu le choix des entreprises ayant investi dans l’open source. Les raisons pour lesquelles cela pourrait constituer un livre entier, et s'il était suffisamment bien écrit, il pourrait être adapté à l'un de ces films de théâtre d'art qui séduisent la critique mais jamais les Oscars.

Lire aussi: Les fournisseurs de Kubernetes s'accordent sur la standardisation

C'est peut-être là la seule raison qui compte: la décision précoce de Google d'encourager la Linux Foundation à création de la Cloud Native Computing Foundation (CNCF) a donné à Kubernetes suffisamment de temps pour nourrir de manière organique une clientèle parmi le groupe de personnes le plus large. L’ensemble du modèle économique open source tourne autour de la valeur du support. Les entreprises qui ne souhaitent plus s’enfermer dans un seul fournisseur (qui, il est vrai, n’est pas le cas de tout le monde) apprécient la nouvelle valeur du pluralisme dans un système de support. Un groupe de vendeurs agissant, sinon toujours de concert, du moins avec un minimum de coordination vers le même objectif, est supérieur à un fournisseur unique dirigeant une plate-forme monopolistique dans aucun domaine particulier direction.

Pourquoi Kubernetes est important maintenant

Kubernetes n'appartient à aucune entreprise, bien qu'il soit basé sur un projet appelé Borg qui a été initialement développé en interne chez Google, et Google est souvent perçu comme le leader de facto du le Communauté de développement Kubernetes. Cela dit, Microsoft a complètement réorganisé toute sa philosophie de système serveur autour de Kubernetes et a embauché plusieurs de ses principaux créateurs. En tant que projet open source, Kubernetes est régi par la Cloud Native Computing Foundation (CNCF), une agence de la Linux Foundation.

Lire aussi: Kubernetes passe à un programme open source à part entière

Google a initialement conçu Borg pour répondre à ses propres objectifs internes. Il est donc plus que juste d'utiliser le moteur de recherche de Google lui-même comme exemple: le travail de base consistant à rechercher des correspondances les entrées dans une requête de recherche sont effectuées par des centaines, voire des milliers, de services individuels qui partagent le responsabilité. Je dirais « d'innombrables », mais ce n'est pas seulement faux, mais contraire à l'objectif même de Kubernetes. Il tient compte de tous les services et composants qui composent le ou les travaux actifs sur l'ensemble du réseau.

Docker n'a-t-il pas quelque chose à voir avec ça ?

Il n'existe malheureusement pas de meilleur terme à l'heure actuelle pour désigner le conteneur dans lequel ces morceaux de programmes distribués sont contenus que « conteneur ». (Pendant un moment, nous appelions ces choses "Conteneurs Docker» pour les distinguer des « conteneurs Tupperware », mais aujourd'hui, Docker ne comprend qu'une partie de l'écosystème des conteneurs; de plus, il existe plusieurs formats de conteneur.) Si vous connaissez un fichier ZIP, qui utilise des méthodes mathématiques compression pour regrouper plusieurs fichiers en un seul, alors vous comprenez déjà un peu les logiciels modernes conteneurs. Ils utilisent en fait la même méthode pour compresser plusieurs fichiers ensemble. Ces fichiers sont constitués uniquement des éléments exécutables et des données dont le programme aurait besoin pour s'exécuter, sans avoir à chercher ailleurs sur le réseau. L'un de ces éléments peut en réalité être un petit système d'exploitation -- une version miniaturisée de Linux, généralement, ou de Microsoft, un petit cousin de Windows appelé Nanoserveur.

Lire aussi: Comment obtenir l'aide Kubernetes dont vous avez besoin

Un programme écrit pour cette méthode de déploiement conteneurisé, tel qu'une réponse à une requête de recherche, pourrait rechercher dans un index de pages Web mises en cache une entrée qui n'a pas été trouvée. n'a pas encore été sélectionné, examinez le contexte sémantique de cette entrée pour rechercher des correspondances avec le contenu de la requête, classez le résultat et enregistrez-le dans une liste pour une collecte ultérieure et récupération. Le programme se terminerait alors. C'est l'une des caractéristiques d'un service distribué qui le rend si différent d'une application PC: il répond à une requête puis s'arrête. Il sait qu'il fait partie d'un travail beaucoup plus vaste, donc une fois qu'il remplit sa fonction, il cesse d'exister. Les ingénieurs logiciels empruntent un concept à la philosophie moderne pour décrire cet aspect: Éphémérisme. Contrairement à une application basée sur une interface graphique, qui passe littéralement la plupart de ses cycles à attendre une réponse de son utilisateur, un service éphémère remplit sa fonction puis expire.

Dans un réseau conteneurisé (encore une fois, désolé, mais il n'y a pas de meilleur mot), les programmes sont exécutés isolément les uns des autres. Même s'ils partagent le même processeur et le même espace mémoire, le système d'exploitation hôte en dehors des conteneurs maintient leur séparation. (En théorie, cette dépendance conjointe est exploitable, bien qu'aucun exploit menaçant connu n'existe encore dans la nature.) La communication ne peut avoir lieu entre les conteneurs que via un réseau défini par logiciel. Un SDN plus sophistiqué donnera à ces conteneurs des adresses réseau de manière stratégique, en tenant compte de la manière dont ils seront rassemblés pour effectuer une tâche commune.

Ce que signifie orchestrer les charges de travail

C’est ici que l’orchestration entre en scène. Contrairement à « conteneur », «orchestration" est un terme qui décrit parfaitement le rôle que joue Kubernetes. Même si certains ont illustré ce concept en utilisant un chef d'orchestre, il existe une grande différence entre un chef d'orchestre et un orchestrateur, tant en musique que dans les applications distribuées. L’acte d’orchestration définit les modèles permettant aux applications individuelles de fonctionner ensemble, de concert les unes avec les autres – comme les instruments d’un groupe. Tandis que le compositeur produit le motif original du logiciel, y compris sa ligne mélodique et son rythme (le terme désignant l'assemblage d'un conteneur logiciel est en fait une composition), l'orchestrateur réalise la pièce audible.

« C'est pourquoi j'appelle Kubernetes une « plateforme composable » », a expliqué Brian Gracely, directeur de la stratégie produit chez Red Hat, lors d'un récent webinaire de l'entreprise. "Il existe en quelque sorte un cadre sur ce à quoi cela devrait ressembler - et une partie de cela vient de Kubernetes. communauté, une partie vient d'années et d'années d'expérience au sein de la communauté, sur la façon de déployer applications."

Lire aussi: Pourquoi Docker adopte enfin Kubernetes

La tâche principale de l'orchestrateur est de maintenir l'état de fonctionnement des applications sous sa confiance. À une autre époque, cette tâche était confiée au système d’exploitation. Mais c’était à l’époque où la plate-forme n’était qu’un processeur unique doté d’une seule banque de mémoire et de périphériques de stockage dédiés. Aujourd’hui, il n’existe pas grand-chose pour lier matériellement un service conteneurisé au contexte plus large d’une application. (Avec la plus sophistiquée de ces architectures, utilisée par d'énormes services cloud tels que Netflix, un tel lien n'existe pas du tout.) En effet, c'est l'orchestrateur qui prend la fonctionnalité et le produit du travail de tous ces services, les organise sous une forme de manifeste et propose un semblant d'application. Modifiez le manifeste et vous pourriez avoir une application complètement différente.

Il n’y a rien de structurellement unique qui distingue Kubernetes de tout autre type d’application. Ce n'est pas une machine virtuelle. Son orchestrateur fonctionne sur un système opérateur. Lors de son exécution, il gère un cluster de nœuds, ce qui constitue une manière plus abstraite de faire référence à des serveurs pouvant être physiques ou virtuels. Sur chacun de ces nœuds se trouvent des pods de conteneurs. Et au sein de chacun d'eux se trouve un agent côté client appelé kubelet, qui gère les fonctions indépendamment au nom de l'orchestrateur, pour le nœud auquel il est affecté. Mais même cela est un programme comme les autres.

Lire aussi: Comment installer rapidement Kubernetes sur Ubuntu

Kubernetes n’est donc pas comme Hadoop, qui remodèle véritablement la structure des applications exécutées sur les serveurs. Pourtant, le modèle distribué apporté par cet orchestrateur est radicalement différent de celui qui prévalait jusqu’en 2016. Les modèles de déploiement ne changent pas avec le temps, comme la mode, la cuisine ou les plateformes politiques. Si nous sommes honnêtes, la montée en puissance soudaine de Kubernetes n’est pas due à un besoin soudain ressenti par toutes les entreprises du monde de diffuser de petits morceaux d’applications à travers le cloud. Kubernetes est né du besoin de Google de rendre ses charges de travail accessibles à l'échelle mondiale et gérables sur des dizaines de milliers de nœuds. Très peu d'autres organisations dans le monde ressemblent à Google ou auraient le profil de centre de données de Google. Toutes les entreprises ne disposent pas de leur propre moteur de recherche – ce qui, si vous y réfléchissez bien, explique pourquoi Google existe.

L'attrait des systèmes distribués

Alors pourquoi, exactement, Kubernetes ou l’orchestration de conteneurs ont-ils un quelconque attrait pour les entreprises? Les raisons de son véritable attrait ont moins à voir avec les charges de travail elles-mêmes, mais bien plus avec le modèle de développement et de déploiement qui les entoure :

Continuité: lorsqu'une application est composée de composants granulaires, il devient beaucoup plus facile de faire évoluer cette application de manière granulaire en mettant à jour et en améliorant ces composants individuellement. L'orchestrateur peut effectuer les ajustements appropriés en fonction de l'impact de ces changements individuels sur la charge de travail dans son ensemble. Les améliorations apportées aux fonctionnalités des applications ne doivent plus être mises en œuvre dans le cadre de refontes massives, ce qui, le plus souvent, a un impact négatif sur leur convivialité. La notion de intégration continue et livraison continue (CI/CD, le « D » signifiant souvent « déploiement ») peut être beaucoup plus facilement automatisé par un plate-forme conçue dès le départ pour comprendre le déploiement lui-même de manière plus petite et plus gérable. pas.

Résilience: Kubernetes gère des réplicas actifs de groupes de conteneurs, appelés jeux de réplicas, dans le but exprès de maintenir la disponibilité et la réactivité dans le cas où un conteneur ou un groupe de conteneurs (ce que Kubernetes appelle un pod) échoue. Cela signifie qu'un centre de données n'a pas besoin de répliquer l'intégralité de l'application et de déclencher un équilibreur de charge pour passer à l'application secondaire si le principal échoue. En fait, une pluralité de pods dans un jeu de réplicas sont généralement exécutés à tout moment, et le travail de l'orchestrateur consiste à maintenir cette pluralité tout au long de la durée de vie de l'application.

Lire aussi: Comment devenir développeur: une aide-mémoire

Évolutivité – Le principal gain pour les organisations qui orchestrent des charges de travail distribuées à l'aide de Kubernetes est la capacité intégrée pour que les charges de travail se multiplient dans le système si nécessaire – pour augmenter et diminuer à nouveau, conformément à la politique définie dans avance. Pour minimiser les risques de chaos, Kubernetes regroupe les conteneurs associés sous forme de pods. Un service appelé le autoscaler peut être configuré pour répliquer automatiquement les pods vers différents nœuds, lorsqu'il détermine que les ressources allouées à ces pods ne sont pas utilisées autant qu'elles pourraient l'être.

Kubernetes est-il la plateforme, ou autre chose ?

Il subsiste une certaine incertitude quant à savoir si Kubernetes est une plateforme au même titre que Microsoft Windows. VMware vSphere est une plate-forme: un fournisseur complet de tous les services et ressources nécessaires au fonctionnement des logiciels hébergés. efficacement. Indéniablement, Kubernetes est un « moteur », le principal élément fournissant la puissance à un système logiciel distribué. Pourtant, Kubernetes ne fournit pas lui-même ces éléments, tout comme le prédécesseur de Windows, MS-DOS, ne fournissait pas à l'origine son propre optimiseur de disque dur ni sa propre procédure de sauvegarde.

Mais comme le prétendent de nombreux utilisateurs, Kubernetes, en tant que moteur efficace, est le centre d’une plate-forme qui peut être composée d’un certain nombre de services capables de fonctionner en tandem. Certains diraient que l'objectif du CNCF actuel est de maintenir, de rassembler et de nourrir une pluralité d'autres projets indépendants et open source -- par exemple, la surveillance des systèmes tels que Prometheus, des gestionnaires de données de journaux tels que Fluentd (pas une faute de frappe) et des authentificateurs de contenu de confiance tels que Notary - qui peuvent collectivement comprendre un plate-forme. Au moment d'écrire ces lignes, la CNCF a certifié 59 distributions, dont beaucoup sont commerciales, présentant l'orchestrateur ainsi que d'autres outils CNCF ou les outils respectifs de leurs fournisseurs.

Lire aussi: La Linux Foundation propose un cours gratuit d'introduction à Kubernetes

"Vous verrez que Kubernetes ne fournit pas toutes ces choses", a déclaré Gracely de Red Hat. "Ce sont tous des domaines dans lesquels la communauté est présente, à travers différents fournisseurs, à travers des projets complémentaires open source, offrant au marché de nombreuses options, en leur donnant le choix, en leur donnant la possibilité de brancher ces différents éléments et en permettant aux entreprises de décider en fin de compte, dans ce cadre plus large, comment puis-je construire la meilleure plate-forme pour ce que nous voulons faire, choisir les meilleurs éléments qui ont du sens pour nous, tout en restant interopérables et supportable ?"

Pourtant, comme le démontre le commentaire de Gracely lui-même, puisque le produit de l'une de ces collections est incontestablement un plate-forme et Kubernetes en est le facilitateur au centre, alors tous ces résultats devraient être "Kubernetes plates-formes. » OpenShift de Red Hat en est un exemple marquant, ainsi que la dernière édition 2.0 de Rancher.

Où est le monolithe ?

Que Kubernetes soit perçu par les gestionnaires de centres de données et les DSI comme une plateforme ou comme un moteur n’est pas une question ésotérique ou anodine. Si l'orchestrateur veut continuer à progresser dans l'entreprise, il ne peut pas se permettre d'être traité comme une expérience de laboratoire, ou comme un de ces outils fous que les développeurs adorent mais que personne d'autre ne comprend. "Moteur" implique la nécessité d'un châssis complet (ou, pour emprunter une expression de mon autre travail, une "nouvelle pile"), et donne ainsi à certains évaluateurs l'impression qu'il est incomplet de par sa conception.

Une plate-forme doit donner à l'entreprise l'espoir qu'elle pourra bientôt héberger toutes ses applications, pas seulement les plus géniales avec les Q bouclés et les microservices. C'est pourquoi la CNCF présente Kubernetes comme une plateforme capable d'héberger aussi bien des applications anciennes que nouvelles via la conteneurisation, même si les avantages du transfert d'anciennes applications des machines virtuelles vers des conteneurs ne sont pas encore démontrés évalué.

Lire aussi: Kubernetes continue de s'améliorer

L'une des caractéristiques déterminantes des applications de l'ère pré-conteneurisation, par rapport aux modèles distribués, est leur incapacité à être décomposées, subdivisées ou mises à l'échelle. Les développeurs modernes qualifient ces applications de monolithiques. Lors d'une récente Sommet Open Source, le directeur exécutif de la CNCF, Dan Kohn, a vanté les vertus d'un modèle de transition pour les monolithes appelé « lift-and-shift ».

Il l'a défini comme « le concept selon lequel vous pouvez réellement prendre n'importe quel logiciel jamais écrit et l'emballer dans un conteneur. Nous avons été formés à considérer les conteneurs comme des éléments très sveltes qui ne contiennent qu'un nombre minimal de bibliothèques et exactement le minimum de logiciels nécessaires à leur exécution. Mais si vous disposez d’une application Java de huit Go, vous pouvez envelopper un conteneur autour de celle-ci. Le simple fait de le conteneuriser crée en fait une certaine valeur pour vous, avant même de le déplacer vers le cloud. »

Regroupés à la porte de départ

Le marché que Kohn et d'autres partisans de Kubernetes proposent aux entreprises est qu'une plate-forme basée sur Kubernetes ou intégrée à celui-ci sera au moins capable de prendre en charge des applications préexistantes - bien que dans un contexte ou un motif différent - en même temps, on lui fait confiance pour ouvrir la voie à ce complètement nouveau et apparemment étranger architecture.

Une nouvelle gamme de plates-formes d'hébergement d'applications basées sur le cloud public aidera la CNCF à faire passer son message, mais avec le conteneur plutôt que la machine virtuelle comme base du modèle commercial. Moteur Google Kubernetes (GKE, anciennement Google Container Engine), Service Azure Kubernetes (AKS, anciennement Azure Container Service), Service IBM Cloud Kubernetes (anciennement IBM Bluemix Container Service), Amazon Elastic Container Service pour Kubernetes (EKS), Service de conteneurs pivot (PKS, et peut-être ressentez-vous un thème avec ce « K » signifiant un mot « C »), et plus récemment Moteur VMware Kubernetes, font tous progresser le concept soudain très réel de conteneurs en tant que service (CaaS) en tant que forme évoluée de PaaS. Tout cela s’ajoute à OpenShift en ligne de Red Hat, qui a été le pionnier du concept CaaS avec Kubernetes.

Lire aussi: Kubernetes 1.10: améliorer le stockage, la sécurité et la mise en réseau

Vous pouvez désormais utiliser Docker pour composer un conteneur et n'importe laquelle de ces plates-formes CaaS pour héberger ce conteneur sur leurs propres clusters Kubernetes. Dans tous ces cas, le conteneur remplace la VM comme unité de consommation, vous n'avez donc plus besoin de mettre en place votre propre infrastructure virtuelle de votre côté du cloud, uniquement pour exécuter des applications.

C’est là que la révolution Kubernetes portera ses fruits. À l'heure actuelle, il existe un marché très sain dans la fourniture de ressources basées sur le cloud uniquement pour l'hébergement d'applications, et non pour les systèmes d'exploitation virtualisés sur lesquels elles sont installées. Il s'agit d'un marché si sain et si soudain que VMware n'a eu d'autre choix que de le rejoindre. À mesure que de nouvelles applications non monolithiques sont créées, développées et amenées à maturité dans le cloud public, le signe de le succès de ce marché dépendra de la rapidité avec laquelle les entreprises cesseront de se soucier de savoir si et comment mettre en œuvre soulever et déplacer.

En savoir plus - Depuis le réseau CBS Interactive

• Kubernetes dirigera le centre de données hyperscale en 2018
• Qu’est-ce que l’hyperconvergence? Voici comment cela fonctionne et pourquoi c'est important
• Red Hat et Microsoft apportent OpenShift à Azure

Autre part

• Kubernetes est-il déjà devenu trop complexe pour l’informatique d’entreprise ?
• Contexte: Kubernetes, OpenStack et comment SAP a construit sa propre plate-forme conteneurisée
• L'état de l'écosystème Kubernetes