GSP767

Présentation

L'infrastructure sous-jacente d'un cluster Google Kubernetes Engine est constituée de nœuds qui correspondent à des instances individuelles de VM Compute. Cet atelier montre comment l'optimisation de l'infrastructure de votre cluster peut vous aider à réduire les coûts et obtenir une architecture plus efficace pour vos applications.

Vous allez découvrir une stratégie qui vous permettra de maximiser l'utilisation (et d'éviter la sous-utilisation) de vos précieuses ressources d'infrastructure en sélectionnant des types de machines correctement configurés pour un exemple de charge de travail. Outre le type d'infrastructure utilisé, l'emplacement géographique physique de cette infrastructure a également une incidence sur les coûts. Tout au long de cet exercice, vous allez apprendre à élaborer une stratégie rentable pour gérer des clusters régionaux à haute disponibilité.

Objectifs

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

• Examiner l'utilisation des ressources d'un déploiement
• Augmenter la capacité d'un déploiement
• Migrer votre charge de travail vers un pool de nœuds avec un type de machine optimisé
• Explorer les options d'emplacement pour votre cluster
• Surveiller les journaux de flux entre les pods de différentes zones
• Déplacer un pod à trafic élevé pour réduire au maximum les coûts du trafic entre zones

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.

Dans cet atelier, vous allez créer un petit cluster afin de l'utiliser. Son provisionnement prend entre deux et cinq minutes.

Si vous avez appuyé sur le bouton Démarrer l'atelier et que le message resources being provisioned s'affiche en bleu avec un cercle de chargement, cela signifie que votre cluster est toujours en cours de création.

Pendant ce temps, vous pouvez commencer à lire les instructions et explications suivantes. Toutefois, les commandes de shell ne fonctionneront pas tant que le provisionnement des ressources n'est pas terminé.

Tâche 1 : Se familiariser avec les types de machines des nœuds

Présentation générale

Un type de machine est un ensemble de ressources matérielles virtualisées disponibles pour une instance de machine virtuelle (VM). Il détermine, entre autres, les limites qui s'appliquent aux disques persistants, à la taille de la mémoire système et au nombre de processeurs virtuels (vCPU). Les types de machines sont regroupés et organisés par famille en fonction de différentes charges de travail.

Si vous devez choisir un type de machine pour votre pool de nœuds, sachez que la famille de types de machines à usage général offre généralement le meilleur rapport prix/performances pour diverses charges de travail. Les types de machines à usage général se composent des séries N et E2 :

Les différences entre ces types de machines font que certains peuvent être plus adaptés que d'autres à votre application. En général, la série E2 offre des performances équivalentes à celles de la série N1, avec la possibilité d'optimiser les coûts. L'utilisation exclusive du type de machine E2 permet ainsi généralement de réduire les coûts.

Toutefois, avec un cluster, il est plus important que les ressources utilisées soient optimisées en fonction des besoins de votre application. Pour les applications ou les déploiements plus importants qui requièrent une forte évolutivité, l'empilement de vos charges de travail sur quelques machines optimisées peut s'avérer moins coûteux que leur répartition sur de nombreuses machines à usage général.

Il est important de connaître les détails de votre application pour prendre votre décision. Si votre application présente des exigences spécifiques, vous pouvez vous assurer que le type de machine est configuré en conséquence.

Dans la section suivante, vous allez examiner une application de démonstration et la migrer vers un pool de nœuds avec un type de machine adapté.

Tâche 2 : Choisir le type de machine approprié pour l'application Hello

Examiner les exigences liées au cluster de démonstration Hello

Au début de l'atelier, un cluster de démonstration Hello avec deux nœuds E2 de taille moyenne (2 vCPU et 4 Go de mémoire) a été créé automatiquement. Ce cluster déploie une instance répliquée d'une application Web simple appelée application Hello, un serveur Web écrit en Go qui répond à toutes les requêtes avec le message "Hello, World!".

1. Une fois l'étape de provisionnement de l'atelier terminée, accédez à la console Cloud, cliquez sur le menu de navigation, puis sélectionnez Kubernetes Engine.

2. Dans la fenêtre Clusters Kubernetes, sélectionnez hello-demo-cluster.

3. Dans la fenêtre suivante, sélectionnez l'onglet Nœuds :

La liste des nœuds de votre cluster doit s'afficher :

Observez comment GKE a utilisé les ressources de votre cluster. Vous pouvez voir les besoins de chaque nœud en termes de processeur et de mémoire, ainsi que la capacité qui pourrait leur être allouée.

