Google ACE: Conteneurs, hébergement d'applications et plateformes sans serveur — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Google Cloud offre un éventail de plateformes pour exécuter des conteneurs et des applications, allant du serverless entièrement géré aux clusters Kubernetes configurables. La sélection et l’exploitation de la bonne plateforme nécessitent de comprendre les plans de contrôle, les modèles de mise à l’échelle, les mécanismes de publication, la mise en réseau et la sécurité. Cette section regroupe des recommandations opérationnelles pour Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine et Cloud Functions, ainsi que des patterns pour les secrets, les déploiements sécurisés et les diagnostics.

Kubernetes Engine : Clusters, Workloads et Réseau

Les clusters GKE fournissent un plan de contrôle Kubernetes géré avec des pools de nœuds que vous dimensionnez et sécurisez. Choisissez Autopilot pour une surcharge opérationnelle minimale et des valeurs par défaut optimisées, ou Standard pour un contrôle granulaire des nœuds, du réseau et des modules complémentaires. Utilisez les canaux de publication et la mise à niveau automatique des nœuds pour des mises à niveau prévisibles et sûres ; activez la réparation automatique des nœuds. Préférez Container-Optimized OS pour des nœuds renforcés, sauf si des paquets spécifiques nécessitent Ubuntu.

• Pools de nœuds et ordonnancement

  • Séparez les pools de nœuds par classe de charge de travail (par ex., générale, GPU, spot) et utilisez les taints/tolerations pour diriger les Pods.
  • Activez l’autoscaler de cluster et configurez les min/max par pool. Sachez que les PodDisruptionBudgets et les requêtes de ressources peuvent bloquer la réduction de la taille du cluster (scale-in) ou laisser des Pods en attente si les requêtes dépassent les types de nœuds disponibles.
  • Les nœuds Spot/préemptifs réduisent les coûts mais introduisent un risque d’éviction ; combinez-les avec des budgets de surge pour les Deployments et des contraintes de topologie de Pod pour la résilience.

• Namespaces et multi-location

  • Utilisez les namespaces pour partitionner les quotas, les politiques et le RBAC. Appliquez des NetworkPolicies pour restreindre le trafic est-ouest. Appliquez les standards de sécurité des Pods au niveau du namespace pour éviter les charges de travail privilégiées.

• Workloads

  • Les Deployments gèrent les Pods stateless avec des mises à jour progressives (rolling updates), des budgets de surge/indisponibilité et des restaurations rapides. Utilisez des sondes de préparation (readiness probes) pour contrôler l’envoi de trafic et des sondes de vivacité/démarrage (liveness/startup probes) pour l’autoréparation. Des sondes de préparation mal configurées peuvent provoquer une perte de trafic ; testez avant la mise en production.
  • Les StatefulSets fournissent des identités stables et une mise à l’échelle ordonnée pour les bases de données et les systèmes basés sur un quorum. Utilisez un Service headless et une StorageClass qui prend en charge le provisionnement dynamique ; planifiez la localité zonale des PV.
  • Les DaemonSets ordonnancent un Pod par nœud (par ex., agents de journalisation/surveillance). Ils respectent l’autoscaling et les événements de drainage (drain) et sont idéaux pour la télémétrie à l’échelle du nœud.

• Services et Ingress

  • ClusterIP expose un DNS et un équilibrage de charge intra-cluster. NodePort est principalement destiné au dépannage. LoadBalancer provisionne un équilibreur de charge TCP/UDP externe ou interne Google Cloud ; utilisez l’interne pour les services privés.
  • GKE Ingress configure un équilibrage de charge HTTP(S) mondial avec des certificats gérés, des mappages d’URL et Cloud Armor. Pour une gestion de trafic moderne, préférez l’équilibrage de charge natif aux conteneurs (NEG) pour des vérifications de santé par Pod et une convergence plus rapide. Assurez-vous que les points de terminaison de préparation reflètent la santé réelle de l’application ; sinon, le backend devient défaillant, provoquant des erreurs 502.

• Autoscaling

  • L’Horizontal Pod Autoscaler (HPA) met à l’échelle les réplicas en fonction de métriques comme le CPU ou de métriques personnalisées via Cloud Monitoring ; assurez-vous que le Metrics Server est sain. Le Vertical Pod Autoscaler (VPA) peut ajuster la taille des requêtes ; évitez les conflits avec le HPA en utilisant le VPA en mode « recommandation » pour les workloads gérés par HPA ou utilisez le mode compatible HPA+VPA avec précaution.
  • L’autoscaler de cluster ajoute/supprime des nœuds pour s’adapter aux Pods. Si les Pods demandent plus de ressources qu’aucun type de nœud n’en offre, ils ne seront jamais ordonnancés ; alignez les requêtes/limites avec les types de nœuds des pools.

