Mettre à l'échelle et équilibrer la charge des applications

KubernetesBeginner
Pratiquer maintenant

Introduction

Dans ce laboratoire, vous allez démarrer un cluster Kubernetes local en utilisant Minikube, déployer une application NGINX exemple, puis la mettre à l'échelle pour répondre à des demandes variables. Vous allez observer l'équilibrage de charge entre plusieurs pods, surveiller les événements du cluster et obtenir une brève introduction au Horizontal Pod Autoscaler (HPA) pour l'automatisation future de la mise à l'échelle. Ce laboratoire vise à fournir une expérience pratique complète pour comprendre la mise à l'échelle et l'équilibrage de charge dans Kubernetes.

Démarrer le cluster Kubernetes

Dans cette étape, vous allez apprendre à démarrer et vérifier un cluster Kubernetes local en utilisant Minikube. C'est une étape essentielle pour déployer et gérer des applications conteneurisées dans un environnement Kubernetes.

Tout d'abord, démarrez le cluster Minikube :

minikube start

Exemple de sortie :

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Vérifiez l'état du cluster en utilisant plusieurs commandes :

minikube status
kubectl get nodes

Exemple de sortie pour minikube status :

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Exemple de sortie pour kubectl get nodes :

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Ces commandes confirment que :

  1. Minikube est en cours d'exécution avec succès.
  2. Un cluster Kubernetes local a été créé.
  3. Le cluster est prêt à être utilisé.
  4. Vous disposez d'un cluster mono - noeud avec des capacités de plan de contrôle.

Déployer une application exemple

Dans cette étape, vous allez apprendre à déployer une application web simple en utilisant un déploiement (Deployment) Kubernetes avec une seule réplique. Nous allons créer un manifeste YAML pour un serveur web NGINX et l'appliquer au cluster Minikube. Comprendre comment déployer une application est fondamental pour utiliser Kubernetes.

Tout d'abord, créez un répertoire pour vos manifestes Kubernetes :

mkdir -p ~/project/k8s-manifests
cd ~/project/k8s-manifests

Créez un nouveau fichier YAML pour le déploiement :

nano nginx-deployment.yaml

Ajoutez la configuration de déploiement suivante :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Enregistrez le fichier (Ctrl+X, puis Y, puis Entrée).

Explication de la configuration YAML :

  • apiVersion: apps/v1 : Spécifie la version de l'API pour les déploiements (Deployments).
  • kind: Deployment : Indique qu'il s'agit d'un objet de déploiement, utilisé pour gérer les applications répliquées.
  • metadata : Contient les métadonnées du déploiement.
    • name: nginx-deployment : Le nom du déploiement.
    • labels: app: nginx : Une étiquette utilisée pour identifier ce déploiement.
  • spec : Contient la spécification du déploiement.
    • replicas: 1 : Le nombre souhaité d'instances de pods (répliques). Dans ce déploiement initial, nous n'avons qu'une seule réplique.
    • selector : Définit comment le déploiement sélectionnera les pods à gérer.
      • matchLabels: app: nginx : Les pods avec l'étiquette app: nginx seront gérés par ce déploiement.
    • template : Le modèle de pod. Il spécifie la configuration des pods créés par le déploiement.
      • metadata.labels: app: nginx : Étiquette qui s'applique aux pods gérés par ce déploiement.
      • spec.containers : Définit les conteneurs dans le pod.
        • name: nginx : Le nom du conteneur.
        • image: nginx:latest : L'image Docker pour le conteneur (en utilisant la dernière image NGINX).
        • ports: containerPort: 80 : Expose le port 80 dans le conteneur.

Appliquez le déploiement au cluster Kubernetes :

kubectl apply -f nginx-deployment.yaml

Exemple de sortie :

deployment.apps/nginx-deployment created

Vérifiez l'état du déploiement :

kubectl get deployments
kubectl get pods

Exemple de sortie pour kubectl get deployments :

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           30s

Exemple de sortie pour kubectl get pods :

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          30s

