Cette page explique comment utiliser l'autoscaling horizontal des pods pour effectuer l'autoscaling d'un déploiement à l'aide de différents types de métriques. Vous pouvez appliquer les mêmes consignes pour configurer un objet HorizontalPodAutoscaler
dans n'importe quel objet Deployment évolutif.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update
.
Versions de l'API pour les objets HorizontalPodAutoscaler
Lorsque vous utilisez Google Cloud Console, les objets HorizontalPodAutoscaler
sont créés à l'aide de l'API autoscaling/v2
.
Lorsque vous utilisez kubectl
pour créer ou afficher des informations sur un autoscaler horizontal de pods, vous pouvez spécifier l'API autoscaling/v1
ou l'API autoscaling/v2
.
apiVersion: autoscaling/v1
est la version par défaut et ne vous permet d'effectuer un autoscaling qu'en fonction de l'utilisation du processeur. Pour effectuer un autoscaling à partir d'autres métriques, il est recommandé d'utiliser la versionapiVersion: autoscaling/v2
. L'exemple présenté dans la section Créer l'exemple de déploiement utiliseapiVersion: autoscaling/v1
.La version
apiVersion: autoscaling/v2
est recommandée pour la création d'objetsHorizontalPodAutoscaler
. Cette version permet d'effectuer un autoscaling en fonction de plusieurs métriques, y compris des métriques personnalisées ou externes. Tous les autres exemples de cette rubrique utilisent la versionapiVersion: autoscaling/v2
.
Pour vérifier quelles versions d'API sont compatibles, utilisez la commande kubectl api-versions
.
Vous pouvez spécifier l'API à utiliser lors de l'affichage des détails d'un autoscaler horizontal de pods utilisant apiVersion: autoscaling/v2
.
Créer l'exemple de déploiement
Avant de pouvoir créer un autoscaler horizontal de pods, vous devez créer la charge de travail qu'il devra surveiller. Les exemples de cette section appliquent différentes configurations d'autoscaler horizontal de pods au déploiement nginx
suivant. Des exemples distincts illustrent l'utilisation d'un autoscaler horizontal de pods basé sur l'utilisation des ressources, sur une métrique personnalisée ou externe et sur plusieurs métriques.
Enregistrez le fichier suivant dans un fichier nommé nginx.yaml
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
resources:
# You must specify requests for CPU to autoscale
# based on CPU utilization
requests:
cpu: "250m"
Ce manifeste spécifie une valeur pour les requêtes de processeur. Si vous souhaitez effectuer un scaling automatique en fonction de l'utilisation d'une ressource exprimée en pourcentage, vous devez spécifier les requêtes pour cette ressource. Si vous ne spécifiez pas de requêtes, vous ne pouvez effectuer un scaling automatique qu'en fonction de la valeur absolue de l'utilisation de la ressource, par exemple, pour l'utilisation de processeur, exprimée en milliprocesseurs.
Pour créer le déploiement, appliquez le manifeste nginx.yaml
:
kubectl apply -f nginx.yaml
Le déploiement comporte la valeur spec.replicas
définie sur 3, donc trois pods sont déployés.
Vous pouvez le vérifier à l'aide de la commande kubectl get deployment nginx
.
Chacun des exemples de cette section applique un autoscaler horizontal de pods différent à un exemple de déploiement nginx.
Effectuer un autoscaling basé sur l'utilisation des ressources
Cet exemple crée un objet HorizontalPodAutoscaler
afin d'effectuer un autoscaling du déploiement nginx
lorsque l'utilisation du processeur dépasse 50 %, et garantit l'existence d'au moins 1 instance dupliquée et d'au plus 10 instances dupliquées.
Vous pouvez créer un autoscaler horizontal de pods qui cible l'utilisation du processeur à l'aide de la console Google Cloud, de la commande kubectl apply
ou, pour l'utilisation moyenne du processeur, de la commande kubectl autoscale
.
Console
Accédez à la page Charges de travail dans la console Google Cloud.
Cliquez sur le nom du déploiement
nginx
.Cliquez sur list Actions > Évoluer automatiquement.
Spécifiez les valeurs suivantes :
- Nombre minimal d'instances dupliquées : 1
- Nombre maximal d'instances dupliquées : 10
- Métrique d'autoscaling : processeur
- Cible : 50
- Unité : %
Cliquez sur OK.
Cliquez sur Évoluer automatiquement.
kubectl apply
Enregistrez le fichier manifeste YAML suivant dans un fichier nommé nginx-hpa.yaml
:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
Pour créer le HPA, appliquez le fichier manifeste à l'aide de la commande suivante :
kubectl apply -f nginx-hpa.yaml
kubectl autoscale
Pour créer un objet HorizontalPodAutoscaler
qui ne cible que l'utilisation moyenne du processeur, vous pouvez utiliser la commande kubectl autoscale
:
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
Pour obtenir la liste des autoscalers horizontaux de pods dans le cluster, exécutez la commande suivante :
kubectl get hpa
Le résultat ressemble à ce qui suit :
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 3 61s
Pour obtenir des détails sur l'autoscaler horizontal de pods, vous pouvez utiliser la console Google Cloud ou la commande kubectl
.
Console
Accédez à la page Charges de travail dans la console Google Cloud.
Cliquez sur le nom du déploiement
nginx
.Affichez la configuration de l'autoscaler horizontal de pods dans la section Autoscaler.
D'autres informations sur les événements d'autoscaling sont disponibles dans l'onglet Événements.
kubectl get
Pour obtenir des détails sur l'autoscaler horizontal de pods, vous pouvez utiliser kubectl get hpa
avec l'option -o yaml
. Le champ status
contient des informations sur le nombre actuel d'instances dupliquées et les événements d'autoscaling récents.
kubectl get hpa nginx -o yaml
Le résultat ressemble à ce qui suit :
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
annotations:
autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
HPA was able to successfully calculate a replica count from cpu resource utilization
(percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
desired count is within the acceptable range"}]'
autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
creationTimestamp: "2019-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
targetCPUUtilizationPercentage: 50
status:
currentCPUUtilizationPercentage: 0
currentReplicas: 3
desiredReplicas: 3
Avant de suivre les autres exemples présentés dans cette section, supprimez le HPA :
kubectl delete hpa nginx
Lorsque vous supprimez un autoscaler horizontal de pods, le nombre d'instances dupliquées du déploiement reste le même. Le déploiement ne rétablit pas automatiquement l'état qui précède l'application de l'autoscaler de pods horizontaux.
Apprenez-en plus sur la suppression d'un autoscaler horizontal de pods.
Autoscaling basé sur le trafic de l'équilibreur de charge
L'autoscaling basé sur le trafic est une fonctionnalité de GKE qui intègre des signaux d'utilisation du trafic provenant d'équilibreurs de charge à des pods d'autoscaling.
L'utilisation du trafic comme signal d'autoscaling peut être utile, car le trafic est un indicateur principal de la charge, complémentaire aux processeurs et à la mémoire. L'intégration avec GKE garantit que la configuration est facile et que l'autoscaling réagit rapidement aux pics de trafic pour répondre à la demande.
L'autoscaling basé sur le trafic est activé par le contrôleur Gateway et ses fonctionnalités de gestion du trafic globale. Pour en savoir plus, consultez la page Autoscaling basé sur le trafic.
L'autoscaling basé sur le trafic de l'équilibreur de charge n'est disponible que pour les charges de travail passerelle.
Exigences
L'autoscaling basé sur le trafic présente les exigences suivantes:
- Compatible avec GKE 1.24 et versions ultérieures.
- API Gateway activée dans votre cluster GKE.
- Compatible avec le trafic qui transite par des équilibreurs de charge déployés à l'aide de l'API Gateway et de la ressource GatewayClass
gke-l7-global-external-managed
,gke-l7-regional-external-managed
,gke-l7-rilb
ougke-l7-gxlb
.
Limites
L'autoscaling basé sur le trafic présente les limites suivantes :
- Non compatible avec les ressources GatewayClass multicluster (
gke-l7-global-external-managed-mc
,gke-l7-regional-external-managed-mc
,gke-l7-rilb-mc
etgke-l7-gxlb-mc
). - Non compatible avec le trafic utilisant des services de type
ClusterIP
ouLoadBalancer
.
Déployer l'autoscaling basé sur le trafic
L'exercice suivant utilise HorizontalPodAutoscaler
pour procéder à l'autoscaling du déploiement store-autoscale
en fonction du trafic qu'il reçoit. Une passerelle accepte le trafic entrant provenant d'Internet pour les pods. L'autoscaler compare les signaux de trafic de la passerelle à la capacité de trafic par pod configurée sur la ressource de service store-autoscale
. En générant du trafic vers la passerelle, vous influencez le nombre de pods déployés.
Le schéma suivant illustre le fonctionnement de l'autoscaling basé sur le trafic:
Pour déployer l'autoscaling basé sur le trafic, procédez comme suit:
Pour les clusters standards, vérifiez que les ressources GatewayClasses sont installées dans votre cluster. Pour les clusters Autopilot, les ressources GatewayClasses sont installés par défaut.
kubectl get gatewayclass
Le résultat confirme que les ressources GatewayClass de GKE sont prêtes à être utilisées dans votre cluster:
NAME CONTROLLER ACCEPTED AGE gke-l7-global-external-managed networking.gke.io/gateway True 16h gke-l7-regional-external-managed networking.gke.io/gateway True 16h gke-l7-gxlb networking.gke.io/gateway True 16h gke-l7-rilb networking.gke.io/gateway True 16h
Si vous n'obtenez pas ce résultat, activez l'API Gateway dans votre cluster GKE.
Déployez l'exemple d'application et l'équilibreur de charge de passerelle sur votre cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml
L'exemple d'application crée:
- Un déploiement avec deux instances dupliquées.
- Capacité de service avec
max-rate-per-endpoint
défini sur10
Tant que cette fonctionnalité est disponible en version Bêta, utilisez une annotation dans le service. Lorsque cette fonctionnalité sera disponible pour tous les utilisateurs, la règle de service remplacera l'annotation. Pour en savoir plus sur les fonctionnalités de la ressource Gateway, consultez la page Fonctionnalités GatewayClass. - Une passerelle externe pour accéder à l'application sur Internet. Pour en savoir plus sur l'utilisation des équilibreurs de charge Gateway, consultez la page Déployer des passerelles.
- Un objet HTTPRoute qui correspond à tout le trafic et l'envoie au service
store-autoscale
.
La capacité du service est un élément essentiel de l'utilisation de l'autoscaling basé sur le trafic, car elle détermine la quantité de trafic par pod qui déclenche un événement d'autoscaling. Elle configure la capacité de service à l'aide de l'annotation de service
networking.gke.io/max-rate-per-endpoint
, qui définit le trafic maximal qu'un service doit recevoir en requêtes par seconde et par pod. La capacité de service est spécifique à l'application. Pour en savoir plus, consultez la section Déterminer la capacité de votre service.Enregistrez le manifeste suivant sous le nom
hpa.yaml
:apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: store-autoscale spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: store-autoscale minReplicas: 1 maxReplicas: 10 metrics: - type: Object object: describedObject: kind: Service name: store-autoscale metric: name: "autoscaling.googleapis.com|gclb-capacity-utilization" target: averageValue: 70 type: AverageValue
Ce fichier manifeste décrit un objet
HorizontalPodAutoscaler
avec les propriétés suivantes:minReplicas
etmaxReplicas
: définissent le nombre minimal et maximal d'instances dupliquées pour ce déploiement. Dans cette configuration, le nombre de pods peut faire évoluer de 1 à 10 instances dupliquées.describedObject.name: store-autoscale
: référence au servicestore-autoscale
qui définit la capacité du trafic.scaleTargetRef.name: store-autoscale
: référence au déploiementstore-autoscale
qui définit la ressource mise à l'échelle par l'autoscaler horizontal de pods.averageValue: 70
: valeur moyenne cible de l'utilisation de la capacité. Cela donne à l'autoscaler horizontal des pods une marge de croissance qui permet aux pods en cours d'exécution de traiter le trafic excédentaire pendant la création des pods.
L'autoscaler horizontal des pods entraîne le comportement de trafic suivant:
- Le nombre de pods est ajusté entre 1 et 10 instances dupliquées afin d'atteindre 70% du taux maximal par point de terminaison. Cela se traduit par 7 RPS par pod lorsque
max-rate-per-endpoint=10
. - À plus de 7 RPS par pod, les pods font l'objet d'un scaling à la hausse jusqu'à atteindre le nombre maximal de 10 instances dupliquées ou jusqu'à que le trafic moyen atteigne 7 RPS par pod.
- Si le trafic est réduit, les pods évoluent vers le bas à un taux raisonnable à l'aide de l'algorithme d'autoscaler horizontal des pods.
Vous pouvez également déployer un générateur de trafic pour valider le comportement de l'autoscaling basé sur le trafic.
À 30 RPS, le déploiement est réduit à cinq instances dupliquées de sorte que chaque instance dupliquée reçoive idéalement 6 RPS de trafic, ce qui correspond à 60% d'utilisation par pod. Ce seuil est inférieur à l'objectif de 70% de l'utilisation. Les pods sont donc adaptés de manière appropriée. En fonction des fluctuations du trafic, le nombre d'instances dupliquées avec autoscaling peut également varier. Pour obtenir une description plus détaillée du calcul du nombre d'instances dupliquées, consultez la page Comportement de l'autoscaling.
Effectuer un autoscaling basé sur une métrique personnalisée ou externe
Pour créer des autoscalers horizontaux de pods pour les métriques personnalisées et externes, consultez la section Optimiser l'autoscaling des pods en fonction des métriques.
Procéder à un autoscaling basé sur plusieurs métriques
Cet exemple crée un autoscaler horizontal des pods qui réalise un autoscaling en fonction de l'utilisation du processeur et d'une métrique personnalisée nommée packets_per_second
.
Si vous avez suivi l'exemple précédent et que vous disposez toujours d'un autoscaler horizontal de pods nommé nginx
, supprimez-le avant de commencer cet exemple.
Vous aurez besoin de la version apiVersion: autoscaling/v2
. Pour plus d'informations sur les API disponibles, consultez la page Versions d'API pour les objets HorizontalPodAutoscaler
.
Enregistrez ce fichier manifeste YAML en tant que fichier nommé nginx-multiple.yaml
:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- type: Resource
resource:
name: memory
target:
type: AverageValue
averageValue: 100Mi
# Uncomment these lines if you create the custom packets_per_second metric and
# configure your app to export the metric.
# - type: Pods
# pods:
# metric:
# name: packets_per_second
# target:
# type: AverageValue
# averageValue: 100
Appliquez le manifeste YAML :
kubectl apply -f nginx-multiple.yaml
Une fois créé, l'autoscaler horizontal des pods surveille le déploiement nginx
pour l'utilisation moyenne du processeur, l'utilisation moyenne de la mémoire et la métrique personnalisée packets_per_second
si vous avez annulé la mise en commentaire. L'autoscaler horizontal des pods effectue un autoscaling du déploiement en fonction de la métrique dont la valeur crée l'événement d'autoscaling le plus important.
Afficher les détails d'un autoscaler horizontal de pods
Pour afficher la configuration et les statistiques d'un autoscaler horizontal de pods, exécutez la commande suivante :
kubectl describe hpa HPA_NAME
Remplacez HPA_NAME
par le nom de votre objet HorizontalPodAutoscaler
.
Si l'autoscaler horizontal de pods utilise apiVersion: autoscaling/v2
et qu'il est basé sur plusieurs métriques, la commande kubectl describe hpa
n'affiche que la métrique d'utilisation du processeur. Pour afficher toutes les métriques, exécutez la commande suivante :
kubectl describe hpa.v2.autoscaling HPA_NAME
Remplacez HPA_NAME
par le nom de votre objet HorizontalPodAutoscaler
.
L'état actuel de chaque autoscaler horizontal de pods est indiqué dans le champ Conditions
et les événements d'autoscaling sont répertoriés dans le champ Events
.
Le résultat ressemble à ce qui suit :
Name: nginx
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp: Tue, 05 May 2020 20:07:11 +0000
Reference: Deployment/nginx
Metrics: ( current / target )
resource memory on pods: 2220032 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale recommended size matches current size
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
Supprimer un autoscaler horizontal de pods
Vous pouvez supprimer un autoscaler horizontal de pods à l'aide de la console Google Cloud ou de la commande kubectl delete
.
Console
Pour supprimer l'autoscaler horizontal de pods nginx
, procédez comme suit :
Accédez à la page Charges de travail dans la console Google Cloud.
Cliquez sur le nom du déploiement
nginx
.Cliquez sur list Actions > Évoluer automatiquement.
Cliquez sur Supprimer.
kubectl delete
Pour supprimer l'autoscaler horizontal de pods nginx
, utilisez la commande suivante :
kubectl delete hpa nginx
Lorsque vous supprimez un autoscaler horizontal de pods, le déploiement (ou un autre objet de déploiement) n'est pas mis à l'échelle et ne revient pas au nombre d'instances dupliquées du manifeste de déploiement d'origine. Pour rétablir manuellement le scaling du déploiement sur trois pods, vous pouvez utiliser la commande kubectl scale
:
kubectl scale deployment nginx --replicas=3
Nettoyer
Supprimez l'autoscaler horizontal de pods, si ce n'est pas déjà fait :
kubectl delete hpa nginx
Supprimez le déploiement
nginx
:kubectl delete deployment nginx
Vous pouvez également supprimer le cluster.
Dépannage
Lorsque vous configurez un autoscaler horizontal de pods, des messages d'avertissement semblables aux suivants peuvent s'afficher :
unable to fetch pod metrics for pod
Il est normal que ce message s'affiche au démarrage du serveur de métriques. Toutefois, si vous continuez à voir des avertissements et que vous remarquez que les pods ne sont pas mis à l'échelle pour votre charge de travail, assurez-vous d'avoir spécifié des requêtes de ressources pour chaque conteneur de votre charge de travail. Pour utiliser des pourcentages cibles d'utilisation d'une ressource avec l'autoscaling horizontal des pods, vous devez configurer les requêtes pour cette ressource pour chaque conteneur et dans chaque pod de la charge de travail. Sinon, l'autoscaler de pods horizontaux ne peut pas effectuer les calculs nécessaires et n'effectue aucune action en lien avec cette métrique.
Étape suivante
- En savoir plus sur l'autoscaling horizontal des pods.
- En savoir plus sur l'autoscaling vertical des pods.
- En savoir plus sur l'autoscaling des pods multidimensionnels.
- Découvrez comment procéder à un autoscaling des déploiements avec des métriques personnalisées.
- Découvrez comment attribuer des ressources de processeur aux conteneurs et aux pods.
- Découvrez comment attribuer des ressources mémoire aux conteneurs et aux pods.