Guide Complet pour l'Administration d'un Cluster Kubernetes : Architecture, Concepts Avancés et Stratégies Opérationnelles

Guide Complet pour l’Administration d’un Cluster Kubernetes:

1. Introduction aux Fondamentaux de l’Architecture Distribuée Kubernetes

Dans le paysage actuel de l’infrastructure informatique, Kubernetes s’est imposé comme le standard de facto pour l’orchestration de conteneurs. Cependant, administrer un cluster de production exige une compréhension qui dépasse largement la simple exécution de commandes impératives. Il est nécessaire d’appréhender la plateforme comme un système distribué complexe, conçu pour maintenir un état désiré à travers une boucle de réconciliation perpétuelle. Ce rapport explore en profondeur l’architecture interne de Kubernetes, disséquant les interactions entre le plan de contrôle et le plan de données, avant d’aborder les stratégies avancées de gestion réseau, de stockage, de sécurité et les opérations critiques dites “Day 2”.

L’architecture de Kubernetes repose sur un principe de découplage strict entre l’intelligence décisionnelle du système, centralisée dans le Plan de Contrôle (Control Plane), et la capacité d’exécution brute, répartie sur les Nœuds de Travail (Worker Nodes) ou Plan de Données.1 Cette séparation garantit non seulement la scalabilité horizontale du système, mais aussi sa résilience : une panne des nœuds de travail n’affecte pas l’intégrité de la base de données du cluster, et une panne temporaire du plan de contrôle n’arrête pas les charges de travail existantes.2

1.1 Le Plan de Contrôle : Cerveau du Cluster

Le Plan de Contrôle est l’ensemble des composants qui prennent les décisions globales concernant le cluster (telles que la planification des tâches), détectent et répondent aux événements du cluster (comme le démarrage d’un nouveau pod lorsque le champ replicas d’un déploiement n’est pas satisfait).1 Pour assurer la haute disponibilité en production, ces composants sont généralement répliqués sur plusieurs machines, souvent appelées “maîtres” ou nœuds du plan de contrôle.

1.1.1 Le Serveur API (kube-apiserver) : Le Pivot Central

Le composant central et névralgique du plan de contrôle est le kube-apiserver. Il agit comme le point d’entrée unique pour toutes les requêtes administratives et les communications internes. Contrairement à une architecture monolithique, Kubernetes adopte une conception “Hub-and-Spoke” où l’API Server est le moyeu central.4

Techniquement, le serveur API expose une interface RESTful HTTP qui permet aux utilisateurs, aux composants du cluster et aux contrôleurs externes de manipuler les objets Kubernetes (Pods, Services, etc.). Sa fonction première est de valider et de configurer les données pour les objets API. Il est le seul composant autorisé à communiquer directement avec le magasin de données etcd.3 Tous les autres composants, qu’il s’agisse du planificateur, du gestionnaire de contrôleurs ou des kubelets sur les nœuds, doivent passer par l’API Server pour lire ou écrire l’état du cluster.

Cette architecture présente un avantage majeur en termes de sécurité et de gouvernance : en centralisant l’accès aux données, l’API Server devient le point de contrôle idéal pour l’authentification, l’autorisation et l’admission. De plus, il est conçu pour être sans état (stateless) et peut s’adapter horizontalement (scale-out) pour gérer un trafic croissant, les requêtes étant simplement équilibrées entre plusieurs instances du serveur.5

1.1.2 etcd : La Mémoire Persistante et Cohérente

Si l’API Server est le cerveau, etcd est la mémoire du cluster. Il s’agit d’un magasin de clés-valeurs distribué, cohérent et hautement disponible, utilisé pour stocker toutes les données du cluster, y compris la configuration, l’état et les métadonnées.6 Dans l’écosystème Kubernetes, etcd est la source unique de vérité. Si les données dans etcd sont perdues, le cluster est perdu.

etcd utilise l’algorithme de consensus Raft pour garantir la cohérence des données entre les instances distribuées. Cela signifie que pour qu’une écriture soit considérée comme validée, elle doit être acceptée par une majorité (quorum) des membres du cluster etcd. Cette exigence de quorum dicte l’architecture de déploiement : un cluster etcd de production doit comporter un nombre impair de nœuds (généralement 3 ou 5) pour tolérer les pannes sans perdre sa capacité à élire un leader et à écrire des données.5 Par exemple, un cluster de 3 nœuds peut tolérer la perte d’un nœud, tandis qu’un cluster de 5 nœuds peut en tolérer deux.

