Kubernetes : les bases pour les petites équipes

Vous voulez faire tourner une application qui ne tombe pas en panne quand un processus s'arrête, et qui s'adapte à la charge sans devoir acheter un serveur supplémentaire à trois heures du matin. Kubernetes fait cela, mais il demande un prix d'entrée en complexité que vous devez payer avant d'en voir les bénéfices.

Cet article explique comment faire ces six premières étapes — créer un cluster, déployer une application, l'exposer, la faire évoluer, la mettre à jour — et ce que chaque étape vous coûte. Pour des équipes de deux à dix développeurs qui font tourner des conteneurs et qui n'ont pas d'équipe plateforme dédiée.

Prérequis

Vous avez besoin d'une machine avec au moins 4 Go de RAM et 2 cœurs CPU. Toutes les commandes fonctionnent sous Linux, macOS ou Windows (via WSL2).

• Docker (pour faire tourner les images de nœuds du cluster)
• `kubectl` version 1.28 ou plus récente
• Minikube version 1.31 ou plus récente, ou Kind version 0.20 ou plus récente
• Connaissances de base en YAML et en ligne de commande

Vérifiez vos versions :

kubectl version --client
minikube version
docker --version

Étape 1 : Créez un cluster local

Un cluster Kubernetes se compose d'un plan de contrôle qui gère l'état et de nœuds workers qui exécutent les charges de travail. En production, ce sont des machines séparées ; localement, tout tourne sur une seule machine dans un environnement virtuel.

Minikube est le démarrage le plus rapide :

minikube start --cpus=2 --memory=4096

Cela télécharge une image de nœud et démarre un cluster. Cela prend cinq à dix minutes la première fois, ensuite cela va plus vite.

Si vous choisissez Kind, vous faites tourner Kubernetes dans des conteneurs Docker au lieu d'une VM :

kind create cluster --name pixzo-test

Kind démarre plus vite que Minikube et consomme moins de mémoire, mais il vous manque certaines fonctionnalités comme les load balancers qui fonctionnent dans Minikube. Commencez avec Minikube si vous voulez rester simple ; choisissez Kind si vous avez peu de RAM.

Pourquoi cela vaut ce que cela coûte : vous apprenez la gestion de cluster sur une machine que vous pouvez jeter. Si vous faites des erreurs — et vous en ferez — vous redémarrez le cluster au lieu de réparer un serveur de production.

Étape 2 : Déployez une application

Un Deployment est un manifeste qui décrit quelle image de conteneur doit tourner et combien de réplicas. Kubernetes lit ce fichier et veille à ce que la réalité corresponde à ce qui y est écrit.

Créez un fichier `deployment.yaml` :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80

Déployez-le avec :

kubectl apply -f deployment.yaml

Kubernetes démarre maintenant deux Pods sur les nœuds workers disponibles. Un Pod est la plus petite unité que Kubernetes gère — un conteneur autour d'un ou plusieurs conteneurs qui collaborent et partagent les mêmes ressources réseau et de stockage.

Le point essentiel : Kubernetes vérifie en continu que le nombre de Pods en cours d'exécution correspond à `replicas`. Si un Pod plante, Kubernetes en démarre un nouveau. Vous n'avez pas besoin d'intervenir vous-même.

Étape 3 : Explorez l'application

`kubectl` est votre seule interface vers le cluster. Pratiquement tout ce que vous faites passe par cette commande.

Consultez l'état de vos Pods :

kubectl get pods

La sortie affiche le nom de chaque Pod, son état (`Running`, `Crashing`, `Pending`) et combien de fois il a été redémarré. Si vous voyez `CrashLoopBackOff`, il y a un problème avec le conteneur lui-même — vérifiez les logs :

kubectl logs deployment/nginx-demo

Si vous voulez des détails sur un Pod spécifique, par exemple pourquoi il tourne sur un certain nœud ou quels événements l'ont précédé :

kubectl describe pods

Prenez le temps d'apprendre ces trois commandes. Elles représentent quatre-vingt-dix pour cent de votre interaction quotidienne avec le cluster.

Étape 4 : Exposez l'application

Les Pods sont par défaut uniquement accessibles à l'intérieur du cluster. Ils reçoivent une adresse IP interne qui change dès que le Pod redémarre. Pour un accès externe, vous définissez un Service — un point d'accès stable qui pointe vers les Pods derrière un label.

Créez `service.yaml` :

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx-demo
  ports:
<ul><li>port: 80</li></ul>
    targetPort: 80
    nodePort: 30080

Et activez-le :

kubectl apply -f service.yaml