4. Cliquez sur le premier nœud de votre cluster.

Consultez la section Pods. Votre pod hello-server doit s'afficher dans l'espace de noms default. Si aucun pod hello-server ne s'affiche, revenez en arrière et sélectionnez le deuxième nœud de votre cluster.

Vous remarquerez que le pod hello-server a besoin de 400 mCPU. Un certain nombre d'autres pods kube-system devraient également être en cours d'exécution. Ceux-ci sont chargés pour permettre aux services de cluster de GKE, tels que la surveillance, de s'activer.

5. Appuyez sur le bouton Retour pour revenir à la page précédente, Nœuds.

Vous constatez que vous avez besoin de deux nœuds E2 de taille moyenne pour exécuter une instance répliquée de votre application Hello-App ainsi que les services kube-system essentiels. Par ailleurs, alors que vous vous servez de la plupart des ressources de processeur du cluster, vous n'utilisez qu'environ un tiers de la mémoire pouvant être allouée.

Si la charge de travail de cette application était complètement statique, vous pourriez créer un type de machine avec une configuration personnalisée disposant de la quantité exacte de processeurs et de mémoire requise. En procédant ainsi, vous réduiriez les coûts pour l'ensemble de votre infrastructure de cluster.

Toutefois, les clusters GKE exécutent souvent plusieurs charges de travail pour lesquelles la capacité doit généralement être augmentée ou réduite.

Que se passerait-il si vous augmentiez la capacité pour l'application Hello ?

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.

Augmenter la capacité pour l'application Hello

1. Accédez aux identifiants de votre cluster :

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Augmentez la capacité de Hello-Server :

kubectl scale deployment hello-server --replicas=2

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Augmenter la capacité de l'application Hello

3. Retournez dans la console, puis accédez au menu Kubernetes Engine situé à gauche et sélectionnez Charges de travail.

hello-server peut s'afficher avec l'état d'erreur Disponibilité minimale non présente.

Remarque : Il se peut que l'erreur n'apparaisse pas dans votre atelier. Selon la version Kubernetes de votre cluster, il se peut que les demandes de ressources des pods kube-system soient moins importantes et que le cluster soit en mesure de traiter la nouvelle charge de travail. Si vous ne voyez pas l'erreur, pas d'inquiétude. Cela n'empêche aucunement de terminer cet atelier.

4. Cliquez sur le message d'erreur pour obtenir des informations sur l'état. Comme vous pouvez le constater, la cause de l'erreur est Insufficient cpu.

C'est tout à fait normal. Rappelez-vous que le cluster n'avait presque plus de ressources de processeur et que vous avez demandé 400 mCPU supplémentaires avec une autre instance répliquée de hello-server.

5. Augmentez la taille de votre pool de nœuds pour gérer votre nouvelle requête :

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. Lorsque vous êtes invité à poursuivre la procédure, saisissez y et appuyez sur Entrée.

7. Dans la console, actualisez la page Charges de travail jusqu'à ce que l'état de votre charge de travail hello-server soit redéfini sur OK :

Examiner votre cluster

Maintenant que vous avez augmenté la capacité pour la charge de travail, revenez à l'onglet "Nœuds" de votre cluster.

1. Cliquez sur hello-demo-cluster :

2. Ensuite, cliquez sur l'onglet Nœuds.

Le pool de nœuds de taille plus importante peut gérer la charge de travail plus intensive. Voyons néanmoins comment les ressources de votre infrastructure sont utilisées.

Bien que GKE utilise au mieux les ressources d'un cluster, le mécanisme peut encore être optimisé. Vous pouvez voir qu'un de vos nœuds se sert de la majeure partie de sa mémoire alors que deux autres nœuds disposent d'une grande quantité de mémoire inutilisée.

À ce stade, si vous continuez à augmenter la capacité pour l'application, vous allez constater que le même schéma se répète. Kubernetes tente de trouver un nœud pour chaque nouvelle instance répliquée du déploiement hello-server, échoue et crée un autre nœud avec environ 600 mCPU.

Problème de bin packing

Dans un problème de bin packing, vous devez "faire rentrer" des objets de formes et de volumes différents dans un nombre limité de "bacs" ou de conteneurs de forme régulière. L'enjeu consiste essentiellement à placer les objets dans un nombre minimal de bacs, en les "emballant" le plus efficacement possible.