L’importance critique d’etcd impose des contraintes opérationnelles strictes. Il est recommandé d’héberger etcd sur des disques rapides (SSD) pour minimiser la latence des écritures disque (fsync), qui impacte directement la performance globale du cluster. De plus, la sauvegarde régulière d’etcd est la tâche de maintenance la plus vitale pour tout administrateur Kubernetes, car elle seule permet la restauration complète de l’état du cluster en cas de désastre majeur.8

1.1.3 Le Planificateur (kube-scheduler) : Orchestration des Ressources

Le kube-scheduler a une responsabilité unique mais complexe : assigner les nouveaux Pods, qui n’ont pas encore de nœud attribué, à un nœud spécifique du cluster capable de les exécuter.3 Ce processus, bien qu’il puisse sembler simple, implique une analyse multidimensionnelle des contraintes.

Le processus de décision du planificateur se déroule en deux phases principales :

1. Filtrage (Predicates) : Le planificateur élimine tous les nœuds qui ne satisfont pas aux exigences strictes du Pod. Par exemple, si un Pod demande 4 Go de RAM, tous les nœuds disposant de moins de 4 Go de mémoire libre sont écartés. Les taints (souillures) et tolerations, les affinités de nœuds et les ports requis sont également évalués ici.
2. Scoring (Priorities) : Parmi les nœuds restants, le planificateur attribue un score à chacun. Les critères peuvent inclure l’équilibrage de charge (préférer le nœud le moins chargé), la localité des images (préférer un nœud qui a déjà l’image conteneur pour accélérer le démarrage) ou l’affinité inter-pod (regrouper ou séparer les services). Le nœud avec le score le plus élevé est sélectionné.

Ce mécanisme est hautement configurable et extensible, permettant aux administrateurs de définir leurs propres politiques de planification ou même d’exécuter plusieurs planificateurs en parallèle pour différents types de charges de travail.

1.1.4 Le Gestionnaire de Contrôleurs (kube-controller-manager)

Le kube-controller-manager est un démon qui intègre les boucles de contrôle principales de Kubernetes. En robotique et en automatisation, une boucle de contrôle est un mécanisme non terminant qui régule l’état d’un système. Dans Kubernetes, chaque contrôleur surveille l’état actuel du cluster via l’API Server et effectue les changements nécessaires pour le faire converger vers l’état désiré.6

Bien que logiquement séparés, ces contrôleurs sont compilés dans un seul binaire binaire pour réduire la complexité de déploiement. Parmi les contrôleurs essentiels, on trouve :

• Node Controller : Surveille l’état des nœuds et réagit s’ils tombent en panne (par exemple, en cessant d’envoyer des heartbeats).2
• Replication Controller / ReplicaSet Controller : S’assure que le nombre correct de répliques de Pods est en cours d’exécution pour chaque objet de réplication défini.
• EndpointSlice Controller : Remplit les objets Endpoints (qui lient les Services et les Pods), permettant aux Services de diriger le trafic vers les conteneurs appropriés.
• ServiceAccount & Token Controllers : Créent des comptes et des jetons d’accès API par défaut pour les nouveaux espaces de noms.

1.1.5 Le Cloud Controller Manager (CCM)

Le cloud-controller-manager est un composant introduit pour découpler le code spécifique au fournisseur de cloud du noyau de Kubernetes. Il exécute des contrôleurs qui interagissent avec l’API du fournisseur de cloud sous-jacent.3

Cela permet aux mainteneurs de Kubernetes d’évoluer indépendamment des fournisseurs de cloud. Le CCM gère des tâches telles que :

• La détection des nœuds : Vérifier auprès du fournisseur de cloud si un nœud a été supprimé physiquement après qu’il a cessé de répondre.
• Le routage : Configurer les routes dans l’infrastructure cloud pour que les conteneurs sur différents nœuds puissent communiquer.
• Les équilibreurs de charge (Services LoadBalancer) : Provisionner automatiquement les load balancers du cloud (comme AWS ELB ou GCP Load Balancer) lorsqu’un Service de type LoadBalancer est créé.

1.2 Le Plan de Données : Les Nœuds de Travail (Worker Nodes)

Les nœuds de travail sont les bêtes de somme du cluster. Ils fournissent l’environnement d’exécution pour les applications conteneurisées. Chaque nœud est géré par le plan de contrôle et contient les services nécessaires pour exécuter des Pods.1

