Comment configurer l'autoscaler de pod horizontal Kubernetes à l'aide de Metrics Server

De Get Docs
Aller à :navigation, rechercher

Introduction

Kubernetes vise à fournir à la fois résilience et évolutivité. Il y parvient en déployant plusieurs pods avec différentes allocations de ressources, pour assurer la redondance de vos applications. Bien que vous puissiez développer et réduire manuellement vos propres déploiements en fonction de vos besoins, Kubernetes fournit une assistance de premier ordre pour la mise à l'échelle à la demande, à l'aide d'une fonctionnalité appelée Horizontal Pod Autoscaling. Il s'agit d'un système en boucle fermée qui augmente ou réduit automatiquement les ressources (pods d'application) en fonction de vos besoins actuels. Vous créez un HorizontalPodAutoscaler (ou HPA) pour chaque déploiement d'application nécessitant une mise à l'échelle automatique, et laissez-le s'occuper automatiquement du rest.

À un haut niveau, HPA fait ce qui suit :

  1. Il garde un œil sur les métriques des demandes de ressources provenant des charges de travail de vos applications (pods), en interrogeant le serveur de métriques.
  2. Il compare la valeur de seuil cible que vous avez définie dans la définition HPA avec l'utilisation moyenne des ressources observée pour vos charges de travail d'application (processeur et mémoire).
  3. Si le seuil cible est atteint, HPA augmentera le déploiement de votre application pour répondre à des demandes plus élevées. Sinon, s'il est inférieur au seuil, le déploiement sera réduit. Pour voir quelle logique HPA utilise pour faire évoluer le déploiement de votre application, vous pouvez consulter la page détails de l'algorithme de la documentation officielle.

Sous le capot, un HorizontalPodAutoscaler est un CRD (Custom Resource Definition) qui pilote une boucle de contrôle Kubernetes mise en œuvre via un contrôleur dédié au sein du Control Plane de votre grappe. Vous créez un HorizontalPodAutoscaler Manifeste YAML ciblant votre application Deployment, puis utilisez kubectl pour appliquer la ressource HPA dans votre cluster.

Pour fonctionner, HPA a besoin d'un serveur de métriques disponible dans votre cluster pour récupérer les métriques requises, telles que l'utilisation du processeur et de la mémoire. Une option simple est le Kubernetes Metrics Server. Le serveur de métriques fonctionne en collectant des métriques de ressources à partir de Kubelets et en les exposant via le Kubernetes API Server à l'autoscaler de pod horizontal. L'API Metrics est également accessible via kubectl top si besoin.

Dans ce didacticiel, vous allez :

  • Déployez Metrics Server sur votre cluster Kubernetes.
  • Découvrez comment créer des autoscalers de pod horizontaux pour vos applications.
  • Testez chaque configuration HPA à l'aide de deux scénarios : charge d'application constante et variable.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de :

Étape 1 - Installer le serveur de métriques via Helm

Vous commencerez par ajouter le metrics-server référentiel à votre helm listes de paquets. Vous pouvez utiliser helm repo add:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server

Ensuite, utilisez helm repo update pour actualiser les packages disponibles :

helm repo update metrics-server
OutputHang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "metrics-server" chart repository
Update Complete. ⎈Happy Helming!⎈

Maintenant que vous avez ajouté le référentiel à helm, vous pourrez ajouter metrics-server à vos déploiements Kubernetes. Vous pouvez écrire votre propre configuration de déploiement ici, mais ce didacticiel suivra le Kubernetes Starter Kit de DigitalOcean, qui comprend une configuration pour metrics-server.

Pour ce faire, clonez le dépôt Git du kit de démarrage Kubernetes :

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git

La metrics-server la configuration se trouve dans Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v3.8.2.yaml. Vous pouvez l'afficher ou le modifier en utilisant nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v3.8.2.yaml

Il contient quelques paramètres de stock. Notez que replicas est une valeur fixe, 2.

metrics-server-values-v3.8.2.yaml

## Starter Kit metrics-server configuration
## Ref: https://github.com/kubernetes-sigs/metrics-server/blob/metrics-server-helm-chart-3.8.2/charts/metrics-server
##

# Number of metrics-server replicas to run
replicas: 2

apiService:
  # Specifies if the v1beta1.metrics.k8s.io API service should be created.
  #
  # You typically want this enabled! If you disable API service creation you have to
  # manage it outside of this chart for e.g horizontal pod autoscaling to
  # work with this release.
  create: true

