Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Cluster Autoscaler

Présentation de

Le Kubernetes Cluster Autoscaler est une solution d'autoscaling de cluster populaire gérée par SIG Autoscaling. https://github.com/kubernetes/community/tree/master/sig-autoscaling Il est chargé de s'assurer que votre cluster dispose de suffisamment de nœuds pour planifier vos pods sans gaspiller de ressources. Il surveille les pods qui ne sont pas planifiés et les nœuds sous-utilisés. Il simule ensuite l'ajout ou la suppression de nœuds avant d'appliquer la modification à votre cluster. L'implémentation d'AWS Cloud Provider dans Cluster Autoscaler contrôle le .DesiredReplicas champ de vos groupes EC2 Auto Scaling.

Ce guide fournit un modèle mental pour configurer le Cluster Autoscaler et choisir le meilleur ensemble de compromis pour répondre aux exigences de votre organisation. Bien qu'il n'existe pas de meilleure configuration, il existe un ensemble d'options de configuration qui vous permettent de trouver un compromis entre performances, évolutivité, coût et disponibilité. En outre, ce guide fournit des conseils et des bonnes pratiques pour optimiser votre configuration pour AWS.

Glossaire

La terminologie suivante sera fréquemment utilisée tout au long de ce document. Ces termes peuvent avoir une signification large, mais sont limités aux définitions ci-dessous aux fins du présent document.

L'évolutivité fait référence aux performances du Cluster Autoscaler lorsque le nombre de pods et de nœuds de votre cluster Kubernetes augmente. Lorsque les limites d'évolutivité sont atteintes, les performances et les fonctionnalités du Cluster Autoscaler se dégradent. Comme le Cluster Autoscaler dépasse ses limites d'évolutivité, il est possible qu'il n'ajoute ou ne supprime plus de nœuds dans votre cluster.

Les performances font référence à la rapidité avec laquelle le Cluster Autoscaler est capable de prendre et d'exécuter des décisions de dimensionnement. Un Cluster Autoscaler parfaitement performant prendrait instantanément une décision et déclencherait une action de dimensionnement en réponse à des stimuli, tels qu'un pod devenant non planifiable.

La disponibilité signifie que les pods peuvent être planifiés rapidement et sans interruption. Cela inclut les cas où les pods nouvellement créés doivent être planifiés et lorsqu'un nœud réduit met fin à tous les pods restants qui lui ont été planifiés.

Le coût est déterminé par la décision qui sous-tend la mise à l'échelle et la mise à l'échelle des événements. Les ressources sont gaspillées si un nœud existant est sous-utilisé ou si un nouveau nœud trop volumineux est ajouté pour les pods entrants. Selon le cas d'utilisation, l'arrêt prématuré des dosettes peut entraîner des coûts en raison d'une décision agressive de réduction d'échelle.

Les groupes de nœuds sont un concept Kubernetes abstrait désignant un groupe de nœuds au sein d'un cluster. Il ne s'agit pas d'une véritable ressource Kubernetes, mais elle existe en tant qu'abstraction dans le Cluster Autoscaler, l'API Cluster et d'autres composants. Les nœuds d'un groupe de nœuds partagent des propriétés telles que des étiquettes et des couleurs, mais peuvent être composés de plusieurs zones de disponibilité ou de types d'instances.

Les groupes EC2 Auto Scaling peuvent être utilisés comme implémentation de groupes de nœuds sur EC2. Les groupes EC2 Auto Scaling sont configurés pour lancer des instances qui rejoignent automatiquement leurs clusters Kubernetes et appliquent des étiquettes et des couleurs à la ressource Node correspondante dans l'API Kubernetes.

Les groupes de nœuds gérés EC2 constituent une autre implémentation des groupes de nœuds sur EC2. Ils simplifient la configuration manuelle des groupes de mise à l'échelle automatique EC2 et fournissent des fonctionnalités de gestion supplémentaires telles que la mise à niveau de la version des nœuds et la terminaison progressive des nœuds.

Utilisation du Cluster Autoscaler

Le Cluster Autoscaler est généralement installé en tant que Déploiement dans votre cluster. Il utilise l'élection du leader pour garantir une haute disponibilité, mais le travail est effectué par une seule réplique à la fois. Il n'est pas évolutif horizontalement. Pour les configurations de base, par défaut, cela devrait fonctionner immédiatement en suivant les instructions d'installation fournies, mais il y a quelques points à garder à l'esprit.