1.2.1 Kubelet : L’Agent de Nœud

Le kubelet est l’agent principal qui s’exécute sur chaque nœud. Il est le point de contact entre le plan de contrôle et le nœud. Sa responsabilité première est de s’assurer que les conteneurs sont en cours d’exécution et sains dans les Pods assignés à son nœud.2

Le kubelet fonctionne de manière déclarative : il reçoit une spécification de Pod (PodSpec) de l’API Server et interagit avec le moteur de conteneur (via CRI) pour lancer les conteneurs correspondants. Il surveille ensuite continuellement l’état de ces conteneurs, exécutant des sondes de vivacité (liveness probes) et de disponibilité (readiness probes) pour rapporter leur statut au plan de contrôle.

Une fonctionnalité critique du kubelet est l’auto-enregistrement. Au démarrage, le kubelet s’enregistre auprès de l’API Server, créant un objet Node qui représente la machine dans le cluster. Il envoie ensuite régulièrement des mises à jour de statut et des “heartbeats” pour confirmer sa disponibilité.2

1.2.2 Kube-proxy : Le Réseau de Nœud

kube-proxy est un proxy réseau qui s’exécute sur chaque nœud, implémentant une partie du concept de Service Kubernetes.9 Son rôle est de maintenir les règles réseau sur le nœud, permettant la communication réseau vers les Pods depuis l’intérieur ou l’extérieur du cluster.

Historiquement, kube-proxy fonctionnait en mode “userspace”, ce qui était lent et inefficace. Aujourd’hui, il utilise principalement deux modes plus performants :

• iptables : Utilise les fonctionnalités de filtrage de paquets du noyau Linux. C’est le mode par défaut robuste et mature. Cependant, dans les très grands clusters avec des milliers de services, la mise à jour des règles iptables peut devenir un goulot d’étranglement de performance.
• IPVS (IP Virtual Server) : Basé sur le module de transport de charge du noyau Netfilter, IPVS offre de meilleures performances et une meilleure scalabilité pour les grands clusters, ainsi que des algorithmes d’équilibrage de charge plus sophistiqués.11

Il est important de noter que certaines implémentations CNI modernes, comme Cilium, peuvent remplacer entièrement kube-proxy en utilisant la technologie eBPF pour gérer le routage et l’équilibrage de charge directement dans le noyau, offrant des performances encore supérieures.12

1.2.3 Container Runtime Interface (CRI)

Le Container Runtime est le logiciel responsable de l’exécution des conteneurs. Pour éviter de dépendre d’une technologie spécifique (comme Docker), Kubernetes a introduit la Container Runtime Interface (CRI), une interface standardisée permettant de brancher n’importe quel moteur de conteneur compatible.9

Les runtimes populaires incluent :

• containerd : Un runtime industriel léger et performant, désormais le standard par défaut dans de nombreuses distributions Kubernetes.
• CRI-O : Un runtime léger conçu spécifiquement pour Kubernetes, optimisé pour la conformité OCI (Open Container Initiative).
• Docker Engine : Bien que pionnier, Docker n’est plus supporté directement via “dockershim” depuis Kubernetes 1.24, obligeant les administrateurs à migrer vers containerd ou CRI-O.13

2. Le Cycle de Vie d’une Requête API : De la Commande à la Persistance

Comprendre le flux exact d’une requête API est indispensable pour sécuriser et déboguer un cluster. Lorsqu’un administrateur tape kubectl apply, une chaîne complexe d’événements se déclenche avant que la moindre modification ne soit enregistrée dans etcd.

2.1 Authentification (Authentication) : “Qui êtes-vous?”

La première ligne de défense est l’authentification. Kubernetes ne possède pas de base de données interne d’utilisateurs “normaux” (humains). Il suppose que la gestion des utilisateurs est externalisée.14

Les méthodes d’authentification principales sont :

• Certificats Client X.509 : Utilisés principalement par les composants système (kubelet, scheduler) et souvent par les administrateurs via le fichier kubeconfig. L’identité est extraite du champ CN (Common Name) du certificat.15
• Jetons Bearer (Service Accounts) : Les comptes de service sont des identités gérées par Kubernetes pour les processus s’exécutant dans des Pods. Chaque compte de service possède un jeton JWT (JSON Web Token) monté dans le Pod, lui permettant de s’authentifier auprès de l’API.14
• OpenID Connect (OIDC) : La méthode recommandée pour les utilisateurs humains en entreprise. Elle permet d’intégrer Kubernetes avec des fournisseurs d’identité externes comme Google, Azure AD ou Keycloak. L’API Server vérifie la signature du jeton ID token fourni par l’utilisateur sans avoir besoin de contacter le fournisseur d’identité à chaque requête.15
• Proxy d’Authentification : Permet de déléguer l’authentification à un proxy frontal qui transmet l’identité via des en-têtes HTTP de confiance.16