hostNetwork:
  # Specifies if metrics-server should be started in hostNetwork mode.
  #
  # You would require this enabled if you use alternate overlay networking for pods and
  # API server unable to communicate with metrics-server. As an example, this is required
  # if you use Weave network on EKS
  enabled: false

Reportez-vous à la page graphique du serveur de métriques pour une explication des paramètres disponibles pour metrics-server.

Remarque : Vous devez être assez prudent lorsque vous associez des déploiements Kubernetes à votre version en cours d'exécution de Kubernetes, et la helm les graphiques eux-mêmes sont également versionnés pour appliquer cela. Le courant en amont helm graphique pour metrics-server est 3.8.2, qui déploie la version 0.6.1 de metrics-server lui-même. Dans la Metrics Server Compatibility Matrix, vous pouvez voir cette version 0.6.x prend en charge Kubernetes 1.19+.


Après avoir examiné le fichier et apporté des modifications, vous pouvez procéder au déploiement metrics-server, en fournissant ce fichier avec le helm install commande:

HELM_CHART_VERSION="3.8.2"

helm install metrics-server metrics-server/metrics-server --version "$HELM_CHART_VERSION" \
  --namespace metrics-server \
  --create-namespace \
  -f "Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v${HELM_CHART_VERSION}.yaml"

Cela va déployer metrics-server à votre cluster Kubernetes configuré :

OutputNAME: metrics-server
LAST DEPLOYED: Wed May 25 11:54:43 2022
NAMESPACE: metrics-server
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
***********************************************************************
* Metrics Server                                                      *
***********************************************************************
  Chart version: 3.8.2
  App version:   0.6.1
  Image tag:     k8s.gcr.io/metrics-server/metrics-server:v0.6.1
***********************************************************************

Après le déploiement, vous pouvez utiliser helm ls pour vérifier que metrics-server a été ajouté à votre déploiement :

helm ls -n metrics-server
OutputNAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
metrics-server  metrics-server  1               2022-02-24 14:58:23.785875 +0200 EET    deployed        metrics-server-3.8.2    0.6.1

Ensuite, vous pouvez vérifier l'état de toutes les ressources Kubernetes déployées sur le metrics-server espace de noms :

kubectl get all -n metrics-server

En fonction de la configuration avec laquelle vous avez déployé, à la fois le deployment.apps et replicaset.apps les valeurs doivent compter 2 instances disponibles.

OutputNAME                                  READY   STATUS    RESTARTS   AGE
pod/metrics-server-694d47d564-9sp5h   1/1     Running   0          8m54s
pod/metrics-server-694d47d564-cc4m2   1/1     Running   0          8m54s

NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/metrics-server   ClusterIP   10.245.92.63   <none>        443/TCP   8m54s

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/metrics-server   2/2     2            2           8m55s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/metrics-server-694d47d564   2         2         2       8m55s

Vous avez maintenant déployé metrics-server dans votre cluster Kubernetes. Dans l'étape suivante, vous passerez en revue certains des paramètres d'une définition de ressource personnalisée HorizontalPodAutoscaler.

Étape 2 - Apprendre à connaître les HPA

Jusqu'à présent, vos configurations utilisaient une valeur fixe pour le nombre de ReplicaSet instances à déployer. Dans cette étape, vous apprendrez à définir un CRD HorizontalPodAutoscaler afin que cette valeur puisse augmenter ou diminuer de manière dynamique.

Un typique HorizontalPodAutoscaler CRD ressemble à ceci :

crd.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Les paramètres utilisés dans cette configuration sont les suivants :

  • spec.scaleTargetRef: Une référence nommée à la ressource mise à l'échelle.
  • spec.minReplicas: limite inférieure du nombre d'instances dupliquées jusqu'à laquelle l'autoscaler peut réduire.
  • spec.maxReplicas: La limite supérieure.
  • spec.metrics.type: la métrique à utiliser pour calculer le nombre de répliques souhaité. Cet exemple utilise le Resource type, qui indique au HPA de mettre à l'échelle le déploiement en fonction de la moyenne CPU (ou mémoire). averageUtilization est fixé à une valeur seuil de 50.

Vous avez deux options pour créer un HPA pour le déploiement de votre application :

  1. Utilisez le kubectl autoscale commande sur un déploiement existant.
  2. Créez un manifeste HPA YAML, puis utilisez kubectl pour appliquer les modifications à votre cluster.

Vous allez d'abord essayer l'option n ° 1, en utilisant une autre configuration du kit de démarrage DigitalOcean Kubernetes. Il contient un déploiement appelé myapp-test.yaml qui démontrera HPA en action en créant une charge CPU arbitraire.