Exemples courts :

• Restaurer une version défaillante :
  • kubectl rollout undo deployment/web
• Inspecter rapidement un autre contexte :
  • kubectl config use-context CONTEXT && kubectl config view

Gestion des Artefacts, Sécurité de la Chaîne d’Approvisionnement et Publications Sécurisées

Artifact Registry héberge des images de conteneurs par région avec le support des VPC Service Controls. Adoptez des dépôts (ou des préfixes) distincts pour les environnements et imposez des tags immuables ; déployez par digest pour éliminer toute ambiguïté. Intégrez Cloud Build ou votre CI pour construire et pousser les images avec des métadonnées de provenance.

• Gestion des vulnérabilités

  • Activez Artifact Analysis pour analyser les images à la recherche de CVE du système d’exploitation et des langages. Interrompez les builds ou bloquez la promotion en cas de découvertes de haute sévérité. Combinez avec Binary Authorization pour exiger des signatures/attestations (par ex., passage de la politique de vulnérabilité, provenance SLSA) avant l’admission dans GKE.

• Promotion d’images

  • Promouvez en copiant un digest d’image des dépôts de développement vers ceux de pré-production/production ou en ré-étiquetant dans un dépôt de promotion ; évitez le tag mutable « latest ». Automatisez avec des déclencheurs Cloud Build conditionnés par les tests et les résultats d’analyse.

• Secrets et configuration

  • Préférez Secret Manager avec un accès basé sur le principe de moindre privilège. Sur GKE, utilisez le pilote CSI Secret Manager avec Workload Identity pour que les nœuds n’aient jamais accès aux secrets à longue durée de vie. Pour les configurations KRM, séparez les ConfigMap (non-secret) des Secret (sensible) et montez-les en lecture seule.
  • Pour le serverless, montez les secrets via des liaisons directes avec Secret Manager ; évitez d’intégrer des secrets dans les variables d’environnement, sauf si c’est strictement nécessaire.

• Patterns de restauration et de publication

  • Kubernetes : utilisez les mises à jour progressives avec maxUnavailable=0 pour un déploiement sans interruption de service et maxSurge ajusté à la capacité ; faites du canary avec deux Deployments derrière un seul Service ou utilisez un maillage de services (Service mesh) pour des pourcentages progressifs. Protégez les workloads critiques avec des PodDisruptionBudgets et minReadySeconds.
  • Cloud Run et App Engine : utilisez les révisions/versions et la répartition du trafic pour les déploiements canary et blue/green. Gardez les révisions précédentes préchauffées pour réduire la latence de restauration.
  • Modes de défaillance : la dérive des tags modifiables, les lacunes temporelles dans les analyses et les sondes de préparation mal spécifiées sont des causes courantes de pannes. Utilisez des digests d’image, des vérifications de pré-déploiement et des sondes de santé synthétiques.

Plateformes d’applications sans serveur

Cloud Run fournit une puissance de calcul native pour les conteneurs, pilotée par les requêtes, avec une mise à l’échelle automatique jusqu’à zéro et une application de l’identité par requête.

• Services et jobs Cloud Run

  • Les services gèrent le HTTP ; la simultanéité (concurrency) contrôle le nombre de requêtes simultanées par instance (à régler pour optimiser la latence ou l’efficacité). Les jobs gèrent les traitements par lots/cron non-HTTP et peuvent être parallélisés.
  • Les révisions sont des instantanés (snapshots) immuables. La répartition du trafic (traffic splitting) permet des déploiements canary par pourcentage. Définissez un nombre minimal d’instances pour réduire les démarrages à froid (cold starts) ; utilisez l’allocation de CPU au repos si un travail en arrière-plan est nécessaire.
  • Identité : assignez un compte de service dédié par service/révision avec le moindre privilège. Restreignez l’invocation via IAM (rôle Cloud Run Invoker) ou rendez-la publique si nécessaire. Pour l’authentification des utilisateurs finaux, utilisez des jetons IAP signés ou l’authentification intégrée de Cloud Run avec Identity Platform.

