Chapitre 6. Appliquer l'autoscaling à un cluster OpenShift Container Platform
L'application de l'autoscaling à un cluster OpenShift Container Platform implique le déploiement d'un autoscaler de cluster, puis le déploiement d'autoscalers de machine pour chaque type de machine dans votre cluster.
Vous ne pouvez configurer l'autoscaler de cluster que dans les clusters où l'API machine est opérationnelle.
6.1. À propos de l'autoscaler de cluster
L'autoscaler de cluster ajuste la taille d'un cluster OpenShift Container Platform pour répondre à ses besoins de déploiement actuels. Il utilise des arguments déclaratifs, de type Kubernetes, pour fournir une gestion de l'infrastructure qui ne repose pas sur des objets d'un fournisseur de cloud spécifique. L'autoscaler de cluster a une portée de cluster et n'est pas associé à un espace de noms particulier.
L'autoscaler de cluster augmente la taille du cluster lorsque des pods ne parviennent pas à être planifiés sur l'un des nœuds de travail actuels en raison de ressources insuffisantes ou lorsqu'un autre nœud est nécessaire pour répondre aux besoins de déploiement. L'autoscaler de cluster n'augmente pas les ressources du cluster au-delà des limites que vous avez spécifiées.
L'autoscaler de cluster calcule la mémoire totale, le CPU et le GPU sur tous les nœuds du cluster, même s'il ne gère pas les nœuds du plan de contrôle. Ces valeurs ne sont pas axées sur une seule machine. Il s'agit d'une agrégation de toutes les ressources de l'ensemble de la grappe. Par exemple, si vous définissez la limite maximale des ressources mémoire, l'autoscaler de la grappe inclut tous les nœuds de la grappe lors du calcul de l'utilisation actuelle de la mémoire. Ce calcul est ensuite utilisé pour déterminer si l'autoscaler de cluster a la capacité d'ajouter des ressources de travailleur supplémentaires.
Assurez-vous que la valeur maxNodesTotal dans la définition de la ressource ClusterAutoscaler que vous créez est suffisamment grande pour tenir compte du nombre total possible de machines dans votre cluster. Cette valeur doit englober le nombre de machines du plan de contrôle et le nombre possible de machines de calcul vers lesquelles vous pourriez évoluer.
Toutes les 10 secondes, l'autoscaler de cluster vérifie quels sont les nœuds inutiles dans le cluster et les supprime. L'autoscaler de cluster considère qu'un nœud doit être supprimé si les conditions suivantes sont remplies :
-
L'utilisation du nœud est inférieure au seuil node utilization level pour la grappe. Le niveau d'utilisation du nœud est la somme des ressources demandées divisée par les ressources allouées au nœud. Si vous ne spécifiez pas de valeur dans la ressource personnalisée
ClusterAutoscaler, l'autoscaler de cluster utilise une valeur par défaut de0.5, ce qui correspond à une utilisation de 50 %. - L'autoscaler de cluster peut déplacer tous les pods en cours d'exécution sur le nœud vers les autres nœuds. Le planificateur Kubernetes est responsable de la planification des pods sur les nœuds.
- L'autoscaler de cluster n'a pas d'annotation de réduction d'échelle désactivée.
Si les types de pods suivants sont présents sur un nœud, l'autoscaler de cluster ne supprimera pas le nœud :
- Les pods dont les budgets de perturbation des pods (PDB) sont restrictifs.
- Les pods du système Kube qui ne s'exécutent pas par défaut sur le nœud.
- Les pods du système Kube qui n'ont pas de PDB ou qui ont un PDB trop restrictif.
- Pods qui ne sont pas soutenus par un objet contrôleur tel qu'un déploiement, un ensemble de répliques ou un ensemble avec état.
- Pods avec stockage local.
- Pods qui ne peuvent pas être déplacés ailleurs en raison d'un manque de ressources, de sélecteurs de nœuds ou d'affinités incompatibles, d'anti-affinités correspondantes, etc.
-
À moins qu'ils n'aient également une annotation
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true", les pods qui ont une annotation"cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
Par exemple, vous fixez la limite maximale de l'unité centrale à 64 cœurs et configurez l'autoscaler de cluster pour qu'il ne crée que des machines dotées de 8 cœurs chacune. Si votre cluster commence avec 30 cœurs, l'autoscaler de cluster peut ajouter jusqu'à 4 nœuds supplémentaires avec 32 cœurs, pour un total de 62.
Si vous configurez l'autoscaler de cluster, des restrictions d'utilisation supplémentaires s'appliquent :
- Ne modifiez pas directement les nœuds faisant partie de groupes de nœuds à mise à l'échelle automatique. Tous les nœuds d'un même groupe de nœuds ont la même capacité et les mêmes étiquettes et exécutent les mêmes pods système.
- Spécifiez les requêtes pour vos pods.
- Si vous devez éviter que des pods soient supprimés trop rapidement, configurez des PDB appropriés.
- Confirmez que le quota de votre fournisseur de cloud est suffisamment important pour prendre en charge les pools de nœuds maximums que vous configurez.
- N'exécutez pas d'autoscalers de groupes de nœuds supplémentaires, en particulier ceux proposés par votre fournisseur de cloud.
L'autoscaler de pods horizontaux (HPA) et l'autoscaler de clusters modifient les ressources du cluster de différentes manières. Le HPA modifie le nombre de répliques du déploiement ou de l'ensemble de répliques en fonction de la charge CPU actuelle. Si la charge augmente, le HPA crée de nouvelles répliques, quelle que soit la quantité de ressources disponibles pour la grappe. S'il n'y a pas assez de ressources, l'autoscaler du cluster ajoute des ressources pour que les pods créés par l'HPA puissent fonctionner. Si la charge diminue, l'APH arrête certaines répliques. Si cette action entraîne une sous-utilisation ou un vide complet de certains nœuds, l'autoscaler de cluster supprime les nœuds inutiles.
L'autoscaler de cluster prend en compte les priorités des pods. La fonction de priorité et de préemption des pods permet de planifier les pods en fonction des priorités si le cluster ne dispose pas de suffisamment de ressources, mais l'autoscaler de cluster garantit que le cluster dispose des ressources nécessaires pour faire fonctionner tous les pods. Pour respecter l'intention des deux fonctionnalités, l'autoscaler de cluster inclut une fonction de coupure de priorité. Vous pouvez utiliser cette coupure pour planifier les pods "best-effort", qui n'entraînent pas l'augmentation des ressources par l'autoscaler de cluster, mais qui s'exécutent uniquement lorsque des ressources sont disponibles.
Les modules dont la priorité est inférieure à la valeur limite n'entraînent pas l'augmentation de la taille du cluster et n'empêchent pas la réduction de la taille du cluster. Aucun nouveau nœud n'est ajouté pour exécuter les pods, et les nœuds exécutant ces pods peuvent être supprimés pour libérer des ressources.
La mise à l'échelle automatique du cluster est prise en charge pour les plates-formes qui disposent d'une API machine.
