GSP769

Présentation

L'un des nombreux avantages de Google Cloud est son modèle de facturation, qui vous facture uniquement les ressources que vous utilisez. Par conséquent, il est impératif de n'allouer qu'une quantité raisonnable de ressources pour vos applications et votre infrastructure, et de les utiliser au mieux. GKE offre un certain nombre d'outils et de stratégies qui vous permettent de réduire l'utilisation de différents services et ressources, tout en améliorant la disponibilité de votre application.

Cet atelier présente quelques concepts qui vous aideront à augmenter l'efficacité et la disponibilité des ressources pour vos charges de travail. En analysant et en ajustant la charge de travail de votre cluster, vous pouvez vous assurer que vous n'utilisez que les ressources dont vous avez besoin, et ainsi optimiser les coûts associés au cluster.

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
   • 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. 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 inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. 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 aux essais offerts.

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

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant 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 l'atelier

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

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

2. Cliquez sur Autoriser.

3. Créez un cluster à trois nœuds :

gcloud container clusters create test-cluster --num-nodes=3 --enable-ip-alias

L'option --enable-ip-alias est incluse afin de permettre aux pods d'utiliser des adresses IP d'alias, qui seront nécessaires pour l'équilibrage de charge natif en conteneurs via une entrée.

Dans cet atelier, vous allez utiliser une application Web HTTP simple que vous commencerez par déployer en tant que pod unique.

4. Créez un fichier manifeste pour le pod gb-frontend :

cat << EOF > gb_frontend_pod.yaml apiVersion: v1 kind: Pod metadata: labels: app: gb-frontend name: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 256Mi ports: - containerPort: 80 EOF

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

kubectl apply -f gb_frontend_pod.yaml

Cliquez sur Vérifier ma progression pour valider l'objectif. Provisionner l'environnement de l'atelier

Tâche 1 : Équilibrage de charge natif en conteneurs via une entrée

L'équilibrage de charge natif en conteneurs permet aux équilibreurs de charge de cibler directement les pods Kubernetes et de répartir le trafic de manière homogène entre ceux-ci.

Sans l'équilibrage de charge natif en conteneurs, le trafic de l'équilibreur de charge est transféré vers les groupes d'instances de nœuds, puis acheminé via des règles iptables vers des pods se trouvant ou non dans le même nœud :

L'équilibrage de charge natif en conteneurs permet d'appliquer directement l'équilibrage de charge aux pods, et donc de réduire potentiellement le nombre de sauts de réseau :

Outre le fait d'offrir un routage plus efficace, l'équilibrage de charge natif en conteneurs permet de réduire considérablement l'utilisation du réseau, d'améliorer les performances, de répartir le trafic entre les pods de façon homogène et de vérifier l'état au niveau des applications.

Pour tirer parti de l'équilibrage de charge natif en conteneurs, le paramètre de VPC natif doit être activé sur le cluster. Cela vous a été indiqué lorsque le cluster a été créé avec l'option --enable-ip-alias.

1. Le fichier manifeste suivant configure un service ClusterIP qui sera utilisé pour router le trafic vers le pod de votre application, afin de permettre à GKE de créer un groupe de points de terminaison du réseau :

cat << EOF > gb_frontend_cluster_ip.yaml apiVersion: v1 kind: Service metadata: name: gb-frontend-svc annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: ClusterIP selector: app: gb-frontend ports: - port: 80 protocol: TCP targetPort: 80 EOF

Le fichier manifeste comprend un champ annotations où l'annotation de cloud.google.com/neg permet d'activer l'équilibrage de charge natif en conteneurs pour votre application lorsqu'une entrée est créée.

2. Appliquez la modification à votre cluster :

kubectl apply -f gb_frontend_cluster_ip.yaml

3. Créez ensuite une entrée pour votre application :

cat << EOF > gb_frontend_ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gb-frontend-ingress spec: defaultBackend: service: name: gb-frontend-svc port: number: 80 EOF

4. Appliquez la modification à votre cluster :

