Imaginez une situation où, lorsque la charge utilisateur augmente ou diminue sur une application, il n’y a aucun moyen pour l’application d’évoluer ou d’augmenter ses ressources selon les besoins. Une telle application ne survivrait probablement pas sur le marché actuel grâce à Mise à l’échelle automatique de Kubernetesqui peut facilement surmonter une telle situation avec ses différents mécanismes de mise à l’échelle.
Les mécanismes d’autoscaling de Kubernetes permettent de faire évoluer les pods et les nœuds selon les besoins. Il existe trois méthodes différentes prises en charge par Kubernetes Autoscaling.
- Autoscaler de pod horizontal (HPA)
- Autoscaler de pod vertical (VPA)
- Autoscaler de cluster (CA)
Dans cet article, nous examinerons les différentes méthodes d’autoscaling de Kubernetes qui facilitent le processus automatisé de mise à l’échelle des ressources requises par l’application.
Qu’est-ce que l’autoscaling Kubernetes ?
De nombreuses tâches administratives peuvent être automatisées avec Kubernetes, notamment le provisionnement et la mise à l’échelle. Au lieu d’affecter les ressources manuellement, vous pouvez automatiser les procédures qui vous font gagner du temps, vous permettant de répondre rapidement aux pics de demande et d’économiser de l’argent en réduisant lorsque les ressources ne sont pas nécessaires. Cela peut être utilisé conjointement avec le Cluster Autoscaler, qui alloue uniquement les ressources nécessaires.
L’utilisation de l’autoscaling vous rend plus susceptible de fonctionner avec une utilisation optimale des ressources et des dépenses dans le cloud. Sans mise à l’échelle automatique, vous provisionnez manuellement (et réduisez ultérieurement) les ressources chaque fois que les conditions changent.
En augmentant et en réduisant dynamiquement les ressources en réponse à la demande, Kubernetes Autoscaling aide à optimiser l’utilisation des ressources et les dépenses.
Avant de passer aux notions pratiques, examinons la théorie derrière chaque fonctionnalité d’autoscaling de Kubernetes.
L’autoscaler de pod horizontal Kubernetes
L’autoscaler de pod horizontal Kubernetes dans Kubernetes modifie la ressource de charge de travail, telle qu’un déploiement, un StatefulSet ou d’autres ressources similaires, et adapte automatiquement la charge de travail pour répondre à la demande. La mise à l’échelle horizontale fait référence au déploiement de pods supplémentaires dans le cluster Kubernetes en réponse à une charge croissante.
De plus, l’Autoscaler de pod horizontal ordonne automatiquement à la ressource de charge de travail de se réduire si la charge chute et que le nombre de pods dépasse le minimum défini. Cela permet à vos applications d’évoluer en réponse à la demande croissante et d’évoluer lorsque les ressources ne sont pas nécessaires, libérant ainsi des nœuds pour d’autres applications. Par exemple, si un déploiement exécute un pod et que vous souhaitez que le nombre de pods varie entre un et quatre en fonction de l’utilisation des ressources, vous pouvez créer un HPA qui adaptera le nombre de pods contrôlés par le déploiement.
Il convient de noter que la mise à l’échelle automatique des pods horizontaux n’est pas compatible avec les charges de travail non évolutives, telles que les DaemonSets. Les Daemonsets fonctionnent sur la base « un pod par nœud », et par conséquent, ils ne peuvent pas avoir de répliques, c’est pourquoi HPA n’est pas compatible avec les Daemonsets.
L’autoscaler de pod vertical Kubernetes
Le Vertical Pod Autoscaler est un outil de mise à l’échelle automatique qui peut être utilisé pour redimensionner les pods afin d’optimiser les ressources CPU et mémoire. Vous pouvez utiliser la mise à l’échelle automatique des pods verticaux pour fournir des valeurs recommandées pour les demandes et les limites de CPU et de mémoire ou pour mettre à jour automatiquement les valeurs au lieu d’avoir à configurer des demandes et des limites de CPU et de mémoire à jour pour les conteneurs de vos pods.
Le Kubernetes Vertical Pod Autoscaler augmente automatiquement les réservations de CPU et de mémoire de vos pods pour vous aider à « dimensionner correctement » vos applications. Cela peut augmenter l’utilisation des ressources du cluster tout en libérant du processeur et de la mémoire pour d’autres pods.
Voici quelques-uns des avantages offerts par l’APV :
- Comme ils ne consomment que ce dont ils ont besoin, les pods utilisent efficacement les nœuds du cluster.
- Vous n’avez pas besoin d’effectuer de longues procédures d’analyse comparative pour identifier les valeurs optimales d’exigences en matière de processeur et de mémoire.
- Le temps de maintenance est réduit, car le VPA peut modifier les requêtes CPU et mémoire au fil du temps sans aucune intervention de votre part.
Autoscaler de cluster Kubernetes
En fonction de la présence de pods en attente et de données d’utilisation des nœuds, l’autoscaler Kubernetes augmente ou diminue la taille d’un cluster Kubernetes en ajoutant ou en supprimant des nœuds.
Lorsque l’autoscaler Kubernetes identifie des pods en attente qui ne peuvent pas être planifiés, ce qui peut entraîner des contraintes de ressources, il ajoute des nœuds au cluster. De plus, lorsque l’utilisation d’un nœud tombe en dessous d’un seuil particulier défini par l’administrateur du cluster, il supprime les nœuds du cluster, ce qui permet à tous les pods d’avoir un endroit où s’exécuter et évite les nœuds inutiles.
Nœuds de travail
Kubernetes-as-a-Service est géré par EKS. Cela dit, cela fait principalement référence au plan de contrôle Kubernetes. Vous devez toujours fournir des nœuds de calcul à votre cluster EKS pour que les pods soient déployés. Il existe deux façons de créer des nœuds de travail pour votre cluster EKS.
Nœuds autogérés :
Avec cette option, vous créez, gérez et administrez vos propres noeuds worker, ce qui vous donne plus de contrôle sur vos serveurs.
Nœuds gérés EKS :
Avec cette option, vous n’avez pas besoin de gérer les nœuds dans le cluster EKS Kubernetes. Tout ce que vous avez à faire est de spécifier les configurations et EKS s’occupe du reste. Plus loin dans cet article, nous vous montrerons comment utiliser les nœuds gérés EKS pour créer des nœuds de travail pour le cluster.
Mises à jour bleu-vert et continues dans Kubernetes
L’une des choses les plus importantes à savoir à cet égard est de savoir comment lancer de manière fiable la prochaine version de l’application lorsqu’elle est déjà en cours d’exécution. Comment remplacer les pods actuels sans perturber le trafic ?
Kubernetes prend en charge diverses options de déploiement. Ci-dessous, nous vous présentons deux options qui permettent un déploiement sécurisé tout en conservant la possibilité de revenir en arrière si nécessaire.
Déploiement bleu-vert
Comment fonctionne le déploiement Blue-Green dans Kubernetes ?
- Supposons que vous disposiez de la première version du logiciel appelée my-app (v1), qui s’exécute actuellement en bleu.
- Vous disposez d’une nouvelle version (v2) prête à être déployée. Vous devez donc créer un nouvel environnement, appelé environnement vert. Les utilisateurs ne sont pas conscients du changement car l’environnement bleu continue de fonctionner normalement. Ils ne remarqueront rien jusqu’à ce que vous changiez le trafic du bleu au vert.
- Fondamentalement, les deux versions existent en même temps, mais le service Kubernetes pointe toujours vers la version bleue ; par conséquent, la plupart des utilisateurs ne remarqueront pas le changement. Différents types de tests peuvent être effectués sur la nouvelle version sans déranger les utilisateurs existants.
- Lorsque vous êtes prêt, le service Kubernetes est basculé pour pointer vers la nouvelle version (v2), et sans aucun temps d’arrêt, tous les utilisateurs en direct peuvent désormais accéder à la nouvelle version du logiciel.
- Si la nouvelle version (v2) fonctionne comme prévu, l’ancienne version (v1) sera supprimée. La nouvelle version deviendra la version actuelle et le service Kubernetes continuera à fonctionner normalement.
- Si des problèmes surviennent avec la nouvelle version (v2), le service Kubernetes reviendra à la version précédente (v1), ce qui aura un effet très négligeable sur les utilisateurs. La nouvelle version sera effacée et tout reviendra à son état précédent, c’est-à-dire ; l’ancienne version (v1).
Mise à jour continue
La possibilité d’exécuter des mises à jour continues est l’un des principaux avantages de l’utilisation d’un déploiement pour gérer vos pods. Les mises à jour continues vous permettent de mettre à jour progressivement la configuration de vos pods, et les déploiements vous offrent un contrôle optimal sur le processus.
La stratégie de mise à jour est le paramètre le plus critique lorsqu’il s’agit de configurer des mises à jour continues.
Spec.strategy.type offre deux valeurs possibles dans votre manifeste de déploiement :
- Mise à jour continue : de nouveaux pods sont progressivement introduits et les anciens pods sont progressivement supprimés.
- Recréer : avant l’insertion de nouveaux pods, tous les anciens pods sont terminés.
Autres autoscalers : Karpenter
Karpenter est un autoscaler de cluster Kubernetes open source, personnalisable et hautement performant basé sur AWS. Il améliore la disponibilité des applications et l’efficacité du cluster en déployant rapidement les ressources de calcul appropriées en réponse à une charge d’application changeante.
Karpenter propose également des ressources informatiques juste à temps pour répondre aux exigences de votre application et fournira bientôt une empreinte de ressources de calcul en cluster, ce qui réduira les coûts et augmentera les performances. Karpenter surveille les demandes de ressources agrégées des pods non planifiés et décide de déployer de nouveaux nœuds ou de mettre fin à ceux existants pour réduire les retards de planification et les dépenses d’infrastructure.
Kubernetes Keda — Mise à l’échelle automatique pilotée par les événements
KEDA (Kubernetes-based Event-driven Autoscaling) est un composant open source créé par Microsoft et Red Hat, qui permet à la charge de travail Kubernetes de bénéficier d’un style d’architecture piloté par les événements.
KEDA met à l’échelle horizontalement un déploiement ou un travail Kubernetes. Il est basé sur le Kubernetes Horizontal Pod Autoscaler et permet aux utilisateurs de spécifier des critères d’autoscaling basés sur des informations provenant de n’importe quelle source d’événement, y compris une latence de sujet Kafka et des métriques acquises à partir d’une requête Prometheus. Cette fonctionnalité vous permet de choisir parmi une liste de déclencheurs prédéfinis qui servent de source d’événements et de métriques lors de la mise à l’échelle automatique d’un déploiement ou d’un travail.
Mise à l’échelle automatique de Kubernetes
Avant de nous plonger dans les différents mécanismes d’autoscaling de Kubernetes à un niveau pratique, créons un cluster Kubernetes sur AWS en utilisant les nœuds gérés par EKS comme terrain de jeu.
Créer un cluster EKS
1. Accédez à EKS et cliquez sur les options « Ajouter un cluster » → « Créer ».
2. L’écran de configuration ci-dessous devrait apparaître sur votre appareil. Donnez un nom au cluster, choisissez la version et le rôle de service, puis cliquez sur le bouton « Suivant ».
3. Ensuite, sélectionnez un VPC, des sous-réseaux et un groupe de sécurité.
4. Gardez le point de terminaison du cluster sur « Public » afin qu’il soit accessible depuis votre machine. Sélectionnez les dernières versions des modules complémentaires de mise en réseau et cliquez sur le bouton « Suivant ».
5. Cliquez sur le bouton « Suivant » et activez la journalisation si nécessaire.
6. Vérifiez la configuration et cliquez sur le bouton « Créer » pour…