Une fois authentifiée, la requête est marquée avec un nom d’utilisateur (User) et des groupes, mais n’est pas encore autorisée à agir.

2.2 Autorisation (Authorization) : “Avez-vous le droit?”

L’étape suivante vérifie si l’utilisateur identifié a la permission d’exécuter l’action demandée (verbe : get, list, create, delete) sur la ressource spécifiée (objet : pods, services) dans un espace de noms donné.

Kubernetes supporte plusieurs modes, mais RBAC (Role-Based Access Control) est le standard universel.17 RBAC repose sur quatre objets fondamentaux :

1. Role : Définit un ensemble de permissions (règles) limitées à un Namespace spécifique.
2. ClusterRole : Définit des permissions globales au cluster (pour les ressources non namespaced comme les Nœuds) ou des permissions communes réutilisables.
3. RoleBinding : Lie un “Sujet” (User, Group, ServiceAccount) à un Role, lui accordant les permissions dans ce Namespace.
4. ClusterRoleBinding : Lie un Sujet à un ClusterRole, accordant les permissions sur l’ensemble du cluster.

Tableau Comparatif des Portées RBAC

Objet RBAC	Portée	Usage Typique	Risque de Sécurité
Role	Namespace	Droits de lecture/écriture pour une application spécifique.	Faible
ClusterRole	Cluster	Définition de permissions standards (ex: view, edit, admin).	N/A (Définition seule)
RoleBinding	Namespace	Accorder un accès limité à un développeur sur un projet.	Faible
ClusterRoleBinding	Cluster	Accorder des droits d’administration globaux ou à des agents système.	Élevé (Donne accès à tout)

Un point de confusion fréquent, et une faille de sécurité potentielle, réside dans l’utilisation excessive de ClusterRoleBinding. Accorder des droits via ce mécanisme donne accès à tous les namespaces, présents et futurs.

2.3 Contrôle d’Admission (Admission Control) : Les Gardiens du Temple

Même authentifiée et autorisée, une requête peut être rejetée ou modifiée par les contrôleurs d’admission. Ces modules interceptent la requête avant la persistance.19

Ils se divisent en deux phases :

1. Mutation (Mutating Admission) : Modifie l’objet. Par exemple, ServiceAccount injecte automatiquement le jeton de compte de service dans un Pod. DefaultStorageClass ajoute la classe de stockage par défaut si l’utilisateur ne l’a pas spécifiée.
2. Validation (Validating Admission) : Valide l’objet. Si un contrôleur rejette la requête, l’opération entière échoue. Par exemple, LimitRanger vérifie que les ressources demandées respectent les limites du namespace.

Webhooks d’Admission et Moteurs de Politique

Pour une gouvernance avancée, Kubernetes permet d’enregistrer des Webhooks externes. C’est ici qu’interviennent des outils comme OPA Gatekeeper ou Kyverno.21 Ces moteurs permettent d’appliquer des politiques complexes “Policy-as-Code” qui ne sont pas couvertes par le RBAC standard, telles que :

• Interdire les images provenant de registres non sécurisés (ex: Docker Hub public).
• Obliger la présence de labels spécifiques (ex: cost-center).
• Empêcher les conteneurs de s’exécuter en mode privilégié (securityContext).

L’intégration de ces contrôles est cruciale pour sécuriser la “Supply Chain” logicielle et garantir la conformité des déploiements.

2.4 Validation et Persistance

Enfin, l’objet passe par une validation de schéma interne (vérifiant les types de champs, les valeurs obligatoires) avant d’être sérialisé et écrit dans etcd. Une fois l’écriture confirmée par le consensus Raft d’etcd, l’API Server répond “201 Created” au client. À ce stade, l’objet existe dans la base de données, mais aucun conteneur ne tourne encore. C’est le début du travail pour les contrôleurs asynchrones.

3. Architecture Réseau Avancée et Connectivité

