En tant qu'ingénieur cloud, votre entreprise vous confie la gestion d'une application stratégique qui ajoute fréquemment de nouvelles fonctionnalités. Vous devez déployer les nouvelles fonctionnalités et mises à jour tout en minimisant l'impact sur les utilisateurs et les temps d'arrêt. L'application est conteneurisée et déployée sur Kubernetes. Parfois, vous devez adapter sa capacité en fonction de l'évolution de la demande des utilisateurs. Vous souhaitez également contrôler le trafic vers l'application depuis Internet. Voici quelques-uns des éléments que vous allez devoir prendre en compte pour gérer l'application et la mettre à jour :

• Comment créer un fichier manifeste de déploiement pour votre cluster ?
• Comment ajuster manuellement le nombre de pods dans votre déploiement ?
• Comment créer un service qui contrôle le trafic entrant vers votre application ?
• Comment déployer des mises à jour avec le moins d'interruptions possible pour les utilisateurs ?
• Comment exécuter des déploiements Canary pour tester de nouvelles fonctionnalités avant d'effectuer un déploiement complet ?

En tant que professionnel du cloud habitué à utiliser Azure Kubernetes Service (AKS), vous avez probablement utilisé des fichiers manifestes YAML pour exécuter des déploiements Kubernetes sur AKS. Vous avez probablement utilisé des pipelines DevOps pour rendre les conteneurs et le code de l'application disponibles pour vos clusters Kubernetes.

Pour adapter le nombre de pods à la demande, vous pouvez modifier manuellement le fichier manifeste ou utiliser les commandes kubectl. Pour contrôler le trafic entrant vers votre application, vous devez élaborer le plan de déploiement de l'équilibreur de charge dans le pipeline DevOps, puis l'exécuter. Lorsque vous devez modifier l'image de conteneur, vous devez exécuter le pipeline DevOps pour la rendre disponible, puis utiliser les commandes kubectl pour déclencher un déploiement.

Pour exécuter une mise à jour Canary, vous devez installer Prometheus, configurer le pipeline, ajouter le fichier manifeste et exécuter le pipeline de déploiement.

Vous allez maintenant découvrir comment créer des fichiers manifestes de déploiement pour Google Kubernetes Engine (GKE) afin de créer, faire évoluer et modifier des déploiements.

Présentation

Cet atelier aborde les principes de base pour utiliser des fichiers manifestes de déploiement. Les fichiers manifestes sont des fichiers de configuration requis pour un déploiement et peuvent être utilisés sur différents pods. Ils sont faciles à modifier.

Objectifs

Cet atelier va vous apprendre à effectuer les tâches suivantes :

• Créer des fichiers manifestes de déploiement, les déployer sur le cluster et vérifier la replanification des pods lorsque les nœuds sont désactivés
• Déclencher manuellement le scaling des pods à la hausse ou à la baisse dans les déploiements
• Déclencher un déploiement (mise à jour progressive vers la version la plus récente) et des rollbacks
• Effectuer un déploiement Canary

Mettre en place l'atelier

Accéder à l'atelier

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Qwiklabs dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai.
   Une fois l'atelier lancé, vous ne pouvez pas le mettre en pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à Google Cloud Console.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité.
   Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront appliqués.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

Activer Google Cloud Shell

Google 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.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

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.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

Credentialed accounts: - @.com (active)

Exemple de résultat :

Credentialed accounts: - google1623327_student@qwiklabs.net

• Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project =

Exemple de résultat :

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

Tâche 1 : Créer des fichiers manifestes de déploiement et les déployer sur le cluster

Dans cette tâche, vous allez créer un fichier manifeste de déploiement pour un pod du cluster.

Se connecter au cluster GKE de l'atelier

1. Dans Cloud Shell, définissez les variables d'environnement correspondant à la zone et au nom du cluster en saisissant la commande suivante :

export my_zone={{{project_0.default_zone|Zone}}} export my_cluster=standard-cluster-1