Points clés de ce déploiement :

  1. Nous avons créé un déploiement avec une seule réplique.
  2. Le déploiement utilise la dernière image NGINX.
  3. Le conteneur expose le port 80.
  4. Le déploiement a une étiquette app: nginx pour l'identification.

Inspectez les détails du déploiement :

kubectl describe deployment nginx-deployment

La sortie de l'exemple montrera la configuration du déploiement, les événements et l'état actuel.

Mettre à l'échelle les déploiements pour gérer une charge accrue

Dans cette étape, vous allez apprendre à mettre à l'échelle votre application pour gérer plus de trafic. Dans le monde réel, à mesure que votre application devient plus populaire, une seule réplique peut ne pas être suffisante pour gérer la charge. Pour résoudre ce problème, Kubernetes vous permet de facilement augmenter la taille de votre application en augmentant le nombre d'instances de pods (répliques).

Avant de procéder à la mise à l'échelle, discutons brièvement des raisons pour lesquelles plusieurs répliques sont nécessaires. Une seule réplique d'une application ne peut gérer qu'un certain nombre de requêtes simultanées. Si le trafic dépasse cette capacité, l'application peut devenir lente ou non réactive. En ayant plusieurs répliques, la charge peut être répartie entre différentes instances de pods, garantissant que l'application reste réactive et disponible. Ce concept est essentiel pour créer des applications évolutives.

Vous allez maintenant apprendre à mettre à l'échelle votre déploiement Kubernetes en modifiant le champ replicas dans le manifeste YAML, ainsi qu'en utilisant la commande kubectl scale.

Ouvrez le manifeste de déploiement créé précédemment :

nano ~/project/k8s-manifests/nginx-deployment.yaml

Modifiez le champ replicas de 1 à 3 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 ## Changed from 1 to 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Enregistrez le fichier (Ctrl+X, puis Y, puis Entrée).

Appliquez le déploiement mis à jour :

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

Exemple de sortie :

deployment.apps/nginx-deployment configured

Vérifiez le déploiement mis à l'échelle :

kubectl get deployments
kubectl get pods

Exemple de sortie pour kubectl get deployments :

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           5m

Exemple de sortie pour kubectl get pods :

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          5m
nginx-deployment-xxx-zzz            1/1     Running   0          30s
nginx-deployment-xxx-www            1/1     Running   0          30s

Méthode alternative de mise à l'échelle en utilisant kubectl scale :

kubectl scale deployment nginx-deployment --replicas=4

Exemple de sortie :

deployment.apps/nginx-deployment scaled

Vérifiez le nouveau nombre de répliques :

kubectl get deployments
kubectl get pods

Points clés concernant la mise à l'échelle :

  1. Modifiez replicas dans le fichier YAML ou utilisez la commande kubectl scale.
  2. Utilisez kubectl apply pour mettre à jour le déploiement lorsque vous apportez des modifications au fichier YAML.
  3. Kubernetes s'assure que le nombre souhaité de répliques est en cours d'exécution.
  4. Vous pouvez augmenter (augmenter le nombre de répliques) ou diminuer (diminuer le nombre de répliques) la taille de votre déploiement.

Vérifier l'équilibrage de charge en vérifiant les réponses de plusieurs pods

Dans cette étape, vous allez apprendre à vérifier l'équilibrage de charge dans Kubernetes en créant un Service et en vérifiant les réponses de plusieurs pods. L'équilibrage de charge est crucial pour répartir le trafic entre plusieurs répliques, afin de s'assurer qu'aucun pod n'est surchargé. Les Services Kubernetes gèrent automatiquement ce processus.

Créez un service pour exposer le déploiement :

nano ~/project/k8s-manifests/nginx-service.yaml

Ajoutez la configuration de service suivante :

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

Enregistrez le fichier (Ctrl+X, puis Y, puis Entrée).