Vous pouvez consulter ce fichier en utilisant nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/myapp-test.yaml

myapp-test.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-test
spec:
  selector:
    matchLabels:
      run: myapp-test
  replicas: 1
  template:
    metadata:
      labels:
        run: myapp-test
    spec:
      containers:
        - name: busybox
          image: busybox
          resources:
            limits:
              cpu: 50m
            requests:
              cpu: 20m
          command: ["sh", "-c"]
          args:
            - while [ 1 ]; do
              echo "Test";
              sleep 0.01;
              done

Notez les dernières lignes de ce fichier. Ils contiennent une syntaxe shell pour imprimer à plusieurs reprises "Test" cent fois par seconde, pour simuler la charge. Une fois que vous avez terminé d'examiner le fichier, vous pouvez le déployer dans votre cluster à l'aide de kubectl:

kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/myapp-test.yaml

Ensuite, utilisez kubectl autoscale créer un HorizontalPodAutoscaler ciblant le myapp-test déploiement:

kubectl autoscale deployment myapp-test --cpu-percent=50 --min=1 --max=3

Notez les arguments passés à cette commande - cela signifie que votre déploiement sera mis à l'échelle entre 1 et 3 répliques chaque fois que l'utilisation du processeur atteint 50 pour cent.

Vous pouvez vérifier si la ressource HPA a été créée en exécutant kubectl get hpa:

kubectl get hpa

La TARGETS colonne de la sortie affichera éventuellement un chiffre de current usage%/target usage%.

OutputNAME         REFERENCE                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
myapp-test   Deployment/myapp-test      240%/50%   1         3         3          52s

Remarque : Le TARGETS la valeur de la colonne s'affichera <unknown>/50% pendant un certain temps (environ 15 secondes). Ceci est normal, car HPA doit collecter des valeurs moyennes au fil du temps et il n'aura pas suffisamment de données avant le premier intervalle de 15 secondes. Par défaut, HPA vérifie les métriques toutes les 15 secondes.


Vous pouvez également observer les événements consignés générés par un HPA en utilisant kubectl describe:

kubectl describe hpa myapp-test
OutputName:                                                  myapp-test
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           <none>
CreationTimestamp:                                     Mon, 28 May 2022 10:10:50 -0800
Reference:                                             Deployment/myapp-test
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  240% (48m) / 50%
Min replicas:                                          1
Max replicas:                                          3
Deployment pods:                                       3 current / 3 desired
...
Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  17s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
  Normal  SuccessfulRescale  37s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target

C'est le kubectl autoscale méthode. Dans un scénario de production, vous devez généralement utiliser à la place un manifeste YAML dédié pour définir chaque HPA. De cette façon, vous pouvez suivre les modifications en faisant valider le manifeste dans un référentiel Git et le modifier si nécessaire.

Vous en découvrirez un exemple dans la dernière étape de ce didacticiel. Avant de poursuivre, supprimez le myapp-test déploiement et ressource HPA correspondante :

kubectl delete hpa myapp-test
kubectl delete deployment myapp-test

Étape 3 - Mise à l'échelle automatique des applications via Metrics Server

Dans cette dernière étape, vous expérimenterez deux manières différentes de générer la charge et la mise à l'échelle du serveur via un manifeste YAML :

  1. Un déploiement d'application qui crée une charge constante en effectuant des calculs gourmands en CPU.
  2. Un script shell simule cette charge externe en effectuant des appels HTTP successifs rapides pour une application Web.

Test de charge constante

Dans ce scénario, vous allez créer un exemple d'application implémentée à l'aide de Python, qui effectue des calculs gourmands en CPU. Semblable au script shell de la dernière étape, ce code Python est inclus dans l'un des exemples de manifestes du kit de démarrage. Vous pouvez ouvrir le constant-load-deployment-test.yaml utilisant nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-deployment-test.yaml

constant-load-deployment-test.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: python-test-code-configmap
data:
  entrypoint.sh: |-
    #!/usr/bin/env python

    import math

    while True:
      x = 0.0001
      for i in range(1000000):
        x = x + math.sqrt(x)
        print(x)
      print("OK!")

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: constant-load-deployment-test
spec:
  selector:
    matchLabels:
      run: python-constant-load-test
  replicas: 1
  template:
    metadata:
      labels:
        run: python-constant-load-test
    spec:
      containers:
        - name: python-runtime
          image: python:alpine3.15
          resources:
            limits:
              cpu: 50m
            requests:
              cpu: 20m
          command:
            - /bin/entrypoint.sh
          volumeMounts:
            - name: python-test-code-volume
              mountPath: /bin/entrypoint.sh
              readOnly: true
              subPath: entrypoint.sh
      volumes:
        - name: python-test-code-volume
          configMap:
            defaultMode: 0700
            name: python-test-code-configmap