• Réseau

  • Utilisez les connecteurs VPC sans serveur (Serverless VPC connectors) pour atteindre les ressources VPC privées. Choisissez l’egress : tout le trafic via le connecteur, ou uniquement les plages privées RFC1918. Soyez conscient des quotas de débit du connecteur ; adaptez la taille du connecteur et alignez sa région avec celle du service. Pour l’Internet sortant avec des ressources ayant uniquement des IP privées, combinez avec Cloud NAT.
  • Private Service Connect peut consommer de manière privée des services producteurs ou exposer des points de terminaison (endpoints) internes. Pour l’ingestion via HTTP(S) externe, utilisez Cloud Load Balancing avec des NEG sans serveur (serverless NEGs).

App Engine propose deux environnements :

• Standard
  • En bac à sable (sandboxed), se met à l’échelle rapidement, prend en charge la mise à l’échelle automatique, de base ou manuelle. La mise à l’échelle automatique avec min_idle_instances fournit une capacité pré-chauffée. Démarrage à froid rapide et modèle de déploiement simple ; personnalisations limitées au niveau de l’OS et un ensemble de runtimes fixe.
• Flexible
  • Exécute Docker sur des VM Compute Engine avec plus de contrôle sur les bibliothèques système et le réseau. Cycle de vie des instances plus lent et coût de base plus élevé ; adapté lorsque des runtimes personnalisés ou des bibliothèques natives sont nécessaires.
• Services et versions
  • Répartissez le trafic par version (aléatoire, par cookie ou par IP). Chaque service peut se mettre à l’échelle indépendamment. Utilisez des déploiements progressifs (gradual rollouts) et conservez une version précédente pour un retour en arrière (rollback) instantané.

Cloud Functions fournit des fonctions mono-usage pilotées par les événements.

• Déclencheurs (Triggers) : Pub/Sub, Cloud Storage, HTTP, Eventarc pour de nombreuses sources. Rendez les gestionnaires (handlers) idempotents ; certains déclencheurs effectuent des nouvelles tentatives en cas d’échec, ce qui entraîne un traitement en double.
• Configuration du runtime : variables d’environnement, liaisons Secret Manager, nombre maximal d’instances, mémoire/CPU. Contrôlez la simultanéité (concurrency) pour les fonctions HTTP afin d’équilibrer la latence et le coût.
• Pièges courants : une simultanéité (concurrency) non limitée ou des effets de bord non idempotents provoquent la duplication de données ; assurez-vous d’avoir des DLQ pour Pub/Sub ; définissez des délais d’attente (timeouts) appropriés.

Sélection de la plateforme, mise en réseau et responsabilité opérationnelle

Sélectionnez une plateforme en fonction du contrôle requis, des caractéristiques de mise à l’échelle, des besoins de portabilité et du budget opérationnel.

• Contrôle vs surcharge de gestion

  • Contrôle maximal : GKE Standard (OS des nœuds, réseau, modules de sécurité complémentaires) avec la surcharge opérationnelle correspondante.
  • Équilibré : GKE Autopilot (pas de gestion des nœuds, sécurité préconfigurée).
  • Surcharge de gestion minimale : Cloud Run, App Engine, Cloud Functions (pas de nœuds, mise à l’échelle gérée), mais limités par les modèles d’exécution et de requêtes.

• Mise à l’échelle et adéquation à la charge de travail

  • Charges de travail avec des pics de requêtes : Cloud Run/App Engine Standard excellent ; Functions pour les gestionnaires événementiels.
  • Réseau stateful ou personnalisé : GKE avec les fonctionnalités StatefulSets et CNI.
  • Portabilité : conteneurs sur GKE/Cloud Run ; les Functions sont moins portables en raison du modèle FaaS.

• Réseau serverless, sortie (egress) et services privés

  • Utilisez des connecteurs VPC pour l’accès privé ; surveillez l’utilisation du connecteur pour éviter la limitation (throttling). Configurez la sortie (egress) sur « all » uniquement lorsque c’est nécessaire ; sinon, limitez-la aux plages privées pour réduire les coûts et les risques.
  • Pour l’entrée (ingress) privée, envisagez l’équilibrage de charge HTTP(S) interne avec des NEG serverless ou Private Service Connect.
  • Pour le contrôle de l’exfiltration de données, associez à VPC Service Controls là où il est pris en charge et restreignez les routes de sortie via le pare-feu et Cloud NAT.

• Diagnostics et responsabilité opérationnelle

  • Standardisez sur Cloud Logging avec des journaux structurés (JSON) et des ID de trace/span à travers les services pour la corrélation. Utilisez les tableaux de bord Cloud Monitoring, les vérifications de disponibilité (uptime checks), les SLO et les politiques d’alerte.
  • Pour GKE : activez Cloud Ops for GKE, collectez les métriques applicatives via Prometheus ou Cloud Monitoring, et utilisez des DaemonSets pour la télémétrie au niveau du nœud.
  • Pour le serverless : tirez parti des journaux de requêtes intégrés, d’Error Reporting, de Trace et de Profiler. Définissez des SLO et des alertes par service sur la latence, le taux d’erreur et la saturation (concurrence, CPU de l’instance).
  • Modèle de responsabilité : définissez qui est responsable des paramètres d’exécution (mise à l’échelle, concurrence), de l’IAM et des pipelines de déploiement. Testez régulièrement les restaurations (rollbacks) et les scénarios de sinistre.