Explication de la configuration YAML :

  • apiVersion: v1 : Spécifie la version de l'API pour les Services.
  • kind: Service : Indique qu'il s'agit d'un objet Service.
  • metadata : Contient les métadonnées du Service.
    • name: nginx-service : Le nom du Service.
  • spec : Contient la spécification du service.
    • selector : Définit vers quels pods ce service dirigera le trafic.
      • app: nginx : Sélectionne les pods avec l'étiquette app: nginx, qui correspondent aux pods créés à l'étape précédente.
    • type: ClusterIP : Crée un service interne avec une adresse IP de cluster, utilisé pour la communication interne. Ce type de service n'est accessible qu'au sein du cluster Kubernetes.
    • ports : Définit comment le service mappera le trafic.
      • port: 80 : Le port que le service expose.
      • targetPort: 80 : Le port sur lequel l'application à l'intérieur du conteneur écoute.

Appliquez le service :

kubectl apply -f ~/project/k8s-manifests/nginx-service.yaml

Exemple de sortie :

service/nginx-service created

Vérifiez le service :

kubectl get services

Exemple de sortie :

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP   30m
nginx-service   ClusterIP   10.96.xxx.xxx   <none>        80/TCP    30s

Maintenant, pour véritablement vérifier l'équilibrage de charge, vous allez créer un pod temporaire et envoyer plusieurs requêtes au service. Cela vous permettra de constater que les requêtes sont réparties entre différents pods NGINX.

Créez un pod temporaire pour tester l'équilibrage de charge :

kubectl run curl-test --image=curlimages/curl --rm -it -- sh

Cette commande effectue les actions suivantes :

  • kubectl run curl - test : Crée un nouveau pod nommé curl - test.
  • --image=curlimages/curl : Utilise une image Docker avec curl installé.
  • --rm : Supprime automatiquement le pod une fois qu'il a terminé.
  • -it : Alloue un pseudo - TTY et garde l'entrée standard ouverte.
  • -- sh : Démarre une session shell dans le pod.

À l'intérieur du pod temporaire, exécutez plusieurs requêtes :

for i in $(seq 1 10); do curl -s nginx-service | grep -q "Welcome to nginx!" && echo "Welcome to nginx - Request $i"; done

Cette boucle enverra 10 requêtes au nginx - service. Chaque requête devrait être acheminée vers l'un des pods NGINX disponibles. La sortie affichera Welcome to nginx - Request $i pour chaque requête réussie.

Exemple de sortie :

Welcome to nginx - Request 1
Welcome to nginx - Request 2
Welcome to nginx - Request 3
...

Quittez le pod temporaire :

exit

Points clés concernant l'équilibrage de charge :

  1. Les Services répartissent le trafic entre tous les pods correspondants.
  2. Chaque requête peut potentiellement atteindre un pod différent.
  3. Kubernetes utilise par défaut une approche en tourniquet (round - robin).
  4. Le type de service ClusterIP assure un équilibrage de charge interne.
  5. Le test avec curl montre que la charge est répartie entre plusieurs instances NGINX.

Ajuster dynamiquement l'échelle du déploiement pour répondre à la demande

Dans cette étape, vous allez pratiquer l'ajustement dynamique de l'échelle de votre déploiement Kubernetes pour répondre aux demandes changeantes de l'application en utilisant la commande kubectl scale. Cette étape met l'accent sur l'aspect pratique de l'ajustement du nombre de répliques en cours d'exécution sans modifier directement le fichier YAML, ce qui peut être utile pour des ajustements rapides en réponse à des pics de trafic.

Tout d'abord, vérifiez l'état actuel du déploiement :

kubectl get deployments

Exemple de sortie :

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           45m

Mettez à l'échelle le déploiement en utilisant la commande kubectl :

kubectl scale deployment nginx-deployment --replicas=5

Exemple de sortie :

deployment.apps/nginx-deployment scaled

Vérifiez le nouveau nombre de répliques :

kubectl get deployments
kubectl get pods

Exemple de sortie pour les déploiements :

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   5/5     5            5           46m

Exemple de sortie pour les pods :

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          1m
nginx-deployment-xxx-zzz            1/1     Running   0          1m
nginx-deployment-xxx-www            1/1     Running   0          1m
nginx-deployment-xxx-aaa            1/1     Running   0          1m
nginx-deployment-xxx-bbb            1/1     Running   0          1m