Assurez-vous que :

Utiliser l'accès le moins privilégié au rôle IAM

Lorsque la détection automatique est utilisée, nous vous recommandons vivement d'utiliser l'accès avec le moindre privilège en limitant les actions autoscaling:SetDesiredCapacity et autoscaling:TerminateInstanceInAutoScalingGroup aux groupes Auto Scaling qui sont limités au cluster actuel.

Cela empêchera un Autoscaler de cluster exécuté dans un cluster de modifier des groupes de nœuds dans un autre cluster, même si l'--node-group-auto-discoveryargument n'a pas été limité aux groupes de nœuds du cluster à l'aide de balises (par exemple). k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/my-cluster": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

Configuration de vos groupes de nœuds

Une mise à l'échelle automatique efficace commence par la configuration correcte d'un ensemble de groupes de nœuds pour votre cluster. Il est essentiel de sélectionner le bon ensemble de groupes de nœuds pour optimiser la disponibilité et réduire les coûts de vos charges de travail. AWS implémente des groupes de nœuds à l'aide des groupes EC2 Auto Scaling, qui sont flexibles pour un grand nombre de cas d'utilisation. Cependant, le Cluster Autoscaler émet certaines hypothèses concernant vos groupes de nœuds. En veillant à ce que les configurations de votre groupe EC2 Auto Scaling restent cohérentes avec ces hypothèses, vous réduirez les comportements indésirables.

Assurez-vous que :

Optimisation des performances et de l'évolutivité

Comprendre la complexité d'exécution de l'algorithme de dimensionnement automatique vous aidera à régler le Cluster Autoscaler pour qu'il continue à fonctionner correctement dans les grands clusters de plus de 1 000 nœuds.

Les principaux paramètres permettant de régler l'évolutivité du Cluster Autoscaler sont les ressources fournies au processus, l'intervalle d'analyse de l'algorithme et le nombre de groupes de nœuds dans le cluster. D'autres facteurs entrent en ligne de compte dans la véritable complexité d'exécution de cet algorithme, tels que la complexité des plugins de planification et le nombre de pods. Ces paramètres sont considérés comme non configurables car ils sont naturels à la charge de travail du cluster et ne peuvent pas être facilement ajustés.

Le Cluster Autoscaler charge l'état complet du cluster en mémoire, y compris les pods, les nœuds et les groupes de nœuds. À chaque intervalle de scan, l'algorithme identifie les modules non programmables et simule la planification pour chaque groupe de nœuds. Le réglage de ces facteurs implique différents compromis qui doivent être soigneusement pris en compte pour votre cas d'utilisation.

Mise à l'échelle automatique verticale du Cluster Autoscaler

Le moyen le plus simple d'adapter le Cluster Autoscaler à de plus grands clusters consiste à augmenter les demandes de ressources pour son déploiement. La mémoire et le processeur doivent être augmentés pour les grands clusters, bien que cela varie considérablement en fonction de la taille du cluster. L'algorithme de mise à l'échelle automatique stocke tous les pods et nœuds en mémoire, ce qui peut entraîner une empreinte mémoire supérieure à un gigaoctet dans certains cas. L'augmentation des ressources se fait généralement manuellement. Si vous constatez que le réglage constant des ressources entraîne une charge opérationnelle, pensez à utiliser l'Addon Resizer ou le Vertical Pod Autoscaler.

Réduire le nombre de groupes de nœuds

La réduction du nombre de groupes de nœuds est un moyen de garantir que le Cluster Autoscaler continuera à fonctionner correctement sur les grands clusters. Cela peut s'avérer difficile pour certaines organisations qui structurent leurs groupes de nœuds par équipe ou par application. Bien que cela soit entièrement pris en charge par l'API Kubernetes, il est considéré comme un anti-pattern de Cluster Autoscaler avec des répercussions sur l'évolutivité. Il existe de nombreuses raisons d'utiliser plusieurs groupes de nœuds (par exemple, Spot ou GPU), mais dans de nombreux cas, il existe des modèles alternatifs qui produisent le même effet tout en utilisant un petit nombre de groupes.

Assurez-vous que :

Réduction de l'intervalle de numérisation

