GSP053

Aperçu

Les équipes DevOps font souvent appel à différents types de déploiements pour gérer divers scénarios de déploiement d'applications tels que "déploiements continus", "déploiements bleu-vert" et "déploiements Canary", entre autres. Cet atelier sera l'occasion de pratiquer le scaling et la gestion de conteneurs pour apprendre à mettre en place ces scénarios courants composés de plusieurs déploiements hétérogènes.

Objectifs de l'atelier

• Pratiquer l'outil kubectl
• Créer des fichiers de déploiement YAML
• Lancer et modifier des déploiements, et procéder à leur scaling
• S'entraîner à mettre à jour des déploiements et des styles de déploiements

Prérequis

Pour optimiser votre apprentissage, les recommandations suivantes sont recommandées pour cet atelier :

• Vous avez suivi ces ateliers Google Cloud Skills Boost :
• Présentation de Docker
• Hello Node Kubernetes
• Vous avez des compétences en administration système Linux.
• Vous comprenez la théorie DevOps : concepts de déploiement continu.

Présentation des déploiements

Les déploiements hétérogènes consistent généralement à connecter au moins deux environnements ou régions ayant des infrastructures distinctes dans le but de répondre à des besoins techniques ou opérationnels spécifiques. Selon leurs spécificités, ces déploiements peuvent être "hybrides", "multicloud" ou "public-privé".

Dans le cadre de cet atelier, nous aborderons des déploiements hétérogènes qui s'étendent sur diverses régions dans un environnement cloud unique, dans plusieurs environnements cloud publics (multicloud) ou dans une combinaison d'environnements sur site et cloud public (hybride ou public-privé).

Différents problèmes d'ordre opérationnel et technique peuvent se présenter lors des déploiements qui se limitent à un environnement ou une région :

• Ressources insuffisantes : dans un environnement donné, en particulier s'il s'agit d'un environnement sur site, les ressources de calcul, de stockage ou réseau disponibles ne suffisent pas toujours à répondre aux besoins de production.
• Portée géographique limitée : dans un environnement unique, des utilisateurs géographiquement éloignés doivent tous accéder au même déploiement. Leur trafic peut être réparti sur toute la planète et converger vers une position centrale.
• Disponibilité restreinte : un trafic à l'échelle du Web exige des applications ayant une certaine tolérance aux pannes et de la résilience.
• Dépendance vis-à-vis d'un fournisseur : les abstractions de plate-forme et d'infrastructure liées à certains fournisseurs peuvent empêcher le portage des applications.
• Manque de flexibilité des ressources : vos ressources peuvent être limitées à un ensemble spécifique de fonctionnalités de calcul, de stockage ou réseau.

Les déploiements hétérogènes peuvent aider à résoudre ces problèmes, à condition d'être structurés par des processus et des procédures programmatiques et déterministes. Les procédures ponctuelles ou ad hoc peuvent donner lieu à des déploiements ou des processus fragiles et peu tolérants aux pannes. Les processus ad hoc peuvent entraîner des pertes de données ou de trafic. Pour être efficaces, les processus de déploiement doivent être reproductibles et mettre en œuvre des méthodes éprouvées de gestion des comptes, de configuration et de maintenance.

Les trois scénarios de déploiement hétérogènes les plus courants sont les déploiements multicloud, les déploiements appliqués à des données sur site, et les processus d'intégration et de diffusion continues (CI/CD).

Les exercices suivants illustrent certains cas d'utilisation courants des déploiements hétérogènes, ainsi que des méthodes de déploiement bien structurées basées sur Kubernetes et d'autres ressources d'infrastructure.

Configuration