kubectl apply -f gb_frontend_ingress.yaml

Lors de la création de l'entrée, un équilibreur de charge HTTP(S) est créé avec un groupe de points de terminaison du réseau dans chaque zone d'exécution du cluster. Après quelques minutes, l'entrée reçoit une adresse IP externe.

L'équilibreur de charge créé dispose d'un service de backend qui s'exécute dans votre projet et définit la manière dont Cloud Load Balancing répartit le trafic. Un état de fonctionnement est associé à ce service de backend.

5. Pour vérifier l'état du service de backend, commencez par récupérer son nom :

BACKEND_SERVICE=$(gcloud compute backend-services list | grep NAME | cut -d ' ' -f2)

6. Obtenez l'état de fonctionnement du service :

gcloud compute backend-services get-health $BACKEND_SERVICE --global

Vous devrez patienter quelques minutes avant d'obtenir l'état de fonctionnement HEALTHY (Opérationnel).

Le résultat ressemble à ce qui suit :

--- backend: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/networkEndpointGroups/k8s1-95c051f0-default-gb-frontend-svc-80-9b127192 status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/instances/gke-test-cluster-default-pool-7e74f027-47qp ipAddress: 10.8.0.6 port: 80 kind: compute#backendServiceGroupHealth Remarque : Ces vérifications d'état sont gérées par l'équilibreur de charge Google Cloud. Elles sont différentes des vérifications d'activité et d'aptitude fournies par l'API Kubernetes, qui peuvent être utilisées pour déterminer l'état de chaque pod. Les vérifications d'état assurées par l'équilibreur de charge Google Cloud utilisent des routes spéciales en dehors du réseau VPC de votre projet pour déterminer la réussite ou l'échec d'un backend.

Une fois que l'état de chaque instance a été vérifié comme étant HEALTHY (Opérationnel), vous pouvez accéder à l'application via son adresse IP externe.

7. Récupérez-la avec la commande suivante :

kubectl get ingress gb-frontend-ingress

8. Si vous saisissez cette adresse IP externe dans une fenêtre de navigateur, l'application se charge.

Cliquez sur Vérifier ma progression pour valider l'objectif. Équilibrage de charge natif en conteneurs via une entrée

Tâche 2 : Test de charge d'une application

Il est important de comprendre la capacité de votre application afin de configurer correctement les demandes et les limites de ressources pour les pods de votre application, et de décider de la meilleure stratégie d'autoscaling.

Au début de l'atelier, vous avez déployé votre application en tant que pod unique. En testant la charge de votre application sur un pod unique sans autoscaling configuré, vous découvrirez le nombre de requêtes simultanées que votre application peut traiter, la quantité de ressources processeur et de mémoire dont elle a besoin, et son comportement face à des charges importantes.

Pour tester la charge de votre pod, vous utiliserez Locust, un framework de test de charge Open Source.

1. Téléchargez les fichiers image Docker pour Locust dans Cloud Shell :

gsutil -m cp -r gs://spls/gsp769/locust-image .

Le répertoire locust-image contient entre autres des fichiers de configuration Locust.

2. Créez l'image Docker pour Locust et stockez-la dans le registre Container Registry de votre projet :

gcloud builds submit \ --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/locust-tasks:latest locust-image

3. Vérifiez que l'image Docker se trouve dans le registre Container Registry de votre projet :

gcloud container images list

Résultat attendu :

Locust se compose d'un nœud principal et d'un certain nombre de machines de type "nœud de calcul" permettant de générer une charge.

4. Copiez et appliquez le fichier manifeste pour créer un déploiement à pod unique pour le nœud principal et un déploiement à cinq instances répliquées pour les nœuds de calcul :

gsutil cp gs://spls/gsp769/locust_deploy_v2.yaml . sed 's/${GOOGLE_CLOUD_PROJECT}/'$GOOGLE_CLOUD_PROJECT'/g' locust_deploy_v2.yaml | kubectl apply -f -

5. Pour accéder à l'interface utilisateur de Locust, récupérez l'adresse IP externe du service LoadBalancer correspondant :