Le modèle réseau de Kubernetes est conçu pour éliminer la complexité de la gestion des ports et du NAT (Network Address Translation) entre conteneurs. Il impose un modèle de “réseau plat” où chaque Pod possède sa propre adresse IP unique, routable depuis n’importe quel autre Pod du cluster.22

3.1 CNI : Le Cœur du Réseau Kubernetes

L’implémentation de ce modèle est déléguée aux plugins CNI (Container Network Interface). Le choix du CNI est une décision architecturale majeure qui impacte la performance, la sécurité et l’observabilité.23

Comparaison Détaillée des Plugins CNI

Le marché des CNI est vaste, mais quatre solutions dominent, chacune avec une philosophie distincte :

1. Flannel : La Simplicité de l’Overlay

Flannel est l’option la plus simple. Il crée un réseau overlay (généralement VXLAN) qui encapsule les paquets des Pods dans des paquets UDP des nœuds.

• Avantages : Installation triviale, fonctionne partout.
• Inconvénients : Performance moyenne due à l’encapsulation/désencapsulation. Surtout, Flannel ne supporte pas les Network Policies nativement, ce qui en fait un choix risqué pour les environnements multi-tenants.24

2. Calico : Performance et Sécurité BGP

Calico est le standard de l’industrie pour les clusters d’entreprise. Il peut fonctionner en mode Overlay (VXLAN/IPIP) mais excelle en mode routage direct utilisant BGP (Border Gateway Protocol).

• Fonctionnement : En mode BGP, Calico propage les routes des Pods aux routeurs du réseau physique, éliminant le besoin d’encapsulation.
• Sécurité : Calico offre un moteur de Network Policies très riche, supportant non seulement les standards Kubernetes mais aussi des règles étendues (GlobalNetworkPolicy, règles d’application L7).24

3. Cilium : La Révolution eBPF Cilium représente la nouvelle génération de réseau Kubernetes. Au lieu d’utiliser iptables ou le routage classique, il utilise eBPF (Extended Berkeley Packet Filter) pour insérer la logique réseau directement dans le noyau Linux de manière sécurisée et performante.12

• Performance : En contournant la pile TCP/IP traditionnelle et les tables iptables géantes, Cilium offre des latences ultra-faibles et un débit élevé.
• Fonctionnalités : Il peut remplacer kube-proxy, offre une observabilité L7 (HTTP, DNS, Kafka) via son composant Hubble, et gère le chiffrement transparent (WireGuard/IPsec). C’est le choix privilégié pour les clusters à très haute échelle.25

4. Canal : Le Compromis Canal n’est pas un CNI unique mais une combinaison : il utilise l’agent Flannel pour le réseau (simple) et le moteur Calico pour les politiques de sécurité. C’est une bonne option de transition pour ceux qui veulent la simplicité de Flannel avec la sécurité de Calico.24

3.2 Services et Exposition des Applications

Les Pods étant éphémères, leur IP change à chaque redémarrage. L’objet Service fournit une abstraction stable pour accéder à un groupe de Pods.22

• ClusterIP : Crée une IP virtuelle (VIP) interne. kube-proxy intercepte le trafic vers cette VIP et le redirige vers l’un des Pods backend via des règles iptables ou IPVS. C’est le mode par défaut pour la communication Est-Ouest (interne).11
• NodePort : Ouvre un port statique (plage 30000-32767) sur chaque nœud du cluster. Le trafic arrivant sur ce port est NATé vers le Service. Bien que simple, ce mode n’est pas recommandé pour la production publique car il expose directement les nœuds et utilise des ports non standards.26
• LoadBalancer : S’intègre au fournisseur de cloud (AWS, Azure, GCP) pour provisionner un équilibreur de charge externe (L4) qui pointe vers les NodePorts. C’est la méthode standard pour exposer un service TCP/UDP unique sur le cloud.

3.3 Ingress et l’Évolution vers Gateway API

Pour exposer plusieurs services HTTP/HTTPS sans payer un LoadBalancer par service, on utilise Ingress.

• Architecture : Un objet Ingress définit les règles de routage (ex: api.monsite.com -> Service API, monsite.com/blog -> Service Blog). Un Ingress Controller (comme NGINX, HAProxy, ou Traefik) lit ces règles et configure un proxy inverse pour diriger le trafic.27

Cependant, Ingress a montré ses limites (manque de standardisation des fonctionnalités avancées via des annotations propriétaires). La communauté Kubernetes développe activement Gateway API, une nouvelle norme plus expressive et orientée rôles. Gateway API sépare la définition de l’infrastructure (Gateway, gérée par les Ops) de la définition du routage applicatif (HTTPRoute, gérée par les Devs), offrant un modèle plus robuste pour les environnements multi-équipes.22