NodePort rend l'application accessible via le port 30080 sur l'adresse IP de votre nœud Minikube :

minikube service nginx-service --url

Cela ouvre votre navigateur vers la bonne adresse.

Il existe trois types de Services. ClusterIP est uniquement accessible en interne — utile pour la communication entre microservices. NodePort fonctionne pour les tests mais n'est pas adapté à la production. LoadBalancer vous donne une adresse IP externe via votre fournisseur cloud, mais ne fonctionne pas dans Minikube sans configuration supplémentaire.

Commencez avec NodePort. C'est moche mais fonctionnel, et vous apprenez le concept sans réglages spécifiques au fournisseur cloud.

Étape 5 : Faites évoluer l'application

Avec `kubectl scale`, vous ajustez le nombre de réplicas :

kubectl scale deployment/nginx-demo --replicas=5

Kubernetes démarre maintenant trois Pods supplémentaires — ou en arrête deux si vous réduisez à trois. Cela fonctionne manuellement, mais vous pouvez aussi configurer une mise à l'échelle automatique horizontale basée sur l'utilisation du CPU :

kubectl autoscale deployment/nginx-demo --min=2 --max=10 --cpu-percent=70

Cela coûte un composant supplémentaire : le metrics-server. Il collecte les données CPU et mémoire des nodes. Sans metrics-server, la commande d'autoscaling ne fait rien.

Ne passez pas à l'autoscaling trop tôt. La mise à l'échelle manuelle vous apprend de combien de ressources votre application a réellement besoin. La mise à l'échelle automatique basée sur un trafic que vous ne comprenez pas entraîne des coûts que vous n'attendez pas — surtout si vous migrez plus tard vers un fournisseur cloud.

Étape 6 : Mettez à jour l'application

Lorsque vous avez une nouvelle version de votre image, vous mettez à jour le manifeste et vous le réappliquez :

kubectl set image deployment/nginx-demo nginx=nginx:1.28

Kubernetes effectue une mise à jour continue (rolling update) : il remplace progressivement les anciens Pods par de nouveaux, sans interrompre le service. Vérifiez la progression :

kubectl rollout status deployment/nginx-demo

Si quelque chose tourne mal, vous annulez la mise à jour :

kubectl rollout undo deployment/nginx-demo

Ces trois commandes — set, status, undo — constituent votre flux de travail de déploiement. C'est moins avancé que les outils GitOps comme ArgoCD, mais pour une petite équipe, c'est souvent suffisant.

Vérification

Vérifiez que tout fonctionne correctement :

kubectl get pods,deployments,services

La sortie doit afficher cinq Pods en cours d'exécution (si vous avez mis à l'échelle à cinq), un Deployment avec le statut souhaité et un Service avec un port attribué.

Enfin : récupérez l'application via le Service :

curl $(minikube service nginx-service --url)

Vous devriez voir la page nginx par défaut.

Problèmes fréquents

Le Pod reste bloqué dans le statut `Pending`. Le node ne dispose pas de ressources suffisantes. Vérifiez avec `kubectl describe pod` si une limite de ressources est dépassée, et augmentez la mémoire de Minikube : `minikube stop`, puis `minikube start --memory=6144`.

`CrashLoopBackOff` sur nginx. Le conteneur démarre et plante à plusieurs reprises. Consultez les logs avec `kubectl logs deployment/nginx-demo`. C'est souvent une mauvaise balise d'image ou une erreur de configuration dans un volume monté.

`kubectl` ne peut pas se connecter au cluster. Votre `kubectl` local communique avec un autre contexte que votre cluster Minikube. Définissez le contexte avec :

kubectl config use-context minikube

La documentation officielle de Kubernetes est divisée en Concepts, Tasks, Tutorials et References. La section Concepts explique comment les choses fonctionnent, Tasks donne des instructions étape par étape, Tutorials combinent les deux en scénarios, et References contient les détails techniques bruts de l'API. Commencez par les Concepts sur les Pods et les Services, pas par les References — celles-ci se lisent uniquement lorsque vous devez rechercher quelque chose de spécifique.

Kubernetes ne réduit pas la complexité, il la déplace. Vous échangez des scripts de déploiement manuels contre un système que vous devez apprendre à comprendre avant qu'il ne vous apporte quelque chose. La question n'est pas de savoir si vous pouvez le faire fonctionner — n'importe qui peut le faire avec un tutoriel — mais si vous pouvez le maintenir lorsque votre application grandit et que le premier message d'erreur inexpliqué apparaît. C'est le moment où l'investissement porte ses fruits, ou pas.