Chapitre 4. Cluster autoscaling pour ROSA HCP
L’application d’autoscaling à Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP) implique la configuration d’un ou de plusieurs pools de machines avec autoscaling. Il est possible d’utiliser le Cluster Autoscaler pour configurer davantage l’autoscaling à l’échelle du cluster qui s’applique à tous les pools de machines qui sont autoscaling.
4.1. À propos du cluster autoscaler Copier lienLien copié sur presse-papiers!
Le cluster autoscaler ajuste la taille d’un ROSA avec le cluster HCP pour répondre à ses besoins actuels de déploiement. Il utilise des arguments déclaratifs de style Kubernetes pour fournir une gestion de l’infrastructure qui ne repose pas sur des objets d’un fournisseur de cloud spécifique. Le cluster autoscaler a une portée de cluster, et n’est pas associé à un espace de noms particulier. Dans ROSA avec HCP, le Cluster Autoscaler est entièrement géré, ce qui signifie qu’il est hébergé avec le plan de contrôle.
Le cluster autoscaler augmente la taille du cluster lorsqu’il y a des pods qui n’arrivent pas à planifier 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. Le cluster autoscaler n’augmente pas les ressources de cluster au-delà des limites que vous spécifiez.
Le cluster autoscaler calcule la mémoire totale, le CPU et le GPU uniquement sur les nœuds qui appartiennent aux pools de machines d’autoscaling. L’ensemble des nœuds de pool de machines qui ne sont pas autoscaling sont exclus de cette agrégation. À titre d’exemple, si vous définissez le maxNodesTotal à 50 sur un ROSA avec cluster HCP avec trois pools de machines dans lesquels un seul pool de machines n’est pas autoscaling, le cluster autoscaler limite les nœuds totaux à 50 dans seulement les deux pools de machines qui sont autoscaling. Le pool de machines à mise à l’échelle manuelle unique peut avoir des nœuds supplémentaires, ce qui fait que les nœuds de cluster totalisent plus de 50.
Élimination automatique des nœuds
Chaque 10 secondes, le cluster autoscaler vérifie quels nœuds sont inutiles dans le cluster et les supprime. L’autoscaleur de cluster considère un nœud pour l’enlèvement si les conditions suivantes s’appliquent:
- L’utilisation des nœuds est inférieure au seuil d’utilisation des nœuds pour le cluster. Le niveau d’utilisation des nœuds correspond à la somme des ressources demandées divisées par les ressources allouées au nœud. Lorsque vous ne spécifiez pas une valeur dans la ressource personnalisée ClusterAutoscaler, le cluster autoscaler utilise une valeur par défaut de 0,5, ce qui correspond à une utilisation de 50%.
- Le cluster autoscaler peut déplacer tous les pods s’exécutant sur le nœud vers les autres nœuds. Le planificateur de Kubernetes est responsable de la planification des pods sur les nœuds.
- Le cluster autoscaler n’a pas de mise à l’échelle vers le bas annotation désactivée.
Lorsque les types de gousses suivants sont présents sur un nœud, le cluster autoscaler ne supprimera pas le nœud:
- Les pods avec des budgets de perturbation des pod restrictifs (PDB).
- Les pods du système Kube qui ne s’exécutent pas sur le nœud par défaut.
- Les gousses de système Kube qui n’ont pas de PDB ou qui ont un PDB trop restrictif.
- Les pods qui ne sont pas soutenus par un objet de contrôleur tel qu’un déploiement, un ensemble de répliques ou un ensemble étatique.
- Gousses avec stockage local.
- Des pods qui ne peuvent pas être déplacés ailleurs en raison d’un manque de ressources, de sélecteurs de nœuds incompatibles ou d’affinité, et ainsi de suite.
- À moins qu’ils aient également une "cluster-autoscaler.kubernetes.io/safe-to-evict": "vrai" annotation, pods qui ont un "cluster-autoscaler.kubernetes.io/safe-to-evict": "faux" annotation.
À titre d’exemple, vous définissez la limite maximale de CPU à 64 cœurs et configurez le cluster autoscaler pour créer uniquement des machines qui ont 8 cœurs chacun. Lorsque votre cluster commence avec 30 cœurs, le cluster autoscaler peut ajouter jusqu’à 4 nœuds supplémentaires avec 32 cœurs, pour un total de 62.
Limites
Lorsque vous configurez le cluster autoscaler, des restrictions d’utilisation supplémentaires s’appliquent:
- Il ne faut pas modifier directement les nœuds qui sont dans les groupes de nœuds autoscalenés. Dans le même groupe de nœuds, tous les nœuds ont la même capacité et les mêmes étiquettes et exécutent les mêmes pods système.
- Indiquez les demandes pour vos pods.
- Lorsque vous devez éviter que les pods ne soient supprimés trop rapidement, configurez les PDB appropriés.
- Confirmez que votre quota de fournisseur de cloud est suffisamment important pour prendre en charge les pools de nœuds maximum que vous configurez.
- Il ne faut pas exécuter d’autoscaleurs de groupe de nœuds supplémentaires, en particulier ceux offerts par votre fournisseur de cloud.
Le cluster autoscaler n’ajoute des nœuds dans les groupes de nœuds autoscales que si cela se traduirait par un pod programmé. Lorsque les types de nœuds disponibles ne peuvent pas répondre aux exigences d’une demande de pod, ou si les groupes de nœuds qui pourraient répondre à ces exigences sont à leur taille maximale, l’autoscaleur de cluster ne peut pas augmenter.
Interaction avec d’autres fonctions de planification
Le pod horizontal autoscaler (HPA) et le cluster autoscaler modifient les ressources de cluster de différentes manières. L’HPA modifie le nombre de répliques du déploiement ou de la réplique en fonction de la charge CPU actuelle. En cas d’augmentation de la charge, la HPA crée de nouvelles répliques, quelle que soit la quantité de ressources disponibles pour le cluster. En l’absence de ressources, le cluster autoscaler ajoute des ressources afin que les gousses créées par HPA puissent s’exécuter. En cas de diminution de la charge, la HPA arrête certaines répliques. Lorsque cette action fait que certains nœuds sont sous-utilisés ou complètement vides, le cluster autoscaler supprime les nœuds inutiles.
Le cluster autoscaler prend en compte les priorités des pod. La fonction Pod Priority and Preemption permet de planifier les pods en fonction des priorités si le cluster n’a pas suffisamment de ressources, mais le cluster autoscaler garantit que le cluster dispose de ressources pour exécuter tous les pods. Afin d’honorer l’intention des deux fonctionnalités, le cluster autoscaler inclut une fonction de coupure prioritaire. Cette coupure peut être utilisée pour programmer les pods "meilleur effort", ce qui n’entraîne pas le cluster autoscaler d’augmenter les ressources, mais plutôt de s’exécuter uniquement lorsque des ressources de rechange sont disponibles.
Les gousses de priorité inférieures à la valeur de coupure n’entraînent pas la mise à l’échelle du cluster ou n’empêchent pas le cluster de descendre à l’échelle. Aucun nouveau nœud n’est ajouté pour exécuter les pods, et les nœuds exécutant ces pods peuvent être supprimés sur des ressources gratuites.