kubectl get service locust-main

Si la valeur External IP (Adresse IP externe) est <pending>, attendez une minute et réexécutez la commande précédente jusqu'à ce qu'une valeur valide s'affiche.

6. Dans une nouvelle fenêtre de navigateur, accédez à [EXTERNAL_IP_ADDRESS]:8089 pour ouvrir la page Web Locust :

Cliquez sur Vérifier ma progression pour valider l'objectif. Test de charge d'une application

Locust vous permet de créer un essaim sur votre application en simulant un grand nombre d'utilisateurs en même temps. Vous pouvez ainsi simuler du trafic en spécifiant le nombre d'utilisateurs et le taux d'apparition.

7. Dans cet exemple, pour représenter une charge type, saisissez 200 pour le nombre d'utilisateurs à simuler et 20 pour le taux d'apparition.

8. Cliquez sur Start swarming (Démarrer le travail en essaim).

Au bout de quelques secondes, l'état doit être passé à Running (En cours d'exécution) avec 200 utilisateurs et environ 150 requêtes par seconde (RPS).

9. Accédez à la console Cloud, puis cliquez sur Menu de navigation () > Kubernetes Engine.

10. Sélectionnez Charges de travail dans le volet de gauche.

11. Cliquez ensuite sur votre pod gb-frontend déployé.

Vous accédez ainsi à la page des détails du pod, qui affiche un graphique représentant l'utilisation du processeur et de la mémoire de votre pod. Observez les valeurs utilisées et les valeurs demandées.

Remarque : Pour voir les valeurs de métriques affichées sous le graphique, cliquez sur les trois points en haut à droite du graphique, puis sélectionnez Développer la légende du graphique dans le menu déroulant.

Avec le test de charge actuel, qui génère environ 150 requêtes par seconde, l'utilisation du processeur peut varier de 0,04 à 0,06. Cela représente 40 à 60 % de la demande de ressources de processeur pour votre pod unique. En revanche, l'utilisation de la mémoire stagne à environ 80 Mi, bien en dessous des 256 Mi demandés. Il s'agit de la capacité par pod. Ces informations seront utiles pour configurer l'autoscaler de cluster, les demandes et les limites de ressources, et pour choisir entre un autoscaler de pods horizontal ou vertical et le mettre en œuvre.

En plus des valeurs de référence, nous vous recommandons de tenir compte des performances de votre application après une utilisation intensive ou des pics de trafic soudains.

12. Revenez à la fenêtre du navigateur Locust et cliquez sur l'option Edit (Modifier) située en haut de la page, sous l'état.

13. Cette fois, saisissez 900 pour le nombre d'utilisateurs à simuler et 300 pour le taux d'apparition.

14. Cliquez sur Start swarming (Démarrer le travail en essaim).

Votre pod recevra soudainement 700 demandes supplémentaires, dans les deux à trois secondes. Une fois que la valeur RPS a atteint environ 150 et que l'état indique 900 utilisateurs, revenez à la page Détails du pod et observez l'évolution des graphiques.

Si la mémoire n'a pas bougé, vous pouvez en revanche constater que le processeur a atteint presque 0,07, soit 70 % de la demande de ressources de processeur pour votre pod. Si cette application était destinée à un déploiement, vous pourriez certainement réduire la demande de mémoire totale en toute sécurité et configurer votre autoscaler horizontal pour qu'il se déclenche en fonction de l'utilisation du processeur.

Tâche 3 : Vérifications d'aptitude et d'activité

Configurer une vérification d'activité

Une vérification d'activité, si elle est configurée dans le pod Kubernetes ou la spécification de déploiement, s'exécute en continu pour détecter si un conteneur a besoin d'être redémarré, et déclencher ce redémarrage le cas échéant. Cette option permet de redémarrer automatiquement les applications bloquées dont l'exécution n'est peut-être pas achevée. Par exemple, un équilibreur de charge géré par Kubernetes (tel qu'un service) n'enverra le trafic à un backend de pod que si tous ses conteneurs réussissent une vérification d'aptitude.