3.4 DNS Interne : CoreDNS

La découverte de services repose sur le DNS. CoreDNS est le serveur DNS interne du cluster. Il surveille l’API et crée des enregistrements DNS pour chaque Service.28

Le format standard est : <nom-service>.<namespace>.svc.cluster.local. CoreDNS gère également des enregistrements avancés comme les SRV records pour les ports nommés, permettant aux applications de découvrir dynamiquement le numéro de port d’un service, ce qui est crucial pour les bases de données distribuées ou les services headless.30

Débogage DNS : Les problèmes de résolution DNS sont fréquents (boucles de redirection, timeouts). L’outil dnsutils ou dig exécuté dans un pod de test est essentiel pour diagnostiquer si le problème vient de CoreDNS, de la connectivité réseau ou de la configuration du Pod (ndots, resolv.conf).30

3.5 Network Policies : Le Pare-Feu Interne

Par défaut, Kubernetes est un système “ouvert” : tous les Pods peuvent communiquer entre eux, même entre différents namespaces. Pour sécuriser un cluster, il est impératif d’implémenter des Network Policies. Ces objets permettent de définir des règles de whitelisting (liste blanche) pour le trafic entrant (Ingress) et sortant (Egress) basées sur des labels.32

Recommandation de Sécurité : Adopter une approche “Zero Trust” en appliquant une politique “Deny-All” par défaut dans chaque namespace, puis en ouvrant explicitement les flux nécessaires. Cela empêche un attaquant qui compromet un Pod web frontal d’accéder librement aux bases de données ou aux services internes non protégés.33

4. Gestion des Charges de Travail et Planification

Kubernetes orchestre les applications via des contrôleurs de haut niveau qui gèrent le cycle de vie des Pods.

4.1 Pods et Cycle de Vie

Le Pod est l’unité atomique de Kubernetes. Il encapsule un ou plusieurs conteneurs partageant le même espace de noms réseau et le même stockage.34

Le cycle de vie d’un Pod traverse plusieurs phases : Pending (en attente de planification ou de téléchargement d’image), Running, Succeeded ou Failed. Comprendre les états d’erreur intermédiaires est crucial pour le débogage :

• CrashLoopBackOff : Le processus applicatif plante au démarrage.
• ImagePullBackOff : Erreur d’accès au registre ou image inexistante.
• OOMKilled : Le conteneur a consommé plus de mémoire que sa limite autorisée.

4.2 Contrôleurs de Charge de Travail (Workload Controllers)

Plutôt que de gérer des Pods nus, on utilise des contrôleurs adaptés au type d’application :

• Deployments : Pour les applications sans état (Stateless). Ils gèrent les mises à jour progressives (Rolling Updates) et les rollbacks. Ils utilisent des ReplicaSets en arrière-plan pour assurer le nombre de copies désiré.34
• StatefulSets : Pour les applications avec état (bases de données, files de message). Ils garantissent l’unicité et l’ordre des Pods (web-0, web-1). Chaque Pod reçoit un volume persistant dédié qui le suit même s’il est reprogrammé sur un autre nœud.36
• DaemonSets : Assurent qu’une copie d’un Pod tourne sur tous les nœuds (ou un sous-ensemble). Utilisé pour les agents d’infrastructure comme les collecteurs de logs (Fluentd), les agents de monitoring ou les plugins CNI.34
• Jobs / CronJobs : Pour les tâches éphémères ou planifiées (batch processing, backups).

4.3 Gestion des Ressources et QoS

Pour assurer la stabilité du cluster, il est impératif de définir des demandes (requests) et des limites (limits) de ressources (CPU/RAM) pour chaque conteneur.

Kubernetes utilise ces valeurs pour classer les Pods en trois classes de qualité de service (QoS) qui déterminent leur priorité d’éviction en cas de famine de ressources :

1. Guaranteed : requests = limits pour CPU et RAM. Priorité la plus haute, derniers à être tués.
2. Burstable : requests < limits. Peuvent utiliser plus de ressources si disponibles, mais sont tués avant les Guaranteed.
3. BestEffort : Pas de requests ni limits. Premiers à être tués par l’OOM Killer si le nœud sature.38

L’oubli de ces configurations est une cause majeure d’instabilité en production.39

5. Architecture de Stockage et Persistance