Maintenant, mettez à jour le fichier YAML du déploiement pour une mise à l'échelle persistante :

nano ~/project/k8s-manifests/nginx-deployment.yaml

Modifiez le champ replicas :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5 ## Updated from previous value
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Appliquez la configuration mise à jour :

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

Exemple de sortie :

deployment.apps/nginx-deployment configured

Simulez une mise à l'échelle à la baisse pour une demande réduite :

kubectl scale deployment nginx-deployment --replicas=2

Exemple de sortie :

deployment.apps/nginx-deployment scaled

Vérifiez le nombre réduit de répliques :

kubectl get deployments
kubectl get pods

Points clés concernant la mise à l'échelle :

  1. Utilisez kubectl scale pour une mise à l'échelle rapide et temporaire.
  2. Mettez à jour le fichier YAML pour une configuration persistante.
  3. Kubernetes garantit une mise à l'échelle fluide avec une perturbation minimale.
  4. Vous pouvez augmenter ou diminuer l'échelle en fonction des besoins de l'application en utilisant à la fois la commande et la configuration.

Surveiller les événements de déploiement et de pods pour détecter les changements

Dans cette étape, vous allez apprendre à surveiller les déploiements et les pods Kubernetes en utilisant diverses commandes kubectl pour suivre les changements, résoudre les problèmes et comprendre le cycle de vie de vos applications. La capacité d'observation est cruciale pour garantir la santé et les performances de vos applications.

Décrivrez le déploiement actuel pour obtenir des informations détaillées :

kubectl describe deployment nginx-deployment

Exemple de sortie :

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      [timestamp]
Labels:                 app=nginx
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-xxx (2/2 replicas created)
Events:          <some deployment events>

Obtenez des informations détaillées sur les pods individuels :

kubectl describe pods -l app=nginx

La sortie de l'exemple montrera les détails de chaque pod, notamment :

  • L'état actuel
  • Les informations sur les conteneurs
  • Les événements
  • Les adresses IP
  • Les informations sur le nœud

Affichez les événements au niveau du cluster :

kubectl get events

Exemple de sortie :

LAST SEEN   TYPE      REASON              OBJECT                           MESSAGE
5m          Normal    Scheduled           pod/nginx-deployment-xxx-yyy    Successfully assigned default/nginx-deployment-xxx-yyy to minikube
5m          Normal    Pulled              pod/nginx-deployment-xxx-yyy    Container image "nginx:latest" already present on machine
5m          Normal    Created             pod/nginx-deployment-xxx-yyy    Created container nginx
5m          Normal    Started             pod/nginx-deployment-xxx-yyy    Started container nginx

Filtrez les événements pour des ressources spécifiques :

kubectl get events --field-selector involvedObject.kind=Deployment

La sortie de l'exemple montrera uniquement les événements liés au déploiement.

Simulez un événement en supprimant un pod :

## Get a pod name
POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')

## Delete the pod
kubectl delete pod $POD_NAME

Observez les événements et la recréation du pod :

kubectl get events
kubectl get pods

Points clés concernant la surveillance :

  1. kubectl describe fournit des informations détaillées sur les ressources.
  2. kubectl get events affiche les événements au niveau du cluster.
  3. Kubernetes remplace automatiquement les pods supprimés.
  4. Les événements aident à résoudre les problèmes de déploiement.
  5. Utilisez describe pour obtenir des informations détaillées sur un objet et events pour suivre les actions.

Présentation brève du Horizontal Pod Autoscaler (HPA) pour une étude future

Dans cette étape, vous allez découvrir le Horizontal Pod Autoscaler (HPA), une fonctionnalité puissante de Kubernetes qui permet de mettre à l'échelle automatiquement les applications en fonction de l'utilisation des ressources. L'HPA vous permet de définir des règles de mise à l'échelle basées sur des métriques telles que l'utilisation du CPU, l'utilisation de la mémoire ou même des métriques personnalisées.

Comprendre l'HPA :

