Fonctionnement des déploiements Kubernetes
L’application de suivi de drones a plusieurs composants déployés séparément les uns des autres. Votre travail consiste à configurer les déploiements pour ces composants sur le cluster. Ici, vous examinerez quelques-unes des options de déploiement à votre disposition pour déployer ces composants.
Options de déploiement des pods
Il existe plusieurs options pour gérer le déploiement de pods dans un cluster Kubernetes quand vous utilisez kubectl. Les options sont :
- Modèles de pods
- Contrôleurs de réplication
- Jeux de réplicas
- Déploiements
Vous pouvez utiliser l’une de ces quatre définitions de type d’objet Kubernetes pour déployer un ou plusieurs pods. Ces fichiers utilisent YAML pour décrire l’état prévu du pod ou des pods à déployer.
Qu’est-ce qu’un modèle de pod ?
Un modèle de pod vous permet de définir la configuration du pod que vous souhaitez déployer. Le modèle contient des informations, comme le nom de l’image conteneur et le registre de conteneurs à utiliser pour extraire les images. Le modèle inclut également des informations de configuration d'exécution, notamment les ports à utiliser. Les modèles sont définis en utilisant YAML de la même façon que lorsque vous créez des fichiers Docker.
Vous pouvez utiliser des modèles pour déployer des pods manuellement. Toutefois, un pod déployé manuellement n’est pas relancé s’il échoue, s’il est supprimé ou s’il est arrêté. Pour gérer le cycle de vie d’un pod, vous devez créer un objet Kubernetes de niveau supérieur.
Qu’est-ce qu’un contrôleur de réplication ?
Un contrôleur de réplication utilise des modèles de pod et définit un nombre spécifié de pods qui doivent s’exécuter. Le contrôleur vous permet d’exécuter plusieurs instances du même pod et garantit que les pods sont toujours en cours d’exécution sur un ou plusieurs nœuds du cluster. Le contrôleur remplace les pods en cours d’exécution de cette façon par de nouveaux pods s’ils échouent, sont supprimés ou sont arrêtés.
Par exemple, supposons que vous déployez le site web front-end de suivi de drones et que les utilisateurs commencent à accéder au site web. Si, pour une raison ou une autre, tous les pods échouent, le site web n’est pas disponible pour vos utilisateurs, sauf si vous lancez de nouveaux pods. Un contrôleur de réplication vous permet de vérifier que votre site web est toujours disponible.
Qu’est-ce qu’un jeu de réplicas ?
Un jeu de réplicas remplace le contrôleur de réplication comme méthode préférée pour déployer des réplicas. Un jeu de réplicas inclut les mêmes fonctionnalités qu’un contrôleur de réplication, mais il dispose d’une option de configuration supplémentaire pour inclure une valeur de sélecteur.
Un sélecteur permet au jeu de réplicas d’identifier tous les pods en cours d’exécution sous celui-ci. Avec cette fonctionnalité, vous pouvez gérer des pods étiquetés avec la même valeur que celle du sélecteur, mais qui ne sont pas créés avec le jeu de réplicas.
Qu’est-ce qu’un déploiement ?
Un déploiement crée un objet de gestion d’un niveau supérieur à un jeu de réplicas et vous permet de déployer et gérer des mises à jour pour les pods dans un cluster.
Supposons que vous avez cinq instances de votre application déployées dans votre cluster. Cinq pods exécutent la version 1.0.0 de votre application.
Si vous décidez de mettre à jour manuellement votre application, vous pouvez supprimer tous les pods, puis lancer de nouveaux pods qui exécutent la version 2.0.0 de votre application. Avec cette stratégie, votre application subit un temps d'arrêt.
Vous souhaitez plutôt effectuer une mise à jour propagée en lançant des pods avec la nouvelle version de votre application avant de supprimer les pods de l'ancienne version. Les mises à jour propagées lancent un pod à la fois au lieu d'arrêter tous les pods les plus anciens en même temps. Les déploiements respectent le nombre de réplicas configurés dans la section qui décrit les informations sur les jeux de réplicas. Le nombre de pods spécifié est conservé dans le jeu de réplicas quand les anciens pods sont remplacés par de nouveaux pods.
Par défaut, les déploiements fournissent une stratégie de mise à jour propagée pour la mise à jour des pods. Vous pouvez également utiliser une stratégie de recréation. Cette stratégie met fin aux pods avant de lancer de nouveaux pods.
Les déploiements vous fournissent également une stratégie d’annulation que vous pouvez exécuter avec kubectl.
Les déploiements utilisent des fichiers de définition basés sur YAML et facilitent la gestion des déploiements. Gardez à l’esprit que les déploiements vous permettent d’appliquer n’importe quelle modification à votre cluster. Par exemple, vous pouvez déployer de nouvelles versions d’une application, mettre à jour des étiquettes et exécuter d’autres réplicas de vos pods.
kubectl offre une syntaxe pratique pour créer automatiquement un déploiement quand vous utilisez la commande kubectl run pour déployer un pod. Cette commande crée un déploiement avec le jeu de réplicas et les pods requis. La commande ne crée cependant pas de fichier de définition. Une bonne pratique consiste à gérer tous les déploiements avec des fichiers de définition de déploiement et à suivre les modifications en utilisant un système de contrôle de versions.
Points à prendre en considération pour le déploiement
Kubernetes a des exigences spécifiques quant à la façon dont vous configurez le réseau et le stockage pour un cluster. La façon dont vous configurez ces deux aspects affecte vos décisions concernant l’exposition de vos applications sur le réseau de cluster et le stockage des données.
Par exemple, chaque service de l’application de suivi de drones a des exigences spécifiques pour l’accès utilisateur, pour l’accès réseau inter-processus et pour le stockage des données. À présent, examinons ces aspects d’un cluster Kubernetes et la façon dont ils influencent le déploiement des applications.
Réseau Kubernetes
Supposons que vous ayez un cluster avec un plan de contrôle et deux nœuds. Quand vous ajoutez des nœuds à Kubernetes, une adresse IP est affectée automatiquement à chaque nœud à partir d’une plage de réseau privé interne. Par exemple, supposons que votre plage réseau locale est 192.168.1.0/24.
Chaque pod déployé se voit affecter une adresse IP d’un pool d’adresses IP. Par exemple, supposons que votre configuration utilise la plage réseau 10.32.0.0/12, comme dans l’image suivante.
Par défaut , les pods et les nœuds ne peuvent pas communiquer entre eux en utilisant les différentes plages d’adresses IP.
Pour compliquer encore les choses, rappelez-vous que les pods sont temporaires. L’adresse IP du pod est temporaire et ne peut pas être utilisée pour se reconnecter à un pod nouvellement créé. Cette configuration influence la façon dont votre application communique avec ses composants internes, ainsi que la façon dont vous et les services interagissez avec elle en externe.
Pour simplifier la communication, Kubernetes s’attend à une configuration réseau telle que :
- Les pods puissent communiquer les uns avec les autres sur les nœuds sans traduction d’adresses réseau (NAT).
- Les nœuds puissent communiquer avec tous les pods et vice versa, sans traduction d’adresses réseau (NAT).
- Les agents sur un nœud puissent communiquer avec tous les nœuds et tous les pods.
Kubernetes offre plusieurs options réseau que vous pouvez installer pour configurer le réseau. Il s’agit par exemple de Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T et Weave Net.
Les fournisseurs de cloud peuvent également fournir leurs propres solutions réseau. Par exemple, Azure Kubernetes Service (AKS) prend en charge l’interface réseau de conteneur Réseau virtuel Azure, Kubenet, Flannel, Cilium et Antrea.
Services Kubernetes
Un service Kubernetes est un objet Kubernetes qui fournit un réseau stable pour les pods. Un service Kubernetes permet la communication entre les nœuds, les pods et les utilisateurs internes et externes de votre application sur le cluster.
Kubernetes affecte une adresse IP à un service lors de sa création, tout comme un nœud ou un pod. Ces adresses sont attribuées à partir de la plage d'adresses IP du cluster d'un service ; par exemple, 10.96.0.0/12. Un service reçoit également un nom DNS basé sur le nom du service ainsi qu’un port IP.
Dans l’application de suivi de drones, la communication réseau est la suivante :
Le site web et l’API RESTful sont accessibles aux utilisateurs en dehors du cluster.
Les services de cache en mémoire et de file d’attente de messages sont accessibles respectivement au front-end et à l’API RESTful, mais pas aux utilisateurs externes.
La file d’attente de messages a besoin d’accéder au service de traitement des données, mais pas aux utilisateurs externes.
La base de données NoSQL est accessible au service de cache en mémoire et de traitement de données, mais pas aux utilisateurs externes.
Pour prendre en charge ces scénarios, vous pouvez configurer trois types de services pour exposer les composants de votre application.
| Service | Description |
|---|---|
| ClusterIP | Adresse affectée à un service qui rend le service disponible pour un ensemble de services à l’intérieur du cluster. Par exemple, la communication entre les composants front-end et back-end de votre application. |
| NodePort | Le port du nœud, situé entre 30000 et 32767, que le plan de contrôle Kubernetes attribue au service ; par exemple, 192.169.1.11 sur clusters01. Vous configurez ensuite le service avec un port cible sur le pod que vous voulez exposer. Par exemple, configurez le port 80 sur le pod exécutant l’un des front-ends. Vous pouvez maintenant accéder au front-end via une adresse IP de nœud et une adresse de port. |
| LoadBalancer | Équilibreur de charge qui permet la distribution de la charge entre les nœuds exécutant votre application et l’exposition du pod à l’accès réseau public. En règle générale, vous configurez des équilibreurs de charge quand vous utilisez des fournisseurs de cloud. Dans ce cas, le trafic provenant de l’équilibreur de charge externe est dirigé vers les pods qui exécutent votre application. |
Dans l’application de suivi de drones, vous pouvez décider d’exposer le site web de suivi et l’API RESTful en utilisant un équilibreur de charge et le service de traitement des données avec un ClusterIP.
Comment grouper les pods
La gestion des pods par adresse IP n’est pas pratique. Les adresses IP des pods changent au fil de leur recréation par les contrôleurs et vous pouvez avoir un nombre quelconque de pods en cours d’exécution.
Un objet de service vous permet de cibler et de gérer des pods spécifiques dans votre cluster en utilisant des étiquettes de sélecteur. Vous définissez l’étiquette de sélecteur dans une définition de service pour qu’elle corresponde à l’étiquette du pod définie dans le fichier de définition du pod.
Par exemple, supposons que vous avez de nombreux pods en cours d’exécution. Seuls quelques-uns de ces pods sont sur le front-end et vous voulez définir un service LoadBalancer qui cible seulement les pods du front-end. Vous pouvez appliquer votre service pour exposer ces pods en référençant l’étiquette de pod comme valeur de sélecteur dans le fichier de définition du service. Le service regroupe uniquement les pods qui correspondent à l'étiquette. Si un pod est supprimé et recréé, le nouveau pod est automatiquement ajouté au groupe du service via son étiquette en correspondance.
Stockage Kubernetes
Kubernetes utilise le même concept de volume de stockage que celui que vous trouvez quand vous utilisez Docker. Les volumes Docker sont moins gérés que les volumes Kubernetes, car les durées de vie des volumes Docker ne sont pas gérées. La durée de vie des volumes Kubernetes est une durée de vie explicite qui correspond à la durée de vie du pod. Cette correspondance de durée de vie signifie qu’un volume présente les conteneurs qui s’exécutent dans le pod. Toutefois, si le pod est supprimé, c’est donc le volume.
Kubernetes fournit des options pour provisionner un stockage persistant avec l’utilisation de PersistentVolumes. Vous pouvez aussi demander un stockage spécifique pour les pods en utilisant des PersistentVolumeClaims.
Ces deux options sont à prendre en compte lors du déploiement de composants d’application nécessitant un stockage persistant, comme des files d’attente de messages et des bases de données.
Considérations relatives à l’intégration au cloud
Kubernetes ne dicte pas la pile de technologies que vous utilisez dans votre application native cloud. Dans un environnement cloud comme Azure, vous pouvez utiliser plusieurs services en dehors du cluster Kubernetes.
Rappelez-vous que Kubernetes ne fournit aucun des services suivants :
- Middleware
- Infrastructures de traitement des données
- Bases de données
- Caches
- Systèmes de stockage de clusters
Dans la solution de suivi de drones, trois services fournissent des fonctionnalités de middleware : une base de données NoSQL, un service de cache en mémoire et une file d’attente de messages. Vous pouvez sélectionner MongoDB Atlas pour la solution NoSQL, Redis pour gérer le cache en mémoire et RabbitMQ ou Kafka, en fonction de vos besoins en file d’attente de messages.
Quand vous utilisez un environnement cloud comme Azure, une bonne pratique est d’utiliser les services en dehors du cluster Kubernetes. Cette décision peut simplifier la configuration et la gestion du cluster. Par exemple, vous pouvez utiliser Azure Cache pour Redis pour les services caching en mémoire, la messagerie Azure Service Bus pour la file d’attente de messages et Azure Cosmos DB pour la base de données NoSQL.