2. Dans Cloud Shell, configurez la complétion par tabulation pour kubectl :

source <(kubectl completion bash)

3. Dans Cloud Shell, configurez l'accès de l'outil de ligne de commande kubectl à votre cluster en saisissant la commande suivante :

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. Saisissez la commande suivante dans Cloud Shell pour cloner le dépôt dans l'environnement Cloud Shell de l'atelier :

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. Créez un lien symbolique qui servira de raccourci vers le répertoire de travail :

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. Passez au répertoire qui contient les exemples de fichiers de l'atelier :

cd ~/ak8s/Deployments/

Créer un fichier manifeste de déploiement

Nous vous avons fourni un exemple de fichier manifeste de déploiement nommé nginx-deployment.yaml. Vous allez l'utiliser pour créer un déploiement. Ce déploiement est configuré pour exécuter trois instances répliquées de pod. Chaque pod qui écoute sur le port TCP 80 ne comprend qu'un seul conteneur nginx :

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

1. Exécutez la commande suivante pour déployer votre fichier manifeste :

kubectl apply -f ./nginx-deployment.yaml

2. Pour afficher la liste des déploiements, exécutez la commande suivante :

kubectl get deployments

Le résultat doit ressembler à cet exemple.

Résultat :

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 3 0 3s

3. Patientez quelques secondes, puis répétez la commande jusqu'à ce que le nombre de déploiements EN COURS indiqué par la commande corresponde au nombre de déploiements VOULUS.

Le résultat final doit ressembler à cet exemple.

Résultat :

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 42s

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer et déployer le fichier manifeste nginx-deployment

Tâche 2 : Effectuer manuellement un scaling à la hausse ou à la baisse du nombre de pods dans les déploiements

Parfois, vous voudrez arrêter une instance de pod ou, au contraire, vous voudrez exécuter dix pods. Dans Kubernetes, vous pouvez effectuer le scaling d'un pod donné, afin d'ajuster le nombre de ses instances. Pour arrêter ces instances, il suffit d'effectuer un scaling à zéro instance.

Dans cette tâche, vous allez effectuer un scaling à la hausse et à la baisse des pods dans la console Google Cloud et Cloud Shell.

Effectuer le scaling à la hausse et à la baisse des pods via la console

1. Basculez vers l'onglet de la console Cloud Console.
2. Dans le menu de navigation (), cliquez sur Kubernetes Engine > Charges de travail.
3. Cliquez sur nginx-deployment (votre déploiement) pour ouvrir la page d'informations sur le déploiement.
4. En haut de la page, cliquez sur ACTIONS > Scaling > Modifier les instances dupliquées.
5. Saisissez 1, puis cliquez sur SCALING.

Cela provoque le scaling de votre cluster à la baisse. L'état du pod se met à jour sous Pods gérés. Vous devrez peut-être cliquer sur Actualiser.

Effectuer un scaling des pods à la hausse ou à la baisse dans le shell

1. Revenez à l'onglet Cloud Shell du navigateur.
2. Dans Cloud Shell, exécutez la commande suivante pour afficher la liste des pods du déploiement :

kubectl get deployments

Résultat :

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

3. Pour effectuer le scaling à la hausse du pod en revenant à trois instances dupliquées, exécutez la commande suivante :

kubectl scale --replicas=3 deployment nginx-deployment

4. Pour afficher la liste des pods du déploiement, exécutez la commande suivante :

kubectl get deployments

Résultat :

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

Tâche 3 : Déclencher un déploiement et un rollback

Seule la modification du modèle de déploiement du pod (par exemple .spec.template) peut déclencher un déploiement. Il peut s'agir, par exemple, de la mise à jour des étiquettes ou des images de conteneurs. Les autres types de mise à jour (par exemple, le scaling du déploiement) ne déclenchent pas de déploiement.

Dans cette tâche, vous allez déclencher un déploiement, puis un rollback.

Déclencher un déploiement