Le problème est semblable à celui que vous rencontrez lorsque vous tentez d'optimiser des clusters Kubernetes pour les applications qu'ils exécutent. Vous disposez d'un certain nombre d'applications, dont les besoins en ressources (par exemple, mémoire et processeurs) sont probablement variés. Vous devez essayer d'intégrer le plus efficacement possible ces applications dans les ressources d'infrastructure que Kubernetes gère pour vous (et qui représentent sans doute la majeure partie des coûts engendrés par votre cluster).

Votre cluster de démonstration Hello n'utilise pas le bin packing de façon très efficace. Il serait plus rentable de configurer Kubernetes en faisant appel à un type de machine mieux adapté à cette charge de travail.

Remarque : Pour plus de simplicité, cet atelier vise à optimiser une seule application. En réalité, votre cluster Kubernetes exécute probablement de nombreuses applications avec des exigences différentes. La plate-forme Kubernetes dispose d'outils conçus pour vous aider à adapter les charges de travail de vos applications aux diverses machines auxquelles elle a accès. Vous pouvez utiliser différents pools de nœuds GKE pour permettre à un cluster Kubernetes de gérer plusieurs types de machines.

Migrer vers un pool de nœuds optimisé

• Créez un pool de nœuds avec un type de machine de plus grande capacité :

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Créer un pool de nœuds

Vous pouvez maintenant migrer les pods vers le nouveau pool de nœuds en procédant comme suit :

1. Appliquez la commande "cordon" au pool de nœuds existant : cette opération a pour effet de marquer les nœuds du pool existant (node) comme non programmables. Kubernetes arrête de planifier de nouveaux pods sur ces nœuds une fois que ceux-ci ont été marqués comme non programmables.
2. Appliquez la commande "drain" au pool de nœuds existant : cette opération a pour effet de supprimer les charges de travail s'exécutant sur les nœuds du pool existant (node) après un délai de grâce.

• Commencez par marquer les nœuds du pool d'origine comme non programmables (commande "cordon") :

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

• Ensuite, appliquez la commande "drain" au pool :

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

À ce stade, vos pods devraient s'exécuter sur le nouveau pool de nœuds larger-pool :

kubectl get pods -o=wide

3. Une fois les pods migrés, vous pouvez supprimer sans risque l'ancien pool de nœuds :

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. Lorsque vous êtes invité à poursuivre la procédure, saisissez y et appuyez sur Entrée.

La suppression peut prendre environ deux minutes. Pendant ce temps, lisez la section suivante.

Analyse des coûts

Vous allez maintenant exécuter la même charge de travail, qui nécessitait trois machines e2-medium, sur une machine e2-standard-2.

Examinez le coût horaire lié à l'utilisation des types de machines e2 standard et à cœur partagé :

Standard :

Cœur partagé :

Le coût horaire de trois machines e2-medium est d'environ 0,1 $, tandis que celui d'une machine e2-standard-2 avoisine 0,067 $.

Une économie de 0,04 $ par heure peut sembler minime. Pourtant, ces coûts peuvent s'accumuler tout au long de la durée de vie d'une application en cours d'exécution. L'impact serait encore plus notable à grande échelle. Étant donné que la machine e2-standard-2 peut distribuer votre charge de travail plus efficacement et avec moins d'espace inutilisé, les coûts liés à l'augmentation de la capacité progressent moins rapidement.

C'est intéressant, car le type de machine à cœur partagé E2-medium est conçu pour être rentable avec les petites applications nécessitant peu de ressources. Toutefois, pour la charge de travail actuelle de Hello-App, l'utilisation d'un pool de nœuds avec un type de machine de capacité supérieure s'avère être une stratégie plus rentable.

Dans la console Cloud, vous devriez toujours vous trouver dans l'onglet Nœuds de votre cluster hello-demo. Actualisez cet onglet, puis examinez les champs Processeur demandé et Processeur allouable pour votre nœud larger-pool.

Notez que vous pouvez pousser plus loin l'optimisation. Le nouveau nœud peut accueillir une autre instance répliquée de votre charge de travail sans qu'il soit nécessaire d'en provisionner un autre. Autre possibilité : vous pouvez choisir un type de machine de taille personnalisée qui répond aux besoins de l'application en termes de processeurs et de mémoire, ce qui permet d'économiser encore plus de ressources.

Notez que ces prix varient selon l'emplacement de votre cluster. Dans la prochaine partie de cet atelier, vous allez apprendre à sélectionner la meilleure région et gérer un cluster régional.

Sélectionner l'emplacement approprié pour un cluster

