Architecte Kubernetes

Un cluster Kubernetes ne se résume pas à kubectl apply. Entre une plateforme qui tient la charge, les pannes, les audits de sécurité et la facture, et un assemblage fragile qui dérive en six mois, il y a une décision d'architecture. C'est le rôle de l'architecte Kubernetes : concevoir un cluster aligné sur vos contraintes métier, réglementaires et budgétaires, le construire en Infrastructure as Code, et le maintenir en production. Voici comment nous procédons, ce que vous recevez, et ce que cela coûte réellement.

Qu'est-ce qu'un architecte Kubernetes ?

Un architecte Kubernetes conçoit, dimensionne et fait évoluer l'architecture d'un ou plusieurs clusters Kubernetes en production. Il ne se limite pas à déployer des manifestes : il arbitre les choix structurants (managé ou auto-hébergé, mono ou multi-cluster, modèle réseau (CNI), stratégie d'identité (RBAC), socle de sécurité, plan de reprise, modèle de coûts) et les traduit en une plateforme cohérente, documentée et exploitable par vos équipes.

Concrètement, son périmètre couvre cinq dimensions qui doivent tenir ensemble :

• La conception du cluster : topologie du control plane et des worker nodes, choix de la distribution (AKS, EKS, GKE, ou auto-géré comme RKE2/k3s/OpenShift), modèle réseau et stockage.
• La sécurité by design : RBAC au moindre privilège, Pod Security Standards, Network Policies, gestion des secrets, supply chain, intégrés dès la conception, pas ajoutés après coup.
• La résilience : haute disponibilité multi-zones, sauvegarde, plan de reprise avec objectifs RTO/RPO testés.
• Le coût : dimensionnement des nodes, autoscaling, arbitrage Spot/réservations, visibilité FinOps par namespace.
• L'exploitation (jour 2) : upgrades de version, patching, gestion de l'etcd, observabilité, GitOps, la vie réelle du cluster après la mise en production.

L'architecte Kubernetes répond à une question que l'ingénieur DevOps ne pose pas toujours : « cette plateforme tiendra-t-elle dans trois ans, à dix fois la charge, sous contrainte d'audit, sans coûter une fortune ni enfermer l'entreprise ? » C'est une fonction de conception et d'arbitrage, pas seulement d'exécution.

Cette mission s'inscrit dans une logique plus large d'architecte Azure (intégration AKS) et d'architecte AWS (EKS) : un cluster ne vit jamais seul, il s'appuie sur une landing zone cloud, un réseau, des identités et une facturation qui font partie intégrante de l'architecture.

Architecte, administrateur ou ingénieur DevOps : qui fait quoi ?

La confusion entre ces trois rôles fausse beaucoup de recrutements et d'appels d'offres. Ils sont complémentaires, pas interchangeables.

| Rôle | Question centrale | Horizon | Livrables typiques | |---|---|---|---| | Architecte Kubernetes | Quelle plateforme concevoir, et pourquoi ? | Stratégique (mois/années) | Dossier d'architecture, IaC, standards, choix managé/auto-hébergé, modèle de coûts | | Administrateur / SRE Kubernetes | Comment opérer et maintenir le cluster ? | Opérationnel (jour le jour) | Upgrades, sauvegardes, gestion des incidents, tuning | | Ingénieur DevOps | Comment livrer vite et sûrement les applis ? | CI/CD, chaîne de livraison | Pipelines, GitOps, automatisation des déploiements |

L'architecte définit le cadre ; l'administrateur le maintient ; l'ingénieur DevOps y livre les applications. Dans une PME ou une ETI, ces trois casquettes sont parfois portées par la même personne, ce qui crée précisément le besoin d'un regard d'architecte externe pour poser les fondations avant que la dette technique ne s'installe. Notre rôle de consultant Kubernetes recoupe ces dimensions selon le besoin.

L'architecture de Kubernetes : control plane et data plane

Pour concevoir une plateforme, il faut d'abord en comprendre l'anatomie. Une architecture Kubernetes se divise en deux ensembles : le control plane (le cerveau, qui décide) et les worker nodes (les muscles, qui exécutent). Le control plane maintient l'état désiré du cluster ; les nodes font tourner vos conteneurs. Cette séparation est le socle de toute décision d'architecture.

Définition courte. L'architecture Kubernetes = un control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) qui pilote, et un ensemble de worker nodes (kubelet, kube-proxy, container runtime) qui exécutent les pods. Le control plane réconcilie en continu l'état réel vers l'état désiré décrit dans etcd.

Schéma d'architecture commenté

Voici la topologie de référence d'un cluster Kubernetes, du plan de contrôle aux charges de travail :

                          ┌──────────────────────── CONTROL PLANE ────────────────────────┐
   kubectl / CI / GitOps  │                                                                │
   ─────────────────────► │   kube-apiserver ──► etcd (état du cluster, clé/valeur)        │
        (API REST)        │        │                                                       │
                          │        ├──► kube-scheduler        (place les pods sur un node) │
                          │        ├──► kube-controller-mgr   (réconcilie l'état désiré)   │
                          │        └──► cloud-controller-mgr  (intègre le cloud : LB, vol.)│
                          └───────────────────────────────┬────────────────────────────────┘
                                                          │ (API)
        ┌──────────── WORKER NODE 1 ────────────┐   ┌──────────── WORKER NODE 2 ──────────┐
        │ kubelet (pilote les pods)             │   │ kubelet                             │
        │ kube-proxy (règles réseau Services)   │   │ kube-proxy                          │
        │ container runtime (containerd/CRI-O)  │   │ container runtime                   │
        │  ┌─────Pod─────┐  ┌─────Pod─────┐      │   │  ┌─────Pod─────┐  ┌─────Pod─────┐    │
        │  │ conteneur(s)│  │ conteneur(s)│      │   │  │ conteneur(s)│  │ conteneur(s)│    │
        │  └─────────────┘  └─────────────┘      │   │  └─────────────┘  └─────────────┘    │
        └───────────────────────────────────────┘   └─────────────────────────────────────┘
                         ▲                                          ▲
                         └──────────── CNI (réseau pods) ───────────┘
                              Services · Ingress · Network Policies · CoreDNS

Tout passe par le kube-apiserver : c'est l'unique porte d'entrée du cluster. Une commande kubectl, un pipeline CI, un agent GitOps, tous écrivent l'état désiré dans etcd via l'API. Les contrôleurs et le scheduler observent cet état et agissent. Cette centralisation explique pourquoi la sécurisation de l'API server et la sauvegarde d'etcd sont des décisions d'architecture critiques.

Le control plane en détail

Le control plane regroupe les composants qui prennent les décisions. Sur un cluster managé (AKS, EKS, GKE), le fournisseur l'opère et le maintient pour vous ; sur un cluster auto-hébergé, il est entièrement sous votre responsabilité, ce qui change radicalement l'effort d'exploitation.

• kube-apiserver : le point d'entrée unique de l'API Kubernetes. Il valide et traite chaque requête REST, applique l'authentification, l'autorisation (RBAC) et l'admission control. Tout le reste communique à travers lui. C'est le composant à sécuriser et à rendre hautement disponible en priorité.
• etcd : la base de données clé/valeur distribuée qui stocke l'intégralité de l'état du cluster (objets, configuration, secrets). C'est la source de vérité. Sa perte sans sauvegarde équivaut à la perte du cluster. Sa sauvegarde et son chiffrement sont non négociables sur un cluster auto-hébergé.
• kube-scheduler : il décide sur quel node placer chaque nouveau pod, en fonction des requests de ressources, des contraintes d'affinity/anti-affinity, des taints/tolerations et de l'état des nodes.
• kube-controller-manager : il exécute les boucles de contrôle qui réconcilient l'état réel vers l'état désiré (contrôleur de Deployments, de nodes, de ServiceAccounts, etc.). C'est le moteur de l'« auto-réparation » de Kubernetes.
• cloud-controller-manager : il fait le lien avec le fournisseur cloud sous-jacent : provisionnement des LoadBalancers, des volumes persistants, gestion du cycle de vie des nodes. C'est lui qui rend Kubernetes « cloud-aware ».

Les worker nodes en détail

Les worker nodes exécutent vos charges de travail. Chaque node embarque trois composants essentiels :

• kubelet : l'agent qui tourne sur chaque node. Il reçoit les spécifications de pods de l'API server et s'assure que les conteneurs correspondants tournent et sont en bonne santé (exécution des probes).
• kube-proxy : il maintient les règles réseau sur le node pour router le trafic vers les pods d'un Service. Selon la configuration, il opère en mode iptables, IPVS, ou est remplacé par eBPF (Cilium).
• container runtime : le moteur qui exécute réellement les conteneurs. Depuis l'abandon de dockershim, les runtimes standard via l'interface CRI sont containerd et CRI-O (Docker n'est plus utilisé directement comme runtime, même si les images au format OCI restent les mêmes).

Le dimensionnement des nodes (taille, nombre, pools dédiés), leur répartition multi-zones et leur taux de remplissage (bin packing) sont parmi les leviers d'architecture les plus déterminants pour la résilience et le coût.

Les objets Kubernetes : pods, déploiements et compagnie

Concevoir une plateforme, c'est aussi choisir le bon type d'objet pour chaque charge. Les confondre crée des bugs subtils en production.

• Pod : la plus petite unité déployable. Un ou plusieurs conteneurs partageant réseau et stockage. On ne déploie presque jamais un pod « nu » : on le pilote via un contrôleur de plus haut niveau.
• ReplicaSet : garantit qu'un nombre donné de répliques d'un pod tourne en permanence. Géré implicitement par les Deployments.
• Deployment : le contrôleur de référence pour les applications sans état (stateless). Il gère les ReplicaSets, les déploiements progressifs (RollingUpdate) et les rollbacks. C'est l'objet le plus courant.
• StatefulSet : pour les applications avec état (bases de données, files de messages) nécessitant une identité réseau stable, un ordre de démarrage et des volumes persistants attachés à chaque réplique.
• DaemonSet : garantit qu'un pod tourne sur chaque node (ou un sous-ensemble). Idéal pour les agents transverses : collecte de logs, monitoring, CNI, sécurité.
• Job / CronJob : pour les traitements ponctuels (Job) ou planifiés (CronJob), batchs, migrations, tâches récurrentes, qui s'exécutent puis se terminent.

Erreur fréquente que nous corrigeons en conception : faire tourner une base de données dans un Deployment plutôt qu'un StatefulSet, ou un batch dans un Deployment qui redémarre en boucle. Le bon objet pour la bonne charge évite des incidents difficiles à diagnostiquer.

Un extrait de Deployment durci, tel que nous le standardisons, illustre les bonnes pratiques minimales :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 3
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: api
          image: registry.exemple.fr/api:1.4.2   # tag immuable, jamais "latest"
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { memory: "512Mi" }
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }

Le réseau Kubernetes : CNI, Services, Ingress, Gateway API

Le réseau est l'un des domaines où une mauvaise architecture coûte le plus cher à corriger après coup. Quatre couches structurent la connectivité d'un cluster.

• CNI (Container Network Interface) : le plugin qui attribue une IP à chaque pod et gère le routage. Les choix de référence sont Calico, Cilium (souvent basé sur eBPF pour la performance et l'observabilité) et Flannel. Sur AKS, on arbitre entre Azure CNI (Overlay ou Pod Subnet) et l'option Cilium ; sur EKS, le VPC CNI d'AWS attribue des IP du VPC aux pods. Ce choix conditionne la scalabilité réseau et l'intégration au réseau d'entreprise.
• Service : une abstraction stable (IP virtuelle + nom DNS) devant un groupe de pods éphémères. Types : ClusterIP (interne), NodePort, LoadBalancer (exposition externe via le cloud).
• Ingress / Gateway API : pour exposer du HTTP(S) avec routage par hôte/chemin et terminaison TLS. L'Ingress historique (via un contrôleur type ingress-nginx) cède progressivement la place à la Gateway API, plus expressive et désormais standard pour le routage L4/L7, la séparation des rôles et le multi-tenant.
• Network Policies : le pare-feu interne du cluster. Par défaut, tout pod peut joindre tout autre pod (réseau « plat »). Une architecture sérieuse applique un socle deny-by-default et n'autorise que les flux nécessaires, namespace par namespace.

À cela s'ajoute CoreDNS, le serveur DNS interne qui résout les noms de Services en IP au sein du cluster. Une configuration CoreDNS mal dimensionnée est une cause fréquente de latences applicatives mystérieuses.

Sécurité du cluster : RBAC, Pod Security, secrets, supply chain

La sécurité ne s'ajoute pas, elle se conçoit. Un architecte Kubernetes intègre cinq lignes de défense dès la conception, un sujet que nous traitons en profondeur dans notre offre dédiée à la sécurisation de l'infrastructure cloud et la sécurité Kubernetes.

• RBAC (contrôle d'accès basé sur les rôles) : le principe du moindre privilège. Chaque identité (utilisateur, ServiceAccount) ne reçoit que les droits strictement nécessaires. On bannit les wildcards (verbs: ["*"]) et les liaisons cluster-admin sur des comptes applicatifs. Sur AKS, on intègre Microsoft Entra ID ; sur EKS, IAM Identity Center et IRSA (IAM Roles for Service Accounts).
• Pod Security Standards (PSS) : trois profils (privileged, baseline, restricted) appliqués via le Pod Security Admission. On vise le profil restricted sur les namespaces applicatifs : pas de conteneur root, pas de privilège, readOnlyRootFilesystem, capabilities Linux supprimées.
• Admission control / policy-as-code : OPA Gatekeeper ou Kyverno bloquent à l'admission tout manifeste non conforme (image non signée, requests absentes, conteneur privilégié). La règle ne repose plus sur la discipline humaine mais sur une politique versionnée. Sur AKS, Azure Policy for Kubernetes s'appuie sur Gatekeeper.
• Secrets et chiffrement : un secret Kubernetes natif est encodé en base64, ce qui n'est pas du chiffrement. On active le chiffrement at rest de l'etcd (via KMS) et/ou on externalise vers un coffre : Azure Key Vault (CSI driver), AWS Secrets Manager, HashiCorp Vault avec l'External Secrets Operator. Le TLS/mTLS sécurise les communications inter-services (souvent via un service mesh : Istio, Linkerd).
• Supply chain : scan de vulnérabilités des images (Trivy, Grype), génération d'un SBOM (Syft), signature des images (Cosign) vérifiée à l'admission, registres privés, images minimales (distroless), tags immuables.

La majorité des incidents de sécurité que nous analysons sur des clusters managés ne viennent pas du fournisseur, mais de la colonne « client » du modèle de responsabilité partagée : RBAC trop large, absence de Network Policies, secrets en clair. Le fournisseur sécurise le cluster ; vous restez responsable de ce qui tourne dedans.

Observabilité : métriques, logs, traces et probes

Un cluster qu'on n'observe pas ne peut être ni exploité dans la durée, ni défendu en incident. L'architecture d'observabilité repose sur trois piliers et un socle de santé applicative.

• Métriques : Prometheus collecte les métriques (cluster, nodes, pods, applications), Grafana les visualise. Le Metrics Server fournit les métriques de base nécessaires à l'autoscaling (HPA). L'alerting (Alertmanager) déclenche les notifications sur seuils.
• Logs : agrégation centralisée via Loki ou la stack ELK (Elasticsearch, Logstash, Kibana), avec une rétention conforme à vos obligations.
• Traces : le tracing distribué (OpenTelemetry, Jaeger, Tempo) suit une requête à travers les microservices, indispensable pour diagnostiquer la latence en architecture distribuée.
• Probes de santé : livenessProbe (le conteneur est-il vivant ? sinon, redémarrage), readinessProbe (peut-il recevoir du trafic ?), startupProbe (gère les démarrages lents). Une livenessProbe mal réglée provoque des redémarrages en boucle ; une readinessProbe absente envoie du trafic vers des pods non prêts.

Sur AKS, Azure Monitor / Managed Prometheus et Container Insights s'intègrent nativement ; sur EKS, CloudWatch Container Insights et Amazon Managed Service for Prometheus font le même travail. Les prestataires de notre réseau conçoivent l'observabilité comme un livrable à part entière, pas comme un ajout de dernière minute.

Add-ons, GitOps et écosystème CNCF

Un cluster « nu » n'est pas une plateforme. L'architecture définit le socle d'add-ons à déployer de façon cohérente et reproductible :

• Metrics Server (socle de l'autoscaling), Kubernetes Dashboard (visualisation, à sécuriser strictement).
• Helm : le gestionnaire de paquets de référence. Les Helm charts packagent et versionnent les déploiements complexes de manière paramétrable.
• GitOps avec ArgoCD ou FluxCD : l'état désiré du cluster est décrit dans Git, source de vérité unique. Un agent réconcilie en continu le cluster vers cet état et détecte toute dérive (drift). Le déploiement n'est plus un kubectl apply manuel mais un merge validé et tracé. C'est un pilier de notre approche infrastructure & DevOps.

L'écosystème CNCF (Cloud Native Computing Foundation) fournit la majorité de ces briques (Prometheus, Cilium, ArgoCD, Helm…). Une bonne architecture en sélectionne un sous-ensemble maîtrisé plutôt que d'empiler des outils : chaque add-on est aussi une surface à patcher et à sécuriser.

Bonnes pratiques d'architecture d'un cluster

Au-delà des composants, quelques décisions structurantes séparent une plateforme saine d'un château de cartes.

• Namespaces : isoler les environnements et les équipes (dev/staging/prod, par produit), avec des ResourceQuotas et LimitRanges pour borner la consommation.
• requests / limits : déclarer les ressources de chaque conteneur. Des requests justes (mesurées sur l'usage P95/P99 réel) sont la clé d'un cluster à la fois stable et économe. Trop hautes : gaspillage. Trop basses : évictions et throttling CPU.
• Autoscaling à trois étages : le HPA (Horizontal Pod Autoscaler) ajuste le nombre de répliques selon la charge ; le VPA (Vertical Pod Autoscaler) recommande/ajuste les requests ; le Cluster Autoscaler (ou Karpenter sur EKS) ajoute/retire des nodes selon la demande.
• affinity / tolerations : placer les pods intelligemment : répliques réparties sur des nodes et zones distincts (anti-affinity, topologySpreadConstraints), workloads dédiés sur des pools de nodes spécifiques (taints/tolerations).
• Health checks et PDB : probes justes + Pod Disruption Budgets pour protéger les services critiques pendant les opérations de maintenance (drain, upgrade).

Ces standards, nous les livrons sous forme de policies versionnées (Kyverno) et de modèles IaC, pour qu'ils s'appliquent automatiquement et non par discipline.

Haute disponibilité, résilience et tolérance aux pannes

La résilience est une décision d'architecture, pas une option qu'on coche. Elle se conçoit à plusieurs niveaux.

• Control plane HA : sur un cluster managé, le fournisseur assure la redondance du control plane (souvent avec un SLA, payant sur certaines offres). Sur un cluster auto-hébergé, il faut au minimum 3 nœuds de control plane (etcd en quorum impair) répartis sur plusieurs zones.
• Multi-AZ : répartir les worker nodes et les répliques applicatives sur plusieurs zones de disponibilité d'une même région. La perte d'une zone ne doit pas mettre le service à terre. C'est le socle minimal de toute architecture de production sérieuse.
• Multi-cluster / multi-région : pour les exigences les plus fortes (DORA, continuité critique), on conçoit plusieurs clusters actifs/passifs ou actifs/actifs, avec réplication des données et bascule de trafic. Cela augmente le coût et la complexité, d'où l'importance d'arbitrer selon le besoin réel.
• Sauvegarde et reprise : sauvegarde de l'etcd (auto-hébergé) et des ressources/volumes applicatifs (Velero), avec des objectifs RTO/RPO documentés et testés. Un backup jamais restauré n'est pas un backup.

Ce volet rejoint directement nos travaux sur l'infrastructure cloud instable et la continuité d'activité (PRA/PCA).

Managé ou auto-hébergé : l'incidence sur l'architecture

Le choix entre un Kubernetes managé (AKS, EKS, GKE) et un cluster auto-hébergé (RKE2, k3s, OpenShift…) n'est pas qu'une décision d'achat : il change la topologie à concevoir. En managé, le fournisseur opère le control plane (etcd, apiserver, upgrades) et l'architecte se concentre sur les node pools, le réseau, les identités et les charges. En auto-hébergé, le control plane redevient un objet d'architecture à part entière : au moins 3 nœuds etcd en quorum répartis sur plusieurs zones, plan d'upgrade et de patching du plan de contrôle, sauvegarde et restauration d'etcd. La portabilité reste maximale (on-premise, multi-cloud), au prix d'un effort d'exploitation nettement supérieur.

Du point de vue de la conception, l'impact se résume à trois points techniques :

• Périmètre de responsabilité : en managé, le control plane sort de votre surface à patcher et à durcir ; en auto-hébergé, il s'y ajoute (CVE du control plane, défragmentation etcd, rotation des certificats).
• Réseau et intégration cloud : le cloud-controller-manager du fournisseur provisionne LoadBalancers et volumes en managé ; en auto-hébergé, ces intégrations sont à concevoir et à maintenir.
• Réversibilité technique : un cluster managé piloté en IaC propre reste portable ; l'auto-hébergé l'est par construction.

L'arbitrage make-or-buy lui-même (managé vs auto-géré, choix de distribution, maturité de l'équipe requise, TCO de l'exploitation) relève du conseil et non de la seule architecture. Il est traité en profondeur par notre consultant Kubernetes, dans la section « L'arbitrage make-or-buy : managé, vanilla, ou renoncer à Kubernetes ». Pour la dimension plateforme cloud, voyez aussi consultant Azure pour entreprise et consultant AWS pour entreprise.

Notre position d'indépendant : nous ne vendons aucune plateforme. Côté architecture, les prestataires de notre réseau conçoivent aussi bien un AKS/EKS managé qu'un cluster auto-hébergé, le choix dépend de vos contraintes, pas de notre catalogue.

Infrastructure as Code : Terraform, Bicep, Helm, manifests

Une architecture Kubernetes qui n'est pas en code n'est pas reproductible, et n'est pas réversible. Les prestataires de notre réseau construisent tout en Infrastructure as Code, à plusieurs niveaux :

• Le provisionnement du cluster et de la landing zone : Terraform (multi-cloud) ou Bicep (Azure) déploient le cluster managé, le réseau, les identités, le stockage. terraform plan / apply rendent chaque changement prévisible et traçable ; la détection de drift signale toute dérive manuelle.
• Les charges applicatives : manifests Kubernetes versionnés et Helm charts paramétrés, déployés via GitOps (ArgoCD/Flux).
• Les politiques : RBAC, Network Policies, policies Kyverno, tout est code, versionné, revu.

Ce socle IaC est aussi notre engagement de réversibilité : le code est versionné dans vos dépôts Git, et la documentation vous est remise. Nous détaillons cette approche dans nos pages consultant Terraform et infrastructure as code entreprise.

FinOps Kubernetes : maîtriser le coût d'un cluster

Voici l'angle que presque aucune page concurrente française ne creuse, et où une bonne architecture se rentabilise en quelques mois. Un cluster mal architecturé sur le plan des coûts paie en moyenne 30 à 50 % de ressources réservées mais inutilisées (ordre de grandeur observé sur des clusters comparables, jamais une promesse).

Les leviers d'architecture FinOps que nous intégrons :

• Rightsizing des requests/limits : caler les ressources déclarées sur l'usage réel mesuré (P95/P99). C'est le quick-win le plus rentable, et la première cause de gaspillage.
• Autoscaling économe : HPA/VPA bien réglés + Cluster Autoscaler/Karpenter pour ne payer que les nodes nécessaires, et un bon bin packing pour remplir les nodes (un node à 30 % d'utilisation est un node à moitié gaspillé).
• Extinction hors usage : scale-to-zero des environnements non productifs la nuit et le week-end.
• Arbitrage Spot / Réservations : Spot Instances pour les workloads interruptibles (batch, CI, asynchrone), Savings Plans / Reserved Instances (engagement 1 ou 3 ans) pour le socle stable, on-demand pour la charge variable imprévisible. Beaucoup de clusters paient le tarif on-demand plein alors que 60-70 % de leur charge est parfaitement prévisible.
• Visibilité et showback/chargeback : OpenCost ou Kubecost répartissent le coût par namespace, équipe ou produit, via une stratégie d'étiquetage (labels/tags) cohérente. Sans visibilité par équipe, personne n'est responsable et la facture dérive.

Le FinOps et le GreenOps pointent souvent la même remédiation : un cluster mieux rempli, capable de scale-to-zero, consomme moins de nodes, donc moins d'énergie.

Cet axe s'articule avec notre offre d'audit FinOps et notre pilier d'optimisation des coûts cloud.

Décliner la conformité dans l'architecture du cluster

La définition juridique des cadres FR/UE (RGPD, DORA, NIS2, HDS, souveraineté) et la façon de cadrer une mission de mise en conformité relèvent de notre consultant Azure pour entreprise, qui en est la référence. Voir « Conformité réglementaire FR/UE sur Azure : RGPD, HDS, DORA, NIS2 ». Ici, l'angle est strictement technique : comment une obligation se traduit en décisions d'architecture dans le cluster Kubernetes.

Le mapping spécifique à la plateforme conteneurisée :

• HDS (données de santé) : l'hébergement se fait chez un partenaire certifié HDS (la certification vise l'hébergeur, pas le cluster). Au niveau de l'architecture K8s, on ajoute l'isolation par namespace/cluster dédié, le chiffrement at rest des volumes et de l'etcd, et la journalisation des accès.
• CIS Kubernetes Benchmark : le référentiel de durcissement propre à K8s (control plane, etcd, kubelet, politiques), avec scoring (outillé via kube-bench). Les prestataires de notre réseau conçoivent les clusters pour s'y conformer dès le départ, c'est la déclinaison cluster du socle de sécurité décrit plus haut.
• Traçabilité et localisation : audit logs de l'API server, contrôle des secrets, et choix de région UE des node pools et du stockage, la brique technique des exigences RGPD et de souveraineté.
• Résilience opérationnelle (DORA) : au niveau du cluster, cela se traduit par des PRA testés, des sauvegardes etcd/Velero et une IaC versionnée favorisant la réversibilité technique.

Nous adaptons l'architecture aux obligations de votre secteur : santé, finance, industrie, distribution, secteur public, SaaS. Pour une mission centrée conformité, voyez l'audit de conformité cloud.

Portabilité technique du cluster : concevoir pour pouvoir sortir

L'engagement contractuel de réversibilité et l'anti-enfermement côté prestataire (propriété du code, comptes à votre nom, transparence, clauses de sortie) sont portés par notre page prestataire Azure. Voir « L'angle d'Architecte Cloud : indépendance, réversibilité, transparence ». Ici, l'angle est purement technique : comment l'architecture d'un cluster Kubernetes préserve, ou détruit, la portabilité.

Kubernetes est par nature un standard portable, mais cette portabilité se conçoit, elle ne va pas de soi :

• Manifests standard : privilégier les API Kubernetes natives et les Helm charts paramétrables plutôt que des extensions propriétaires non substituables, pour qu'une bascule AKS → EKS → on-premise ne soit pas une réécriture.
• Abstraction du stockage et du réseau : s'appuyer sur les StorageClass et les interfaces CSI/CNI standard, isoler les points d'adhérence au cloud (LoadBalancer, Ingress controller, secrets store) derrière des couches identifiées et documentées.
• Limiter les services propriétaires non portables : chaque service managé du cloud (file managée, base managée) qui entre dans la plateforme est un point de friction à la sortie ; on l'assume en connaissance de cause, pas par défaut.
• IaC comme contrat de portabilité : l'ensemble Terraform/Bicep + manifests + policies décrit la plateforme de bout en bout ; reconstruire ailleurs revient à rejouer ce code, pas à redécouvrir une configuration.

La portabilité technique n'est pas qu'un confort : c'est aussi la traduction concrète, au niveau du cluster, de l'exigence DORA de réversibilité pour le secteur financier. Une plateforme dont on ne peut pas techniquement sortir est un risque.

C'est le cœur de notre approche de gouvernance cloud et de migration cloud entreprise.

Concevoir le cluster pour son exploitation jour 2

Concevoir un cluster est une chose ; le maintenir en production en est une autre. L'exploitation Day-2 / Run (supervision 24/7, gestion des incidents, infogérance du cluster au quotidien) constitue 80 % de son cycle de vie, c'est un métier à part entière, traité par notre consultant Kubernetes dans la section « Operations Day-2 / Run en production », et opéré en infogérance cloud entreprise.

Le rôle de l'architecte n'est pas de réaliser le run, mais de rendre le cluster exploitable dès la conception. Concrètement, l'architecture intègre en amont les éléments qui faciliteront (ou non) la vie en production :

• Stratégie d'upgrade : Kubernetes publie une version mineure tous les ~4 mois et n'en maintient que les trois dernières ; on conçoit des upgrades par vagues (control plane puis node pools, avec PDB et surge nodes) pour les rendre possibles sans interruption.
• Surface à patcher maîtrisée : un socle d'add-ons réduit et choisi limite la charge de patching et de remédiation des CVE (type runc, ingress-nginx).
• DR natif du cluster : sauvegarde de l'état (etcd) et des workloads/volumes (Velero), bascule multi-zone/multi-cluster, avec des objectifs RTO/RPO documentés, ce volet de résilience native est détaillé dans la section haute disponibilité ci-dessus, et reste propre aux pages Kubernetes.

Troubleshooting : diagnostiquer un cluster en panne

Un architecte expérimenté se reconnaît aussi à sa capacité à diagnostiquer vite. Voici les pannes les plus fréquentes et leur logique de résolution, un savoir-faire absent des pages concurrentes.

• CrashLoopBackOff : un conteneur redémarre en boucle. Causes typiques : livenessProbe trop agressive, configuration manquante (secret/ConfigMap), erreur applicative au démarrage, OOMKilled (mémoire insuffisante). Diagnostic : kubectl logs --previous, kubectl describe pod.
• Pending / Unschedulable : le scheduler ne trouve pas de node. Causes : requests trop élevées, pas de node disponible, taints sans toleration, quota de namespace atteint.
• Problèmes réseau CNI : pods qui ne se joignent pas, DNS qui échoue (CoreDNS surchargé), Network Policy trop restrictive qui bloque un flux légitime.
• Panne control plane / etcd : API server injoignable, etcd qui perd le quorum (sur auto-hébergé). C'est le scénario le plus critique, d'où l'importance de la HA et des sauvegardes etcd.
• Saturation des nodes : évictions de pods, throttling CPU, pression mémoire, souvent un symptôme de requests/limits mal calibrés ou d'absence d'autoscaling.

Single vs multi-cluster et multi-tenant

À mesure que l'organisation grandit, une question d'architecture revient : un grand cluster partagé, ou plusieurs clusters ? La méthodologie de décision compte plus que la réponse.

| Modèle | Avantages | Inconvénients | Quand le choisir | |---|---|---|---| | Single-cluster, multi-tenant (namespaces) | Coût mutualisé, moins de control planes à gérer | Isolation plus faible, blast radius large | Équipes de confiance, budget contraint, charges homogènes | | Multi-cluster | Isolation forte, blast radius limité, conformité par cluster | Plus de control planes, coût et complexité accrus | Prod/dev séparés, multi-région, tenants externes, exigences réglementaires |

Le critère décisif est le blast radius (le rayon d'impact d'une panne ou d'une compromission) confronté au coût. Un cluster unique partagé est plus économique mais concentre le risque ; le multi-cluster isole mais multiplie les control planes et l'effort d'exploitation. Pour le multi-tenant en single-cluster, l'isolation repose sur les namespaces, RBAC, Network Policies, ResourceQuotas et policies, une isolation logique, moins forte qu'une frontière de cluster.

Faut-il vraiment un cluster ? Le préalable à l'architecture

Avant de concevoir une plateforme, encore faut-il que Kubernetes soit la bonne réponse. La liste des anti-patterns et des cas où il faut renoncer à K8s (application unique, site vitrine, MVP, charges sporadiques mieux servies par un PaaS comme App Service/App Runner, un conteneur serverless comme Container Apps/Fargate, ou des fonctions Functions/Lambda) est traitée en détail par notre consultant Kubernetes. Voir « Quand NE PAS adopter Kubernetes : les anti-patterns ».

Du point de vue de l'architecte, la règle tient en une phrase : on conçoit un cluster quand la complexité applicative réelle (microservices nombreux, multi-environnements, portabilité, scalabilité fine, avec une équipe ou une infogérance pour l'exploiter) le justifie, pas par effet de mode. Si ce préalable n'est pas vérifié, l'architecture la plus saine est souvent de ne pas déployer Kubernetes.

Si vous hésitez, notre audit d'infrastructure cloud et notre conseil en architecture tranchent la question sur des critères objectifs.

Notre méthodologie : audit, conception, build, run

Nous structurons toute mission d'architecture Kubernetes en quatre phases, avec des livrables précis à chaque étape. Cette démarche s'ancre dans la landing zone cloud (Cloud Adoption Framework côté Azure, Control Tower / Landing Zone Accelerator côté AWS), car un cluster ne se conçoit jamais hors de son organisation cloud.

1. Audit / cadrage. Compréhension du besoin métier, des contraintes (réglementaires, budgétaires, équipe), et de l'existant. Livrable : note de cadrage, choix managé/auto-hébergé argumenté, dimensionnement cible.
2. Conception. Architecture de la landing zone et du cluster : topologie, réseau (CNI), identités (RBAC/Entra/IAM), sécurité, résilience (multi-AZ, RTO/RPO), modèle de coûts. Livrable : dossier d'architecture (DAT) et schémas.
3. Build (IaC). Construction en Terraform/Bicep + Helm/GitOps, déploiement des add-ons (observabilité, policies, secrets), mise en place des standards. Livrable : IaC versionnée dans vos dépôts, environnements déployés, documentation.
4. Run / infogérance. Exploitation : monitoring, upgrades, patching, sauvegardes, gestion d'incidents, FinOps continu. Disponible en 24/7. Livrable : runbooks, tableaux de bord, rapports d'exploitation.

Les durées indicatives : la conception et le build d'un cluster managé prennent généralement de 3 à 15 jours selon la complexité (un mono-cluster AKS/EKS de référence en bas de fourchette ; une architecture multi-cluster, multi-région ou sous forte contrainte de conformité en haut). Le run est ensuite récurrent.

Combien coûte une architecture Kubernetes ? Durée, budget et livrables

La transparence sur le budget fait partie de notre méthode. Les chiffres ci-dessous sont indicatifs et établis sur devis selon le périmètre réel, ils ne constituent pas un prix ferme (sujet sensible, présenté en fourchette).

• Durée : de 3 à 15 jours selon la taille et la complexité de l'architecture.
• Budget indicatif : de 8 000 à 25 000 € selon le périmètre.

Ce qui fait varier la durée et le budget :

| Périmètre | Durée indicative | Budget indicatif | |---|---|---| | Conception + build d'un mono-cluster managé (AKS/EKS), un environnement | 3 à 6 j | à partir de ~8 000 € | | Plateforme multi-environnements (dev/staging/prod), GitOps, observabilité complète | 6 à 10 j | fourchette médiane | | Multi-cluster / multi-région, auto-hébergé, ou forte exigence de conformité (DORA/HDS) | 10 à 15 j | haut de fourchette |

L'exploitation (run / infogérance) fait l'objet d'un forfait mensuel distinct, dimensionné selon le périmètre et le niveau de service souhaité.

Le rendez-vous de cadrage initial est offert : il permet d'estimer précisément le périmètre avant tout engagement. Demandez votre diagnostic ou contactez-nous pour un devis, réponse sous 48 h ouvrées.

Cas représentatif : la plateforme AKS d'une ETI industrielle

Le scénario suivant est représentatif des missions que nous coordonnons (persona anonymisé, chiffres constatés sur des cas comparables, non garantis).

Contexte : DSI d'un groupe industriel (ETI), migration de plusieurs applications vers des microservices, besoin d'une plateforme cible sur Azure. Pas d'équipe Kubernetes en interne. Contrainte : confidentialité des données de production, budget maîtrisé.

Choix d'architecture : AKS managé (pas d'auto-hébergé, faute d'équipe dédiée), cluster privé, intégration Entra ID + Azure RBAC, Azure CNI Overlay, secrets dans Azure Key Vault via CSI driver, GitOps avec ArgoCD, observabilité Managed Prometheus + Grafana, multi-AZ, sauvegarde Velero, policies Kyverno.

FinOps dès la conception : node pools dimensionnés sur l'usage réel, Spot pour les environnements hors prod, réservations sur le socle stable, scale-to-zero la nuit en dev/staging.

Effets observés : plateforme multi-AZ avec plan de reprise testé, déploiements automatisés et tracés via GitOps, coûts maîtrisés par showback par namespace. L'intégralité de l'IaC Terraform livrée dans les dépôts du client, comptes Azure à son nom, réversibilité assurée.

Ce type de mission illustre notre angle : une architecture qui sert à la fois le DSI (fiabilité), le RSSI (sécurité, conformité) et le DAF (coût maîtrisé).

Pourquoi Architecte Cloud pour votre architecture Kubernetes

Nous sommes un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires et experts qualifiés sur Azure et AWS, du conseil à l'exploitation 24/7. Ce qui structure nos missions d'architecture Kubernetes :

• Vision 360° : nous réunissons conception, sécurité, FinOps, conformité et exploitation dans une seule cohérence, là où le marché traite ces volets séparément.
• Indépendance : conseil sans parti pris de plateforme. Nous recommandons managé ou auto-hébergé, Azure ou AWS, selon votre intérêt, pas un catalogue.
• Autonomie et réversibilité : tout ce qui est construit vous appartient (IaC dans vos dépôts, comptes à votre nom, documentation remise). Pas d'enfermement.
• Couverture multi-cloud réelle : expertise AKS de premier plan (Entra ID, Azure Policy, Defender for Containers, Key Vault CSI), au même niveau qu'EKS, et non une transposition approximative depuis AWS.
• Preuves : 12 ans d'expertise, de nombreux projets accompagnés, un réseau de clients établi et une satisfaction client élevée. Microsoft Azure Partner (Solutions Partner, Infrastructure) et AWS Partner (Advanced Tier). Prestataires et experts qualifiés du réseau, disposant des certifications requises : Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner. Démarche ISO 27001, membre de la FinOps Foundation.

Pour aller plus loin : nos services, notre conseil en architecture, le guide du cloud et la page à propos. Si votre besoin est plus large, voyez notre rôle de prestataire Azure, de prestataire AWS, ou notre approche de la migration cloud.

FAQ : Architecte Kubernetes

Qu'est-ce qu'un architecte Kubernetes ?

C'est un expert qui conçoit, dimensionne et fait évoluer l'architecture d'un ou plusieurs clusters Kubernetes en production. Il arbitre les choix structurants (managé ou auto-hébergé, mono ou multi-cluster, réseau (CNI), identité (RBAC), sécurité, résilience, modèle de coûts) et les traduit en une plateforme cohérente, en Infrastructure as Code, documentée et exploitable par vos équipes.

Quelle est la différence entre un architecte et un administrateur Kubernetes ?

L'architecte définit le cadre (quelle plateforme concevoir et pourquoi), avec un horizon stratégique : dossier d'architecture, IaC, standards, choix managé/auto-hébergé, modèle de coûts. L'administrateur (ou SRE) opère et maintient le cluster au quotidien : upgrades, sauvegardes, incidents, tuning. L'architecte pose les fondations, l'administrateur les fait vivre. Dans une PME, une même personne porte souvent les deux casquettes.

Quelles sont les compétences d'un architecte Kubernetes ?

Maîtrise de l'architecture Kubernetes (control plane, nodes, réseau, stockage), de la sécurité (RBAC, Pod Security, secrets, supply chain), de l'Infrastructure as Code (Terraform, Bicep, Helm), du FinOps, de la résilience (HA, PRA, RTO/RPO) et d'au moins un cloud (AKS, EKS, GKE) avec sa landing zone. Les certifications de référence sont CKA, CKAD, CKS, complétées par des certifications cloud (Azure Solutions Architect Expert, AWS DevOps Engineer Professional).

Quel est le salaire d'un architecte Kubernetes en France ?

À titre indicatif et selon l'expérience et la région, un architecte Kubernetes salarié se situe généralement dans une fourchette d'environ 60 000 à 90 000 € bruts annuels, davantage en grand compte ou en Île-de-France. En prestation externe, le coût se raisonne au projet (conception et build) plutôt qu'au salaire : c'est l'objet de notre budget indicatif. Ces ordres de grandeur varient selon le marché.

Quels sont les composants de l'architecture Kubernetes ?

Deux ensembles. Le control plane : kube-apiserver (porte d'entrée de l'API), etcd (base d'état clé/valeur), kube-scheduler (placement des pods), kube-controller-manager (boucles de réconciliation) et cloud-controller-manager (intégration cloud). Les worker nodes : kubelet (agent qui pilote les pods), kube-proxy (réseau des Services) et le container runtime (containerd ou CRI-O qui exécute les conteneurs).

Comment fonctionne le control plane de Kubernetes ?

Tout passe par le kube-apiserver, point d'entrée unique qui valide les requêtes, applique l'authentification, le RBAC et l'admission control, puis enregistre l'état désiré dans etcd. Le scheduler place les nouveaux pods sur les nodes ; le controller-manager exécute des boucles qui réconcilient en continu l'état réel vers l'état désiré ; le cloud-controller-manager provisionne les ressources cloud (LoadBalancers, volumes).

À quoi sert etcd dans Kubernetes ?

etcd est la base de données clé/valeur distribuée qui stocke l'intégralité de l'état du cluster : objets, configuration, secrets. C'est la source de vérité unique. Sa perte sans sauvegarde équivaut à la perte du cluster. Sur un cluster auto-hébergé, son chiffrement at rest, sa sauvegarde régulière et le test de restauration sont des décisions d'architecture critiques.

Quelles sont les bonnes pratiques pour architecturer un cluster Kubernetes ?

Isoler via les namespaces (ResourceQuotas, LimitRanges) ; déclarer des requests/limits calées sur l'usage réel ; activer l'autoscaling à trois étages (HPA, VPA, Cluster Autoscaler/Karpenter) ; répartir les répliques sur plusieurs nodes et zones (anti-affinity, multi-AZ) ; poser des probes justes et des Pod Disruption Budgets ; appliquer la sécurité by design (RBAC moindre privilège, Network Policies deny-by-default, Pod Security restricted) ; et tout gérer en Infrastructure as Code et GitOps.

Quelle est la différence entre un namespace et un cluster Kubernetes ?

Un cluster est l'ensemble physique/logique complet (control plane + nodes). Un namespace est une partition logique à l'intérieur d'un cluster, qui isole des ressources, des quotas et des droits entre équipes ou environnements. L'isolation par namespace est logique (RBAC, Network Policies, quotas) et plus faible que la frontière d'un cluster séparé : le choix single-cluster multi-tenant vs multi-cluster dépend du blast radius acceptable et du budget.

Combien de temps faut-il pour déployer une architecture Kubernetes en production ?

La conception et le build d'un cluster managé prennent généralement de 3 à 15 jours selon la complexité : un mono-cluster AKS/EKS de référence en bas de fourchette, une architecture multi-cluster, multi-région ou sous forte contrainte de conformité en haut. L'exploitation (run) est ensuite récurrente. Le budget indicatif associé se situe entre 8 000 et 25 000 €, sur devis selon le périmètre.

Comment sécuriser une architecture Kubernetes ?

Par cinq lignes de défense conçues dès le départ : RBAC au moindre privilège (sans wildcards ni cluster-admin abusif), Pod Security Standards profil restricted, admission control en policy-as-code (Kyverno/Gatekeeper), gestion des secrets chiffrés (KMS, Key Vault, Vault, pas de base64 brut), et sécurité de la supply chain (scan CVE, SBOM, signature d'images). On y ajoute les Network Policies deny-by-default, le mTLS et l'alignement sur le CIS Kubernetes Benchmark.

Comment optimiser les coûts d'un cluster Kubernetes (FinOps) ?

Par le rightsizing des requests/limits sur l'usage réel observé (P95/P99), un autoscaling économe et un bon bin packing des nodes, l'extinction des environnements hors usage (scale-to-zero), l'arbitrage entre Spot (workloads interruptibles), Savings Plans/Reserved Instances (socle stable) et on-demand, et la visibilité par namespace via OpenCost ou Kubecost pour un showback/chargeback par équipe. On constate fréquemment 30 à 50 % de ressources réservées inutilisées avant remédiation, un ordre de grandeur observé, pas une promesse.

Quelle architecture Kubernetes pour la haute disponibilité ?

Un control plane redondant (assuré par le fournisseur en managé ; au moins 3 nœuds etcd en quorum sur plusieurs zones en auto-hébergé), des worker nodes et des répliques applicatives répartis sur plusieurs zones de disponibilité (multi-AZ), des Pod Disruption Budgets et des probes justes, et une stratégie de sauvegarde/restauration (Velero, etcd) avec des objectifs RTO/RPO documentés et testés. Pour les exigences les plus fortes, une architecture multi-cluster ou multi-région.