Kubernetes fonctionne avec une API declarative : on cree des objets, puis le control plane observe et corrige l'etat du cluster.
Guide Kubernetes
Comprendre Kubernetes ressource par ressource
Selectionner un type de ressource, comprendre son role, ses relations, ses champs importants, les commandes utiles et les pieges qui reviennent en production.
20
ressources expliquees
6
pages thematiques
1
lecture orientee terrain
Cette page sert de carte mentale pour savoir quel objet utiliser : Deployment pour du stateless, StatefulSet pour de l'etat, Service pour le reseau, PVC pour le stockage.
Comprendre les ressources evite les manifests copies au hasard et aide a diagnostiquer vite : labels faux, probes absentes, droits trop larges, volumes mal classes.
Workloads
Deployment
Quand l'utiliser
Champs a connaitre
Relations
Points d'attention
Commandes utiles
Exemple minimal
Evolutions Kubernetes
Suivre ce qui change vraiment dans Kubernetes
Les releases Kubernetes ajoutent beaucoup de details, mais les tendances fortes sont lisibles : securite plus declarative, stockage plus riche, Gateway API, meilleures ressources pour l'IA et moins de bricolage autour des webhooks.
Kubernetes evolue par KEPs, cycles de releases et niveaux alpha, beta, stable. Une fonctionnalite stable devient exploitable comme base de plateforme.
Suivre les evolutions aide a savoir quoi adopter, quoi tester en lab, quoi eviter en production et quand remplacer une solution maison.
Une plateforme qui suit les bonnes evolutions reduit la dette : moins d'annotations proprietaires, moins de scripts, plus d'API natives et mieux supportees.
Admission et securite plus natives
Les politiques basees sur CEL et les controles d'admission natifs limitent le besoin de webhooks externes pour valider ou muter des objets simples.
Operations plus previsibles
Les ameliorations autour du kubelet, des groupes Linux, du resize de Pods et des kubeconfigs renforcent la maintenabilite des clusters existants.
Ressources specialisees et stockage
DRA structure les GPU et accelerateurs. Les snapshots, classes de volumes et attributs CSI deviennent plus proches du cycle applicatif.
Gateway API
Remplace progressivement les Ingress charges en annotations. Elle separe GatewayClass, Gateway et Routes pour mieux repartir les responsabilites entre infra et applicatif.
Admission CEL
Permet d'ecrire des validations ou mutations declaratives dans l'API Kubernetes. C'est plus auditable qu'un webhook maison pour les regles simples.
DRA
Dynamic Resource Allocation sert a allouer proprement GPU, FPGA, NIC avancees ou accelerateurs. Important pour IA, HPC et multi-tenant.
Volume Group Snapshot
Vise la coherence de plusieurs volumes lies a une meme application, par exemple base de donnees plus journaux ou plusieurs composants d'un meme service.
PSI metrics
Les Pressure Stall Information aident a comprendre si CPU, memoire ou I/O bloquent reellement les workloads, au-dela d'une simple moyenne d'utilisation.
In-place Pod resize
Permet d'ajuster certaines ressources sans recreer systematiquement un Pod, utile pour reduire les interruptions et mieux dimensionner en production.
Custom Resource Definitions
CRDs : creer ses propres objets Kubernetes
Une CRD ajoute une ressource dans l'API Kubernetes. Avec un controleur, elle devient une API metier complete : l'utilisateur declare un etat voulu, le controleur agit, puis ecrit l'etat observe dans status.
Une CRD definit group, version, kind, schema OpenAPI et colonnes kubectl. Les instances sont stockees dans l'API Kubernetes comme les objets natifs.
Elle permet de modeliser Backup, Database, Certificate, Cluster, Application, Policy ou tout objet de plateforme avec validation, RBAC et audit Kubernetes.
Une CRD remplace des procedures manuelles par une API declarative. Avec un operator, l'exploitation devient reproductible et observable.
1
Modeliser le domaine
Nommer l'objet, separer spec et status, choisir Namespaced ou Cluster, definir les invariants et les erreurs attendues.
2
Ecrire le schema
Utiliser OpenAPI v3, champs requis, enum, contraintes de type, defaults, additionalPrinterColumns et sous-ressource status.
3
Versionner
Prevoir served/storage, conversion webhook si necessaire, compatibilite descendante et migration des champs sensibles.
4
Reconciler
Le controleur observe l'objet, cree ou corrige les ressources dependantes, gere les finalizers et publie des conditions lisibles.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: backups.platform.example
spec:
group: platform.example
scope: Namespaced
names:
plural: backups
singular: backup
kind: Backup
shortNames: ["bk"]
versions:
- name: v1
served: true
storage: true
subresources:
status: {}
additionalPrinterColumns:
- name: Phase
type: string
jsonPath: .status.phase
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required: ["schedule", "target"]
properties:
schedule:
type: string
target:
type: stringspec
Decrit l'etat voulu par l'utilisateur. Le controleur ne doit pas modifier spec sauf cas tres controle, sinon l'API devient confuse.
status
Decrit l'etat observe : phase, conditions, derniere erreur, ressources creees, dates. C'est la zone du controleur.
finalizers
Retardent la suppression pour nettoyer proprement des ressources externes : snapshot, DNS, bucket, volume, entree cloud.
conditions
Exposent Ready, Progressing, Degraded ou Synced avec reason/message. Indispensable pour le support et l'automatisation.
RBAC
Les droits sur une CRD se gerent comme les ressources natives. On peut donner get/list/watch a une equipe et update/status au controleur.
Limites
Une CRD ne doit pas stocker de gros volumes applicatifs. L'API server n'est pas une base metier ni un systeme d'evenements massif.
Kubernetes en entreprise
Passer du cluster a une vraie plateforme
En entreprise, Kubernetes n'est pas seulement un endroit ou lancer des conteneurs. Il devient un socle de gouvernance, securite, observabilite, deploiement, stockage et experience developpeur.
Une plateforme Kubernetes regroupe des conventions, outils et garde-fous autour du cluster : namespaces, RBAC, GitOps, policies, monitoring, sauvegarde, reseau et support.
Elle donne aux equipes un chemin clair pour deployer sans redevenir administrateur cluster a chaque projet.
La valeur vient de la standardisation : moins de derive, plus de securite, des deploiements repetables et des incidents plus faciles a diagnostiquer.
Adoption
Standardiser images, manifests, probes, requests/limits, ingress, labels, namespaces et conventions de nommage.
Industrialisation
Installer GitOps, CI, registry, scans, observabilite, secrets externes, backups et tests de restauration.
Plateforme interne
Offrir templates, golden paths, self-service controle, environnements ephemeres et documentation vivante.
Optimisation
Ameliorer couts, SLO, multi-cluster, policy as code, capacity planning, DRA et automatisation d'exploitation.
Securite
RBAC minimal, admission policies, image scanning, secrets externes, NetworkPolicy, audit API et separation stricte des environnements.
Fiabilite
Readiness/liveness/startup probes, PDB, HPA, alerting, capacity reservee, runbooks et tests de restauration.
FinOps
Requests/limits, quotas, rightsizing, rapports par namespace, retention des logs et strategie de classes de stockage.
Gouvernance
Ownership clair, catalogue de services, revue des versions, lifecycle des namespaces et decisions tracees.
Experience dev
Templates fiables, exemples deployables, logs faciles, port-forward encadre, docs proches du code et feedback CI lisible.
Operations
Patch management, upgrades controles, sauvegarde etcd, supervision du control plane et procedure de gestion d'incident.
Ecosysteme
Choisir les bons outils autour de Kubernetes
Le bon outillage couvre le cycle complet : ecrire, valider, construire, deployer, observer, securiser, sauvegarder et exploiter. Le but n'est pas d'empiler, mais de rendre les operations claires.
Kubernetes fournit le socle. L'ecosysteme ajoute les briques manquantes pour travailler a l'echelle : GitOps, observabilite, policies, secrets, reseau, stockage et dev experience.
Les outils remplacent les actions manuelles fragiles par des flux repetables, audites et comprehensibles par plusieurs equipes.
Sans outillage, le cluster devient vite opaque. Avec les bons choix, on sait ce qui tourne, qui l'a deploye, pourquoi ca echoue et comment restaurer.
CLI et manifests
kubectl, Kustomize, Helm, kubeconform, kubectl-neat. Base quotidienne pour lire, appliquer, valider et simplifier les manifests.
BaseGitOps
Argo CD, Flux, Helm Controller. Le repo Git devient la source de verite et le cluster converge automatiquement.
DeliveryCI/CD
GitLab CI, GitHub Actions, Tekton, Kaniko, BuildKit. Construire, scanner, signer et publier des images reproductibles.
BuildObservabilite
Prometheus, Grafana, Alertmanager, Loki, Tempo, OpenTelemetry, kube-state-metrics. Mesures, logs, traces et alertes.
VoirReseau
Cilium, Calico, CoreDNS, Gateway API, Ingress controllers, ExternalDNS, cert-manager. Entrer, router, chiffrer et isoler.
RouterSecurite
Kyverno, OPA Gatekeeper, Trivy, Falco, External Secrets Operator, Sealed Secrets. Controler sans bloquer les equipes.
ProtegerStockage
Ceph CSI, Rook, Longhorn, OpenEBS, VolumeSnapshots. Donner des volumes dynamiques et restaurables aux applications.
PersisterBackup
Velero, snapshots CSI, backups applicatifs, restic/kopia. Sauvegarder les objets Kubernetes et les donnees utiles.
RestaurerProvisioning
kubeadm, Cluster API, Terraform/OpenTofu, Ansible, Talos, Flatcar. Reconstruire l'infrastructure de facon controlee.
ClusterExperience dev
Skaffold, Tilt, DevSpace, Telepresence, Backstage, Headlamp. Reduire la friction locale et rendre la plateforme visible.
DevPolicy as code
Kyverno, Gatekeeper, ValidatingAdmissionPolicy. Encadrer images, privileges, labels, ressources et exposition reseau.
ReglesCost et capacity
OpenCost, Goldilocks, metrics-server, VPA recommender. Comprendre les couts et dimensionner les workloads proprement.
FinOpsStockage Ceph
Ceph : stockage bloc, fichier et objet pour Kubernetes
Ceph est un systeme de stockage distribue. Il transforme un ensemble de disques et serveurs en plateforme de stockage resiliente, utilisable en RBD, CephFS ou S3/RGW, puis consommable par Kubernetes via CSI.
Au coeur de Ceph, RADOS stocke les objets dans des pools. CRUSH calcule ou placer les donnees, les OSD les stockent, les MON gardent la carte du cluster et les MGR exposent supervision et modules.
Ceph sert a fournir du bloc pour bases de donnees, du fichier partage pour workloads RWX, et de l'objet compatible S3 pour backups, artefacts ou applications cloud native.
Il evite de dependre d'une baie unique : on scale horizontalement, on replique ou erasure-code les donnees, on remplace des disques, et le cluster se reequilibre.
Kubernetes Workload
PVC / StorageClass
Ceph CSI
RBD / CephFS
RADOS Pools
CRUSH placement
OSD + disques
Comment ca fonctionne
L'application demande un PVC. Kubernetes appelle le driver Ceph CSI. CSI cree une image RBD ou un volume CephFS, puis le monte dans le Pod. Ceph place les donnees dans RADOS.
Bloc, fichier, objet
RBD fournit du bloc, CephFS fournit un filesystem partage, RGW expose une API objet compatible S3. Les trois reposent sur RADOS.
Resilience
Les pools peuvent repliquer les donnees ou utiliser l'erasure coding. Si un OSD tombe, Ceph reconstruit selon les regles CRUSH et l'etat des PG.
Point critique
La performance depend du reseau, des disques, du nombre de PG, des tailles d'objets, du type de pool et du placement CRUSH.
Outil d'administration moderne de Ceph. Il deploie les daemons en conteneurs, orchestre MON, MGR, OSD, MDS, RGW, node-exporter et applique les specifications de services.
Les monitors maintiennent les cartes du cluster : monmap, osdmap, pgmap, auth. Il faut un quorum impair pour que le cluster prenne des decisions.
Le manager collecte l'etat, expose le dashboard, les metrics Prometheus, l'orchestrateur cephadm, le balancer et plusieurs modules operationnels.
Object Storage Daemon. Chaque OSD gere typiquement un disque ou volume. Il stocke les objets, replique, recupere, scrub et remonte son etat au cluster.
Algorithme de placement qui calcule ou placer les donnees sans table centrale geante. Il tient compte des hosts, racks, salles, classes de disques et regles de failure domain.
Un pool regroupe des objets avec une politique : replication, erasure coding, nombre de PG, application associee, regle CRUSH et quotas eventuels.
Placement Group. Les objets sont regroupes en PG pour rendre le placement et le reequilibrage gerables. Trop peu de PG limite la repartition, trop en surcharge le cluster.
Unite de stockage interne. RBD decoupe une image bloc en objets, CephFS stocke donnees et metadata, RGW stocke les objets S3 dans RADOS.
Metadata Server pour CephFS. Il gere l'arborescence, les permissions et metadonnees fichier. Les donnees restent dans les OSD, pas dans le MDS.
RADOS Block Device. Fournit des volumes bloc, snapshots, clones, thin provisioning. Tres courant pour PVC ReadWriteOnce de bases de donnees.
Filesystem distribue POSIX. Utile pour ReadWriteMany, contenus partages, pipelines, outils internes. Necessite au moins un MDS actif.
RADOS Gateway expose S3/Swift. Utile pour buckets, backups, artefacts, datalake. Peut etre separe des usages Kubernetes en PVC.
Container Storage Interface. Le driver Ceph CSI relie Kubernetes a Ceph pour provisionner, attacher, monter, snapshotter et agrandir les volumes.
Dans Kubernetes, elle decrit l'offre : provisioner rbd.csi.ceph.com ou cephfs.csi.ceph.com, pool, fsName, reclaimPolicy et expansion.
Verification reguliere de coherence. Le scrub detecte les incoherences, le deep-scrub lit plus profondement les donnees et peut exposer des problemes disque.
Module qui aide a repartir les PG et l'utilisation entre OSD. Utile apres ajout ou retrait de disques, changement de poids ou croissance des pools.
RBD pour quoi ?
Volumes bloc ReadWriteOnce : PostgreSQL, MySQL, Elasticsearch, Redis persistant, volumes applicatifs avec un seul writer.
CephFS pour quoi ?
ReadWriteMany : contenus partages, uploads, outils internes, traitements qui lisent/ecrivent depuis plusieurs Pods.
RGW pour quoi ?
Objet S3 : sauvegardes, images, artefacts CI, exports, datalake, stockage applicatif qui n'a pas besoin de POSIX.
Operations a surveiller
Quorum MON, espace nearfull/full, PG stuck, OSD down/out, latence reseau, slow ops, scrub errors, MDS laggy, saturation des disques.
Bonnes pratiques
Separer reseau public/cluster si possible, monitorer par pool, tester les restaurations, documenter CRUSH, garder des capacites libres.
Pieges classiques
Trop remplir le cluster, melanger HDD et NVMe sans device class, oublier les backups applicatifs, creer des PG au hasard, ne pas surveiller les MDS.