1. Pour mettre à jour la version de nginx dans le déploiement, exécutez la commande suivante :

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record

Cela permet de mettre à jour l'image de conteneur stockée dans votre déploiement vers la version v1.9.1 de nginx.

2. Exécutez la commande suivante pour afficher l'état du déploiement :

kubectl rollout status deployment.v1.apps/nginx-deployment

Le résultat doit ressembler à cet exemple.

Résultat :

Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 1 old replicas pending termination... Waiting for rollout to finish: 1 old replicas pending termination... deployment "nginx-deployment" successfully rolled out

3. Récupérez la liste des déploiements pour vérifier la modification :

kubectl get deployments

Le résultat doit ressembler à cet exemple.

Résultat :

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

Cliquez sur Vérifier ma progression pour valider l'objectif. Mettre à jour la version de nginx dans le déploiement

4. Affichez l'historique du déploiement :

kubectl rollout history deployment nginx-deployment

Le résultat doit ressembler à cet exemple. Il est possible qu'il ne soit pas identique.

Résultat :

deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true

Déclencher un rollback du déploiement

La commande kubectl rollout undo vous permet de procéder au rollback du déploiement d'un objet.

1. Pour effectuer un rollback vers la version précédente du déploiement nginx, exécutez la commande suivante :

kubectl rollout undo deployments nginx-deployment

2. Affichez l'historique du déploiement mis à jour :

kubectl rollout history deployment nginx-deployment

Le résultat doit ressembler à cet exemple. Il est possible qu'il ne soit pas identique.

Résultat :

deployments "nginx-deployment" REVISION CHANGE-CAUSE 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true 3

3. Affichez les détails de la dernière révision du déploiement :

kubectl rollout history deployment/nginx-deployment --revision=3

Le résultat doit ressembler à cet exemple. Il peut ne pas être identique, mais il indique que la révision est revenue à la version nginx:1.7.9.

Résultat :

deployments "nginx-deployment" with revision #3 Pod Template: Labels: app=nginx pod-template-hash=3123191453 Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

Tâche 4 : Définir le type de service dans le fichier manifeste

Dans cette tâche, vous allez créer et vérifier un service qui contrôle le trafic entrant vers une application. Lorsque vous configurez les services, vous pouvez choisir les types ClusterIP, NodePort ou LoadBalancer. Dans cet atelier, vous allez configurer un type de service LoadBalancer.

Définir des types de services dans le fichier manifeste

Nous vous avons fourni un fichier manifeste nommé service-nginx.yaml, qui déploie un type de service LoadBalancer. Ce service est configuré pour distribuer le trafic entrant sur le port TCP 60000 vers le port 80 de tous les conteneurs présentant l'étiquette app: nginx.

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

• Dans Cloud Shell, exécutez la commande suivante pour déployer votre fichier manifeste :

kubectl apply -f ./service-nginx.yaml

Ce fichier manifeste définit un service et l'applique aux pods qui correspondent au sélecteur. Dans le cas présent, le manifeste est appliqué au conteneur nginx que vous avez déployé dans la tâche 1. Ce service s'applique également à tous les pods portant l'étiquette app: nginx, y compris ceux qui sont créés après le service.

Vérifier la création du type de service LoadBalancer

1. Exécutez la commande suivante pour afficher les détails du service nginx :

kubectl get service nginx

Le résultat doit ressembler à cet exemple.

Résultat :

NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE nginx 10.X.X.X X.X.X.X 60000/TCP run=nginx 1m

2. Lorsque l'adresse IP externe s'affiche, ouvrez la page http://[EXTERNAL_IP]:60000/ dans un nouvel onglet du navigateur pour constater que le serveur est diffusé via l'équilibrage de charge réseau.

Remarque : Le remplissage du champ ExternalIP pour votre service peut prendre quelques secondes. Cela est normal. Il vous suffit d'exécuter de nouveau la commande kubectl get services nginx à quelques secondes d'intervalle jusqu'à ce que le champ soit renseigné.

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer le fichier manifeste qui déploie le type de service LoadBalancer