Avant de cliquer sur le bouton Start Lab (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 Start Lab (Démarrer l'atelier), indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique Qwiklabs 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. Des identifiants temporaires vous sont fournis pour vous permettre de vous connecter à Google Cloud le temps de l'atelier.

Conditions requises

Pour réaliser cet atelier, vous devez :

• avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;
• disposer de suffisamment de temps pour réaliser l'atelier en une fois.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier.

Remarque : Si vous utilisez un appareil Chrome OS, exécutez cet atelier dans une fenêtre de navigation privée.

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 Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient des 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 offre un accès en ligne de commande à vos ressources GCP.

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

   

2. Cliquez sur Continue (Continuez):

   

Il faut quelques instants pour mettre en service et se connecter à l'environnement. Lorsque vous êtes connecté, vous êtes déjà authentifié et le projet est défini sur votre PROJECT_ID. Par exemple:

gcloud est l'outil de ligne de commande associé à Google Cloud Platform. Pré-installé sur Cloud Shell, il est également compatible avec la saisie semi-automatique via la touche de tabulation.

Vous pouvez répertorier les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

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

Pour répertorier les ID de projet, exécutez la commande suivante :

gcloud config list project
	

Résultat :

[core]
project = <ID_Projet>
	

Exemple de résultat :

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

Définir la zone

• Exécutez la commande suivante pour définir votre zone GCP de travail, en veillant à remplacer la zone locale par  :

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

Télécharger l'exemple de code pour cet atelier

1. Téléchargez l'exemple de code permettant de créer et d'exécuter des conteneurs et des déploiements :

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. Créez un cluster avec cinq nœuds 3 (cette opération prend quelques minutes) :

gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Tache 1. Découverte de l'objet "deployment"

Familiarisons-nous avec les déploiements. Commençons par examiner l'objet "deployment".

1. Dans kubectl, la commande explain nous permet d'en savoir plus sur l'objet "deployment".

kubectl explain deployment

2. Nous pouvons aussi afficher l'ensemble des champs en ajoutant l'option --recursive.

kubectl explain deployment --recursive

3. Vous pourrez utiliser la commande "explain" tout au long de l'atelier pour comprendre la structure d'un objet "deployment" et voir l'effet des différents champs.

kubectl explain deployment.metadata.name

Tache 2. Création d'un déploiement

1. Mettez le fichier configuration deployments/auth.yaml à jour :

vi deployments/auth.yaml

2. Lancez l'éditeur :

i

3. Modifiez le champ image de la section "containers" du déploiement comme suit :

... containers: - name: auth image: kelseyhightower/auth:1.0.0 ...

4. Pour enregistrer le fichier auth.yaml, appuyez sur <Échap>, puis saisissez :

:wq

5. À présent, créez un déploiement simple. Examinez le fichier de configuration du déploiement :

cat deployments/auth.yaml

(Résultat)

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Notez que le déploiement crée une instance dupliquée et utilise la version 1.0.0 du conteneur "auth".

L'exécution de la commande kubectl create pour créer le déploiement "auth" crée un pod conforme aux données du fichier manifeste du déploiement. Vous pouvez donc faire évoluer le nombre de pods en modifiant le nombre spécifié dans le champ replicas.

6. Créez maintenant votre déploiement avec la commande kubectl create :

kubectl create -f deployments/auth.yaml

7. Vérifiez ensuite que le déploiement a bien été créé.

kubectl get deployments

8. Une fois le déploiement créé, Kubernetes crée un ReplicaSet pour celui-ci. Nous pouvons vérifier qu'un ReplicaSet a bien été créé pour notre déploiement :

kubectl get replicasets

Vous devriez voir apparaître un ReplicaSet portant un nom du type auth-xxxxxxx.

9. Enfin, nous pouvons afficher les pods créés dans le cadre de notre déploiement. Kubernetes crée un pod en même temps que le ReplicaSet.

kubectl get pods

10. Nous allons maintenant créer un service pour notre déploiement "auth". Vous avez déjà vu les fichiers manifestes des services, donc nous ne nous attarderons pas sur les détails. Créez le service "auth" avec la commande kubectl create :

kubectl create -f services/auth.yaml

11. Procédez de la même façon pour créer et exposer le déploiement "hello" :

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. Et encore une fois pour créer et exposer le déploiement "frontend" :

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml

Remarque : Vous avez créé une ConfigMap pour le déploiement "frontend".

13. Interagissez avec "frontend" en capturant son adresse IP externe, puis en l'appelant avec "curl" :

kubectl get services frontend

Remarque Le remplissage du champ External-IP pour votre service peut prendre quelques secondes. C'est normal. Relancez simplement la commande ci-dessus toutes les quelques secondes jusqu'à ce que le champ soit rempli.

curl -ks https://<EXTERNAL-IP>

Vous obtenez la réponse "hello".

14. Vous pouvez également associer la fonctionnalité de modélisation de sortie de kubectl à la commande "curl", sur une seule ligne :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Tester la tâche terminée

Cliquez sur Check my progress (Vérifier ma progression) ci-dessous pour vérifier votre progression dans l'atelier. Si le cluster Kubernetes et les déploiements Auth, Hello et Frontend ont correctement été créés, vous recevrez une note d'évaluation.

Créer un cluster Kubernetes et des déploiements (Auth, Hello et Frontend)

Procéder au scaling d'un déploiement

Maintenant que nous avons créé un déploiement, nous pouvons procéder à son scaling. Pour ce faire, modifiez le champ spec.replicas.

1. Là encore, la commande kubectl explain vous permet de consulter la description de ce champ, si vous le souhaitez.

kubectl explain deployment.spec.replicas

2. La méthode la plus simple pour modifier le champ "replicas" consiste à utiliser la commande kubectl scale :

kubectl scale deployment hello --replicas=5

Remarque : Le lancement des nouveaux pods peut demander une minute.

Une fois le déploiement modifié, Kubernetes met automatiquement à jour le ReplicaSet associé et lance les nouveaux pods de manière à obtenir un nombre total de cinq pods.

3. Vérifiez que cinq pods hello sont en cours d'exécution :

kubectl get pods | grep hello- | wc -l

4. Maintenant, procédez au scaling inverse de l'application :

kubectl scale deployment hello --replicas=3

5. Vérifiez à nouveau que vous avez le bon nombre de pods :

kubectl get pods | grep hello- | wc -l

Vous avez découvert les déploiements Kubernetes, ainsi que la gestion et le scaling d'un groupe de pods.

Tache 3. Mise à jour progressive

Dans un déploiement, vous pouvez mettre à jour les images vers une nouvelle version par le biais d'un mécanisme de modification progressive. Ainsi, votre déploiement augmente le nombre d'instances dupliquées dans le nouveau ReplicaSet qu'il a créé, à mesure qu'il réduit le nombre d'instances dupliquées dans l'ancien ReplicaSet.

Déclencher une mise à jour progressive

1. Pour mettre à jour votre déploiement, exécutez la commande suivante :

kubectl edit deployment hello

2. Modifiez le champ image de la section "containers" du déploiement comme suit :

... containers: image: kelseyhightower/hello:2.0.0 ...

3. Enregistrez la modification et quittez l'éditeur.

Ensuite, le déploiement modifié est enregistré dans votre cluster et Kubernetes lance une mise à jour progressive.

4. Affichez le nouveau ReplicaSet créé par Kubernetes :

kubectl get replicaset

5. Une nouvelle entrée apparaît également dans l'historique des déploiements :

kubectl rollout history deployment/hello

Suspendre une mise à jour progressive

Si vous constatez des problèmes liés à un déploiement en cours d'exécution, suspendez la mise à jour.

1. Essayez dès à présent :

kubectl rollout pause deployment/hello

2. Consultez l'état actuel du déploiement :

kubectl rollout status deployment/hello

3. Vous pouvez également le vérifier directement sur les pods :

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Reprendre une mise à jour progressive

Le déploiement est suspendu. Par conséquent, certains pods utilisent la nouvelle version, et d'autres l'ancienne.

1. Nous pouvons poursuivre le déploiement avec la commande resume :

kubectl rollout resume deployment/hello

2. Une fois le déploiement terminé, la commande status devrait afficher le résultat suivant.

kubectl rollout status deployment/hello

(Résultat)

deployment "hello" successfully rolled out

Procéder au rollback d'une mise à jour

Supposons qu'un bug ait été détecté dans votre nouvelle version. Tous les utilisateurs connectés aux nouveaux pods rencontreront les problèmes associés à cette nouvelle version.

Dans un tel cas, vous devez revenir à la version précédente pour analyser et corriger la nouvelle version avant de la redéployer.

1. La commande rollout vous permet de procéder à un rollback vers la précédente version :

kubectl rollout undo deployment/hello

2. Vérifiez le rollback dans l'historique :

kubectl rollout history deployment/hello

3. Enfin, vérifiez que tous les pods sont maintenant associés à la version précédente :

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Parfait. Vous savez maintenant mettre à jour des déploiements Kubernetes et des applications, sans provoquer d'interruption.

Tache 4. Déploiements Canary

Les déploiements Canary vous permettent de tester un nouveau déploiement en production sur un sous-ensemble d'utilisateurs. Cette technique est idéale pour déployer des modifications auprès d'un petit groupe d'utilisateurs et limiter ainsi les risques associés aux nouvelles versions.

Créer un déploiement Canary

Un déploiement Canary se compose d'un déploiement distinct incluant votre nouvelle version et d'un service qui cible à la fois votre déploiement normal (stable) et votre déploiement Canary.

1. Commencez par créer un déploiement Canary pour la nouvelle version :

cat deployments/hello-canary.yaml

(Résultat)

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Utilisez la version 2.0.0 afin qu'elle corresponde à la version du sélecteur de service version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. À présent, créez le déploiement Canary :

kubectl create -f deployments/hello-canary.yaml

3. Vous devriez ensuite avoir un déploiement hello et un déploiement hello-canary. Vérifiez-le avec cette commande kubectl :

kubectl get deployments

Sur le service hello, le sélecteur utilisé est app:hello et il se rapporte à la fois aux pods du déploiement de production et du déploiement Canary. Cependant, le déploiement Canary étant associé à un nombre inférieur de pods, il ne sera visible que pour quelques utilisateurs.

Vérifier le déploiement Canary

1. Pour savoir quelle version de hello est diffusée, exécutez la requête :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. Si vous exécutez cette commande plusieurs fois, vous verrez que certaines requêtes sont diffusées par hello 1.0.0 et qu'un sous-ensemble d'entre elles (1/4 = 25 %) sont diffusées par la version 2.0.0.

Tester la tâche terminée

Cliquez sur Check my progress (Vérifier ma progression) ci-dessous pour vérifier votre progression dans l'atelier. Si le déploiement Canary a correctement été créé, vous recevrez une note d'évaluation.

Déploiement Canary

Déploiements Canary en production – Affinité de session

Au cours de cet atelier, chaque requête envoyée au service Nginx pouvait être diffusée par le déploiement Canary. Cependant, comment faire pour s'assurer qu'un utilisateur ne soit jamais servi par le déploiement Canary ? Cela peut s'avérer utile, par exemple, si vous souhaitez éviter qu'une modification apportée à l'interface utilisateur d'une application vienne perturber des utilisateurs. Il s'agit alors de maintenir l'association entre l'utilisateur et l'un ou l'autre des déploiements concernés.

Vous pouvez y parvenir en créant un service avec affinité de session, de sorte que les utilisateurs soient toujours servis par la même version. Dans l'exemple ci-dessous, le service est le même que précédemment, à l'exception du champ sessionAffinity qui a été ajouté et associé à la valeur "ClientIP". Ainsi, les requêtes associées à une même adresse IP de client seront toujours envoyées à la même version de l'application hello.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

Il aurait été difficile de configurer un environnement permettant de tester cette méthode. Vous n'aurez donc pas à le faire ici. Notez toutefois que vous pouvez utiliser le champ sessionAffinity dans le cadre de déploiements Canary en production.

Tache 5. Déploiements bleu-vert

Les mises à jour progressives sont idéales si vous souhaitez déployer une application en douceur, en limitant au minimum les frais, l'impact sur les performances et les interruptions. Or, il peut parfois s'avérer judicieux de modifier les équilibreurs de charge de sorte qu'ils pointent vers la nouvelle version, après son déploiement complet. Si tel est votre cas, optez pour un déploiement bleu-vert.

Pour y parvenir, Kubernetes crée deux déploiements distincts : un "bleu" pour l'ancienne version et un "vert" pour la nouvelle. Votre déploiement hello actuel sera la version "bleue". L'accès aux déploiements se fera via un service agissant comme un routeur. Une fois que la nouvelle version "verte" sera opérationnelle, vous généraliserez son utilisation en mettant à jour le service.

L'un des inconvénients majeurs des déploiements bleu-vert est qu'ils nécessitent au moins le doublement des ressources disponibles dans votre cluster pour héberger votre application. Assurez-vous que le cluster concerné dispose de ressources suffisantes avant de déployer simultanément deux versions de l'application.

Le service

Utilisez le service "hello" existant, mais modifiez son sélecteur comme suit : app:hello, version: 1.0.0. Ainsi, le sélecteur désignera le déploiement "bleu", mais pas le déploiement "vert" qui est associé à une autre version.

Commencez par modifier le service :

kubectl apply -f services/hello-blue.yaml REMARQUE: Ignorez l'avertissement indiquant resource service/hello is missing car il est corrigé automatiquement.

Mise à jour par déploiement bleu-vert

Pour procéder à un déploiement bleu-vert, nous allons créer un déploiement "vert" représentant notre nouvelle version. Le déploiement "vert" modifie le libellé de la version et le chemin de l'image.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. Créez le déploiement "vert" :

kubectl create -f deployments/hello-green.yaml

2. Une fois que votre déploiement "vert" a démarré correctement, vérifiez que la version 1.0.0 actuelle est toujours utilisée :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. À présent, modifiez le service de sorte qu'il pointe vers la nouvelle version :

kubectl apply -f services/hello-green.yaml

4. Le déploiement "vert" est utilisé immédiatement après la modification du service. Vous pouvez maintenant vérifier que la nouvelle version est utilisée systématiquement.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Procéder à un rollback bleu-vert

Si nécessaire, vous pouvez procéder à un rollback vers l'ancienne version de la même manière.

1. Tandis que le déploiement "bleu" est toujours en cours d'exécution, modifiez simplement le service pour l'associer à l'ancienne version.

kubectl apply -f services/hello-blue.yaml

2. Le rollback est mis en œuvre dès la modification du service. Comme tout à l'heure, vérifiez que la bonne version est en cours d'utilisation :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Bravo ! Vous avez découvert les déploiements bleu-vert et appris à déployer des mises à jour d'applications nécessitant un basculement immédiat entre deux versions.

Félicitations !

Notre atelier pratique sur la gestion des déploiements avec Kubernetes se termine ici. Au cours de cet atelier, vous avez eu l'occasion de pratiquer davantage l'outil en ligne de commande kubectl et différents types de configurations de déploiement par fichiers YAML pour assurer le lancement, la mise à jour et le scaling de vos déploiements. Ces exercices fondamentaux vous permettront de mettre en pratique vos compétences dans le cadre de vos propres activités DevOps.

Terminer votre quête

Cet atelier d'auto-formation fait partie des quêtes Qwiklabs Kubernetes in Google Cloud, Kubernetes Solutions, Cloud Engineering, et DevOps Essentials. Une quête est une série d'ateliers associés qui constituent une formation. Si vous terminez cette quête, vous obtenez le badge ci-dessus attestant de votre réussite. Vous pouvez rendre publics les badges que vous recevez et ajouter leur lien dans votre CV en ligne ou sur vos comptes de réseaux sociaux. Inscrivez-vous à cette quête pour obtenir immédiatement les crédits associés à cet atelier si vous l'avez suivi. Découvrez les autres quêtes Qwiklabs disponibles.

Vous recherchez un laboratoire de défis pratique pour démontrer vos compétences Kubernetes et valider vos connaissances? Terminez cet atelier de défi.

Atelier suivant

Continuez votre quête avec ces suggestions:

• Diffusion continue avec Jenkins dans Kubernetes Engine
• Déployer des applications associées à des disques persistants régionaux avec Kubernetes Engine

Étapes suivantes et informations supplémentaires

• Sur le site Web de Google Cloud, découvrez :
• modèles de déploiements avec Kubernetes
• solutions et guides DevOps dans la documentation Google Cloud.
• Sur le site Web de Kubernetes, connectez-vous à la communauté Kubernetes !

Google Cloud Training & Certification

...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.

Dernière mise à jour du manuel : 1 décembre 2022

Dernier test de l'atelier : 1 décembre 2022

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.