Le code Python, qui génère à plusieurs reprises des racines carrées arbitraires, est mis en évidence ci-dessus. Le déploiement récupérera une image docker hébergeant le runtime python requis, puis attachera un ConfigMap à la candidature Pod hébergeant l'exemple de script Python présenté précédemment.

Commencez par créer un espace de noms séparé pour ce déploiement (pour une meilleure observation), puis déployez-le via kubectl:

kubectl create ns hpa-constant-load

kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-deployment-test.yaml -n hpa-constant-load
Outputconfigmap/python-test-code-configmap created
deployment.apps/constant-load-deployment-test created

Remarque : L'exemple de déploiement configure également les limites de demande de ressources pour les exemples de pods d'application. Ceci est important car la logique HPA repose sur la définition de limites de demandes de ressources pour vos pods. En général, il est conseillé de définir des limites de demandes de ressources pour tous vos pods d'application, afin d'éviter les goulots d'étranglement imprévisibles.


Vérifiez que le déploiement a bien été créé et qu'il est opérationnel :

kubectl get deployments -n hpa-constant-load
OutputNAME                            READY   UP-TO-DATE   AVAILABLE   AGE
constant-load-deployment-test   1/1     1            1           8s

Ensuite, vous devrez déployer un autre HPA sur ce cluster. Il existe un exemple correspondant à ce scénario dans constant-load-hpa-test.yaml, que vous pouvez ouvrir avec nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-hpa-test.yaml -n hpa-constant-load

constant-load-hpa-test.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: constant-load-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: constant-load-deployment-test
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Déployez-le via kubectl:

kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-hpa-test.yaml -n hpa-constant-load

Cela va créer un HPA ressource, ciblant l'exemple de déploiement Python. Vous pouvez vérifier le constant-load-test État HPA via kubectl get hpa:

kubectl get hpa constant-load-test -n hpa-constant-load

Noter la REFERENCE ciblage par colonne constant-load-deployment-test, aussi bien que TARGETS colonne affichant les demandes de ressources CPU actuelles par rapport à la valeur de seuil, comme dans le dernier exemple.

OutputNAME                 REFERENCE                                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
constant-load-test   Deployment/constant-load-deployment-test   255%/50%   1         3         3          49s

Vous pouvez également remarquer que le REPLICAS la valeur de la colonne est passée de 1 à 3 pour l'exemple de déploiement d'application, comme indiqué dans la spécification HPA CRD. Cela s'est produit très rapidement car l'application utilisée dans cet exemple génère très rapidement une charge CPU. Comme dans l'exemple précédent, vous pouvez également inspecter les événements HPA consignés à l'aide de kubectl describe hpa -n hpa-constant-load.

Test de charge externe

Un scénario plus intéressant et réaliste consiste à observer où la charge externe est créée. Pour ce dernier exemple, vous allez utiliser un espace de noms et un ensemble de manifestes différents pour éviter de réutiliser les données du test précédent.

Cet exemple utilisera le serveur d'exemple quote of the moment. Chaque fois qu'une requête HTTP est adressée à ce serveur, il envoie une citation différente en réponse. Vous créerez une charge sur votre cluster en envoyant des requêtes HTTP toutes les 1 ms. Ce déploiement est inclus dans quote_deployment.yaml. Examinez ce fichier à l'aide de nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote_deployment.yaml

quote_deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: quote
spec:
  replicas: 1
  selector:
    matchLabels:
      app: quote
  template:
    metadata:
      labels:
        app: quote
    spec:
      containers:
        - name: quote
          image: docker.io/datawire/quote:0.4.1
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi

---
apiVersion: v1
kind: Service
metadata:
  name: quote
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: quote

Notez que le script de requête HTTP réel n'est pas contenu dans le manifeste cette fois-ci - ce manifeste fournit uniquement une application pour exécuter les requêtes pour le moment. Lorsque vous avez terminé d'examiner le fichier, créez l'espace de noms quote et le déploiement à l'aide de kubectl:

kubectl create ns hpa-external-load

kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote_deployment.yaml -n hpa-external-load

Vérifiez que le quote le déploiement de l'application et les services sont opérationnels :