Présentation des régions et des zones

Les ressources Compute Engine utilisées pour les nœuds de votre cluster sont hébergées dans plusieurs emplacements à travers le monde. Ces emplacements sont organisés en régions et en zones. Une région est un emplacement géographique spécifique où vous pouvez héberger vos ressources. Les régions comportent au moins trois zones.

Les ressources contenues dans une zone (telles que les instances de machines virtuelles ou les disques persistants zonaux) sont dites "zonales". D'autres ressources, telles que les adresses IP statiques externes, sont régionales. Les ressources régionales peuvent être utilisées par n'importe quelle ressource de la même région, quelle que soit la zone. En revanche, les ressources zonales ne peuvent être utilisées que par d'autres ressources de la même zone.

Lorsque vous choisissez une région ou une zone, il est important de tenir compte des points suivants :

1. Gestion des défaillances : si les ressources de votre application ne sont réparties que dans une seule zone et que celle-ci devient indisponible, votre application ne sera plus disponible non plus. Pour les applications à grande échelle et soumises à une forte demande, il est souvent préférable de répartir les ressources dans plusieurs zones ou régions afin de gérer les défaillances.
2. Réduction de la latence du réseau : pour réduire la latence du réseau, vous pouvez choisir une région ou une zone proche de votre point de service. Par exemple, si vos clients se trouvent principalement sur la côte est des États-Unis, vous pouvez choisir une région et une zone principales à proximité.

Bonnes pratiques à suivre pour les clusters

Les coûts varient d'une région à l'autre en fonction de divers facteurs. Par exemple, les ressources de la région us-west2 sont généralement plus chères que celles de la région us-central1.

Afin de choisir une région ou une zone pour votre cluster, examinez les tâches effectuées par votre application. Pour un environnement de production sensible à la latence, vous obtiendrez probablement le meilleur rapport coûts/performances en plaçant votre application dans une région/zone où la latence du réseau est réduite et l'efficacité accrue.

En revanche, vous pouvez placer un environnement de développement non sensible à la latence dans une région moins chère afin de diminuer les coûts.

Remarque : Pour en savoir plus sur les VM et les tarifs par région, consultez la documentation "Tarifs des instances de VM".

Gérer la disponibilité des clusters

Il existe plusieurs types de clusters disponibles dans GKE : les clusters zonaux (à zone unique ou multizones) et les clusters régionaux. À première vue, un cluster à zone unique est l'option la moins coûteuse. Toutefois, pour garantir la haute disponibilité de vos applications, il est préférable de répartir les ressources d'infrastructure de votre cluster dans plusieurs zones.

Dans de nombreux cas, le fait de privilégier la disponibilité par le biais d'un cluster multizone ou régional permet d'optimiser le rapport coûts/performances de votre architecture.

Remarque : Au moins une zone supplémentaire est définie pour un cluster multizone. En revanche, celui-ci ne comporte qu'une instance répliquée du plan de contrôle s'exécutant dans une seule zone. Les charges de travail peuvent continuer à s'exécuter en cas d'indisponibilité de la zone du plan de contrôle, mais aucune configuration ne peut être appliquée au cluster tant que le plan de contrôle n'est pas disponible.

Un cluster régional comporte plusieurs instances répliquées du plan de contrôle, qui s'exécutent dans différentes zones d'une région donnée. Les nœuds s'exécutent également dans chaque zone où une instance répliquée du plan de contrôle est en cours d'exécution. Les clusters régionaux consomment le plus de ressources, mais offrent la meilleure disponibilité.

Apprenez-en davantage dans l'article Types de clusters.

Tâche 3 : Gérer un cluster régional

Préparation

La gestion des ressources de votre cluster devient un peu plus complexe si celles-ci sont réparties dans plusieurs zones. Si vous n'êtes pas vigilant, vous risquez d'accumuler des coûts supplémentaires dus à des communications interzones inutiles entre vos pods.

Dans cette section, vous allez observer le trafic réseau de votre cluster et déplacer deux pods générant beaucoup de trafic entre eux pour qu'ils se trouvent dans la même zone.

1. Dans l'onglet Cloud Shell, créez un cluster régional. L'exécution de la commande suivante prend quelques minutes :

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Afin de simuler le trafic entre vos pods et vos nœuds, vous allez créer deux pods sur des nœuds distincts de votre cluster régional. Vous utiliserez la commande ping pour générer du trafic d'un pod à l'autre et le surveiller.

