Qu'est-ce que Kubernetes?

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

La conteneurisation a coupé 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 elles ont besoin, dans un conteneur léger au lieu d'une machine virtuelle. C'est super! Cependant, il ne fournit pas d'immunité contre les pannes du système, les pannes de réseau ou les pannes de disque. Par exemple, si le centre de données, où vos serveurs sont en cours d'exécution, est en maintenance, votre application sera déconnectée.

Kubernetes entre en scène pour résoudre ces problèmes. Il reprend l'idée des conteneurs et l'étend pour qu'il fonctionne sur plusieurs nœuds de calcul (qui peuvent être une machine virtuelle hébergée dans le cloud ou des serveurs bare metal). L'idée est d'avoir un système distribué pour que les applications conteneurisées s'exécutent sur.

Pourquoi Kubernetes?

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

Pour de multiples raisons, la haute disponibilité est avant tout. Vous voulez que votre site e-commerce reste en ligne 24h/24 et 7j/7, ou vous perdrez des affaires, utilisez Kubernetes pour cela. Deuxièmement, l'évolutivité, là où vous souhaitez évoluer. La mise à l'échelle ici implique l'ajout de plus de nœuds de calcul pour donner à votre application en pleine croissance plus d'espace pour fonctionner.

Conception et architecture

Comme tout système distribué, un cluster Kubernetes a un nœud maître, puis de nombreux nœuds de travail, où 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 sécurisé de nouveaux nœuds au cluster.

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

Vue d'ensemble d'un déploiement Kubernetes typique

Maître Kubernetes

Le maître Kubernetes est ce avec quoi l'équipe DevOps interagit et utilise pour provisionner de nouveaux nœuds, déployer de nouvelles applications et surveiller et gérer les ressources. La tâche la plus basique du nœud maître est de horaire la charge de travail efficacement entre tous les nœuds de travail 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 élément important est le etcd qui est un démon qui garde une trace des nœuds de travail et conserve une base de données stockant l'état de l'ensemble du cluster. Il s'agit d'un magasin de données clé-valeur, qui peut également s'exécuter sur un environnement distribué sur plusieurs nœuds maîtres. Le contenu d'etcd donne toutes les données pertinentes sur l'ensemble du cluster. Un nœud de travail examinerait le contenu d'etcd de temps en temps pour déterminer comment il devrait se comporter.

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

le Serveur d'API expose l'API Kubernetes, qui utilise des charges utiles JSON sur HTTPS, pour communiquer avec l'interface utilisateur avec laquelle les équipes de développeurs ou le personnel DevOps finiraient par interagir avec. L'interface utilisateur Web et la CLI utilisent toutes deux 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 du nœud maître comme etcd.

Le nœud maître n'est jamais exposé à l'utilisateur final car cela mettrait en péril 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 correctement, peuvent ensuite transformer ce serveur en membre de votre cluster Kubernetes.

La première chose dont vous aurez besoin est un environnement d'exécution de conteneur, comme Docker, installé et exécuté dessus. Il sera chargé de faire tourner et de gérer les conteneurs, évidemment.

En plus du runtime Docker, nous avons également besoin du Kubelet démon. Il communique avec les nœuds maîtres, via le serveur API et interroge l'etcd, et renvoie des informations sur la santé et l'utilisation des pods qui s'exécutent sur ce nœud.

Cependant, les conteneurs sont assez limités en eux-mêmes, donc Kubernetes a une abstraction plus élevée construite au-dessus d'une collection de conteneurs, connue sous le nom de Pods.

Pourquoi proposer des dosettes?

Docker a pour politique d'exécuter 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 la base de données et un autre pour le serveur Web. Le regroupement de ces composants connexes d'une application dans un pod garantit que, chaque fois que vous effectuez une mise à l'échelle, les deux conteneurs interdépendants coexistent toujours sur le même nœud et communiquent ainsi rapidement et facilement.

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

Retour au nœud Kubernetes

Désormais, 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 pointez-vous votre nom de domaine vers cette collection de pods avec de nombreuses adresses IP?

Vous ne pouvez pas, et vous n'avez pas à! Kube-proxy est la dernière pièce du puzzle qui permet aux opérateurs d'exposer certains pods à Internet. Par exemple, votre front-end peut être rendu accessible au public et le kube-proxy répartirait le trafic entre tous les différents pods responsables de l'hébergement du front-end. Cependant, votre base de données n'a pas besoin d'être rendue publique et kube-proxy autoriserait uniquement la communication interne pour de telles charges de travail liées au back-end.

Avez-vous besoin de tout cela?

Si vous débutez en tant qu'amateur ou étudiant, utiliser Kubernetes pour une application simple serait en fait inefficace. L'ensemble du 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 la peine d'être ajouté. Vous pouvez empêcher les choses de devenir chaotiques. Faites de la place pour la maintenance sans aucun temps d'arrêt. Configurez des conditions de test A/B astucieuses et évoluez progressivement sans trop dépenser pour l'infrastructure en amont.