GSP768

Présentation

Google Kubernetes Engine propose des solutions horizontales et verticales pour le scaling automatique des pods et de l'infrastructure. Ces outils s'avèrent très utiles pour optimiser les coûts, car ils favorisent une exécution efficace de vos charges de travail et vous assurent de ne payer que pour les ressources que vous utilisez.

Dans cet atelier, vous allez configurer et observer l'autoscaling horizontal et l'autoscaling vertical au niveau des pods, ainsi que l'autoscaler de cluster (solution d'infrastructure horizontale) et le provisionnement automatique des nœuds (solution d'infrastructure verticale) pour le scaling au niveau des nœuds. Dans un premier temps, vous utiliserez ces outils d'autoscaling pour limiter autant que possible la consommation de ressources et réduire la taille de votre cluster lors des périodes creuses. Vous augmenterez ensuite le volume de demandes envoyées au cluster et observerez comment l'autoscaling maintient la disponibilité.

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Réduire le nombre d'instances répliquées pour un déploiement avec l'autoscaler horizontal des pods
• Réduire la demande de processeur d'un déploiement avec l'autoscaler vertical des pods
• Diminuer le nombre de nœuds utilisés dans un cluster avec l'autoscaler de cluster
• Créer automatiquement un pool de nœuds optimisé pour une charge de travail avec le provisionnement automatique des nœuds
• Tester le comportement de l'autoscaling en cas de pic de demande
• Surprovisionner le cluster avec les pods de pause

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google Cloud
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau Détails concernant l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau Détails concernant l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais gratuits.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour afficher un menu contenant la liste des produits et services Google Cloud, cliquez sur le menu de navigation en haut à gauche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Provisionner l'environnement de test

1. Définissez la zone par défaut sur  :

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. Exécutez la commande suivante pour créer un cluster à trois nœuds dans la zone  :

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

Pour illustrer l'autoscaling horizontal des pods, cet atelier utilise une image Docker personnalisée basée sur l'image php-apache. Elle définit une page index.php effectuant divers calculs qui sollicitent fortement le processeur. Vous surveillerez un déploiement de cette image.

3. Créez un fichier manifeste pour le déploiement php-apache :

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 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 EOF

4. Appliquez le fichier manifeste ainsi créé à votre cluster :

kubectl apply -f php-apache.yaml

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Provisionner l'environnement de test

Tâche 1 : Adapter le nombre de pods par autoscaling horizontal

L'autoscaling horizontal des pods modifie la forme de votre charge de travail Kubernetes. Il augmente ou réduit automatiquement le nombre de pods selon les ressources de processeur ou de mémoire consommées par la charge de travail, ou selon des métriques personnalisées provenant de Kubernetes ou des métriques issues de sources extérieures au cluster.

1. Dans Cloud Shell, exécutez la commande suivante pour inspecter les déploiements de votre cluster :

kubectl get deployment

Vous devriez voir le déploiement php-apache apparaître avec trois pods en cours d'exécution :

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s Remarque : Si vous ne voyez pas trois pods disponibles, attendez une minute que les pods soient créés, puis relancez la commande. Si vous ne voyez qu'un pod disponible, il est probable que le scaling du déploiement à la baisse ait déjà été effectué.

2. Appliquez un autoscaling horizontal au déploiement php-apache :

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Adapter le nombre de pods par autoscaling horizontal

Cette commande autoscale configure un autoscaler horizontal des pods (Horizontal Pod Autoscaler, HPA) qui maintiendra entre 1 et 10 le nombre d'instances répliquées des pods contrôlés par le déploiement php-apache. L'option cpu-percent cible 50 % d'utilisation moyenne du processeur demandé pour l'ensemble des pods. Le HPA ajuste le nombre d'instances répliquées (via le déploiement) pour maintenir à 50 % l'utilisation moyenne du processeur sur l'ensemble des pods.

3. Vérifiez l'état actuel de l'autoscaler horizontal des pods :

kubectl get hpa

Vous devriez voir 1 %/50 % dans la colonne Targets (Cibles).

Cela signifie que les pods de votre déploiement sont actuellement à 1 % de l'utilisation moyenne cible du processeur. Ce comportement est normal, car l'application php-apache ne reçoit aucun trafic pour le moment.

Remarque : Si <unknown>/50% (<inconnu>/50 %) s'affiche, attendez une minute et exécutez à nouveau la commande kubectl get hpa. Votre HPA n'a pas encore créé d'évaluation.

Notez également la valeur indiquée dans la colonne Replicas (Instances répliquées). Pour l'instant, elle s'élève à 3, mais sera modifiée par l'autoscaler à mesure que le nombre de pods requis évoluera.

En l'occurrence, l'autoscaler va faire évoluer le déploiement à la baisse, jusqu'au nombre minimal de pods indiqué dans la commande autoscale. L'autoscaling de pods horizontal prend entre 5 et 10 minutes et implique d'arrêter des pods ou d'en démarrer de nouveaux selon le sens du scaling.

Passez à l'étape suivante de l'atelier. Vous examinerez les résultats de l'autoscaler plus tard.

Remarque : Dans cet atelier, la métrique cible du HPA est cpu-percent, mais vous pouvez également l'associer à d'autres métriques personnalisées utiles figurant dans les journaux.

Tâche 2 : Adapter la taille des pods par autoscaling vertical

L'autoscaling vertical des pods vous évite d'avoir à réfléchir aux valeurs à spécifier dans les demandes de processeur et de mémoire d'un conteneur. L'autoscaler peut recommander des valeurs pour les demandes et les limites de processeur et de mémoire, ou modifier automatiquement ces valeurs.

Remarque : Vous ne pouvez pas appliquer simultanément l'autoscaling vertical et l'autoscaling horizontal des pods au processeur ni à la mémoire. Les deux autoscalers tenteraient de s'adapter aux variations de la demande sur les mêmes métriques et leurs actions seraient contradictoires. Toutefois, vous pouvez utiliser l'autoscaler vertical des pods (Vertical Pod Autoscaler, VPA) sur le processeur ou la mémoire et le HPA sur des métriques personnalisées pour éviter tout chevauchement.

Le VPA a déjà été activé sur le cluster scaling-demo.

1. Pour le vérifier, exécutez la commande suivante :

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

Le résultat doit indiquer enabled: true.

Remarque : Le VPA peut être activé sur un cluster existant avec gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling.

Pour montrer l'action du VPA, vous allez déployer l'application hello-server.

2. Appliquez le déploiement hello-server à votre cluster :

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. Vérifiez que le déploiement a bien été créé :

kubectl get deployment hello-server

4. Associez une demande de processeur de 450 millicœurs au déploiement :

kubectl set resources deployment hello-server --requests=cpu=450m

5. Ensuite, exécutez la commande suivante pour afficher les détails du conteneur des pods hello-server :

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• Dans le résultat, recherchez Requests (Demandes). Notez que ce pod demande actuellement le processeur de 450 millicœurs précédemment attribué.

6. Créez maintenant un fichier manifeste pour l'autoscaler vertical des pods :

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

La commande ci-dessus génère le fichier manifeste d'un autoscaler vertical des pods ciblant le déploiement hello-server avec une règle de mise à jour Off (Désactivée). Vous pouvez appliquer l'une des trois règles de mise à jour suivante à l'autoscaler vertical des pods en fonction de l'application :

• Off (Désactivée) : le VPA utilise les données de l'historique pour recommander des mises à jour que vous pouvez appliquer manuellement.
• Initial (Initiale) : les recommandations du VPA s'appliquent une fois à la création des pods, mais ne modifient plus la taille des pods ensuite.
• Auto (Automatique) : des pods sont régulièrement supprimés et recréés en fonction de la taille recommandée.

7. Appliquez le fichier manifeste à hello-vpa :

kubectl apply -f hello-vpa.yaml

8. Attendez une minute, puis affichez le VerticalPodAutoscaler :

kubectl describe vpa hello-server-vpa

Recherchez la section "Container Recommandations" (Recommandations pour les conteneurs) à la fin du résultat. Si vous ne la voyez pas, patientez encore un peu, puis relancez la commande précédente. Vous trouverez dans cette section de nombreux types de recommandations, chacune associée à des valeurs de processeur et de mémoire :

• Lower Bound (Limite inférieure) : limite inférieure à partir de laquelle le VPA déclenche un redimensionnement. Si l'utilisation du pod passe en dessous de cette limite, le VPA supprime le pod et le fait évoluer à la baisse.
• Target (Cible) : valeur utilisée par le VPA pour redimensionner le pod.
• Uncapped Target (Cible non plafonnée) : si vous n'attribuez aucune capacité minimale ou maximale au VPA, cette valeur représentera l'utilisation cible pour le VPA.
• Upper Bound (Limite supérieure) : limite supérieure à partir de laquelle le VPA déclenche un redimensionnement. Si l'utilisation du pod dépasse cette limite, le VPA supprime le pod et le fait évoluer à la hausse.

Vous remarquerez que le VPA recommande de réduire la demande de processeur pour ce conteneur à 25m (millicœurs), contre 100m précédemment, et vous suggère aussi une valeur pour la demande de mémoire. À ce stade, vous pouvez appliquer manuellement ces recommandations au déploiement hello-server.

Remarque : L'autoscaling vertical des pods s'appuie sur les données de l'historique du conteneur pour établir ses recommandations. En pratique, il est conseillé d'attendre au moins 24 heures, que le système ait collecté suffisamment de données, pour appliquer des modifications.

9. Pour voir le VPA en action et ses effets dans cet atelier, vous allez définir la règle de mise à jour de hello-vpa sur Auto et observer le scaling.

10. Modifiez le fichier manifeste pour définir la règle sur Auto et appliquez la configuration :

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

Pour redimensionner un pod, l'autoscaler vertical des pods doit supprimer le pod en question et le recréer aux nouvelles dimensions. Par défaut, pour éviter les temps d'arrêt, le VPA ne supprime et ne redimensionne pas le dernier pod actif. C'est pourquoi vous devez disposer d'au moins deux instances répliquées pour voir le VPA effectuer des modifications.

11. Faites passer le déploiement hello-server à deux instances répliquées :

kubectl scale deployment hello-server --replicas=2

12. Vous pouvez maintenant observer vos pods :

kubectl get pods -w

13. Attendez que les pods hello-server-xxx affichent l'état terminating (Arrêt en cours) ou pending (En attente) (ou accédez à Kubernetes Engine > Charges de travail) :

Cela indique que votre VPA supprime et redimensionne les pods. Une fois l'état apparu, appuyez sur Ctrl+C pour quitter la commande.

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Adapter la taille des pods par autoscaling vertical

Tâche 3 : Résultats du HPA

À ce stade, votre HPA aura probablement réduit le nombre d'instances répliquées de votre déploiement php-apache.

1. Exécutez la commande suivante pour vérifier votre HPA :

kubectl get hpa

• Consultez la colonne Replicas (Instances répliquées). Vous constaterez que votre déploiement php-apache ne comprend plus qu'un pod.

Remarque : Si les trois instances répliquées apparaissent encore pour votre déploiement php-apache, patientez encore quelques minutes que l'autoscaler termine ses opérations.

• Le HPA supprime également toutes les ressources inutilisées, puisque l'application est actuellement inactive. Cependant, si la demande de l'application php-apache venait à augmenter, il effectuerait un scaling inverse pour traiter la nouvelle charge.

Remarque : Si la disponibilité de votre application est primordiale, il est préférable de définir une marge légèrement supérieure au nombre minimal de pods requis afin de tenir compte du temps nécessaire à l'autoscaler horizontal des pods pour effectuer le scaling.

Il s'agit d'une précaution très judicieuse pour optimiser les coûts. Avec un autoscaler bien réglé, vous êtes sûr de fournir une application à haute disponibilité et de ne payer que les ressources requises pour assurer une telle disponibilité, quelle que soit la demande.

Tâche 4 : Résultats du VPA

Les pods du déploiement hello-server devraient maintenant être redimensionnés.

1. Examinez vos pods :

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. Recherchez le champ Requests (Demandes).

• Votre VPA a recréé les pods avec leurs utilisations cibles. Il doit maintenant demander moins de ressources de processeur et une certaine quantité de mémoire :

Requests: cpu: 25m memory: 262144k Remarque : Si l'un des pods demande toujours un processeur de 450 millicœurs, définissez manuellement la cible de votre ressource de processeur avec la commande suivante : kubectl set resources deployment hello-server --requests=cpu=25m . En mode automatique, il arrive que le VPA soit très long ou qu'il définisse des limites inférieure ou supérieure incorrectes si les données collectées ne sont pas encore assez précises. Par souci de simplicité et pour ne pas perdre de temps dans cet atelier, nous allons utiliser la règle de mise à jour sur "Off" (Désactivée).

Ainsi, le VPA devient un excellent outil pour optimiser l'utilisation des ressources, et donc les coûts. La demande de processeur initiale de 400 millicœurs dépassait la puissance nécessaire au conteneur. En ajustant la demande aux 25 millicœurs recommandés, vous utilisez moins de processeur sur le pool de nœuds, ce qui pourrait réduire le nombre de nœuds à provisionner dans le cluster.

Si la règle de mise à jour était définie sur Auto, le VPA supprimerait et redimensionnerait sans arrêt les pods du déploiement hello-server tout au long de sa durée de vie. Il ferait évoluer les pods à la hausse par des demandes plus importantes pour traiter un trafic dense, puis à la baisse lors des périodes creuses. Cela peut être utile pour gérer une augmentation constante de la demande de votre application, mais peut s'avérer risqué en termes de disponibilité en cas de pics importants.

De manière générale, il est préférable d'utiliser le VPA avec une règle de mise à jour sur Off (Désactivée) et d'appliquer les recommandations en fonction des besoins pour optimiser l'utilisation des ressources et maximiser la disponibilité du cluster.

Dans les sections suivantes, vous allez apprendre à optimiser encore davantage votre utilisation des ressources grâce à l'autoscaler de cluster et au provisionnement automatique des nœuds.

Tâche 5 : Autoscaler de cluster

L'autoscaler de cluster est conçu pour ajouter ou supprimer des nœuds en fonction de la demande. Lorsque celle-ci est élevée, l'autoscaler de cluster ajoute des nœuds au pool de nœuds pour répondre à cette demande. Lorsque la demande est faible, l'autoscaler de cluster réduit le nombre de nœuds en supprimant des nœuds. Ainsi, vous assurez la haute disponibilité de votre cluster tout en réduisant au mieux les coûts superflus associés aux machines supplémentaires.

1. Activez l'autoscaling pour votre cluster :

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

Cette opération prend quelques minutes.

Lors du scaling d'un cluster, la décision de supprimer un nœud relève d'un compromis entre optimisation de l'utilisation et disponibilité des ressources. Supprimer les nœuds sous-exploités améliore l'utilisation du cluster, mais les nouvelles charges de travail peuvent se trouver contraintes d'attendre le provisionnement de nouvelles ressources avant de pouvoir s'exécuter.

Vous pouvez spécifier le profil d'autoscaling à utiliser pour prendre de telles décisions. Les profils actuellement disponibles sont les suivants :

• Balanced (Équilibré) : profil par défaut.
• Optimize-utilization (Optimiser l'utilisation) : permet d'optimiser l'utilisation plutôt que de conserver les ressources dans le cluster. Lorsque ce profil est sélectionné, l'autoscaler réduit plus radicalement les ressources du cluster. Il peut supprimer davantage de nœuds et supprimer les nœuds plus rapidement. Ce profil est optimisé pour l'utilisation avec des charges de travail par lots, qui ne sont pas sensibles à la latence de démarrage.

2. Passez au profil d'autoscaling optimize-utilization (Optimiser l'utilisation) afin de pouvoir observer tous les effets du scaling :

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. Une fois l'autoscaling activé, observez votre cluster dans la console Cloud. Cliquez sur les trois barres en haut à gauche pour ouvrir le menu de navigation.

4. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.

5. Sur la page Clusters, sélectionnez le cluster scaling-demo.

6. Sur la page du cluster scaling-demo, sélectionnez l'onglet Nœuds.

7. Regardez la présentation de l'utilisation des ressources par vos trois nœuds.

Remarque : Vos chiffres peuvent être différents de ceux présentés sur l'image. Kubernetes ne provisionne et n'attribue pas les ressources de la même manière à chaque fois.

Si vous additionnez les valeurs Processeur demandé et Processeur pouvant être allouée pour les trois nœuds, les totaux sont respectivement 1 555  et 2 820 millicœurs. Cela signifie qu'un total de 1 265 millicœurs de processeur est disponible sur l'ensemble du cluster. Ce nombre est supérieur à ce qui pourrait être fourni par un nœud.

Pour optimiser l'utilisation, la charge de travail associée à la demande actuelle pourrait être concentrée sur deux nœuds au lieu de trois. Cependant, l'autoscaling du cluster à la baisse n'a pas encore été effectué. En effet, les pods système sont répartis sur l'ensemble du cluster.

Votre cluster exécute un certain nombre de déploiements dans l'espace de noms kube-system qui donne accès aux différents services de GKE tels que la journalisation, la surveillance et l'autoscaling, entre autres.

8. Vous pouvez le vérifier en exécutant la commande suivante dans Cloud Shell :

kubectl get deployment -n kube-system

Par défaut, la plupart des pods système de ces déploiements n'autorisent pas l'autoscaler de cluster à les mettre complètement hors connexion pour les replanifier. Cette configuration est généralement souhaitable, car un grand nombre de ces pods collectent des données utilisées dans d'autres déploiements et services. Par exemple, l'interruption temporaire de metrics-agent ou l'arrêt du pod fluentd pourraient créer des lacunes dans les données collectées pour le VPA et le HPA ou dans vos journaux cloud, respectivement.

Pour les besoins de cet atelier, vous allez appliquer des budgets d'interruption à vos pods kube-system, ce qui permettra à l'autoscaler de cluster de les replanifier correctement sur un autre nœud. Ainsi, vous aurez assez d'espace pour procéder au scaling à la baisse de votre cluster.

Les budgets d'interruption de pod (PDB, Pod Disruption Budgets) indiquent comment Kubernetes doit gérer les interruptions, telles que les mises à niveau, suppressions de pods, manques de ressources, etc. Dans les PDB, vous pouvez spécifier les valeurs max-unavailable et/ou min-available (nombre maximal de pods indisponibles et/ou nombre minimal de pods disponibles) pour un déploiement.

9. Exécutez les commandes suivantes afin de créer un PDB pour chacun de vos pods kube-system :

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Autoscaler de cluster

Dans chacune de ces commandes, vous sélectionnez un pod de déploiement kube-system en fonction d'une étiquette définie à la création du pod et vous spécifiez qu'il ne peut y avoir qu'un seul pod indisponible pour le déploiement concerné. L'autoscaler pourra ainsi replanifier les pods système.

Une fois les PDB actifs, votre cluster devrait opérer un scaling à la baisse, passant de trois à deux nœuds, en une ou deux minutes.

10. Exécutez à nouveau cette commande dans Cloud Shell jusqu'à ce qu'il n'y ait plus que deux nœuds en tout :

kubectl get nodes

Dans la console Cloud, actualisez l'onglet Nœuds de votre cluster scaling-demo pour examiner l'organisation de vos ressources :

L'autoscaling que vous avez configuré a réduit votre cluster de trois à deux nœuds.

En termes de coûts, ce scaling du pool de nœuds à la baisse vous permet d'avoir moins de machines à payer durant les périodes de faible demande sur votre cluster. Le scaling pourrait avoir encore plus d'impact si la demande variait fortement au cours de la journée.

Il est important de noter que, si l'autoscaler de cluster a supprimé le nœud superflu, ce sont le VPA et le HPA qui ont permis de réduire suffisamment la demande de processeur et rendu ce nœud inutile. Utilisés conjointement, ces outils sont un excellent moyen d'optimiser vos coûts globaux et votre utilisation des ressources.

Ainsi, l'autoscaler de cluster permet d'ajouter et de supprimer des nœuds en fonction des pods à planifier. Cependant, GKE fournit une autre fonctionnalité spécifique pour le scaling vertical : le provisionnement automatique des nœuds.

Tâche 6 : Provisionnement automatique des nœuds

Le provisionnement automatique des nœuds (Node Auto Provisioning, NAP) ajoute des pools de nœuds dimensionnés pour répondre à la demande. Sans NAP, l'autoscaler de cluster se contente de créer des nœuds dans les pools que vous avez spécifiés, c'est-à-dire que les nouvelles machines sont du même type que les autres nœuds du pool concerné. Cela permet d'optimiser l'utilisation des ressources pour des charges de travail par lots et des applications qui ne nécessitent pas un scaling extrême, car il est souvent plus long de créer un pool de nœuds optimisé pour un cas d'utilisation que d'ajouter des nœuds à un pool existant.

• Activez le provisionnement automatique des nœuds :

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

Dans cette commande, vous spécifiez un minimum et un maximum pour vos ressources de processeur et de mémoire. Ces valeurs s'appliquent à l'ensemble du cluster.

Le NAP peut prendre un peu de temps, et il est fort probable qu'il ne crée pas de pool de nœuds pour le cluster scaling-demo dans son état actuel.

Dans les sections suivantes, vous allez accroître la demande sur votre cluster et observer l'action de vos autoscalers et du NAP.

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Provisionnement automatique des nœuds

Tâche 7 : Effectuer un test avec une demande plus importante

Jusqu'à présent, vous avez vu que le HPA, le VPA et l'autoscaler de cluster peuvent vous aider à limiter les ressources et les coûts lorsque la demande de votre application est faible. Vous allez maintenant voir comment ces outils gèrent la disponibilité en cas de forte demande.

1. Ouvrez un nouvel onglet dans Cloud Shell en appuyant sur l'icône + :

2. Dans le nouvel onglet, exécutez la commande suivante pour envoyer une boucle infinie de requêtes au service php-apache :

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"

3. Revenez à l'onglet Cloud Shell initial.

4. Patientez une minute environ, puis exécutez la commande suivante pour observer l'augmentation de la charge de processeur sur votre HPA :

kubectl get hpa

Patientez et réexécutez la commande jusqu'à ce que votre cible dépasse 100 %.

5. À présent, regardez comment votre cluster gère cette charge accrue en exécutant de manière répétée cette commande :

kubectl get deployment php-apache

Vous pouvez également surveiller votre cluster en actualisant l'onglet Nœuds dans la console Cloud.

Au bout de quelques minutes, vous verrez plusieurs événements se produire.

• Tout d'abord, le HPA fera évoluer automatiquement le déploiement php-apache à la hausse pour gérer la charge supplémentaire.
• Ensuite, l'autoscaler de cluster devra provisionner de nouveaux nœuds pour gérer l'augmentation de la demande.
• Enfin, le provisionnement automatique des nœuds créera un pool de nœuds optimisé pour les demandes de processeur et de mémoire associées aux charges de travail du cluster. Dans ce cas, il s'agira probablement d'un pool de nœuds doté d'un processeur puissant et d'une faible mémoire, car le test de charge dépasse les limites du processeur.

Attendez que le déploiement php-apache augmente jusqu'à sept instances répliquées et que l'onglet "Nœuds" ressemble à ceci :

6. Revenez à l'onglet Cloud Shell dans lequel vous avez exécuté le test de charge, puis arrêtez le test en appuyant sur Ctrl+C. Le cluster va maintenant évoluer à la baisse à mesure que la demande diminue.

Votre cluster a bien effectué un scaling à la hausse pour répondre à une demande plus importante ! Notez toutefois que le traitement de cette hausse de la demande a pris du temps. Pour beaucoup d'applications, la perte de disponibilité pendant le provisionnement de nouvelles ressources est un problème.

Tâche 8 : Optimiser les charges importantes

Lors d'un scaling à la hausse répondant à des charges plus importantes, le HPA ajoute des pods et le VPA les redimensionne en fonction de vos paramètres. Si un nœud existant a suffisamment d'espace, il pourra peut-être exécuter immédiatement l'application sur un nouveau pod, sans avoir à extraire l'image au préalable. Si vous travaillez avec un nœud qui n'a pas encore déployé votre application, l'opération prendra un peu plus de temps, car il devra télécharger les images du conteneur avant d'exécuter l'application.

Ainsi, si vous n'avez pas assez d'espace sur vos nœuds existants et que vous utilisez l'autoscaler de cluster, cela sera encore plus long. En effet, il devra provisionner un nœud, le configurer, puis télécharger l'image et démarrer les pods. Si le provisionnement automatique des nœuds crée un pool de nœuds comme précédemment sur votre cluster, cela prendra encore plus de temps, car le provisionnement du pool viendra s'ajouter aux autres étapes de création du nœud.

Remarque : En pratique, il est important de veiller à ce que votre application utilise des images de conteneur aussi petites que possible. Cela réduit le temps de démarrage à froid des pods, car plus l'image est petite, plus vite le nœud peut la télécharger, une fois provisionné par l'autoscaler de cluster. De plus, les images volumineuses peuvent augmenter le temps de démarrage des pods et nuire aux performances de provisionnement des nœuds lors des pics de trafic.

Afin de gérer ces différentes latences d'autoscaling, vous avez intérêt à surprovisionner légèrement pour limiter la pression sur vos applications lors des autoscalings à la hausse. Cette démarche est très importante pour l'optimisation des coûts, car vous ne souhaitez pas payer plus de ressources que nécessaire, ni détériorer les performances de vos applications.

Pour déterminer le niveau de surprovisionnement requis, vous pouvez appliquer la formule suivante :

À titre d'exemple, pensez à l'utilisation du processeur sur votre cluster. Vous ne voulez pas qu'elle atteigne 100 %. Vous pouvez donc choisir une marge de sécurité de 15 %. La variable de trafic de la formule correspond alors au pourcentage estimé de croissance du trafic dans les deux à trois minutes qui suivent. Dans le test de charge précédemment exécuté, la fourchette de 0 à 150 % était quelque peu exagérée. Optez plutôt pour une augmentation moyenne du trafic de 30 %.

Avec ces chiffres, le calcul vous donne une marge de sécurité d'environ 65 %. Cela signifie que vous devez surprovisionner vos ressources d'environ 65 % pour pouvoir traiter les scalings à la hausse sans problème majeur.

Une stratégie efficace pour surprovisionner un cluster par autoscaling consiste à utiliser des pods de pause.

Les pods de pause sont des déploiements de faible priorité qui peuvent être supprimés et remplacés par des déploiements de priorité élevée. Ainsi, vous pouvez créer des pods de faible priorité qui n'ont aucune fonction, si ce n'est d'occuper un espace tampon. Lorsque le pod de priorité élevée a besoin d'espace, les pods de pause sont supprimés et replanifiés sur un autre nœud ou sur un nouveau nœud, ce qui libère un espace pour planifier rapidement le pod de priorité élevée.

1. Créez un fichier manifeste pour un pod de pause :

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. Appliquez-le à votre cluster :

kubectl apply -f pause-pod.yaml

3. Maintenant, attendez une minute, puis actualisez l'onglet Nœuds de votre cluster scaling-demo.

Observez la création du nœud, probablement dans un nouveau pool de nœuds, qui va accueillir le pod de pause que vous venez de créer. Si vous exécutez à nouveau le test de charge et que votre déploiement php-apache requiert un nœud supplémentaire, celui-ci pourra être planifié sur le nœud contenant votre pod de pause, et le pod de pause sera placé sur un nouveau nœud. Cette stratégie est excellente. Grâce aux pods de pause, le cluster provisionne un nouveau nœud à l'avance, et votre application peut évoluer à la hausse beaucoup plus rapidement. Si vous attendez une augmentation du trafic, vous pouvez ajouter des pods de pause supplémentaires, mais il est recommandé de ne pas ajouter plus d'un pod de pause par nœud.

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Optimiser les charges importantes

Félicitations !

Félicitations ! Dans cet atelier, vous avez configuré un cluster capable d'évoluer automatiquement et efficacement à la hausse ou à la baisse en fonction de la demande. L'autoscaling horizontal des pods et l'autoscaling vertical des pods font évoluer automatiquement les déploiements de votre cluster, tandis que l'autoscaler de cluster et le provisionnement automatique des nœuds font évoluer automatiquement l'infrastructure du cluster.

Comme toujours, c'est la charge de travail qui détermine les outils à employer. Une utilisation judicieuse de ces autoscalers peut vous permettre d'optimiser la disponibilité quand vous en avez besoin et de ne payer que pour les ressources nécessaires lorsque la demande est faible. Ainsi, vous optimisez votre utilisation des ressources et vous faites des économies en réduisant les coûts.

Étapes suivantes et informations supplémentaires

Consultez ces ressources pour approfondir les sujets abordés dans cet atelier :

• Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE : Ajuster l'autoscaling GKE
• Documentation de l'autoscaler de cluster
• Documentation de l'autoscaler horizontal des pods
• Documentation de l'autoscaler vertical des pods

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 1er février 2024

Dernier test de l'atelier : 20 septembre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.