Un intervalle de balayage faible (par exemple 10 secondes) garantit que le Cluster Autoscaler répond le plus rapidement possible lorsque les pods ne peuvent plus être planifiés. Cependant, chaque scan entraîne de nombreux appels d'API à l'API Kubernetes et aux API EC2 Auto Scaling Group ou EKS Managed Node Group. Ces appels d'API peuvent entraîner une limitation du débit, voire une indisponibilité du service pour votre plan de contrôle Kubernetes.

L'intervalle d'analyse par défaut est de 10 secondes, mais sur AWS, le lancement d'un nœud prend beaucoup plus de temps pour lancer une nouvelle instance. Cela signifie qu'il est possible d'augmenter l'intervalle sans augmenter significativement le temps de mise à l'échelle globale. Par exemple, si le lancement d'un nœud prend 2 minutes, la modification de l'intervalle à 1 minute entraînera un compromis entre 6 fois moins d'appels d'API et 38 % de ralentissement des mises à l'échelle.

Partage entre groupes de nœuds

Le Cluster Autoscaler peut être configuré pour fonctionner sur un ensemble spécifique de groupes de nœuds. Grâce à cette fonctionnalité, il est possible de déployer plusieurs instances du Cluster Autoscaler, chacune étant configurée pour fonctionner sur un ensemble différent de groupes de nœuds. Cette stratégie vous permet d'utiliser un nombre arbitrairement élevé de groupes de nœuds, en négociant les coûts pour l'évolutivité. Nous vous recommandons de ne l'utiliser qu'en dernier recours pour améliorer les performances.

Le Cluster Autoscaler n'a pas été conçu à l'origine pour cette configuration, il présente donc certains effets secondaires. Comme les fragments ne communiquent pas, il est possible que plusieurs autoscalers tentent de planifier un pod non planifiable. Cela peut entraîner une mise à l'échelle inutile de plusieurs groupes de nœuds. Ces nœuds supplémentaires seront réduits après lescale-down-delay.

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-1

...

--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2

---

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-2

...

--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4

Assurez-vous que :

Optimisation des coûts et de la disponibilité

Instances Spot

Vous pouvez utiliser des instances ponctuelles dans vos groupes de nœuds et économiser jusqu'à 90 % sur le prix à la demande. En contrepartie, les instances ponctuelles peuvent être interrompues à tout moment lorsqu'EC2 a besoin de retrouver sa capacité. Des erreurs de capacité insuffisante se produisent lorsque votre groupe EC2 Auto Scaling ne peut pas augmenter en raison d'un manque de capacité disponible. Maximiser la diversité en sélectionnant de nombreuses familles d'instances peut augmenter vos chances d'atteindre l'échelle souhaitée en exploitant de nombreux pools de capacité Spot, et réduire l'impact des interruptions d'instances Spot sur la disponibilité de votre cluster. Les politiques d'instance mixte avec les instances Spot sont un excellent moyen d'augmenter la diversité sans augmenter le nombre de groupes de nœuds. N'oubliez pas que si vous avez besoin de ressources garanties, utilisez des On-Demand instances plutôt que des instances ponctuelles.

Il est essentiel que tous les types d'instances disposent d'une capacité de ressources similaire lors de la configuration de politiques d'instance mixtes. Le simulateur de planification de l'autoscaler utilise le premier InstanceType du. MixedInstancePolicy Si les types d'instances suivants sont plus volumineux, des ressources peuvent être gaspillées après une mise à l'échelle. S'ils sont plus petits, vos pods risquent de ne pas être planifiés sur les nouvelles instances en raison d'une capacité insuffisante. Par exemple, les instances M4, M5, M5a et M5n ont toutes des quantités similaires de processeur et de mémoire et sont de bonnes candidates pour un. MixedInstancePolicy L'outil EC2 Instance Selector peut vous aider à identifier des types d'instances similaires.

Il est recommandé d'isoler On-Demand et de répartir la capacité dans des groupes EC2 Auto Scaling distincts. Cette méthode est préférable à l'utilisation d'une stratégie de capacité de base car les propriétés de planification sont fondamentalement différentes. Étant donné que les instances Spot sont interrompues à tout moment (lorsqu'EC2 a besoin de récupérer de la capacité), les utilisateurs altèrent souvent leurs nœuds préemptables, ce qui nécessite une tolérance explicite des pods en ce qui concerne le comportement de préemption. Ces défauts entraînent des propriétés de planification différentes pour les nœuds. Ils doivent donc être séparés en plusieurs groupes EC2 Auto Scaling.