Scénario de problème pratique

Acme Retail prévoit d’exposer une nouvelle API de paiement tout en modernisant ses services internes. Exigences : API publique à faible latence avec des déploiements canary, accès privé à une base de données d’inventaire interne dans un VPC, application de la politique de la chaîne d’approvisionnement, et restauration (rollback) claire avec une surcharge opérationnelle minimale.

1. Choisir Cloud Run pour l’API publique et GKE Autopilot pour le service d’inventaire interne.

• Justification : Cloud Run minimise la surcharge opérationnelle pour le HTTP stateless, prend en charge les révisions et la répartition du trafic ; GKE Autopilot fournit les fonctionnalités de Kubernetes pour les services stateful/internes sans gestion des nœuds.

2. Compiler, analyser et stocker les images dans Artifact Registry avec la provenance.

• Justification : Cloud Build produit des images de conteneurs ; Artifact Analysis recherche les CVE. Le stockage des digests et de la provenance permet à Binary Authorization de garantir que seules les images analysées et signées sont exécutées.

3. Appliquer les politiques d’admission.

• Justification : Activer Binary Authorization sur le cluster GKE pour exiger des signatures et des attestations de politique. Pour Cloud Run, configurer l’automatisation du déploiement pour conditionner la promotion à la validation de la politique de vulnérabilité.

4. Configurer le réseau avec un connecteur VPC Serverless et Cloud NAT.

• Justification : L’API Cloud Run doit atteindre le service d’inventaire et Cloud SQL de manière privée. Un connecteur VPC permet une sortie (egress) privée RFC1918 ; Cloud NAT fournit un accès Internet sortant pour le téléchargement de dépendances sans adresses IP externes sur les ressources privées. Garder le connecteur et les services dans la même région et dimensionner correctement son débit.

5. Sécuriser les identités et les autorisations.

• Justification : Attribuer un compte de service dédié au service Cloud Run avec le moindre privilège (par ex., Client Cloud SQL, autorisations d’invocation (invoke) vers les points de terminaison internes si nécessaire). Pour GKE, utiliser Workload Identity pour que les Pods assument des comptes de service sans informations d’identification au niveau du nœud.

6. Mettre en œuvre un déploiement et une restauration (rollback) sécurisés.

• Justification : Déployer l’API sur une nouvelle révision Cloud Run et répartir 5 % du trafic pour un canary. Surveiller la latence, le taux d’erreur et la saturation ; puis augmenter progressivement jusqu’à 100 % ou effectuer une restauration instantanée en rétablissant le trafic vers la révision précédente. Dans GKE, utiliser les mises à jour progressives (rolling updates) de Deployment avec des sondes de préparation (readiness probes) et un petit déploiement canary derrière le même Service pour valider avant le déploiement complet.

7. Configurer l’observabilité et les SLO.

• Justification : Émettre des journaux JSON structurés avec des ID de trace depuis les deux plateformes vers Cloud Logging. Créer des SLO sur la latence p95 et le taux d’erreurs 5xx ; y attacher des politiques d’alerte. Utiliser Error Reporting et Trace pour l’analyse des causes profondes. Pour GKE, déployer un DaemonSet pour les métriques de nœud et activer Cloud Ops for GKE.

8. Valider les modes de défaillance et la capacité.

• Justification : Effectuer des tests de charge pour vérifier le débit du connecteur VPC, la concurrence de Cloud Run et le comportement du HPA de GKE. Confirmer la précision des sondes de préparation (readiness probes) pour éviter le blackholing (mise en service d’instances non prêtes). Tester les chemins de refus de Binary Authorization et la restauration d’image par digest pour garantir la récupérabilité sous l’application de la politique de la chaîne d’approvisionnement.

Cette approche fournit une API publique sécurisée à faible charge opérationnelle, des services internes contrôlés, un réseau privé, une sécurité de la chaîne d’approvisionnement applicable et une restauration rapide, conformément aux meilleures pratiques opérationnelles de Google Cloud.

← Compute Engine et opérations sur les machines virtuelles · Tous les domaines · Réseautage VPC →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →