Dans cet article, nous aborderons les sujets ci-dessous :
- Qu’est-ce que Kubernetes ?
- Principaux composants Kubernetes (K8s)
Qu’est-ce que Kubernetes?
Kubernetes est un framework d'orchestration de conteneurs open source développé par Google. Essentiellement, il contrôle la vitesse des conteneurs et vous aide à gérer des applications composées de plusieurs conteneurs. De plus, il vous permet de les exploiter dans différents environnements, par exemple des machines physiques, des machines virtuelles, des environnements Cloud ou même des environnements de déploiement hybrides.
Quels problèmes cela résout-il ?
L’émergence de la conteneurisation dans la technologie des microservices a donné naissance à des applications composées de plusieurs conteneurs.
Cependant, la gestion de ces conteneurs dans plusieurs environnements à l'aide de scripts et d'outils créés par l'entreprise peut s'avérer complexe. C'est pourquoi ce scénario spécifique a nécessité le développement de technologies d'orchestration de conteneurs, par exemple des outils d'orchestration tels que Kubernetes, qui garantissent les fonctionnalités suivantes :
- Haute disponibilité : en termes simples, cela signifie que l'application ne subit aucun temps d'arrêt et qu'elle est donc toujours accessible aux utilisateurs.
- L'évolutivité (ou scalabilité) suggère que l'application a des performances élevées, qu'elle se charge rapidement et que les utilisateurs ont des taux de réponse très élevés de la part de l'application.
- La reprise après sinistre indique qu'en cas de problème avec l'infrastructure (par exemple, les données ont été perdues, les serveurs ont explosé ou tout autre problème avec le centre de service s'est produit), il doit y avoir un mécanisme pour récupérer les données et les restaurer à la dernière version. afin que l'application principale ne perde aucune information et que l'application conteneurisée puisse s'exécuter à partir de l'état le plus récent après la récupération.
Principaux composants Kubernetes (K8s)
Ci-dessous, vous pouvez trouver un aperçu des composants principaux de Kubernetes :
Pod
Le Pod est un concept fondamental et l'un des composants essentiels de Kubernetes. Un Pod est la plus petite unité déployable dans Kubernetes, représentant une instance unique d'un processus en cours d'exécution dans un cluster. Il peut contenir un ou plusieurs conteneurs étroitement couplés et partageant le même espace de noms réseau, leur permettant de communiquer entre eux.
A quoi sert le pod ? Il crée un environnement d'exécution ou une couche au-dessus du conteneur Docker. Nous pouvons avoir un pod d'application pour notre application qui utilisera éventuellement un pod de base de données avec son conteneur. Un concept important ici est que nous nous attendons généralement à ce que le pod exécute un conteneur d'application à l'intérieur. Pourtant, vous pouvez également exécuter plusieurs conteneurs dans un seul pod, mais en général, cela ne se produit que si vous disposez du conteneur d'application principal et d'un conteneur d'assistance ou d'un service secondaire qui doit s'exécuter dans ce pod. Vous n’avez qu’un seul serveur et deux conteneurs exécutés dessus avec une couche d’abstraction au-dessus.
Kubernetes propose un réseau virtuel. Cela signifie que chaque pod obtient son adresse IP mais pas le conteneur. De ce fait, les pods peuvent communiquer entre eux en utilisant une adresse IP interne.
Les composants des pods dans Kubernetes ont également un autre concept important appelé « éphémère ». Cela signifie qu'ils peuvent mourir facilement, et lorsque cela se produit (par exemple, si vous perdez un conteneur de base de données parce qu'il est tombé en panne ou parce que les nœuds du serveur que vous utilisez sont à court de ressources), le pod mourra et un nouveau sera créé pour le remplacer. Lorsque cet événement se produit, un nouveau pod se verra attribuer une nouvelle adresse IP. Ce n'est pas pratique si vous communiquez avec la base de données en utilisant l'adresse IP car vous devrez désormais l'ajuster à chaque redémarrage du pod ; c'est pourquoi un autre composant de Kubernetes appelé « Service » est utilisé.
Service
Le service est une adresse IP statique ou permanente qui peut être attachée à chaque pod, ce qui signifie que l'application aura un service et que le pod de base de données aura un autre service. La bonne chose ici est que les cycles de vie du service et du Pod ne sont pas connectés, donc même si le Pod meurt, le service et son adresse IP resteront, indiquant que vous n'aurez plus à changer de point de terminaison.
Pour accéder à une application via le navigateur, vous devrez créer un service externe. C'est un service qui ouvre la communication à partir de sources externes. Cependant, vous ne voudriez évidemment pas que votre base de données soit ouverte aux demandes publiques. C'est pourquoi vous devrez développer ce qu'on appelle un service interne.
Ingress
Lorsque nous créons un service externe, nous spécifions généralement le protocole HTTP, une adresse IP de nœud et le numéro de port qui ressemble à http://129.80.102.2:8080. Bien que cela soit suffisant à des fins de test, pour le produit final, vous voudriez que votre URL ressemble à http://nom-de-domaine. C'est pourquoi un autre composant de Kubernetes appelé « Ingress » a été investi. Ainsi, au lieu du service, la demande est d'abord transmise à Ingress, qui la transmet ensuite au service.
ConfigMap
C'est une règle empirique d'établir une communication via un service. Dans ce cas, notre application aura un point de terminaison de base de données. Pourtant, où configurons-nous habituellement cette URL ou ce point de terminaison de base de données ? Généralement, nous le ferions dans le fichier de propriétés de l'application ou en tant que variable d'environnement externe. Cependant, généralement, il se trouve à l’intérieur de l’image construite de l’application. Par exemple, si le point final du service a changé, nous devrons ajuster cette URL dans l'application. Cela signifie que nous devrons reconstruire l'application avec une nouvelle version et la pousser vers le référentiel. Ensuite, nous devrons extraire cette nouvelle image dans notre pod et redémarrer le tout. Comme vous pouvez le constater, c'est un peu fastidieux pour un changement aussi minime qu'une URL de base de données. Pour cette raison, Kubernetes dispose d'un composant appelé « ConfigMap ».
Il contient généralement des données de configuration telles que les URL d'une base de données ou d'autres services que nous utilisons dans Kubernetes. Nous le connectons simplement au Pod pour qu'il puisse récupérer les données contenues dans ConfigMap. Désormais, si nous changeons le nom du service et le point de terminaison, il nous suffira d'ajuster la carte de configuration.
Il nous aide à gérer les changements de configuration indépendamment du code de l'application, ce qui facilite la modification des paramètres sans reconstruire ni redéployer l'application.
Secret
Mettre un mot de passe ou d'autres informations d'identification sur un « ConfigMap » au format texte brut peut ne pas être sécurisé, même s'il s'agit d'une configuration externe.
A cet effet, Kubernetes dispose d'un autre composant appelé « secret ». Il ressemble à ConfigMap, mais la différence est que nous l'utilisons pour stocker des informations d'identification de données secrètes et qu'il est conservé au format codé en base 64.
Tout comme nous l'avons fait avec ConfigMap, nous devons simplement connecter le secret à notre pod afin que le pod puisse voir les données et lire le secret.
Volume
Il est temps d’examiner de plus près un autre concept crucial : le stockage des données. Parfois, notre application utilise une base de données, et si le conteneur de base de données ou le Pod est redémarré, les données disparaîtront. C'est problématique et peu pratique car nous voulons que notre base de données ou nos données de journal persistent de manière fiable à long terme. La façon de le faire dans Kubernetes consiste à utiliser un autre composant appelé « Volumes ».
Il connecte le stockage physique sur un disque dur à votre pod. Le stockage peut être situé soit sur une machine locale (c'est-à-dire sur le même nœud de serveur sur lequel le pod est exécuté), soit sur un stockage distant (c'est-à-dire en dehors du cluster Kubernetes). Il peut s'agir d'un stockage cloud ou de votre stockage sur site qui ne fait pas partie du cluster Kubernetes. Cela suggère que vous avez une référence externe dessus. À ce stade, lorsque le pod ou le conteneur de base de données sera redémarré, toutes les données y seront conservées. Il s'agit d'un stockage distant. Vous pouvez simplement le considérer comme un disque dur externe branché sur le cluster Kubernetes.
Deployment
Que se passera-t-il si notre pod d'application meurt/plante ou si nous devons redémarrer le pod parce que nous avons construit une nouvelle image de conteneur ? Dans ce cas, nous aurons un certain temps d’arrêt lorsqu’un utilisateur pourra accéder à notre application. C'est une chose très négative si cela se produit en production, mais c'est précisément pourquoi les systèmes distribués et les conteneurs sont avantagés. Ainsi, au lieu de nous appuyer sur un seul pod, nous répliquons tout sur plusieurs serveurs. Ce plan s'appelle « Déploiement ».
Nous aurons donc maintenant un autre nœud sur lequel une réplique ou un clone de notre application peut s'exécuter. Il sera également connecté au service. Vous souvenez-vous que nous avons dit précédemment que le service était comme une adresse IP statique persistante avec un nom DNS ? Cela implique que vous n'avez pas besoin d'ajuster constamment le point de terminaison lorsqu'un pod meurt. Si l'une des répliques de votre pod d'application échoue, le service transmettra les requêtes à une autre, afin que notre application soit toujours accessible à l'utilisateur.
StatefulSet
De même, si notre module de base de données périt, nous devons également disposer d'une réplique de base de données. Néanmoins, nous ne pouvons pas dupliquer une base de données à l'aide du "Deployment". La raison en est que la base de données a un état qui correspond à ses données.
Cela suggère que si nous avons des clones ou des répliques de la base de données, ils devront tous accéder au même stockage de données partagé. Dans ce scénario, vous aurez besoin d'un mécanisme capable de gérer quels pods écrivent actuellement sur ce stockage et lesquels lisent à partir de là. Il est nécessaire d'éviter les incohérences des données. Ce mécanisme, en plus d'une fonctionnalité de réplication, est proposé par un autre composant Kubernetes appelé « StatefulSet ».
Les modules de base de données doivent toujours être développés à l'aide de StatefulSets pour garantir que la lecture et l'écriture de la base de données sont synchronisées.
Pour résumer, nous avons exploré les composants Kubernetes les plus courants :
- Nous avons commencé avec les pods et les services dont nous avions besoin pour communiquer entre eux.
- Ensuite, nous avons examiné le composant Ingress utilisé pour acheminer le trafic vers le cluster.
- Nous avons également examiné une configuration externe utilisant ConfigMaps et Secrets.
- Ensuite, nous avons analysé la persistance des données à l'aide de volumes.
- Enfin, nous avons jeté un coup d'œil rapide aux modèles de pods avec des mécanismes de réplication tels que les déploiements et les StatefulSets, ces derniers étant utilisés spécifiquement pour des applications avec état telles que les bases de données.
Merci