Le stockage dans Kubernetes est abstrait pour permettre la portabilité des applications entre différentes infrastructures (Cloud, On-premise).

5.1 PV et PVC : Le Contrat de Stockage

• PersistentVolume (PV) : Représente une unité de stockage physique (disque EBS, part NFS). C’est une ressource globale au cluster, gérée par l’administrateur.40
• PersistentVolumeClaim (PVC) : Est une requête de stockage émise par un utilisateur (ex: “J’ai besoin de 10 Go en lecture/écriture”). La PVC est liée à un Namespace.41

Le processus de liaison (Binding) associe une PVC à un PV disponible satisfaisant la demande.

5.2 StorageClasses et Provisionnement Dynamique

La création manuelle de PV est fastidieuse. Les StorageClasses permettent l’automatisation. Une StorageClass définit un “profil” de stockage (ex: fast-ssd, cheap-hdd) et un provisionneur. Lorsqu’une PVC demande une classe spécifique, le système appelle dynamiquement le fournisseur de stockage pour créer le volume à la volée.42

• Mode de Liaison (VolumeBindingMode) : Une configuration importante est WaitForFirstConsumer. Avec ce mode, la création du volume est retardée jusqu’à ce que le Pod qui l’utilise soit planifié. Cela est crucial pour les topologies multi-zones : cela garantit que le volume est créé dans la même zone de disponibilité que le nœud où le Pod va atterrir.43

5.3 CSI (Container Storage Interface)

Comme pour le réseau (CNI) et l’exécution (CRI), Kubernetes a standardisé le stockage via CSI. Cela permet aux fournisseurs de stockage de développer leurs propres drivers (plugins) qui s’exécutent comme des Pods dans le cluster, gérant les opérations de montage, démontage, redimensionnement et snapshotting des volumes.5 L’adoption de CSI a massivement élargi la compatibilité de Kubernetes avec les solutions de stockage modernes.

6. Sécurité, Gouvernance et Configuration

La sécurité d’un cluster Kubernetes nécessite une approche en profondeur (“Defense in Depth”).

6.1 Gestion des Secrets et Configuration

• ConfigMaps : Pour les données non sensibles. Elles permettent de découpler la configuration de l’image conteneur, rendant les applications plus portables.44
• Secrets : Pour les données sensibles. Attention : Par défaut, les Secrets sont stockés encodés en base64 (donc lisibles par quiconque a accès à l’API ou à etcd).
  • Bonnes Pratiques : Activer l’Encryption at Rest pour chiffrer les secrets dans etcd.45 Ne jamais commiter de secrets dans Git. Utiliser des outils comme External Secrets Operator pour synchroniser les secrets depuis un coffre-fort externe (Vault, AWS Secrets Manager) vers le cluster.46

6.2 Gouvernance par Politiques (Policy Engines)

RBAC gère l’accès à l’API, mais ne peut pas inspecter le contenu des objets. Pour appliquer des règles métier ou de sécurité fines, on utilise des moteurs de politique via les contrôleurs d’admission.

Comparatif : OPA Gatekeeper vs Kyverno

Critère	OPA Gatekeeper	Kyverno
Philosophie	Générique (Open Policy Agent)	Natif Kubernetes
Langage	Rego (Langage de requête complexe)	YAML (Déclaratif standard)
Portée	Tout (K8s, Terraform, API Gateway)	Spécifique Kubernetes
Mutation	Possible mais complexe	Simple et puissant
Génération	Non	Oui (ex: créer des NetworkPolicies par défaut)
Usage	Entreprises avec besoins transverses	Équipes Ops cherchant la simplicité

Kyverno gagne en popularité car il permet d’écrire des politiques en YAML, le langage natif des administrateurs Kubernetes, facilitant l’adoption.21 OPA reste la référence pour une gouvernance unifiée à travers toute la stack technologique de l’entreprise.48

7. Opérations “Day 2” : Maintenance et Dépannage

Une fois le cluster installé (Day 1), commence la phase critique de l’exploitation continue (Day 2).

7.1 Mises à Jour de Cluster (Cluster Upgrades)

Mettre à jour Kubernetes est une opération à haut risque qui doit suivre une procédure rigoureuse pour éviter les interruptions de service.49 L’outil kubeadm a grandement simplifié ce processus.

Ordre des opérations standard :

