Qu'est-ce que Kubernetes?

Qu'est-ce que Kubernetes? Et quelle est son architecture?

La conteneurisation a réduit le cordon entre les développeurs de logiciels et l'environnement de production. Pas dans le sens où vous n'avez pas du tout besoin d'un système de production, mais vous n'avez pas à vous soucier de la spécificité de l'environnement de production.

Les applications sont désormais regroupées avec les dépendances dont ils ont besoin, dans un conteneur léger au lieu d'une machine virtuelle. C'est super! Cependant, il ne fournit pas l'immunité contre les défaillances du système, la défaillance du réseau ou les défaillances du disque. Par exemple, si le centre de données, où vos serveurs fonctionnent, est sous la maintenance, votre application sera hors ligne.

Kubernetes entre en scène pour résoudre ces problèmes. Il prend l'idée de conteneurs et l'étend pour fonctionner sur plusieurs nœuds de calcul (qui pourraient être des serveurs virtuels hébergés en nuage ou des serveurs en métal nu). L'idée est d'avoir un système distribué pour les applications conteneurisées pour fonctionner.

Pourquoi Kubernetes?

Maintenant, pourquoi auriez-vous besoin d'avoir un environnement distribué en premier lieu?

Pour plusieurs raisons, d'abord et avant tout est la haute disponibilité. Vous voulez que votre site Web de commerce électronique reste en ligne 24/7, ou vous perdrez des affaires, utilisez Kubernetes pour cela. Le deuxième est l'évolutivité, où vous voulez évoluer «sortir». La mise à l'échelle ici implique d'ajouter plus de nœuds de calcul pour donner à votre application croissant plus d'espace pour les jambes pour fonctionner.

Conception et architecture

Comme tout système distribué, un cluster Kubernetes a un nœud maître, puis beaucoup de nœuds de travailleurs, c'est là que vos applications s'exécuteraient réellement. Le maître est responsable de la planification des tâches, de la gestion des charges de travail et de l'ajout de nouveaux nœuds en toute sécurité au cluster.

Maintenant, bien sûr, le nœud maître lui-même peut échouer et emporter le cluster entier avec lui, donc Kubernetes vous permet en fait d'avoir plusieurs nœuds maître pour la redondance.

Une vue sur les yeux d'un déploiement typique de Kubernetes

Maître de Kubernetes

Le maître de Kubernetes est ce que l'équipe DevOps interagit et utilise pour provisionner de nouveaux nœuds, déploier de nouvelles applications et surveillance et gestion des ressources. La tâche la plus élémentaire du nœud maître est de calendrier La charge de travail efficace parmi tous les nœuds de travailleur pour maximiser l'utilisation des ressources, améliorer les performances et suivre diverses politiques choisies par l'équipe DevOps pour leur charge de travail particulière.

Un autre composant important est le etcd qui est un démon qui garde une trace des nœuds de travailleur et conserve une base de données stockant l'état de l'ensemble du cluster. Il s'agit d'un magasin de données de valeur clé, qui peut également s'exécuter sur un environnement distribué sur plusieurs nœuds maître. Le contenu de etcd donne toutes les données pertinentes sur l'ensemble du cluster. Un nœud de travailleur examinerait de temps en temps le contenu de etcd pour déterminer comment il devrait se comporter.

Manette est l'entité qui prendrait les instructions du serveur API (que nous couvrirons plus tard) et effectuerait les actions nécessaires comme la création, la suppression et la mise à jour des applications et des packages.

Le Serveur API Expose l'API Kubernetes, qui utilise des charges utiles JSON sur HTTPS, pour communiquer avec l'interface utilisateur que les équipes du développeur ou le personnel de DevOps finiraient par interagir avec. L'interface utilisateur Web et la CLI consomme cette API pour interagir avec le cluster Kubernetes.

Le serveur API est également responsable de la communication entre les nœuds de travail et divers composants de nœuds maître comme etcd.

Le nœud maître n'est jamais exposé à l'utilisateur final car il risquerait la sécurité de l'ensemble du cluster.

Nœuds kubernetes

Une machine (physique ou virtuelle) aurait besoin de quelques composants importants qui, une fois installés et configurés, peuvent ensuite transformer ce serveur en un membre de votre cluster Kubernetes.

La première chose dont vous aurez besoin est un runtime de conteneur, comme Docker, installé et exécuté dessus. Il sera responsable de la rotation et de la gestion des conteneurs, évidemment.

Avec le runtime docker, nous avons également besoin du Kublet démon. Il communique avec les nœuds maîtres, via le serveur API et interroge l'ETCD, et rend les informations de santé et d'utilisation sur les pods qui fonctionnent sur ce nœud.

Cependant, les conteneurs sont assez limité Gousses.

Pourquoi trouver des gousses?

Docker a une stratégie d'exécution d'une application par conteneur. Souvent décrit comme le "Un processus par conteneur" politique. Cela signifie que si vous avez besoin d'un site WordPress, vous êtes encouragé à avoir deux conteneurs un pour que la base de données puisse fonctionner et un autre pour que le serveur Web puisse fonctionner. Boundling ces composants connexes d'une application dans un pod garantissent que chaque fois que vous évoluez, les deux conteneurs interdépendants coexistent toujours sur le même nœud, et ainsi se parler rapidement et facilement.

Les pods sont l'unité fondamentale de déploiement à Kubernetes. Lorsque vous évoluez, vous ajoutez plus de pods au cluster. Chaque pod reçoit sa propre adresse IP unique dans le réseau interne du cluster.

Retour au nœud Kubernetes

Maintenant, un nœud peut exécuter plusieurs pods et il peut y avoir de nombreux nœuds de ce type. Tout va bien jusqu'à ce que vous pensiez à essayer de communiquer avec le monde extérieur. Si vous avez un service Web simple, comment indiqueriez-vous votre nom de domaine vers cette collection de pods avec de nombreuses adresses IP?

Tu ne peux pas, et tu n'as pas à! Kube est la dernière pièce du puzzle qui permet aux opérateurs d'exposer certaines gousses à Internet. Par exemple, votre front-end peut être rendu publiquement accessible et le kube-proxy distribuerait le trafic entre toutes les différentes pods qui sont responsables de l'hébergement de la frontale. Cependant, votre base de données n'a pas besoin d'être rendue publique et Kube-Proxy ne permettrait que la communication interne pour de telles charges de travail liées.

Avez-vous besoin de tout cela?

Si vous commencez tout juste en tant que amateur ou étudiant, l'utilisation de Kubernetes pour une application simple serait en fait inefficace. L'ensemble de Rigmarole consommerait plus de ressources que votre application réelle et ajouterait plus de confusion pour un seul individu.

Cependant, si vous allez travailler avec une grande équipe et déployer vos applications pour une utilisation commerciale sérieuse, Kubernetes vaut l'ajout des frais généraux. Vous pouvez empêcher les choses de devenir chaotiques. Faire de la place pour l'entretien sans aucun temps d'arrêt. Configurez les conditions de test Nifty A / B et évoluent progressivement sans dépenser trop dans l'infrastructure à l'avance.