2. Exécutez la commande suivante afin de créer un fichier manifeste pour votre premier pod :

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. Créez le premier pod dans Kubernetes en exécutant la commande suivante :

kubectl apply -f pod-1.yaml

4. Ensuite, exécutez la commande ci-dessous afin de créer un fichier manifeste pour votre second pod :

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. Créez le second pod dans Kubernetes :

kubectl apply -f pod-2.yaml

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Vérifier la création des pods

Les pods que vous avez créés utilisent le conteneur node-hello et renvoient le message Hello Kubernetes lorsqu'ils reçoivent une demande.

Si vous réexaminez le fichier pod-2.yaml que vous avez créé, vous pouvez constater qu'une règle podAntiAffinity (anti-affinité de pod) est définie. Elle garantit que le pod n'est pas planifié sur le même nœud que le pod-1. Pour cela, vous devez mettre en correspondance une expression basée sur l'étiquette security: demo du pod-1. La règle podAffinity (affinité de pod) permet de s'assurer que les pods sont planifiés sur le même nœud, tandis que la règle podAntiAffinity garantit que les pods ne sont pas planifiés sur le même nœud.

Remarque : Kubernetes s'appuie également sur le concept des affinités de nœuds, qui peut vous permettre d'optimiser l'emplacement d'exécution d'applications en fonction des types de machines.

Dans le cas présent, la règle podAntiAffinity sert à illustrer le trafic entre les nœuds. Toutefois, en utilisant les règles podAntiAffinity et podAffinity de façon pertinente, vous pouvez exploiter encore mieux les ressources de votre cluster régional.

6. Affichez les pods que vous avez créés :

kubectl get pod pod-1 pod-2 --output wide