Tâche 5 : Effectuer un déploiement Canary

Un déploiement Canary est un déploiement distinct qui sert à tester une nouvelle version de votre application. Un seul service cible à la fois le déploiement Canary et les déploiements standards. Il peut diriger un sous-ensemble d'utilisateurs vers la version Canary, afin de limiter les risques liés aux nouvelles versions.

Le fichier manifeste nginx-canary.yaml qui vous est fourni déploie un seul pod, qui exécute une version de nginx plus récente que celle de votre déploiement principal. Dans cette tâche, vous allez créer un déploiement Canary à l'aide de ce nouveau fichier de déploiement :

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

Le fichier manifeste du service nginx que vous avez déployé dans la tâche précédente utilise un sélecteur d'étiquettes pour cibler les pods portant l'étiquette app: nginx. Le déploiement standard et le nouveau déploiement Canary ont tous les deux l'étiquette app: nginx. Le service répartira les connexions entrantes entre les pods de déploiement standard et les pods de déploiement Canary. Le déploiement Canary présente moins d'instances répliquées (pods) que le déploiement standard. Il est donc accessible à moins d'utilisateurs que le déploiement standard.

1. Créez le déploiement Canary à partir du fichier de configuration :

kubectl apply -f nginx-canary.yaml

2. Une fois le déploiement terminé, vérifiez que les déploiements nginx et nginx-canary sont présents :

kubectl get deployments

3. Dans le navigateur, revenez à l'onglet connecté à l'adresse IP externe du service LoadBalancer et actualisez la page. La page de bienvenue standard Welcome to nginx doit toujours être affichée.
4. Revenez à Cloud Shell et ramenez le déploiement principal à zéro instance dupliquée :

kubectl scale --replicas=0 deployment nginx-deployment

5. Vérifiez que la seule instance dupliquée en cours d'exécution est désormais le déploiement Canary :

kubectl get deployments

6. Dans le navigateur, revenez à l'onglet connecté à l'adresse IP externe du service LoadBalancer et actualisez la page. La page de bienvenue standard Welcome to nginx s'affiche toujours et indique que le service équilibre automatiquement le trafic vers le déploiement Canary.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un déploiement Canary

Affinité de session

La configuration de service utilisée dans le cadre de l'atelier ne garantit pas que toutes les requêtes reçues d'un même client se connecteront toujours au même pod. Chaque requête est traitée séparément et peut se connecter soit au déploiement standard nginx, soit au déploiement nginx-canary.

La possibilité de passer d'une version à l'autre peut entraîner des problèmes si des modifications importantes sont apportées aux fonctionnalités de la version Canary. Pour éviter cela, vous pouvez définir le champ sessionAffinity sur ClientIP dans la spécification du service, si vous avez besoin que la première requête d'un client détermine le pod à utiliser pour toutes les connexions suivantes.

Exemple :

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer sessionAffinity: ClientIP selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

Résumé

Dans cet atelier, vous avez découvert comment GKE utilise le fichier manifeste pour déployer, faire évoluer et exécuter une mise à jour Canary de votre application. Vous trouverez ci-dessous les principales similitudes et différences entre GKE et AKS.

Similitudes :

GKE et AKS sont des services Kubernetes gérés qui permettent aux développeurs de déployer, de gérer et de faire évoluer des applications conteneurisées.

• La structure et la syntaxe de base des fichiers YAML pour les déploiements Kubernetes sont les mêmes pour GKE et AKS.
• AKS et GKE utilisent tous deux des commandes kubectl.

Différences :

• Dans GKE, vous pouvez spécifier les attributs de vos clusters, de vos pods et de votre gestion sans avoir à créer un pipeline DevOps comme vous le feriez pour les déploiements AKS. En effet, GKE dispose de l'infrastructure backend nécessaire pour effectuer les tâches de provisionnement à l'aide du fichier manifeste.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Copyright 2020 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.