L'HPA ajuste automatiquement le nombre de réplicas de pods en cours d'exécution dans un déploiement (Deployment), un ReplicaSet ou un StatefulSet en fonction de l'utilisation observée du CPU ou de la mémoire, ou en fonction de métriques personnalisées fournies par vos applications. Cela garantit que votre application peut être mise à l'échelle automatiquement pour gérer les charges de trafic changeantes, améliorant ainsi les performances et la disponibilité.

Activer l'addon metrics server dans Minikube :

minikube addons enable metrics-server

Exemple de sortie :

* L'addon 'metrics-server' est activé

Le serveur de métriques fournit à Kubernetes des données d'utilisation de vos ressources et il est essentiel pour le bon fonctionnement de l'HPA.

Créer un déploiement avec des demandes de ressources :

nano ~/project/k8s-manifests/hpa-example.yaml

Ajouter le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
        - name: php-apache
          image: k8s.gcr.io/hpa-example
          ports:
            - containerPort: 80
          resources:
            limits:
              cpu: 500m
            requests:
              cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
    - port: 80
  selector:
    run: php-apache

Appliquer le déploiement :

kubectl apply -f ~/project/k8s-manifests/hpa-example.yaml

Explication de la configuration YAML :

  • Ce fichier YAML définit un déploiement pour une application PHP et le service correspondant.
  • La configuration du déploiement est très similaire à celle de NGINX, à l'exception de :
    • name: php-apache : Le nom du déploiement et du conteneur de pod.
    • image: k8s.gcr.io/hpa-example : L'image Docker pour le conteneur.
    • resources : Cette section spécifie les besoins en ressources du conteneur.
      • limits.cpu: 500m : Le nombre maximal de CPU autorisé pour le conteneur.
      • requests.cpu: 200m : Le nombre de CPU garanti alloué au conteneur.
  • Le service est une configuration de service standard, exposant le déploiement en interne.

Créer une configuration HPA :

nano ~/project/k8s-manifests/php-apache-hpa.yaml

Ajouter le manifeste HPA suivant :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Appliquer la configuration HPA :

kubectl apply -f ~/project/k8s-manifests/php-apache-hpa.yaml

Explication de la configuration YAML :

  • apiVersion: autoscaling/v2 : Spécifie la version de l'API pour le HorizontalPodAutoscaler.
  • kind: HorizontalPodAutoscaler : Indique qu'il s'agit d'un objet HPA.
  • metadata : Contient les métadonnées de l'HPA.
    • name: php-apache : Le nom de l'HPA.
  • spec : Contient la spécification de l'HPA.
    • scaleTargetRef : Définit le déploiement cible qui sera mis à l'échelle.
      • apiVersion: apps/v1 : La version de l'API de la ressource cible.
      • kind: Deployment : Le type de ressource cible, qui est un déploiement.
      • name: php-apache : Le nom du déploiement cible à mettre à l'échelle.
    • minReplicas: 1 : Le nombre minimum de réplicas à maintenir en cours d'exécution.
    • maxReplicas: 10 : Le nombre maximum de réplicas jusqu'auquel on peut monter.
    • metrics : Définit comment déterminer les métriques de mise à l'échelle.
      • type: Resource : Mise à l'échelle basée sur une métrique de ressource.
      • resource.name: cpu : Mise à l'échelle basée sur l'utilisation du CPU.
      • resource.target.type: Utilization : Mise à l'échelle basée sur un pourcentage du CPU demandé par le pod.
      • resource.target.averageUtilization: 50 : Mise à l'échelle lorsque l'utilisation moyenne du CPU sur tous les pods dépasse 50 % des demandes.

Vérifier la configuration HPA :

kubectl get hpa

Exemple de sortie :

NAME         REFERENCE              TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache  0%/50%          1         10        1          30s

Simuler une charge et observer la mise à l'échelle automatique en temps réel

Pour simuler une charge élevée et déclencher l'autoscaler, vous allez exécuter un générateur de charge dans un terminal et surveiller l'activité de mise à l'échelle dans un autre terminal.

Tout d'abord, ouvrez un terminal pour le générateur de charge :

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