Le Cluster Autoscaler utilise un concept d'extenseurs, qui propose différentes stratégies pour sélectionner le groupe de nœuds à dimensionner. La stratégie --expander=least-waste est une bonne stratégie par défaut à usage général, et si vous comptez utiliser plusieurs groupes de nœuds pour diversifier les instances Spot (comme décrit dans l'image ci-dessus), cela pourrait vous aider à optimiser davantage les coûts des groupes de nœuds en redimensionnant le groupe qui serait le mieux utilisé après l'activité de dimensionnement.

Prioriser un groupe de nœuds/ASG

Vous pouvez également configurer la mise à l'échelle automatique basée sur les priorités à l'aide de l'extenseur Priority. --expander=prioritypermet à votre cluster de hiérarchiser un groupe de nœuds ou un ASG, et s'il ne peut pas évoluer pour une raison quelconque, il choisira le groupe de nœuds suivant dans la liste des priorités. Cela est utile dans les situations où, par exemple, vous souhaitez utiliser des types d'instance P3 car leur processeur graphique offre des performances optimales pour votre charge de travail, mais comme deuxième option, vous pouvez également utiliser des types d'instance P2.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*p2-node-group.*
    50:
      - .*p3-node-group.*

Cluster Autoscaler essaiera d'augmenter le groupe EC2 Auto Scaling correspondant au nom p3-node-group. Si cette opération échoue--max-node-provision-time, elle tentera de redimensionner un groupe EC2 Auto Scaling correspondant au nom p2-node-group. Cette valeur par défaut est de 15 minutes et peut être réduite pour une sélection de groupes de nœuds plus réactive, mais si la valeur est trop faible, cela peut entraîner des modifications de taille inutiles.

Surapprovisionnement

Le Cluster Autoscaler minimise les coûts en garantissant que les nœuds ne sont ajoutés au cluster que lorsque cela est nécessaire et sont supprimés lorsqu'ils ne sont pas utilisés. Cela a un impact significatif sur la latence du déploiement, car de nombreux pods seront contraints d'attendre la mise à l'échelle d'un nœud avant de pouvoir être planifiés. Les nœuds peuvent prendre plusieurs minutes pour devenir disponibles, ce qui peut augmenter la latence de planification des pods d'un certain ordre de grandeur.

Cela peut être atténué par un surapprovisionnement, qui négocie le coût de la latence de planification. Le surprovisionnement est mis en œuvre à l'aide de pods temporaires à priorité négative, qui occupent de l'espace dans le cluster. Lorsque les modules nouvellement créés ne sont pas programmables et ont une priorité plus élevée, les modules temporaires seront préemptés pour libérer de la place. Les pods temporaires deviennent alors non planifiables, ce qui déclenche le Cluster Autoscaler pour dimensionner les nouveaux nœuds surapprovisionnés.

Le surprovisionnement présente d'autres avantages moins évidents. Sans surprovisionnement, l'un des effets secondaires d'un cluster très utilisé est que les pods prendront des décisions de planification moins optimales en utilisant la preferredDuringSchedulingIgnoredDuringExecution règle d'affinité des pods ou des nœuds. Un cas d'utilisation courant consiste à séparer les pods d'une application hautement disponible entre les zones de disponibilité à l'aide de AntiAffinity. Le surprovisionnement peut augmenter de manière significative les chances qu'un nœud de la zone appropriée soit disponible.

La quantité de capacité surprovisionnée est une décision commerciale prudente pour votre organisation. Il s'agit essentiellement d'un compromis entre performance et coût. Une façon de prendre cette décision est de déterminer votre fréquence de mise à l'échelle moyenne et de la diviser par le temps nécessaire pour augmenter la taille d'un nouveau nœud. Par exemple, si, en moyenne, vous avez besoin d'un nouveau nœud toutes les 30 secondes et qu'EC2 met 30 secondes à provisionner un nouveau nœud, un seul nœud de surprovisionnement garantira qu'il y a toujours un nœud supplémentaire disponible, réduisant ainsi la latence de planification de 30 secondes au prix d'une seule instance EC2 supplémentaire. Pour améliorer les décisions de planification des zones, surprovisionnez un nombre de nœuds égal au nombre de zones de disponibilité de votre groupe EC2 Auto Scaling afin de garantir que le planificateur puisse sélectionner la meilleure zone pour les pods entrants.

Empêcher la réduction des expulsions