1. Pour nous permettre d'illustrer une vérification d'activité, le code suivant génère un fichier manifeste pour un pod dont la vérification d'activité est basée sur l'exécution de la commande cat sur un fichier généré lors de sa création :

cat << EOF > liveness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: liveness-probe name: liveness-demo-pod spec: containers: - name: liveness-demo-pod image: centos args: - /bin/sh - -c - touch /tmp/alive; sleep infinity livenessProbe: exec: command: - cat - /tmp/alive initialDelaySeconds: 5 periodSeconds: 10 EOF

2. Appliquez le fichier manifeste à votre cluster pour créer le pod :

kubectl apply -f liveness-demo.yaml

La valeur initialDelaySeconds indique le temps qui doit s'écouler entre le démarrage du conteneur et la première vérification. La valeur periodSeconds indique la fréquence de vérification.

Remarque : Les pods peuvent également être configurés de façon à inclure un élément startupProbe, qui indique si l'application dans le conteneur est démarrée. Si un élément startupProbe est présent, aucune autre vérification ne sera exécutée tant que l'état Success (Réussite) n'aura pas été obtenu. Cette configuration est recommandée pour les applications dont les temps de démarrage peuvent varier, afin d'éviter les interruptions liées à une vérification d'activité.

Dans cet exemple, la vérification d'activité consiste principalement à déterminer si le fichier /tmp/alive est présent dans le système de fichiers du conteneur.

3. Vous pouvez vérifier l'état du conteneur du pod en consultant les événements du pod :

kubectl describe pod liveness-demo-pod

À la fin du résultat, vous trouverez une section "Events" (Événements) contenant les cinq derniers événements. À ce stade, cette section des événements du pod ne doit inclure que ceux liés à sa création et à son démarrage :

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 19s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 18s kubelet Pulling image "centos" Normal Pulled 18s kubelet Successfully pulled image "centos" Normal Created 18s kubelet Created container liveness-demo-pod Normal Started 18s kubelet Started container liveness-demo-pod

Ce journal des événements inclut tous les échecs de la vérification d'activité, ainsi que les redémarrages déclenchés en conséquence.

4. Supprimez manuellement le fichier utilisé par la vérification d'activité :

kubectl exec liveness-demo-pod -- rm /tmp/alive

5. Une fois le fichier supprimé, la commande cat utilisée par la vérification d'activité doit renvoyer un code de sortie différent de zéro.

6. Vérifiez à nouveau les événements du pod :

kubectl describe pod liveness-demo-pod

La vérification d'activité échoue, et le journal affiche la séquence d'événements générée par cet échec. La liste commence par la vérification d'activité ayant échoué (Liveness probe failed: cat: /tmp/alive: No such file or directory) et se termine par le redémarrage du conteneur (Started container) :

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Warning Unhealthy 36s (x3 over 56s) kubelet Liveness probe failed: cat: /tmp/alive: No such file or directory Normal Killing 36s kubelet Container liveness-demo-pod failed liveness probe, will be restarted Normal Pulling 6s (x2 over 2m20s) kubelet Pulling image "centos" Normal Pulled 6s (x2 over 2m20s) kubelet Successfully pulled image "centos" Normal Created 6s (x2 over 2m20s) kubelet Created container liveness-demo-pod Normal Started 6s (x2 over 2m20s) kubelet Started container liveness-demo-pod Remarque : L'exemple pris pour cet atelier utilise une vérification de commande pour son élément livenessProbe qui dépend du code de sortie d'une commande spécifiée. En plus d'être utilisé en tant que vérification de commande, un livenessProbe peut être configuré en tant que vérification HTTP dépendant d'une réponse HTTP, ou en tant que vérification TCP dépendant de la possibilité d'établir une connexion TCP sur un port spécifique.

Configurer une vérification d'aptitude