kubectl get all -n hpa-external-load
OutputNAME                             READY   STATUS    RESTARTS   AGE
pod/quote-dffd65947-s56c9        1/1     Running   0          3m5s

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/quote   ClusterIP   10.245.170.194   <none>        80/TCP    3m5s

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/quote       1/1     1            1           3m5s

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/quote-6c8f564ff        1         1         1       3m5s

Ensuite, vous allez créer le HPA pour le quote déploiement. Ceci est configuré dans quote-deployment-hpa-test.yaml. Consultez le dossier dans nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote-deployment-hpa-test.yaml

devis-deploiement-hpa-test.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: external-load-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: quote
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 60
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 20

Notez que dans ce cas, une valeur de seuil différente est définie pour la métrique des ressources d'utilisation du processeur (20%). Il existe également un comportement de mise à l'échelle différent. Cette configuration modifie la scaleDown.stabilizationWindowSeconds comportement, et le définit sur une valeur inférieure de 60 secondes. Ce n'est pas toujours nécessaire dans la pratique, mais dans ce cas, vous souhaiterez peut-être accélérer les choses pour voir plus rapidement comment l'autoscaler effectue l'action de réduction. Par défaut, le HorizontalPodAutoscaler a une période de refroidissement de 5 minutes. Cela est suffisant dans la plupart des cas et devrait éviter les fluctuations lors de la mise à l'échelle des répliques.

Lorsque vous êtes prêt, déployez-le en utilisant kubectl:

kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote-deployment-hpa-test.yaml -n hpa-external-load

Maintenant, vérifiez si la ressource HPA est en place et active :

kubectl get hpa external-load-test -n hpa-external-load
OutputNAME                 REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
external-load-test   Deployment/quote   1%/20%    1         3         1          108s

Enfin, vous exécuterez les requêtes HTTP réelles, en utilisant le script shell quote_service_load_test.sh. La raison pour laquelle ce script shell n'était pas intégré au manifeste auparavant est que vous pouvez l'observer en cours d'exécution dans votre cluster tout en vous connectant directement à votre terminal. Passez en revue le script à l'aide de nano ou votre éditeur de texte préféré :

nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/scripts/quote_service_load_test.sh

quote_service_load_test.sh

#!/usr/bin/env sh

echo
echo "[INFO] Starting load testing in 10s..."
sleep 10
echo "[INFO] Working (press Ctrl+C to stop)..."
kubectl run -i --tty load-generator \
    --rm \
    --image=busybox \
    --restart=Never \
    -n hpa-external-load \
    -- /bin/sh -c "while sleep 0.001; do wget -q -O- http://quote; done" > /dev/null 2>&1
echo "[INFO] Load testing finished."

Pour cette démonstration, ouvrez deux fenêtres de terminal distinctes. Dans le premier, lancez le quote_service_load_test.sh script shell :

Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/scripts/quote_service_load_test.sh

Ensuite, dans la deuxième fenêtre, lancez un kubectl commande watch à l'aide de la -w flag sur la ressource HPA :

kubectl get hpa -n hpa-external-load -w

Vous devriez voir la charge cochée vers le haut et mise à l'échelle automatiquement :

OutputNAME                 REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
external-load-test   Deployment/quote   1%/20%    1         3         1          2m49s
external-load-test   Deployment/quote   29%/20%   1         3         1          3m1s
external-load-test   Deployment/quote   67%/20%   1         3         2          3m16s

Vous pouvez observer comment l'autoscaler se déclenche lorsque la charge augmente et incrémente le quote réplica de déploiement de serveur défini sur une valeur supérieure. Dès que le script du générateur de charge est arrêté, il y a une période de refroidissement et après environ 1 minute, le jeu de réplicas est abaissé à la valeur initiale de 1. Vous pouvez appuyer sur Ctrl+C pour terminer le script en cours d'exécution après être revenu à la première fenêtre de terminal.

Conclusion

Dans ce didacticiel, vous avez déployé et observé le comportement de la mise à l'échelle horizontale des pods (HPA) à l'aide de Kubernetes Metrics Server dans plusieurs scénarios différents. HPA est un composant essentiel de Kubernetes qui aide votre infrastructure à gérer plus de trafic en fonction des besoins.

Metrics Server présente une limitation importante dans la mesure où il ne peut fournir aucune métrique au-delà de l'utilisation du processeur ou de la mémoire. Vous pouvez également consulter la documentation de Metrics Server pour comprendre comment travailler dans ses cas d'utilisation. Si vous devez effectuer une mise à l'échelle à l'aide d'autres mesures (telles que l'utilisation du disque ou la charge du réseau), vous pouvez utiliser Prometheus via un adaptateur spécial, nommé prometheus-adapter.