Pour maîtriser pleinement Kubernetes, vous devez connaître différentes manières de faire évoluer les ressources du cluster : en , c'est l'une des tâches principales de Kubernetes. Nous avons fourni un aperçu de haut niveau des mécanismes d'autoscaling horizontal et vertical et de redimensionnement de cluster, ainsi que des recommandations sur la façon de les utiliser efficacement.
Article traduit par l'équipe qui a implémenté l'autoscaling dans .
Pourquoi il est important de penser à la mise à l'échelle
- un outil de gestion et d'orchestration des ressources. Bien sûr, c'est bien de bricoler les fonctionnalités intéressantes de déploiement, de surveillance et de gestion des pods (un pod est un groupe de conteneurs lancés en réponse à une requête).
Cependant, vous devez également réfléchir aux questions suivantes :
- Comment faire évoluer les modules et les applications ?
- Comment garder les conteneurs opérationnels et efficaces ?
- Comment répondre aux changements constants de code et de charges de travail des utilisateurs ?
La configuration des clusters Kubernetes pour équilibrer les ressources et les performances peut s'avérer difficile et nécessite une connaissance approfondie du fonctionnement interne de Kubernetes. La charge de travail de votre application ou de vos services peut fluctuer au cours de la journée, voire au cours d'une heure. Il est donc préférable de considérer l'équilibrage comme un processus continu.
Niveaux de mise à l'échelle automatique de Kubernetes
Un autoscaling efficace nécessite une coordination entre deux niveaux :
- Niveau du pod, y compris l'autoscaler horizontal (Horizontal Pod Autoscaler, HPA) et vertical (Vertical Pod Autoscaler, VPA). Cela fait évoluer les ressources disponibles pour vos conteneurs.
- Niveau du cluster, qui est géré par le Cluster Autoscaler (CA), qui augmente ou diminue le nombre de nœuds au sein du cluster.
Module Autoscaler horizontal (HPA)
Comme son nom l'indique, HPA augmente le nombre de répliques de pods. La plupart des développeurs utilisent la charge du processeur et de la mémoire comme déclencheurs pour modifier le nombre de répliques. Cependant, il est possible de faire évoluer le système en fonction de , leur ou .
Schéma de fonctionnement HPA de haut niveau :
- Le HPA vérifie en permanence les valeurs métriques spécifiées lors de l'installation à un intervalle par défaut de 30 secondes.
- Le HPA tente d'augmenter le nombre de modules si le seuil spécifié est atteint.
- Le HPA met à jour le nombre de répliques au sein du contrôleur de déploiement/réplication.
- Le contrôleur de déploiement/réplication déploie ensuite tous les modules supplémentaires nécessaires.
HPA démarre le processus de déploiement du module lorsqu'un seuil de métrique est atteint
Lorsque vous utilisez HPA, tenez compte des points suivants :
- L'intervalle de vérification HPA par défaut est de 30 secondes. Il est fixé par le drapeau période de synchronisation-de-pod-autoscaler-horizontale dans le gestionnaire de contrôleur.
- L'erreur relative par défaut est de 10 %.
- Après la dernière augmentation du nombre de modules, HPA s'attend à ce que les mesures se stabilisent d'ici trois minutes. Cet intervalle est défini par le drapeau délai de mise à l'échelle du pod-autoscaler-horizontal.
- Après la dernière réduction du nombre de modules, le HPA attend cinq minutes pour se stabiliser. Cet intervalle est défini par le drapeau délai de réduction de l'échelle horizontale du pod-autoscaler.
- HPA fonctionne mieux avec les objets de déploiement plutôt qu'avec les contrôleurs de réplication. La mise à l'échelle automatique horizontale est incompatible avec la mise à jour continue, qui manipule directement les contrôleurs de réplication. Avec le déploiement, le nombre de réplicas dépend directement des objets de déploiement.
Mise à l'échelle verticale des pods
L'autoscaling vertical (VPA) alloue plus (ou moins) de temps CPU ou de mémoire aux pods existants. Convient aux pods avec état ou sans état, mais principalement destiné aux services avec état. Cependant, vous pouvez également utiliser VPA pour les modules sans état si vous devez ajuster automatiquement la quantité de ressources initialement allouées.
VPA répond également aux événements MOO (mémoire insuffisante). La modification du temps CPU et de la mémoire nécessite le redémarrage des pods. Au redémarrage, l'APV respecte le budget d'allocation () pour garantir le nombre minimum de modules requis.
Vous pouvez définir les ressources minimales et maximales pour chaque module. Ainsi, vous pouvez limiter la quantité maximale de mémoire allouée à 8 Go. Ceci est utile si les nœuds actuels ne peuvent définitivement pas allouer plus de 8 Go de mémoire par conteneur. Les spécifications détaillées et le mécanisme de fonctionnement sont décrits dans .
De plus, VPA dispose d’une fonction de recommandation intéressante (VPA Recommender). Il surveille l'utilisation des ressources et les événements MOO de tous les modules pour suggérer de nouvelles valeurs de mémoire et de temps CPU basées sur un algorithme intelligent basé sur des métriques historiques. Il existe également une API qui prend un handle de pod et renvoie les valeurs de ressources suggérées.
Il convient de noter que VPA Recommender ne suit pas la « limite » des ressources. Cela peut conduire le module à monopoliser les ressources au sein des nœuds. Il est préférable de définir la limite au niveau de l'espace de noms pour éviter une consommation énorme de mémoire ou de processeur.
Schéma de fonctionnement VPA de haut niveau :
- VPA vérifie en permanence les valeurs métriques spécifiées lors de l'installation à un intervalle par défaut de 10 secondes.
- Si le seuil spécifié est atteint, le VPA tente de modifier la quantité de ressources allouée.
- Le VPA met à jour le nombre de ressources au sein du contrôleur de déploiement/réplication.
- Lorsque les modules sont redémarrés, toutes les nouvelles ressources sont appliquées aux instances créées.
VPA ajoute la quantité requise de ressources
Veuillez garder les points suivants à l'esprit lorsque vous utilisez VPA :
- La mise à l'échelle nécessite un redémarrage obligatoire du pod. Ceci est nécessaire pour éviter un fonctionnement instable après avoir apporté des modifications. Pour plus de fiabilité, les modules sont redémarrés et distribués entre les nœuds en fonction des ressources nouvellement allouées.
- VPA et HPA ne sont pas encore compatibles entre eux et ne peuvent pas fonctionner sur les mêmes pods. Si vous utilisez les deux mécanismes de mise à l'échelle dans le même cluster, assurez-vous que vos paramètres empêchent leur activation sur les mêmes objets.
- VPA ajuste les demandes de ressources des conteneurs en fonction uniquement de l'utilisation passée et actuelle. Il ne fixe pas de limites d'utilisation des ressources. Il peut y avoir des problèmes avec les applications qui ne fonctionnent pas correctement et commencent à prendre de plus en plus de ressources, cela conduira Kubernetes à désactiver ce pod.
- L’APV en est encore à ses premiers stades de développement. Préparez-vous à ce que le système puisse subir des changements dans un avenir proche. Vous pouvez lire sur и . Ainsi, il est prévu de mettre en œuvre le fonctionnement conjoint de VPA et HPA, ainsi que le déploiement de modules accompagnés d'une politique d'autoscaling vertical pour ceux-ci (par exemple, une étiquette spéciale « nécessite VPA »).
Mise à l'échelle automatique d'un cluster Kubernetes
Cluster Autoscaler (CA) modifie le nombre de nœuds en fonction du nombre de pods en attente. Le système vérifie périodiquement les modules en attente et augmente la taille du cluster si davantage de ressources sont nécessaires et si le cluster ne dépasse pas les limites établies. L'autorité de certification communique avec le fournisseur de services cloud, lui demande des nœuds supplémentaires ou libère des nœuds inactifs. La première version généralement disponible de CA a été introduite dans Kubernetes 1.8.
Schéma de haut niveau de fonctionnement de la SA :
- CA vérifie les modules en attente à un intervalle par défaut de 10 secondes.
- Si un ou plusieurs pods sont en veille parce que le cluster ne dispose pas de suffisamment de ressources disponibles pour les allouer, il tente de provisionner un ou plusieurs nœuds supplémentaires.
- Lorsque le fournisseur de services cloud alloue le nœud requis, il rejoint le cluster et est prêt à servir les pods.
- Le planificateur Kubernetes distribue les pods en attente au nouveau nœud. Si après cela certains modules restent encore en attente, le processus est répété et de nouveaux nœuds sont ajoutés au cluster.
Provisionnement automatique des nœuds de cluster dans le cloud
Tenez compte des éléments suivants lorsque vous utilisez CA :
- CA garantit que tous les pods du cluster disposent de suffisamment d'espace pour s'exécuter, quelle que soit la charge du processeur. Il essaie également de garantir qu'il n'y a pas de nœuds inutiles dans le cluster.
- CA enregistre la nécessité d'une mise à l'échelle après environ 30 secondes.
- Une fois qu'un nœud n'est plus nécessaire, l'autorité de certification attend par défaut 10 minutes avant de faire évoluer le système.
- Le système de mise à l'échelle automatique a le concept d'extenseurs. Il s'agit de différentes stratégies permettant de sélectionner un groupe de nœuds auquel de nouveaux nœuds seront ajoutés.
- Utilisez l’option de manière responsable cluster-autoscaler.kubernetes.io/safe-to-evict (true). Si vous installez de nombreux pods, ou si un grand nombre d'entre eux sont dispersés sur tous les nœuds, vous perdrez en grande partie la possibilité de faire évoluer le cluster.
- utilisation pour empêcher la suppression des pods, ce qui pourrait entraîner le blocage complet de certaines parties de votre application.
Comment les autoscalers Kubernetes interagissent les uns avec les autres
Pour une harmonie parfaite, l’autoscaling doit être appliqué à la fois au niveau du pod (HPA/VPA) et au niveau du cluster. Ils interagissent les uns avec les autres de manière relativement simple :
- Les HPA ou VPA mettent à jour les répliques de pods ou les ressources allouées aux pods existants.
- S'il n'y a pas assez de nœuds pour la mise à l'échelle prévue, l'AC remarque la présence de pods en état d'attente.
- L'AC alloue de nouveaux nœuds.
- Les modules sont distribués vers de nouveaux nœuds.
Système collaboratif évolutif Kubernetes
Erreurs courantes dans la mise à l'échelle automatique de Kubernetes
Les développeurs rencontrent plusieurs problèmes courants lorsqu'ils tentent d'implémenter la mise à l'échelle automatique.
HPA et VPA dépendent de métriques et de certaines données historiques. Si des ressources insuffisantes sont allouées, les modules seront minimisés et ne pourront pas générer de métriques. Dans ce cas, l’autoscaling n’aura jamais lieu.
L’opération de mise à l’échelle elle-même est sensible au temps. Nous souhaitons que les modules et le cluster évoluent rapidement, avant que les utilisateurs ne remarquent des problèmes ou des pannes. Par conséquent, le temps de mise à l’échelle moyen des pods et du cluster doit être pris en compte.
Scénario idéal - 4 minutes :
- 30 secondes. Mettre à jour les métriques cibles : 30 à 60 secondes.
- 30 secondes. HPA vérifie les valeurs métriques : 30 secondes.
- Moins de 2 secondes. Les pods sont créés et passent en état d'attente : 1 seconde.
- Moins de 2 secondes. CA voit les modules en attente et envoie des appels aux nœuds de provisionnement : 1 seconde.
- 3 minutes. Le fournisseur de cloud alloue les nœuds. Les K8 attendent qu'ils soient prêts : jusqu'à 10 minutes (en fonction de plusieurs facteurs).
Scénario du pire des cas (plus réaliste) - 12 minutes :
- 30 secondes. Mettre à jour les métriques cibles.
- 30 secondes. HPA vérifie les valeurs métriques.
- Moins de 2 secondes. Les pods sont créés et passent en état de veille.
- Moins de 2 secondes. L'autorité de certification voit les modules en attente et effectue des appels pour provisionner les nœuds.
- 10 minutes. Le fournisseur de cloud alloue les nœuds. Les K8 attendent qu'ils soient prêts. Le temps d'attente dépend de plusieurs facteurs, tels que le délai du fournisseur, le délai du système d'exploitation et les outils d'assistance.
Ne confondez pas les mécanismes de mise à l'échelle des fournisseurs de cloud avec notre autorité de certification. Ce dernier fonctionne au sein d'un cluster Kubernetes, tandis que le moteur du fournisseur de cloud fonctionne sur une base de distribution de nœuds. Il ne sait pas ce qui se passe avec vos pods ou votre application. Ces systèmes fonctionnent en parallèle.
Comment gérer la mise à l'échelle dans Kubernetes
- Kubernetes est un outil de gestion et d'orchestration des ressources. Les opérations de gestion des pods et des ressources du cluster sont une étape clé dans la maîtrise de Kubernetes.
- Comprendre la logique de l'évolutivité des pods en prenant en compte HPA et VPA.
- CA ne doit être utilisé que si vous avez une bonne compréhension des besoins de vos pods et conteneurs.
- Pour configurer un cluster de manière optimale, vous devez comprendre comment les différents systèmes de mise à l'échelle fonctionnent ensemble.
- Lors de l’estimation du temps de mise à l’échelle, gardez à l’esprit les pires et les meilleurs scénarios.
Source: habr.com