3.2. Custom Metrics Autoscaler Vue d’ensemble de l’opérateur
En tant que développeur, vous pouvez utiliser Custom Metrics Autoscaler Operator pour Red Hat OpenShift pour spécifier comment Red Hat OpenShift Service sur AWS devrait automatiquement augmenter ou diminuer le nombre de pods pour un déploiement, un ensemble d’état, une ressource personnalisée ou un travail basé sur des métriques personnalisées qui ne sont pas basées uniquement sur le CPU ou la mémoire.
Le Custom Metrics Autoscaler Operator est un opérateur optionnel, basé sur le Kubernetes Event Driven Autoscaler (KEDA), qui permet de mettre à l’échelle les charges de travail à l’aide de sources de mesures supplémentaires autres que les métriques de pod.
L’autoscaler de mesures personnalisées ne prend actuellement en charge que les métriques Prometheus, CPU, mémoire et Apache Kafka.
Le Custom Metrics Autoscaler Operator met à l’échelle vos pods de haut en bas en fonction de mesures externes personnalisées provenant d’applications spécifiques. Les autres applications continuent d’utiliser d’autres méthodes de mise à l’échelle. Configurez les déclencheurs, également connus sous le nom de scalers, qui sont la source des événements et des métriques que les métriques automatiques personnalisables utilisent pour déterminer comment mettre à l’échelle. L’autoscaler de mesures personnalisées utilise une API de métriques pour convertir les métriques externes en une forme que Red Hat OpenShift Service sur AWS peut utiliser. L’autoscaler de mesures personnalisées crée un autoscaleur de pod horizontal (HPA) qui effectue la mise à l’échelle réelle.
Afin d’utiliser le programmeur automatique de mesures personnalisées, vous créez un objet ScaledObject ou ScaledJob pour une charge de travail, qui est une ressource personnalisée (CR) qui définit les métadonnées de mise à l’échelle. Le déploiement ou la tâche à mettre à l’échelle, la source des métriques à mettre à l’échelle (déclenchant) et d’autres paramètres tels que les nombres de répliques minimum et maximum autorisés.
Il n’est possible de créer qu’un seul objet à l’échelle ou un travail à l’échelle pour chaque charge de travail que vous souhaitez mettre à l’échelle. En outre, vous ne pouvez pas utiliser un objet à l’échelle ou un travail à l’échelle et le pod horizontal autoscaler (HPA) sur la même charge de travail.
L’autoscaleur de mesures personnalisées, contrairement à l’HPA, peut atteindre zéro. Lorsque vous définissez la valeur minReplicaCount dans les métriques personnalisées autoscaler CR à 0, les métriques personnalisées autoscaler réduit la charge de travail de 1 à 0 répliques à ou plus de 0 répliques à 1. C’est ce qu’on appelle la phase d’activation. Après avoir mis à l’échelle jusqu’à 1 réplique, l’HPA prend le contrôle de la mise à l’échelle. C’est ce qu’on appelle la phase de mise à l’échelle.
Certains déclencheurs vous permettent de modifier le nombre de répliques qui sont mises à l’échelle par le cluster métrique autoscaler. Dans tous les cas, le paramètre pour configurer la phase d’activation utilise toujours la même phrase, préfixée avec activation. Ainsi, si le paramètre seuil configure la mise à l’échelle, activationThreshold configurerait l’activation. La configuration des phases d’activation et de mise à l’échelle vous permet une plus grande flexibilité avec vos stratégies de mise à l’échelle. À titre d’exemple, vous pouvez configurer une phase d’activation plus élevée pour éviter une mise à l’échelle vers le haut ou vers le bas si la métrique est particulièrement faible.
La valeur d’activation a plus de priorité que la valeur de mise à l’échelle en cas de décisions différentes pour chacune. À titre d’exemple, si le seuil est fixé à 10, et que le seuil d’activation est de 50, si la métrique rapporte 40, l’échelle n’est pas active et les pods sont mis à l’échelle à zéro même si l’HPA nécessite 4 instances.
Figure 3.1. Flux de travail autoscaler de mesures personnalisées
- Créez ou modifiez une ressource personnalisée d’objet à échelle pour une charge de travail sur un cluster. L’objet contient la configuration de mise à l’échelle de cette charge de travail. Avant d’accepter le nouvel objet, le serveur API OpenShift l’envoie au processus d’admission autoscaler personnalisé pour s’assurer que l’objet est valide. En cas de réussite de la validation, le serveur API persiste l’objet.
- Le contrôleur autoscaleur de mesure personnalisé montre des objets nouveaux ou modifiés à l’échelle. Lorsque le serveur API OpenShift informe le contrôleur d’une modification, le contrôleur surveille toutes les sources de déclenchement externes, également connues sous le nom de sources de données, qui sont spécifiées dans l’objet pour les modifications apportées aux données métriques. Il y a un ou plusieurs évolutifs qui demandent des données de mise à l’échelle à partir de la source de déclenchement externe. Ainsi, pour un type de déclenchement Kafka, le contrôleur utilise l’échelle Kafka pour communiquer avec une instance Kafka afin d’obtenir les données demandées par le déclencheur.
- Le contrôleur crée un objet horizontal pod autoscaler pour l’objet mis à l’échelle. En conséquence, l’opérateur Horizontal Pod Autoscaler (HPA) commence à surveiller les données de mise à l’échelle associées au déclencheur. Le HPA demande des données de mise à l’échelle à partir du point d’extrémité du serveur API OpenShift cluster.
- Le point d’extrémité du serveur de l’API OpenShift est servi par l’adaptateur métriques autoscaler personnalisé. Lorsque l’adaptateur métrique reçoit une demande de mesures personnalisées, il utilise une connexion GRPC au contrôleur pour la demander pour les données de déclenchement les plus récentes reçues de l’échelleur.
- La HPA prend des décisions de mise à l’échelle en fonction des données reçues de l’adaptateur métrique et augmente ou diminue la charge de travail en augmentant ou en diminuant les répliques.
- En tant qu’il fonctionne, une charge de travail peut affecter les métriques de mise à l’échelle. Ainsi, si une charge de travail est mise à l’échelle pour gérer le travail dans une file d’attente Kafka, la taille de la file d’attente diminue après que la charge de travail traite tout le travail. En conséquence, la charge de travail est réduite.
- Lorsque les métriques sont dans une plage spécifiée par la valeur minReplicaCount, le contrôleur autoscaleur métrique personnalisé désactive toute mise à l’échelle et laisse le compte de réplique à un niveau fixe. Lorsque les métriques dépassent cette plage, le contrôleur d’échelle automatique de mesures personnalisées permet la mise à l’échelle et permet à l’HPA de mettre à l’échelle la charge de travail. Bien que la mise à l’échelle soit désactivée, la HPA ne prend aucune mesure.
3.2.1. Certificats CA personnalisés pour le Custom Metrics Autoscaler Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator utilise par défaut des certificats CA de service générés automatiquement pour se connecter aux services on-cluster.
Lorsque vous souhaitez utiliser des services hors-clus qui nécessitent des certificats CA personnalisés, vous pouvez ajouter les certificats requis à une carte de configuration. Ensuite, ajoutez la carte de configuration à la ressource personnalisée KedaController comme décrit dans Installation des métriques personnalisées autoscaler. L’Opérateur charge ces certificats lors du démarrage et les enregistre selon la confiance de l’Opérateur.
Les cartes de configuration peuvent contenir un ou plusieurs fichiers de certificats contenant un ou plusieurs certificats CA codés PEM. En outre, vous pouvez utiliser des cartes de configuration séparées pour chaque fichier de certificat.
Lorsque vous mettez à jour la carte de configuration pour ajouter des certificats supplémentaires, vous devez redémarrer le pod keda-operator-* pour que les modifications entrent en vigueur.