Bien qu'un pod puisse démarrer et être considéré comme opérationnel selon la vérification d'activité, il est possible qu'il ne soit pas encore prêt à recevoir du trafic immédiatement. Cela est courant pour les déploiements servant de backend à un service tel qu'un équilibreur de charge. Une vérification d'aptitude permet de déterminer à quel moment un pod et ses conteneurs sont prêts à recevoir du trafic.

1. Pour illustrer cela, créez un fichier manifeste afin de générer un pod unique qui servira de serveur Web de test ainsi qu'un équilibreur de charge :

cat << EOF > readiness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe EOF

2. Appliquez le fichier manifeste à votre cluster et créez un équilibreur de charge à l'aide de celui-ci :

kubectl apply -f readiness-demo.yaml

3. Récupérez l'adresse IP externe attribuée à votre équilibreur de charge (une minute peut être nécessaire après la commande précédente pour qu'une adresse lui soit attribuée) :

kubectl get service readiness-demo-svc

4. Saisissez l'adresse IP dans une fenêtre de navigateur. Un message d'erreur vous indique que le site n'est pas accessible.

5. Vérifiez les événements du pod :

kubectl describe pod readiness-demo-pod

Le résultat indique que la vérification d'aptitude a échoué :

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

Un échec de la vérification d'aptitude ne déclenche pas le redémarrage du pod, comme c'est le cas lors d'une vérification d'activité.

6. Utilisez la commande suivante pour générer le fichier que la vérification d'aptitude doit contrôler :

kubectl exec readiness-demo-pod -- touch /tmp/healthz

La section Conditions de la description du pod doit maintenant afficher la valeur True (Vrai) pour Ready (Prêt).

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Résultat :

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

7. À présent, actualisez l'onglet de navigateur pointant vers l'adresse IP externe associée au service readiness-demo-svc. Le message "Welcome to nginx!" (Bienvenue dans nginx !) doit s'afficher correctement.

Définir des vérifications d'aptitude pertinentes pour vos conteneurs d'applications permet de s'assurer que les pods ne reçoivent du trafic que lorsqu'ils sont prêts. Vous pouvez par exemple vérifier si le cache de votre application est chargé au démarrage.

Cliquez sur Vérifier ma progression pour valider l'objectif. Vérifications d'aptitude et d'activité

Tâche 4 : Budgets d'interruptions de pods

Pour assurer la fiabilité et le temps d'activité de votre application GKE, vous devez exploiter les budgets d'interruptions de pods (PDB, Pod Disruption Budgets). PodDisruptionBudget est une ressource Kubernetes qui limite le nombre de pods d'une application dupliquée pouvant être interrompus simultanément en raison de perturbations volontaires.

Les interruptions volontaires incluent les actions administratives telles que la suppression d'un déploiement, la mise à jour du modèle de pod d'un déploiement et l'exécution d'une mise à jour progressive, le drainage des nœuds sur lesquels résident les pods d'une application ou le déplacement des pods vers des nœuds différents.

Tout d'abord, vous devez déployer votre application en tant que déploiement.

1. Supprimez votre application à pod unique :

kubectl delete pod gb-frontend

2. Générez ensuite un fichier manifeste qui créera l'application et déclenchera le déploiement de cinq instances répliquées :

cat << EOF > gb_frontend_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: gb-frontend labels: run: gb-frontend spec: replicas: 5 selector: matchLabels: run: gb-frontend template: metadata: labels: run: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 128Mi ports: - containerPort: 80 protocol: TCP EOF

3. Appliquez ce déploiement à votre cluster :

kubectl apply -f gb_frontend_deployment.yaml

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer des budgets d'interruptions de pods (PDB)

Avant de créer un PDB, vous devez drainer les nœuds de votre cluster et observer le comportement de votre application sans PDB.

4. Pour drainer les nœuds, passez en revue le résultat des nœuds de default-pool et exécutez la commande kubectl drain sur chaque nœud :

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --force --ignore-daemonsets --grace-period=10 "$node"; done