Les deux pods s'affichent avec l'état Running (En cours d'exécution) et les adresses IP internes.

Exemple de résultat : NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

Notez l'adresse IP du pod-2. Vous allez l'utiliser dans la commande suivante.

Simuler le trafic

1. Ouvrez un shell dans le conteneur du pod-1 :

kubectl exec -it pod-1 -- sh

2. Dans le shell, envoyez une requête au pod-2 en remplaçant [POD-2-IP] par l'adresse IP interne affichée pour le pod-2 :

ping [POD-2-IP]

Notez la latence moyenne requise pour pinguer le pod-2 à partir du pod-1.

Examiner les journaux de flux

Lorsque le pod-1 pingue le pod-2, vous pouvez activer les journaux de flux sur le sous-réseau du VPC où le cluster a été créé pour observer le trafic.

1. Dans la console Cloud, ouvrez le menu de navigation, puis accédez à la section Mise en réseau et sélectionnez Réseau VPC.

2. Recherchez le sous-réseau default dans la région et cliquez dessus.

3. Cliquez sur Modifier en haut de l'écran.

4. Activez l'option Journaux de flux.

5. Ensuite, cliquez sur Enregistrer.

6. Enfin, cliquez sur Afficher les journaux de flux dans l'explorateur de journaux.

Vous voyez maintenant une liste de journaux affichant un grand nombre d'informations chaque fois que l'une de vos instances envoie ou reçoit du trafic.

Si les journaux ne sont pas générés, remplacez le signe / avant vpc_flows par %2F comme indiqué dans la capture d'écran ci-dessus.

Les données peuvent être un peu difficiles à lire. Exportez-les ensuite vers une table BigQuery afin de pouvoir rechercher les informations pertinentes.

7. Cliquez sur Autres actions > Créer un récepteur.

8. Nommez votre récepteur FlowLogsSample.

9. Cliquez sur Suivant.

Destination du récepteur

• Pour le service de récepteur, sélectionnez Ensemble de données BigQuery.
• Pour l'ensemble de données BigQuery, sélectionnez Créer un ensemble de données BigQuery.
• Nommez votre ensemble de données us_flow_logs, puis cliquez sur CRÉER UN ENSEMBLE DE DONNÉES.

Il n'est pas nécessaire de modifier les autres paramètres.

1. Cliquez sur Créer un récepteur.

2. À présent, inspectez l'ensemble de données que vous venez de créer. Dans la console Cloud, ouvrez le menu de navigation, puis accédez à la section Analyse et cliquez sur BigQuery.

3. Cliquez sur OK.

4. Sélectionnez le nom de votre projet, puis choisissez us_flow_logs pour afficher la table que vous venez de créer. Si aucune table ne s'affiche, vous devrez peut-être actualiser l'écran jusqu'à ce qu'elle soit créée.

5. Cliquez sur la table compute_googleapis_com_vpc_flows_xxx sous l'ensemble de données us_flow_logs.

6. Cliquez sur Requête > Dans un nouvel onglet.

7. Dans l'éditeur BigQuery, collez ce qui suit entre SELECT et FROM :

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. Cliquez sur Exécuter.

Les journaux de flux précédents sont cette fois filtrés par zone source, VM source, zone de destination et VM de destination.

Recherchez des lignes correspondant à des appels effectués entre deux zones de votre cluster regional-demo.

Remarque : Le numéro de vos journaux ne sera pas exactement identique à celui affiché dans la capture d'écran.

En observant les journaux de flux, vous pouvez constater que le trafic est fréquent entre les différentes zones.

Vous allez maintenant déplacer les pods dans la même zone et voir ce que cela peut vous apporter.

Déplacer un pod à trafic élevé pour réduire au maximum les coûts du trafic entre zones

1. Retournez dans Cloud Shell, puis appuyez sur Ctrl + C pour annuler la commande ping.

2. Saisissez la commande exit pour quitter le shell du pod-1 :

exit

3. Exécutez la commande suivante pour modifier le fichier manifeste du pod-2 :

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

La règle podAntiAffinity se transforme en règle podAffinity tout en continuant à utiliser la même logique. Le pod-2 est maintenant planifié sur le même nœud que le pod-1.

4. Supprimez le pod-2 en cours d'exécution :

kubectl delete pod pod-2

5. Une fois le pod-2 supprimé, recréez-le à l'aide du fichier manifeste que vous venez de modifier :

kubectl create -f pod-2.yaml

Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement effectué la tâche ci-dessus. Simuler le trafic

6. Affichez les pods que vous avez créés et vérifiez qu'ils sont tous les deux à l'état Running (En cours d'exécution) :

kubectl get pod pod-1 pod-2 --output wide

Dans la sortie, vous pouvez voir que le pod-1 et le pod-2 s'exécutent maintenant sur le même nœud.

Notez l'adresse IP du pod-2. Vous allez l'utiliser dans la commande suivante.

7. Ouvrez un shell dans le conteneur du pod-1 :

kubectl exec -it pod-1 -- sh

8. Dans le shell, envoyez une requête au pod-2 en remplaçant [POD-2-IP] par l'adresse IP interne utilisée pour le pod-2 dans la commande précédente :

ping [POD-2-IP]

Comme vous pouvez le constater, le temps de ping moyen entre ces pods est désormais beaucoup plus court.

À ce stade, vous pouvez revenir à l'ensemble de données BigQuery des journaux de flux et vérifier que les journaux récents ne signalent plus de communications interzones indésirables.

Analyse des coûts

Examinez les tarifs de sortie de VM à VM dans Google Cloud :

Lorsque les pods s'envoyaient des pings à partir de différentes zones, les coûts s'élevaient à 0,01 $ par Go. Même si ces frais semblent minimes, ils peuvent s'accumuler très rapidement dans un cluster à grande échelle où plusieurs services effectuent régulièrement des appels entre les zones.

Le fait de regrouper les pods dans la même zone vous a permis d'exécuter les commandes ping sans frais.

Félicitations !

Vous avez exploré l'optimisation des coûts pour les machines virtuelles faisant partie d'un cluster GKE. Vous avez commencé par migrer une charge de travail vers un pool de nœuds avec un type de machine mieux adapté. Ensuite, vous avez analysé les avantages et les inconvénients des différentes régions. Pour finir, vous avez déplacé un pod à trafic élevé dans un cluster régional pour qu'il se trouve toujours dans la même zone que le pod avec lequel il communique.

Dans cet atelier, vous avez découvert des outils et des stratégies économiques pour les VM GKE. Toutefois, pour optimiser vos machines virtuelles, vous devez avant tout bien connaître votre application et ses besoins. Identifier les types de charges de travail à exécuter et estimer les besoins de votre application sont des étapes qui influencent presque toujours le choix de l'emplacement et du type de machine offrant les meilleures performances pour les machines virtuelles à la base de votre cluster GKE.

Le fait d'utiliser efficacement l'infrastructure de votre cluster contribuera dans une large mesure à optimiser vos coûts.

Étapes suivantes et informations supplémentaires

• Documentation sur les types de machines
• Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE : Choisir le type de machine approprié
• Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE : Sélectionner la région appropriée

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 : 30 avril 2024

Dernier test de l'atelier : 30 avril 2024

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.