Kubernetes est devenu le standard de facto de l'orchestration de conteneurs. Mais entre la promesse et la réalité opérationnelle, il y a une courbe d'apprentissage abrupte. Ce qu'il fait, pourquoi c'est puissant, et quand ne pas l'utiliser.
En 2014, Google open-source Borg, son système interne d'orchestration de conteneurs, sous le nom Kubernetes. Dix ans plus tard, le projet est géré par la Cloud Native Computing Foundation (CNCF), compte plus de 88 000 contributeurs, et représente le standard de facto pour déployer des applications conteneurisées à l'échelle. Il n'existe probablement pas de grande infrastructure cloud en 2024 qui n't y soit pas exposée.
Pourtant, Kubernetes reste mal compris — tantôt présenté comme la solution universelle à tous les problèmes de déploiement, tantôt comme une usine à gaz ingérable. La réalité est plus nuancée.
Le problème que Kubernetes résout
Imaginez une application composée de 20 microservices. Chaque service tourne dans un conteneur Docker. Sans orchestration, vous gérez manuellement :
- Sur quel serveur tourne chaque conteneur ?
- Que se passe-t-il si un serveur tombe ? Les conteneurs redémarrent-ils ailleurs ?
- Comment distribuer le trafic entrant entre plusieurs instances du même service ?
- Comment déployer une nouvelle version sans interruption de service ?
- Comment passer de 3 à 30 instances d'un service sous charge ?
- Comment les services communiquent-ils entre eux ?
Kubernetes répond à toutes ces questions avec un modèle déclaratif : vous décrivez l'état souhaité, Kubernetes se charge de l'atteindre et de le maintenir.
Les concepts fondamentaux
Pod — l'unité de base
Un Pod est le plus petit objet déployable dans Kubernetes. Il contient un ou plusieurs conteneurs partageant le même réseau et le même stockage local. En pratique, un Pod = un conteneur applicatif (+ éventuellement des sidecars).
apiVersion: v1
kind: Pod
metadata:
name: mon-app
spec:
containers:
- name: app
image: mon-app:1.4.2
ports:
- containerPort: 3000
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Les Pods sont éphémères — ils naissent et meurent. On ne les gère jamais directement en production.
Deployment — la gestion du cycle de vie
Un Deployment déclare combien de répliques d'un Pod doivent tourner, et gère les mises à jour.
apiVersion: apps/v1
kind: Deployment
metadata:
name: mon-app
spec:
replicas: 3
selector:
matchLabels:
app: mon-app
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: mon-app
spec:
containers:
- name: app
image: mon-app:1.4.2
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
La rollingUpdate garantit qu'au moins 2 instances sur 3 restent disponibles pendant un déploiement. La readinessProbe s'assure que le trafic n'est routé vers un Pod que lorsqu'il est réellement prêt.
Service — l'abstraction réseau
Les Pods ont des IPs éphémères. Un Service expose un groupe de Pods sous une IP stable et un DNS interne, et fait office de load balancer.
apiVersion: v1
kind: Service
metadata:
name: mon-app
spec:
selector:
app: mon-app
ports:
- port: 80
targetPort: 3000
type: ClusterIP # interne au cluster
Ingress — la porte d'entrée
Un Ingress gère le routage HTTP(S) depuis l'extérieur du cluster vers les Services internes. C'est là que se configurent les noms de domaine, le TLS, et les règles de routage par path.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: mon-app
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
rules:
- host: app.mondomaine.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: mon-app
port:
number: 80
tls:
- hosts:
- app.mondomaine.com
secretName: mon-app-tls
ConfigMap et Secret — la configuration externalisée
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
API_URL: "https://api.mondomaine.com"
---
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
DATABASE_PASSWORD: <base64> # idéalement géré par Vault ou External Secrets
Les fonctionnalités qui changent tout
Auto-scaling horizontal (HPA)
Kubernetes peut augmenter ou réduire automatiquement le nombre de répliques d'un Deployment en fonction de métriques — CPU, mémoire, ou métriques custom via Prometheus.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: mon-app
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: mon-app
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Self-healing
Si un Pod crashe, le Deployment en recrée un automatiquement. Si un nœud du cluster tombe, les Pods qui y tournaient sont replanifiés sur d'autres nœuds. Kubernetes surveille en continu l'état réel du cluster et le reconcilie avec l'état déclaré.
Rolling deployments et rollbacks
Un kubectl rollout undo deployment/mon-app revient à la version précédente en quelques secondes. L'historique des déploiements est conservé.
Namespaces — l'isolation logique
Un cluster peut héberger plusieurs équipes ou environnements (dev, staging, prod) via des namespaces, avec des quotas de ressources et des politiques réseau par namespace.
L'écosystème en 2024
Kubernetes seul ne suffit pas. L'écosystème CNCF a maturé autour de lui :
| Besoin | Solution |
|---|---|
| Package manager | Helm |
| GitOps / déploiement déclaratif | ArgoCD, Flux |
| Service mesh | Istio, Linkerd |
| Observabilité | Prometheus + Grafana, OpenTelemetry |
| Gestion des secrets | HashiCorp Vault, External Secrets Operator |
| Certificats TLS | cert-manager |
| Stockage persistant | Rook-Ceph, Longhorn |
| Sécurité des images | Trivy, Falco |
Helm mérite une mention particulière : c'est le gestionnaire de packages de Kubernetes. Un chart Helm est un template de ressources Kubernetes paramétrable — déployer Nginx, PostgreSQL ou une application custom se fait avec une commande et un fichier de valeurs.
Les distributions managées
En 2024, personne ne devrait gérer un cluster Kubernetes from scratch en production. Les cloud providers proposent des offres managées qui gèrent le control plane, les mises à jour et la haute disponibilité :
- Amazon EKS (AWS)
- Google GKE (GCP) — historiquement le plus mature, Google ayant inventé Kubernetes
- Azure AKS (Microsoft)
- OVHcloud Managed Kubernetes pour les équipes qui préfèrent rester en Europe
- k3s pour les environnements edge ou les clusters de développement légers
Quand ne pas utiliser Kubernetes
C'est la question que trop peu se posent.
Kubernetes est complexe. Le control plane implique etcd, kube-apiserver, kube-scheduler, kube-controller-manager. L'opérer correctement nécessite des compétences spécifiques. Le déboguer quand quelque chose ne va pas peut prendre des heures.
Kubernetes est probablement surdimensionné si :
- Votre application est un monolithe avec un ou deux services
- Votre équipe fait moins de 5 développeurs et n'a pas de profil infra dédié
- Votre trafic est prévisible et ne nécessite pas de scaling dynamique
- Vous êtes en phase de validation produit (MVP, early stage)
Dans ces cas, Docker Compose sur un serveur, une PaaS comme Railway, Render ou Fly.io, ou même un simple VPS suffisent. La simplicité opérationnelle a une valeur réelle.
Kubernetes justifie son coût quand :
- Vous avez 10+ services à orchestrer
- Vous avez besoin de déploiements sans interruption de service
- Le scaling automatique est critique pour votre modèle économique
- Vous avez une équipe infra ou plateforme dédiée
La courbe d'apprentissage
C'est la réalité qu'il faut accepter : Kubernetes a une courbe d'apprentissage parmi les plus abruptes de l'écosystème DevOps. Comprendre les concepts de base prend quelques jours. Opérer un cluster en production sereinement prend des mois.
Les ressources recommandées pour 2024 :
- Kubernetes.io — la documentation officielle est excellente
- killer.sh — simulateur d'examen CKA/CKAD pour pratiquer
- k3s + k9s en local pour expérimenter sans frais cloud
- La certification CKA (Certified Kubernetes Administrator) pour valider les acquis
En résumé
Kubernetes a tenu sa promesse : déployer des applications conteneurisées à l'échelle, de façon reproductible, avec haute disponibilité et scaling automatique. C'est un outil remarquable — et remarquablement complexe.
En 2024, la question n'est plus "faut-il connaître Kubernetes ?" pour un développeur backend ou un ingénieur infra. La réponse est oui. La vraie question est "faut-il l'opérer soi-même ?" — et là, la réponse dépend du contexte.