NE PAS FERMER le terminal avec le générateur de charge. OUVRIR UN AUTRE TERMINAL pour surveiller l'activité de mise à l'échelle.

Dans le deuxième terminal, vous pouvez utiliser plusieurs commandes pour observer la mise à l'échelle automatique en temps réel :

  1. Surveiller l'état de l'HPA (mise à jour toutes les quelques secondes) :
kubectl get hpa -w
  1. Observer la création des pods lors de la montée en échelle de l'HPA :
kubectl get pods -w
  1. Suivre les événements liés à l'activité de mise à l'échelle :
kubectl get events --sort-by='.lastTimestamp' -w

Vous pouvez exécuter n'importe quelle de ces commandes pour observer différents aspects du processus de mise à l'échelle automatique. Par exemple, observer les pods avec le flag -w vous montre les pods étant créés en temps réel lorsque le système monte en échelle :

Exemple de sortie pour kubectl get pods -w :

NAME                         READY   STATUS    RESTARTS   AGE
php-apache-xxxxxxxxx-xxxxx   1/1     Running   0          2m
load-generator               1/1     Running   0          30s
php-apache-xxxxxxxxx-yyyyy   0/1     Pending   0          0s
php-apache-xxxxxxxxx-yyyyy   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-yyyyy   1/1     Running   0          3s
php-apache-xxxxxxxxx-zzzzz   0/1     Pending   0          0s
php-apache-xxxxxxxxx-zzzzz   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-zzzzz   1/1     Running   0          2s

Vous verrez l'HPA répondre à l'augmentation de la charge en augmentant le nombre de pods. La mise à jour des métriques peut prendre une minute ou plus pour refléter les changements :

Exemple de sortie pour kubectl get hpa -w :

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          30s
php-apache   Deployment/php-apache   68%/50%   1         10        1          90s
php-apache   Deployment/php-apache   68%/50%   1         10        2          90s
php-apache   Deployment/php-apache   79%/50%   1         10        2          2m
php-apache   Deployment/php-apache   79%/50%   1         10        4          2m15s

Une fois que vous avez terminé d'observer, appuyez sur Ctrl+C pour arrêter la commande de surveillance, puis revenez au premier terminal et appuyez sur Ctrl+C pour arrêter le générateur de charge.

Points clés sur l'HPA :

  1. Met automatiquement à l'échelle les pods en fonction de l'utilisation des ressources, ce qui améliore la résilience de l'application.
  2. Peut être mis à l'échelle en fonction du CPU, de la mémoire ou de métriques personnalisées.
  3. Définit les nombres minimum et maximum de réplicas, garantissant une mise à l'échelle équilibrée et efficace.
  4. L'HPA est un composant crucial pour maintenir les performances et la disponibilité de l'application sous des charges variables.
  5. L'utilisation du flag -w (watch) avec les commandes kubectl permet de surveiller en temps réel les changements dans le cluster.

Résumé

Dans ce laboratoire, vous avez acquis une expérience pratique en matière de mise à l'échelle et d'équilibrage de charge dans Kubernetes. Vous avez commencé par créer un cluster Kubernetes local avec Minikube et déployé une application web NGINX de base. Vous avez ensuite exploré différentes méthodes de mise à l'échelle, notamment la modification des fichiers YAML de déploiement et l'utilisation de la commande kubectl scale pour ajuster le nombre de répliques de pods. Vous avez appris à vérifier l'équilibrage de charge en utilisant les Services Kubernetes et un pod de test temporaire.

En outre, vous avez appris à surveiller les déploiements et les pods grâce aux commandes kubectl describe et kubectl get events. Enfin, vous avez acquis une compréhension de base du Horizontal Pod Autoscaler (HPA), y compris la manière dont il peut mettre automatiquement à l'échelle votre application en fonction de l'utilisation des ressources, en utilisant un exemple basé sur une image php-apache. Ce laboratoire offre une introduction complète aux techniques de mise à l'échelle, d'équilibrage de charge, de surveillance et d'auto - mise à l'échelle dans Kubernetes, et jette les bases pour la gestion d'applications plus complexes dans Kubernetes.