1. Mise à jour du Plan de Contrôle : On commence par le nœud maître primaire. kubeadm upgrade plan vérifie la compatibilité. kubeadm upgrade apply met à jour les composants statiques (API Server, Controller Manager, Scheduler).50
2. Mise à jour des Workers : Une fois le plan de contrôle à jour, on procède nœud par nœud (ou par lot).

• Cordon : Marquer le nœud comme non planifiable.
• Drain : kubectl drain <node> --ignore-daemonsets. Cette commande évince les Pods du nœud proprement. C’est ici que les PodDisruptionBudgets (PDB) sont vitaux pour empêcher Kubernetes de tuer trop de répliques d’une application simultanément.50
• Upgrade : Mise à jour des paquets kubeadm et kubelet, puis redémarrage du service kubelet.
• Uncordon : Réactiver le nœud pour qu’il reçoive de nouveaux Pods.

7.2 Sauvegarde et Restauration (Backup & Restore)

La résilience du cluster repose sur la sauvegarde d’etcd.

• Snapshot Etcd : La commande etcdctl snapshot save permet de capturer l’état complet du cluster. Cette sauvegarde doit être externalisée immédiatement.8
• Velero : Pour une approche plus complète, l’outil open-source Velero est incontournable. Il sauvegarde non seulement les manifestes Kubernetes (via l’API), mais aussi les volumes persistants (via des snapshots disques ou Restic), permettant la migration de namespaces entiers ou la reprise après sinistre (Disaster Recovery).52

7.3 Stratégies d’Autoscaling

L’élasticité est l’une des promesses clés de Kubernetes. Elle se décline en trois mécanismes qui doivent être orchestrés avec soin.53

1. Horizontal Pod Autoscaler (HPA) : Ajoute des répliques de Pods.

• Algorithme : Calcule le ratio currentMetric / desiredMetric.
• Requis : Metrics Server doit être installé. Les Pods doivent avoir des requests définies.
• Avancé : Peut scaler sur des métriques custom (ex: longueur d’une file d’attente Kafka) via Prometheus Adapter.54
  2. Vertical Pod Autoscaler (VPA) : Ajuste les ressources (CPU/RAM) d’un Pod existant.
• Usage : Idéal pour les monolithes Java ou les bases de données difficiles à scaler horizontalement.
• Limitation : Nécessite souvent le redémarrage du Pod pour appliquer les changements. Ne pas utiliser HPA (sur CPU/RAM) et VPA conjointement sur le même indicateur!
  3. Cluster Autoscaler (CA) : Ajoute des nœuds à l’infrastructure.
• Déclencheur : Il réagit à la présence de Pods en état Pending qui ne peuvent être planifiés faute de ressources. Il communique avec l’API du Cloud Provider pour provisionner de nouvelles machines.53

7.4 Guide de Dépannage (Troubleshooting)

L’administrateur doit maîtriser l’art du débogage. Voici les scénarios classiques et les actions correctives :

• CrashLoopBackOff : Le conteneur démarre et échoue immédiatement.
  • Diagnostic : kubectl logs (regarder la sortie standard), kubectl describe pod (vérifier l’Exit Code).
  • Causes fréquentes : Erreur de configuration, variable d’environnement manquante, échec de connexion à la base de données.55
• ImagePullBackOff / ErrImagePull :
  • Diagnostic : Vérifier le nom de l’image. Si le registre est privé, vérifier la présence et la validité du Secret imagePullSecrets.
• OOMKilled (Exit Code 137) :
  • Diagnostic : Le conteneur a dépassé sa limite mémoire (limits.memory).
  • Action : Analyser la consommation mémoire de l’application ou augmenter la limite. Attention, c’est le kernel Linux qui tue le processus brutalement.56
• Problèmes Réseau :
  • Outil : kubectl debug -it <pod> --image=nicolaka/netshoot. Cette commande attache un conteneur temporaire rempli d’outils réseaux (dig, curl, tcpdump, nc) au Pod existant, permettant de voir le réseau du point de vue du Pod sans altérer l’image de production.56

8. Conclusion

L’administration de Kubernetes exige une expertise multidimensionnelle. Au-delà de la maîtrise des commandes, c’est la compréhension intime de l’architecture distribuée — du consensus Raft d’etcd aux appels systèmes eBPF de Cilium — qui distingue l’administrateur efficace. Alors que l’écosystème évolue vers une abstraction toujours plus grande (avec les plateformes managées et le serverless), les fondamentaux exposés dans ce rapport restent les piliers indispensables pour garantir la stabilité, la sécurité et la performance des infrastructures modernes.