Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen CNPE. Lisez de haut en bas ou sautez à une section.
Provisionner et gérer une infrastructure multi-cloud en utilisant des API déclaratives natives de Kubernetes.
Utiliser Crossplane. Installer les CRD des fournisseurs de cloud (par exemple, provider-aws). Définir des abstractions de plateforme avec Composition et CompositeResourceDefinition (XRD).
Pourquoi: Unifie la gestion des applications et de l'infrastructure sous un plan de contrôle unique et un workflow GitOps, en masquant les spécificités du fournisseur aux développeurs.
Gérer le cycle de vie (création, mise à niveau, suppression) de plusieurs clusters Kubernetes à travers différents fournisseurs de manière déclarative.
Implémenter Cluster API (CAPI) avec les fournisseurs d'infrastructure pertinents (par exemple, CAPA pour AWS, CAPZ pour Azure). Définir les clusters comme des ressources Kubernetes dans un cluster de gestion.
Pourquoi: Traite le cycle de vie des clusters comme du code, permettant le GitOps pour les clusters eux-mêmes. Les CAPI MachineHealthChecks offrent une remédiation automatisée des nœuds.
Offrir une forte isolation entre les charges de travail des locataires sur une plateforme Kubernetes partagée.
Combiner des pools de nœuds dédiés (calcul), NetworkPolicies (réseau), RBAC (API), ResourceQuotas (ressource) et Pod Security Standards (sécurité). Envisager les clusters virtuels (vCluster) pour l'isolation du plan de contrôle.
Pourquoi: Une stratégie de défense en profondeur est requise. Aucune fonctionnalité seule n'offre une isolation complète. Chaque couche aborde un aspect différent de la multi-location.
Gérer les configurations et les charges de travail pour un grand nombre de clusters en aval à partir d'un point central.
Désigner un cluster "hub" pour héberger les outils du plan de contrôle de la plateforme (ArgoCD, Flux, Crossplane, moteurs de politique). Les clusters "spoke" exécutent les charges de travail et sont gérés depuis le hub.
Pourquoi: Centralise la gestion, l'application des politiques et l'observabilité, simplifiant les opérations multi-clusters et assurant la cohérence.
Fournir aux équipes de développement des environnements isolés, de type cluster-admin, sans la surcharge des clusters physiques.
Utiliser vCluster. Chaque vCluster exécute un plan de contrôle K8s séparé sous forme de pods au sein d'un namespace de cluster hôte, partageant les nœuds worker hôtes.
Pourquoi: Offre une forte isolation au niveau de l'API à un coût inférieur à celui des clusters complets. Le synchroniseur vCluster matérialise les ressources nécessaires sur le cluster hôte.
Assurer la reprise après sinistre pour les charges de travail avec état (stateful) avec un RPO/RTO faible.
Utiliser un pilote CSI qui prend en charge la réplication de données inter-régions/inter-clusters synchrone ou asynchrone (par exemple, Rook-Ceph, Portworx).
Pourquoi: La réplication est critique pour la disponibilité des données en cas de défaillance régionale. Les instantanés locaux ou les niveaux de performances élevés ne traitent pas la DR inter-sites.
Améliorer la disponibilité des applications en distribuant les répliques sur différents domaines de défaillance.
Utiliser les Pod Topology Spread Constraints dans les spécifications de charge de travail. Définir `topologyKey` (par exemple, `topology.kubernetes.io/zone`) et `whenUnsatisfiable: ScheduleAnyway` ou `DoNotSchedule`.
Pourquoi: Empêche toutes les répliques d'un service d'être planifiées dans une seule zone ou sur un seul nœud, atténuant l'impact des défaillances d'infrastructure localisées.
Gérer les politiques et le RBAC pour les équipes ayant des structures organisationnelles hiérarchiques.
Implémenter le Hierarchical Namespace Controller (HNC). Créer des relations de namespace parent-enfant pour propager le RBAC, les NetworkPolicies et les ResourceQuotas.
Pourquoi: HNC simplifie la gestion en permettant aux administrateurs de plateforme de définir des politiques au niveau de l'équipe/organisation (namespace parent) qui sont automatiquement héritées par tous les sous-namespaces.
Implémenter des stratégies de déploiement avancées et automatisées comme canary ou blue-green avec analyse basée sur les métriques et rollback.
Utiliser Argo Rollouts. Définir une ressource Rollout avec une stratégie (par exemple, canary) qui inclut la configuration de routage du trafic (pour un service mesh) et un AnalysisTemplate faisant référence à un fournisseur de métriques comme Prometheus.
Pourquoi: Découple le déploiement de la logique applicative. Automatise le basculement et l'analyse du trafic, promeut les versions en toute sécurité et les annule automatiquement en cas d'échec, réduisant les risques de déploiement.
Gérer les secrets dans un workflow GitOps sans stocker les identifiants en clair dans Git.
Utiliser Sealed Secrets (chiffre les secrets pour un cluster spécifique) ou External Secrets Operator (synchronise depuis Vault, les gestionnaires de secrets AWS/GCP/Azure). Ne commiter que le secret chiffré ou la ressource de référence dans Git.
Pourquoi: Maintient les données sensibles hors de Git tout en permettant de gérer les secrets de manière déclarative dans le cadre du workflow GitOps, maintenant une source unique de vérité.
Automatiser la création et la gestion des applications ArgoCD pour plusieurs clusters, environnements ou microservices.
Utiliser un ApplicationSet. Définir un modèle pour l'Application et utiliser un générateur (par exemple, cluster, git, matrix) pour créer dynamiquement des Applications basées sur des listes de clusters, des répertoires Git ou d'autres sources.
Pourquoi: Élimine la création manuelle d'Applications, permettant une gestion scalable de centaines d'applications ou de clusters à partir d'une seule définition.
Fournir des environnements de prévisualisation éphémères aux développeurs pour tester les changements dans une pull request.
Utiliser ArgoCD ApplicationSet avec un générateur de Pull Request. Il crée automatiquement une Application lorsqu'une PR est ouverte et la supprime lorsque la PR est fermée/fusionnée.
Pourquoi: Permet aux développeurs de valider les changements dans un environnement live avant de fusionner, améliorant la qualité du code et réduisant les problèmes d'intégration, sans gestion manuelle de l'environnement.
Gérer un ensemble large et complexe d'applications et de composants de plateforme avec ArgoCD de manière structurée.
Implémenter le modèle App-of-Apps. Une Application racine gère d'autres Applications enfants, qui peuvent à leur tour gérer d'autres Applications, créant une structure hiérarchique.
Pourquoi: Fournit un point d'entrée unique pour le démarrage d'un cluster ou d'un environnement tout en permettant une gestion modulaire et basée sur les équipes des ensembles d'applications individuels.
S'assurer que les ressources sont déployées dans le bon ordre (par exemple, les CRD avant les CR, l'infrastructure avant les applications).
Dans ArgoCD, utiliser les Sync Waves et les contrôles de santé des ressources. Dans Flux, utiliser `dependsOn` dans les ressources Kustomization ou HelmRelease.
Pourquoi: Les systèmes déclaratifs appliquent les ressources en parallèle par défaut. Des mécanismes d'ordonnancement explicites sont nécessaires pour gérer les dépendances entre les ressources.
Implémenter un pipeline GitOps complet en utilisant Flux.
Combiner les contrôleurs Flux : Source Controller (pour les sources Git/Helm/OCI), Kustomize Controller (pour appliquer les manifestes) et Helm Controller (pour les HelmReleases). Utiliser Notification Controller pour les alertes.
Pourquoi: Flux est un ensemble composable de contrôleurs spécialisés. Comprendre le rôle de chacun est essentiel pour construire et dépanner la livraison continue basée sur Flux.
S'assurer que l'état du cluster en direct correspond en permanence à l'état désiré dans Git, en annulant toute modification manuelle.
Configurer l'Application ArgoCD avec `syncPolicy.automated.selfHeal: true`. ArgoCD détectera la dérive et synchronisera automatiquement pour annuler les modifications non autorisées.
Pourquoi: L'auto-réparation est un principe fondamental du GitOps qui impose Git comme source unique de vérité et empêche la dérive de configuration, ce qui est essentiel pour la conformité et la stabilité.
Promouvoir les versions d'application à travers les environnements (dev -> staging -> prod) avec des contrôles d'audit et d'approbation appropriés.
Utiliser des répertoires ou des branches distincts par environnement dans Git. Promouvoir les changements en créant des pull requests (par exemple, de la branche/répertoire staging à prod). Appliquer des revues de PR.
Pourquoi: Exploite Git pour les pistes d'audit et les approbations. Le processus de PR devient la porte de promotion formelle, garantissant que les changements sont examinés avant d'atteindre la production.
Implémenter la multi-location dans une instance ArgoCD partagée, en limitant les équipes à leurs propres ressources.
Créer des projets ArgoCD pour chaque équipe. Configurer les projets pour restreindre les dépôts Git source, les clusters/namespaces de destination et les types de ressources autorisés. Intégrer avec le SSO et mapper les groupes aux rôles de projet.
Pourquoi: Les projets sont le mécanisme principal d'isolation multi-locataire et de RBAC dans ArgoCD, permettant un déploiement d'applications en libre-service sécurisé.
Concevoir une API libre-service pour que les développeurs puissent provisionner l'infrastructure sans avoir besoin de connaissances spécifiques au cloud.
Définir une API de haut niveau avec une CompositeResourceDefinition (XRD). Implémenter l'API avec une Composition qui mappe les champs de haut niveau aux ressources gérées sous-jacentes. Les développeurs interagissent avec une simple Composite Resource Claim (XRC).
Pourquoi: Ce modèle à trois couches (Claim -> Composition -> Managed Resource) sépare l'API orientée utilisateur de l'implémentation, offrant une abstraction claire et permettant la gouvernance de la plateforme.
Permettre aux développeurs de démarrer de nouveaux projets, microservices ou infrastructures de manière déclarative et conforme aux normes organisationnelles.
Créer des Backstage Software Templates. Le template définit des paramètres d'entrée (une interface utilisateur de formulaire) et une série d'actions de scaffolder (par exemple, récupérer le squelette, créer un dépôt Git, enregistrer dans le catalogue).
Pourquoi: Automatise les workflows "golden path", réduisant la charge cognitive des développeurs, assurant la cohérence et accélérant la configuration des projets de quelques minutes à quelques secondes.
Créer un point unique et centralisé pour découvrir tous les logiciels, services, API et leur propriété au sein d'une organisation.
Implémenter le Backstage Software Catalog. Ingérer les descripteurs d'entité `catalog-info.yaml` des dépôts Git pour construire un graphe consultable des composants logiciels et de leurs relations.
Pourquoi: Le catalogue est le cœur d'une IDP, offrant une découvrabilité et une base pour d'autres fonctionnalités comme TechDocs, les docs API et la visibilité de l'état CI/CD.
Un opérateur Kubernetes doit nettoyer les ressources externes (par exemple, stockage cloud, enregistrements DNS) lorsqu'une ressource personnalisée est supprimée.
Utiliser les finalizers. Dans le contrôleur, ajouter un finalizer à la CR lors de la création. Dans la boucle de réconciliation, si `deletionTimestamp` est défini, exécuter la logique de nettoyage puis supprimer le finalizer.
Pourquoi: Les finalizers empêchent Kubernetes de supprimer une ressource tant que le contrôleur n'a pas terminé ses tâches de nettoyage, évitant ainsi les ressources externes orphelines.
Fournir aux charges de travail Kubernetes un accès sécurisé et de courte durée aux API des fournisseurs de cloud sans gérer les identifiants statiques.
Utiliser les solutions Workload Identity des fournisseurs de cloud (AWS IRSA, GCP Workload Identity, Azure Workload Identity). Cela lie un ServiceAccount Kubernetes à un rôle IAM cloud, permettant aux pods d'obtenir des identifiants temporaires.
Pourquoi: Élimine le risque d'identifiants statiques de longue durée. C'est le modèle le plus sécurisé pour accorder des permissions cloud aux pods.
Communiquer l'état et la progression de la réconciliation d'une ressource personnalisée aux utilisateurs et aux outils d'automatisation.
Activer la sous-ressource de statut dans la définition du CRD. Le contrôleur doit mettre à jour le statut avec des conditions (par exemple, `Type: Ready`, `Status: True`) et l'état observé.
Pourquoi: Sépare l'état désiré (spec) de l'état observé (status). Fournit un mécanisme standard et observable permettant aux clients de comprendre la santé et la préparation des ressources.
Faire évoluer les API de plateforme (CRD) sans casser les clients ou utilisateurs existants.
Suivre les conventions de versioning des API Kubernetes (v1alpha1 -> v1beta1 -> v1). Lors de l'introduction de changements majeurs, créer une nouvelle version et implémenter un webhook de conversion pour traduire entre les versions stockées et servies.
Pourquoi: Les webhooks de conversion permettent au serveur API de servir plusieurs versions d'une ressource simultanément tout en maintenant une version de stockage unique, permettant une évolution gracieuse de l'API.
Créer des alertes exploitables basées sur des objectifs de fiabilité de service qui équilibrent la sensibilité et l'évitement de la fatigue d'alerte.
Définir des SLO et calculer des budgets d'erreur. Implémenter une alerte multi-fenêtre, multi-taux de consommation qui se déclenche lorsque le taux de consommation du budget d'erreur menace le SLO.
Pourquoi: L'alerte sur l'épuisement du budget d'erreur est plus significative que les simples alertes de seuil. Elle lie directement les alertes à l'impact utilisateur et aux violations de SLO.
Implémenter un pipeline unifié et indépendant du fournisseur pour la collecte, le traitement et l'exportation des signaux d'observabilité (traces, métriques, logs).
Déployer l'OpenTelemetry Collector. Configurer des pipelines avec des récepteurs (par exemple, OTLP, Jaeger), des processeurs (par exemple, batch, attributes) et des exportateurs (par exemple, Prometheus, Loki, Tempo, backends fournisseurs).
Pourquoi: Découple l'instrumentation du backend d'observabilité, permettant à la plateforme de changer ou d'ajouter des backends sans ré-instrumenter les applications. Fournit un point central pour le traitement et l'enrichissement.
Configurer Prometheus de manière déclarative pour découvrir et collecter des métriques à partir des charges de travail Kubernetes.
Utiliser l'opérateur Prometheus. Créer des ressources personnalisées `ServiceMonitor` ou `PodMonitor` qui utilisent des sélecteurs d'étiquettes pour définir quels services ou pods Prometheus doit collecter.
Pourquoi: Offre un moyen natif de Kubernetes de gérer les configurations de collecte, s'intégrant parfaitement aux déploiements d'applications et aux workflows GitOps.
Lors d'une enquête d'incident, naviguer rapidement d'une métrique anormale (par exemple, un pic de latence) aux requêtes spécifiques qui l'ont causée.
Utiliser les exemplars Prometheus. Instrumenter les applications pour attacher des identifiants de trace aux observations de métriques. Configurer Prometheus et Grafana pour afficher les exemplars, fournissant des liens directs des métriques aux traces dans un backend de traçage comme Tempo ou Jaeger.
Pourquoi: Réduit drastiquement le MTTR en liant directement le "quoi" (métrique) au "pourquoi" (trace), éliminant les efforts de corrélation manuelle.
Établir une base pour la surveillance de la santé de tout service critique ou orienté utilisateur.
Surveiller les quatre "Signaux d'Or" : Latence (temps de réponse), Trafic (requêtes par seconde), Erreurs (taux de requêtes échouées) et Saturation (utilisation des ressources).
Pourquoi: Ces quatre signaux offrent une vue complète et de haut niveau de la santé du service et de l'expérience utilisateur, applicable à presque tout type de service.
Offrir aux équipes une visibilité sur le coût de leurs charges de travail Kubernetes pour la refacturation ou la répartition des coûts.
Déployer un outil open-source comme OpenCost ou Kubecost. Ces outils allouent les coûts cloud aux ressources Kubernetes (pods, namespaces, labels) en fonction de leurs requêtes et de leur utilisation de ressources.
Pourquoi: Traduit les factures d'infrastructure en données de coûts significatives et centrées sur l'application, permettant aux équipes de comprendre et d'optimiser leur consommation de ressources.
Réduire le bruit des alertes lors de pannes à grande échelle en supprimant les alertes symptomatiques.
Configurer les `inhibit_rules` dans Alertmanager. Par exemple, inhiber toutes les alertes pour un cluster spécifique si une alerte "ClusterUnreachable" est déjà déclenchée.
Pourquoi: Prévient une "tempête d'alertes" en désactivant les alertes de priorité inférieure qui sont des symptômes d'une alerte de priorité supérieure, de cause profonde, permettant aux équipes d'astreinte de se concentrer sur le vrai problème.
Tester de manière proactive la résilience de la plateforme et des applications en injectant des défaillances de manière contrôlée.
Utiliser un outil d'ingénierie du chaos comme Chaos Mesh ou Litmus. Définir des expériences avec un rayon d'action limité (par exemple, des namespaces ou des étiquettes spécifiques) et des conditions d'arrêt automatisées basées sur les SLO ou les métriques critiques.
Pourquoi: Passe d'une réponse réactive aux incidents à la recherche proactive des faiblesses du système avant qu'elles ne provoquent des pannes de production.
Choisir un moteur de politique pour appliquer des garde-fous sur une plateforme Kubernetes.
Choisir Kyverno pour les politiques natives de Kubernetes basées sur YAML ou OPA/Gatekeeper pour un langage de politique plus puissant et à usage général (Rego).
Pourquoi: Kyverno présente une barrière à l'entrée plus faible pour les ingénieurs Kubernetes. OPA/Gatekeeper est plus flexible et peut être utilisé en dehors de Kubernetes mais a une courbe d'apprentissage plus raide.
Implémenter des politiques de plateforme qui peuvent bloquer les ressources non conformes, ajouter des valeurs par défaut ou créer automatiquement des ressources associées.
Utiliser un moteur de politique comme Kyverno. Utiliser des règles `validate` pour bloquer/auditer, des règles `mutate` pour ajouter des valeurs par défaut (par exemple, securityContext, labels) et des règles `generate` pour créer des ressources (par exemple, NetworkPolicy par défaut).
Pourquoi: Différents types de politiques servent différents objectifs. Les combiner permet une stratégie de gouvernance robuste et multi-facettes qui à la fois impose et aide les utilisateurs à se conformer.
Appliquer un renforcement de sécurité de base pour tous les pods s'exécutant sur la plateforme.
Utiliser les Pod Security Standards (PSS) via le contrôleur d'admission Pod Security intégré. Étiqueter les namespaces avec `pod-security.kubernetes.io/enforce=baseline` ou `restricted`.
Pourquoi: PSS fournit un mécanisme standardisé et intégré pour prévenir les problèmes de sécurité courants comme l'escalade de privilèges et l'accès au namespace de l'hôte, formant une couche de sécurité fondamentale.
S'assurer que seules les images de conteneurs fiables, construites par le pipeline CI/CD officiel, peuvent être déployées sur le cluster.
Implémenter la signature d'images en CI en utilisant Sigstore/Cosign. Utiliser un moteur de politique (Kyverno, Gatekeeper) comme contrôleur d'admission pour vérifier les signatures d'images par rapport à une clé de confiance avant d'autoriser la création d'un pod.
Pourquoi: La vérification cryptographique fournit de solides garanties concernant la provenance et l'intégrité des images, empêchant le déploiement d'images altérées ou non autorisées.
Implémenter un modèle de sécurité "zero-trust" où la communication de service à service est authentifiée par une identité de charge de travail cryptographique, et non par la localisation réseau.
Utiliser SPIFFE/SPIRE pour émettre des identités cryptographiques de courte durée et rotatives (SVIDs) aux charges de travail. Imposer le mTLS (mutual TLS) en utilisant un service mesh, qui valide les SVIDs à chaque requête.
Pourquoi: Déplace la sécurité des contrôles de périmètre réseau vers une identité centrée sur la charge de travail, offrant une authentification forte même pour le trafic interne et limitant le rayon d'impact d'un nœud ou d'un pod compromis.
Isoler les charges de travail au niveau du réseau, en appliquant une posture de "refus par défaut" et en n'autorisant que les chemins de communication requis.
Implémenter les NetworkPolicies de Kubernetes. Appliquer une politique de refus par défaut à chaque namespace, puis ajouter des politiques d'ingress/egress spécifiques qui autorisent le trafic basé sur les étiquettes de pod/namespace.
Pourquoi: Réduit la surface d'attaque par mouvement latéral. La compromission d'un pod n'accorde pas automatiquement l'accès réseau à tous les autres services du cluster.
Créer une piste d'audit complète et inviolable de toutes les actions effectuées sur le serveur API Kubernetes pour la sécurité et la conformité.
Activer la journalisation d'audit Kubernetes sur le serveur API. Configurer une politique d'audit pour enregistrer les événements pertinents (par exemple, toutes les requêtes d'écriture). Envoyer les journaux d'audit vers un backend de stockage sécurisé et immuable ou un SIEM.
Pourquoi: Les journaux d'audit sont essentiels pour l'enquête sur les incidents, les rapports de conformité (par exemple, PCI-DSS, SOC2) et la détection d'activités API anormales.