Exercice – Déployer un objet de mise à l’échelle dans votre cluster Azure Kubernetes Service
Dans cet exercice, vous allez déployer une définition de ressource personnalisée d’objet de mise à l’échelle dans votre cluster AKS. L’objet scaler contient le déclencheur qui connecte votre application déployée à KEDA. Une fois déployé sur AKS, KEDA supervise la liste Redis et effectue un scale-up si la longueur de la liste dépasse le seuil défini ou un scale-down si la longueur de la liste passe en dessous du seuil.
Vue d’ensemble du manifeste ScaledObject
scaleTargetRef
: Cette section décrit la charge de travail observée par KEDA.scaleTargetRef: apiVersion: apps/v1 # Optional. Default: apps/v1 kind: deployment # Optional. Default: Deployment name: contoso-microservice # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: contoso-microservice # Optional. Default: .spec.template.spec.containers[0]
minReplicaCount
etmaxReplicaCount
: Ces attributs déterminent la plage de réplicas utilisée par KEDA pour la mise à l’échelle. Dans ce cas, vous indiquez à KEDA de mettre à l’échelle entre un minimum de zéro réplica et un maximum de vingt réplicas.minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 20 # Optional. Default: 100
Remarque
minReplicaCount: 0
fait passer le nombre de réplicas par défaut du déploiement de un à zéro. Cela se produit si le service est inactif et ne traite aucun événement. Dans cet exercice, s’il n’y a aucun élément dans la liste Redis et que le service reste inactif, KEDA est mis à l’échelle à zéro.advanced
: Cette section est liée à la personnalisation avancée de KEDA.restoreToOriginalReplicaCount
indique à KEDA de retourner le nombre de réplicas à la valeur d’origine après les événements de scale-up. Dans ce cas, vous le définissez surfalse
, ce qui entraîne un scale-down de la valeurminReplicaCount
à zéro.restoreToOriginalReplicaCount: false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15
triggers
: Cette section utilisescalers
pour détecter si l’objet doit être activé ou désactivé et s’il doit alimenter des métriques personnalisées pour des sources d’événement spécifiques. La métriquelistLength
indique à KEDA d’effectuer un scale-up quand il y a dix éléments dans la liste.triggers: - type: redis metadata: # address: # Format must be host:port passwordFromEnv: REDIS_KEY listName: keda # Required listLength: "10" # Required enableTLS: "false" # optional databaseIndex: "0" # optional hostFromEnv: REDIS_HOST portFromEnv: REDIS_PORT
Pour plus d’informations, consultez Scalers KEDA.
Créer le manifeste ScaledObject
Dans Cloud Shell, créez un fichier manifeste pour le déploiement Kubernetes appelé
scaled-object.yaml
en utilisant la commandetouch
:touch scaled-object.yaml
Ouvrez l’éditeur intégré dans Cloud Shell en entrant
code .
Ouvrez le fichier
scaled-object.yaml
et ajoutez la section de code YAML suivante :apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaled-contoso spec: scaleTargetRef: apiVersion: apps/v1 # Optional. Default: apps/v1 kind: deployment # Optional. Default: Deployment name: contoso-microservice # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: contoso-microservice # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 120 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 20 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: - type: redis metadata: # address: # Format must be host:port passwordFromEnv: REDIS_KEY listName: keda # Required listLength: "10" # Required enableTLS: "false" # optional databaseIndex: "0" # optional hostFromEnv: REDIS_HOST portFromEnv: REDIS_PORT
Enregistrez le fichier manifeste (Ctrl + S) et fermez l’éditeur (Ctrl + Q).
Appliquer le manifeste
Déployez le manifeste sur votre cluster en utilisant la commande
kubectl apply
:kubectl apply -f ./scaled-object.yaml
Vous devez obtenir un résultat semblable à l’exemple de sortie qui suit :
scaledobject.keda.sh/scaled-contoso created
Vérifiez le nombre de pods en cours d’exécution en tirant parti de la commande
kubectl get pods
:kubectl get pods
La sortie doit être similaire à l’exemple de sortie suivant, avec un pod en cours d’exécution :
NAME READY STATUS RESTARTS AGE contoso-microservice-794d98b5-4flvg 1/1 Running 0 2m1s
Exécutez régulièrement la commande
kubectl get pods
pour vérifier que le Deployment met à l’échelle le nombre de pods en fonction du backlog de travail.Remarque
Si vous avez installé l’utilitaire watch Linux, vous pouvez utiliser la commande
watch kubectl get pods
pour voir le traitement des éléments de liste Redis par la mise à l’échelle des pods. Sinon, vous pouvez utiliser la commandekubectl get pods -w
.Vous devez obtenir un résultat semblable à l’exemple de sortie qui suit :
NAME READY STATUS RESTARTS AGE contoso-microservice-794d98b5-4flvg 1/1 Running 0 3m contoso-microservice-794d98b5-4jpxp 1/1 Running 0 3m contoso-microservice-794d98b5-4lw7b 1/1 Running 0 2m15s contoso-microservice-794d98b5-5fqj5 1/1 Running 0 3m contoso-microservice-794d98b5-5kdbw 1/1 Running 0 2m15s
Une fois tous les éléments traités et après l’expiration de cooldownPeriod
, le nombre de pods affiché est égal à zéro. Cela est dû au fait que KEDA a supprimé tous les réplicas en cours d’exécution et qu’il ne reste aucun élément à traiter.