Architecture
Diagramme d'architecture d'orchestration de conteneurs Kubernetes montrant le plan de contrôle (API Server, etcd, Scheduler, Controller Manager), les nœuds worker (Kubelet, runtime de conteneurs, kube-proxy, pods), la couche réseau (Ingress, Network Policy, Service Mesh) et le stockage persistant avec pilotes CSI. Ce modèle fournit une vue complète de la pile architecturale Kubernetes du plan de contrôle à la couche de stockage. Référence fondamentale pour les ingénieurs DevOps et les équipes plateforme gérant des clusters Kubernetes.
Code FlowZap complet
ControlPlane { # Kubernetes Control Plane
n1: rectangle label:"API Server"
n2: rectangle label:"etcd (Cluster State)"
n3: rectangle label:"Scheduler"
n4: rectangle label:"Controller Manager"
n5: rectangle label:"Cloud Controller"
n1.handle(right) -> n2.handle(left) [label="Store State"]
n1.handle(bottom) -> n3.handle(top) [label="Schedule Pods"]
n3.handle(right) -> n4.handle(left) [label="Reconcile"]
n4.handle(right) -> n5.handle(left) [label="Cloud Resources"]
n3.handle(bottom) -> WorkerNode.n6.handle(top) [label="Assign Pod"]
}
WorkerNode { # Worker Node
n6: rectangle label:"Kubelet"
n7: rectangle label:"Container Runtime (containerd)"
n8: rectangle label:"kube-proxy"
n9: rectangle label:"Pod A (App Container)"
n10: rectangle label:"Pod B (App Container)"
n11: rectangle label:"Pod C (Sidecar + App)"
n6.handle(right) -> n7.handle(left) [label="Pull Image"]
n7.handle(right) -> n9.handle(left) [label="Start Container"]
n7.handle(bottom) -> n10.handle(top) [label="Start Container"]
n7.handle(bottom) -> n11.handle(top) [label="Start Container"]
n8.handle(bottom) -> Networking.n12.handle(top) [label="Service Routing"]
}
Networking { # Networking Layer
n12: rectangle label:"ClusterIP Service"
n13: rectangle label:"Ingress Controller"
n14: rectangle label:"Network Policy"
n15: rectangle label:"Service Mesh (Istio)"
n12.handle(right) -> n13.handle(left) [label="Expose"]
n13.handle(right) -> n14.handle(left) [label="Filter"]
n14.handle(right) -> n15.handle(left) [label="mTLS"]
}
Storage { # Persistent Storage
n16: rectangle label:"PersistentVolume"
n17: rectangle label:"StorageClass (SSD/HDD)"
n18: rectangle label:"CSI Driver"
n16.handle(right) -> n17.handle(left) [label="Provision"]
n17.handle(right) -> n18.handle(left) [label="Cloud Disk"]
n16.handle(top) -> WorkerNode.n9.handle(bottom) [label="Mount Volume"]
}
Pourquoi ce workflow ?
Managing containers across multiple hosts manually is unsustainable beyond a few services. Kubernetes automates container deployment, scaling, networking, and storage orchestration—providing a declarative platform where you describe the desired state and the system continuously reconciles to achieve it.
Comment ça fonctionne
- Step 1: The API Server receives deployment manifests and stores desired state in etcd.
- Step 2: The Scheduler assigns pods to worker nodes based on resource requirements and constraints.
- Step 3: Kubelet on each worker node pulls container images and starts pods.
- Step 4: kube-proxy manages network routing and service discovery within the cluster.
- Step 5: Ingress controllers expose services to external traffic with TLS termination.
- Step 6: PersistentVolumes provide durable storage that survives pod restarts and rescheduling.
Alternatives
Docker Compose works for single-host deployments. ECS/Fargate provides managed container orchestration without Kubernetes complexity. Nomad offers a simpler alternative for some workloads. This template provides the comprehensive Kubernetes architecture reference.
Key Facts
| Template Name | Architecture d'orchestration de conteneurs Kubernetes |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture du pattern sidecar montrant le proxy Envoy, le collecteur de logs et le watcher de configuration fonctionnant aux côtés des conteneurs applicatifs dans un pod Kubernetes, avec un plan de contrôle gérant la configuration. Ce modèle démontre comment les préoccupations auxiliaires comme la journalisation, la surveillance et la configuration sont déployées en tant que conteneurs co-localisés. Fondamental pour les équipes adoptant des patterns d'orchestration de conteneurs cloud-native.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.