La commande ci-dessus évince les pods du nœud spécifié et les marque comme non programmables (via la commande cordon), de sorte qu'aucun nouveau pod ne puisse être créé sur le nœud. Si les ressources disponibles le permettent, les pods sont redéployés sur un autre nœud.

5. Une fois votre nœud drainé, vérifiez le nombre d'instances répliquées de votre déploiement gb-frontend :

kubectl describe deployment gb-frontend | grep ^Replicas

Le résultat devrait ressembler à ceci :

Replicas: 5 desired | 5 updated | 5 total | 0 available | 5 unavailable

Après le drainage d'un nœud, votre déploiement peut ne comporter aucune instance répliquée disponible, comme indiqué dans le résultat ci-dessus. Si aucun pod n'est disponible, votre application est arrêtée. Réessayez de drainer les nœuds, mais cette fois-ci, définissez un budget d'interruptions de pods pour votre application.

6. Pour cela, vous devez tout d'abord réintégrer les nœuds drainés en les marquant comme ordonnançables. La commande ci-dessous permet de programmer à nouveau les pods sur le nœud :

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl uncordon "$node"; done

7. Vérifiez une nouvelle fois l'état de votre déploiement :

kubectl describe deployment gb-frontend | grep ^Replicas

Le résultat doit se présenter comme suit, avec cinq instances répliquées disponibles :

Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable

8. Créez un budget d'interruptions de pods qui déclarera que le nombre minimal de pods disponibles doit être de quatre :

kubectl create poddisruptionbudget gb-pdb --selector run=gb-frontend --min-available 4

9. Une fois encore, drainez l'un des nœuds de votre cluster et observez le résultat :

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --timeout=30s --ignore-daemonsets --grace-period=10 "$node"; done

Une fois que vous avez évincé l'un des pods de votre application, celle-ci produira en boucle le résultat suivant :

evicting pod default/gb-frontend-597d4d746c-fxsdg evicting pod default/gb-frontend-597d4d746c-tcrf2 evicting pod default/gb-frontend-597d4d746c-kwvmv evicting pod default/gb-frontend-597d4d746c-6jdx5 error when evicting pod "gb-frontend-597d4d746c-fxsdg" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-tcrf2" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-6jdx5" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-kwvmv" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

10. Appuyez sur CTRL+C pour quitter la commande.

11. Vérifiez à nouveau l'état de vos déploiements :

kubectl describe deployment gb-frontend | grep ^Replicas

Le résultat doit se présenter comme suit :

Replicas: 5 desired | 5 updated | 5 total | 4 available | 1 unavailable

Jusqu'à ce que Kubernetes puisse déployer un 5e pod sur un nœud différent pour évincer le suivant, les pods restants demeurent disponibles afin de respecter le budget d'interruptions de pods (PDB). Dans cet exemple, le budget d'interruptions de pods a été configuré pour indiquer min-available, mais un PDB peut également être configuré pour définir la valeur max-unavailable (nombre maximal de pods non disponibles). Les deux valeurs peuvent être exprimées sous la forme d'un nombre entier représentant le nombre de pods, ou d'un pourcentage du nombre total de pods.

Félicitations !

Vous avez appris à créer un équilibreur de charge natif en conteneurs via une entrée, afin de bénéficier d'un équilibrage de charge et d'un routage plus efficaces. Vous avez exécuté un test de charge simple sur une application GKE et observé l'utilisation de référence du processeur et de la mémoire, ainsi que la réaction de l'application aux pics de trafic. Vous avez également configuré des vérifications d'aptitude et d'activité, ainsi qu'un budget d'interruption des pods, afin de garantir la disponibilité de votre application. Ces outils et techniques, combinés les uns aux autres, contribuent à l'efficacité globale de l'exécution de votre application sur GKE, en limitant le trafic réseau inutile, en définissant des indicateurs pertinents pour le comportement de l'application, et en améliorant sa disponibilité.

Étapes suivantes et informations supplémentaires

• Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE : Préparer votre application Kubernetes basée sur le cloud

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 : 13 décembre 2023

Dernier test de l'atelier : 13 décembre 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.