L'expulsion de certaines applications est coûteuse. L'analyse des mégadonnées, les tâches d'apprentissage automatique et les tests finiront par être terminés, mais devront être redémarrés en cas d'interruption. Le Cluster Autoscaler tentera de réduire la taille de tout nœud en dessous du seuil d'utilisation, ce qui interrompra tous les pods restants sur le nœud. Cela peut être évité en veillant à ce que les pods dont l'expulsion coûte cher soient protégés par une étiquette reconnue par le Cluster Autoscaler.

Assurez-vous que :

Cas d’utilisation avancés

Volumes EBS

Le stockage persistant est essentiel pour créer des applications dynamiques, telles que des bases de données ou des caches distribués. Les volumes EBS permettent ce cas d'utilisation sur Kubernetes, mais sont limités à une zone spécifique. Ces applications peuvent être hautement disponibles si elles sont partagées sur plusieurs zones de zone de zone de zone à l'aide d'un volume EBS distinct pour chaque zone de zone de zone de zone. Le Cluster Autoscaler peut ensuite équilibrer la mise à l'échelle des groupes d'autoscaling EC2.

Assurez-vous que :

Co-Scheduling

Les tâches d'entraînement distribué de machine learning bénéficient de manière significative de la latence réduite des configurations de nœuds de même zone. Ces charges de travail déploient plusieurs modules dans une zone spécifique. Cela peut être réalisé en définissant l'affinité des pods pour tous les pods co-planifiés ou en utilisant l'topologyKey: failure-domain.beta.kubernetes.io/zoneaffinité des nœuds. Le Cluster Autoscaler agrandira ensuite une zone spécifique en fonction des demandes. Vous souhaiterez peut-être allouer plusieurs groupes EC2 Auto Scaling, un par zone de disponibilité, afin de permettre le basculement pour l'ensemble de la charge de travail co-planifiée.

Assurez-vous que :

Accélérateurs

Certains clusters tirent parti d'accélérateurs matériels spécialisés tels que le GPU. Lors de la mise à l'échelle, le plug-in du dispositif accélérateur peut prendre plusieurs minutes pour annoncer la ressource au cluster. Le Cluster Autoscaler a simulé que ce nœud disposerait de l'accélérateur, mais tant que l'accélérateur ne sera pas prêt et ne mettra pas à jour les ressources disponibles du nœud, les pods en attente ne peuvent pas être planifiés sur le nœud. Cela peut entraîner une Répétition inutile de la montée en puissance.

De plus, les nœuds dotés d'accélérateurs et utilisant beaucoup de CPU ou de mémoire ne seront pas pris en compte pour la réduction de la taille, même si l'accélérateur n'est pas utilisé. Ce comportement peut être coûteux en raison du coût relatif des accélérateurs. Au lieu de cela, le Cluster Autoscaler peut appliquer des règles spéciales pour prendre en compte les nœuds à réduire s'ils ont des accélérateurs inoccupés.

Pour garantir le bon comportement dans ces cas, vous pouvez configurer le kubelet de vos nœuds accélérateurs pour étiqueter le nœud avant qu'il ne rejoigne le cluster. Le Cluster Autoscaler utilisera ce sélecteur d'étiquette pour déclencher le comportement optimisé de l'accélérateur.

Assurez-vous que :

Redimensionnement à partir de 0

Cluster Autoscaler est capable de dimensionner les groupes de nœuds vers et à partir de zéro, ce qui peut permettre de réaliser d'importantes économies. Il détecte les ressources du processeur, de la mémoire et du GPU d'un groupe Auto Scaling en inspectant les ressources InstanceType spécifiées dans son LaunchConfiguration ou LaunchTemplate. Certains pods nécessitent des ressources supplémentaires, comme WindowsENI ou des ressources spécifiques PrivateIPv4Address NodeSelectors ou des Taints qui ne peuvent pas être découverts à partir du LaunchConfiguration. Le Cluster Autoscaler peut prendre en compte ces facteurs en les découvrant à partir des balises du groupe EC2 Auto Scaling. Par exemple :

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoSchedule

Paramètres supplémentaires

Il existe de nombreuses options de configuration qui peuvent être utilisées pour régler le comportement et les performances du Cluster Autoscaler. Une liste complète des paramètres est disponible sur GitHub.

Ressources supplémentaires

Cette page contient une liste de présentations et de démonstrations de Cluster Autoscaler. Si vous souhaitez ajouter une présentation ou une démo ici, veuillez envoyer une pull request.

Références