Se former à Kubernetes avec Minikube

Ce guide vous permet de créer un cluster Kubernetes local en 5 minutes. Vous apprendrez à démarrer un cluster single-node, multi-nœuds (avec workers), et même un cluster HA (haute disponibilité) avec 3 control-planes. Toutes les commandes ont été testées avec Minikube v1.37.0 et Kubernetes v1.34.0.

Ce que vous saurez faire à la fin :

Installer Minikube et choisir le bon driver
Créer et gérer plusieurs clusters avec les profils
Déployer un cluster multi-nœuds avec workers
Configurer un cluster HA avec kube-vip et etcd distribué
Activer les add-ons utiles (metrics-server, ingress, dashboard)

Quand choisir Minikube

Minikube n'est pas le seul outil pour créer un cluster Kubernetes local. Voici un comparatif pour vous aider à choisir :

Critère	Minikube	Kind	K3s
Cas d'usage	Dev local, apprentissage	CI/CD, tests, clusters jetables	Edge / IoT / homelab, prod légère
Datastore	etcd (kubeadm), HA stacked	etcd (kubeadm) dans les control-planes	SQLite (défaut) ; embedded etcd (HA)
Multi-nœuds	✅ `--nodes`	✅ via config YAML	✅ Natif (server/agent)
HA control plane	✅ `--ha` (min. 3 CP) + kube-vip	✅ multi control-planes (HAProxy)	✅ embedded etcd (min. 3 serveurs)
Ressources	2 CPU, 20 GB disque (défaut)	≥6 GB RAM Docker (8 GB conseillé)	Agent ~275 MiB, Server ~1.6 GiB
GPU	✅ `--gpus` (driver Docker)	⚠️ Pas clé en main	⚠️ À configurer (toolkit + plugin)
Persistance	✅ Profils persistants	⚠️ Plutôt jetable	✅ Cluster système (systemd)
Installation	VM ou conteneur selon driver	Conteneurs Docker "nodes"	Binaire + service (Linux)

Choisissez Minikube si :

Vous débutez avec Kubernetes et voulez un environnement proche de la production
Vous avez besoin de tester la haute disponibilité (HA)
Vous voulez des add-ons prêts à l'emploi (dashboard, metrics, ingress)

Comment fonctionne Minikube

Comprendre l'architecture de Minikube vous aidera à diagnostiquer les problèmes et à choisir le bon driver.

Contrairement à Kind qui utilise des conteneurs Docker comme nœuds, Minikube peut créer des vraies VMs ou des conteneurs selon le driver choisi. C'est ce qui lui permet de supporter des fonctionnalités impossibles avec Kind (GPU, isolation complète).

Architecture avec le driver Docker

Avec le driver docker (le plus courant), chaque nœud est un conteneur Docker qui simule une machine complète :

Architecture Minikube avec driver Docker - nœuds dans des conteneurs

Points clés :

Chaque nœud est un conteneur Docker avec systemd, kubelet, et un runtime conteneur (Docker ou containerd) à l'intérieur
Les pods tournent dans des conteneurs à l'intérieur des conteneurs nœuds
Le réseau entre nœuds passe par le réseau bridge Docker

Architecture avec un driver VM (KVM, VirtualBox)

Avec les drivers VM, chaque nœud est une vraie machine virtuelle :

Architecture Minikube avec driver VM - nœuds dans des machines virtuelles KVM

Avantages des VMs :

Isolation complète (noyau séparé)
Support GPU possible
Plus proche d'un vrai cluster de production

Inconvénients :

Démarrage plus lent (~60s vs ~20s pour Docker)
Consommation mémoire plus élevée

Deux daemons Docker distincts

C'est une source fréquente de confusion : avec le driver Docker, il y a deux daemons Docker :

Docker de l'hôte : celui que vous utilisez avec docker build
Docker du nœud Minikube : celui qui exécute vos pods

Quand vous buildez une image sur l'hôte, elle n'est pas visible dans Minikube. C'est pourquoi vous devez utiliser minikube image load ou configurer votre shell pour utiliser le daemon Minikube :

eval $(minikube docker-env)  # Bascule vers le daemon Minikube
docker build -t mon-app:v1 .  # Build directement dans Minikube
eval $(minikube docker-env -u)  # Revient au daemon local

Prérequis

Avant de commencer, vérifiez que vous avez :

CPU : 2 cœurs minimum (4 recommandés pour HA)
RAM : 2 Go par nœud (6 Go minimum pour un cluster HA de 3 nœuds)
Disque : 20 Go d'espace libre
Docker installé et fonctionnel, Guide d'installation Docker
kubectl installé, Guide kubectl

Vérifier la virtualisation

Les drivers de type VM (kvm2, hyperv, virtualbox) exigent les extensions matérielles VT-x ou AMD-V activées dans le BIOS. Le driver Docker s'en passe, mais la vérification prend deux secondes et évite un échec au premier démarrage.

egrep -q 'vmx|svm' /proc/cpuinfo && echo "Virtualisation OK" || echo "Activez VT-x/AMD-V dans le BIOS"

sysctl -a | grep machdep.cpu.features | grep -i vmx && echo "Virtualisation OK"

Ouvrez PowerShell en administrateur :

systeminfo | findstr /i "virtualization"

Vérifier les limites inotify (Linux)

Pour les clusters multi-nœuds, augmentez les limites inotify si vous rencontrez l'erreur "Too many open files" :

# Vérifier la valeur actuelle
cat /proc/sys/fs/inotify/max_user_instances

# Augmenter si < 256
sudo sysctl -w fs.inotify.max_user_instances=512
sudo sysctl -w fs.inotify.max_user_watches=524288

Installer Minikube

Minikube tient dans un binaire unique : pas de service à activer, pas de dépendance système à gérer. Choisissez l'onglet correspondant à votre poste, le binaire installé pilotera ensuite le driver que vous lui indiquerez.

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
rm minikube-linux-amd64

brew install minikube

choco install minikube

Ou téléchargez depuis le site officiel.

Vérification :

minikube version

minikube version: v1.37.0
commit: ad9b7f9756e14c8a15088a1899398d41a96d77d8

Démarrer un cluster single-node

Le cas le plus simple : un seul nœud qui fait office de control-plane et de worker.

minikube start --driver=docker --cpus=2 --memory=2048 --profile=demo

Option	Description
`--driver=docker`	Utilise Docker comme hyperviseur (recommandé)
`--cpus=2`	Alloue 2 CPU au cluster
`--memory=2048`	Alloue 2 Go de RAM
`--profile=demo`	Nom du cluster (permet d'en avoir plusieurs)

Vérification :

kubectl get nodes -o wide

NAME   STATUS   ROLES           AGE   VERSION   INTERNAL-IP    OS-IMAGE
demo   Ready    control-plane   30s   v1.34.0   192.168.49.2   Ubuntu 22.04.5 LTS

minikube profile list

|---------|--------|---------|--------------|---------|--------|-------|
| Profile | Driver | Runtime |      IP      | Version | Status | Nodes |
|---------|--------|---------|--------------|---------|--------|-------|
| demo    | docker | docker  | 192.168.49.2 | v1.34.0 | OK     | 1     |
|---------|--------|---------|--------------|---------|--------|-------|

Choisir le bon driver

Le driver détermine comment Minikube crée les nœuds du cluster.

Driver	OS	Performance	Cas d'usage
docker	Tous	⭐⭐⭐	Recommandé par défaut
kvm2	Linux	⭐⭐⭐⭐	Meilleure isolation
hyperkit	macOS	⭐⭐⭐	Alternative à Docker Desktop
hyperv	Windows	⭐⭐⭐	Hyper-V natif
virtualbox	Tous	⭐⭐	Compatibilité maximale
podman	Linux	⭐⭐⭐	Alternative à Docker

Définir un driver par défaut

Cette valeur est enregistrée dans la configuration de Minikube et s'applique à tous les minikube start suivants, ce qui évite de répéter --driver à chaque commande.

minikube config set driver docker

Vérifier le driver utilisé

Le driver est figé au moment de la création du profil : en changer impose de supprimer puis de recréer le cluster.

minikube profile list

La colonne Driver indique le driver de chaque cluster.

Gérer plusieurs clusters avec les profils

Un profil Minikube = un cluster Kubernetes indépendant. Chaque profil a ses propres ressources, son driver et sa configuration.

Créer plusieurs profils

Chaque --profile produit un cluster entièrement séparé, avec son propre réseau, ses propres nœuds et ses propres ressources. Les deux clusters ci-dessous peuvent tourner simultanément si votre machine le supporte.

# Cluster de développement
minikube start --profile=dev --cpus=2 --memory=2048 --driver=docker

# Cluster de test avec plus de ressources
minikube start --profile=test --cpus=4 --memory=4096 --driver=docker

Lister les profils

La sortie donne l'essentiel en une ligne par cluster : le driver utilisé, l'adresse IP à contacter, la version de Kubernetes déployée et le nombre de nœuds actifs.

minikube profile list

|---------|--------|---------|--------------|---------|--------|-------|
| Profile | Driver | Runtime |      IP      | Version | Status | Nodes |
|---------|--------|---------|--------------|---------|--------|-------|
| dev     | docker | docker  | 192.168.49.2 | v1.34.0 | OK     | 1     |
| test    | docker | docker  | 192.168.58.2 | v1.34.0 | OK     | 1     |
|---------|--------|---------|--------------|---------|--------|-------|

Basculer entre profils

Basculer de profil ne redémarre aucun cluster : cela change simplement celui que les prochaines commandes minikube viseront par défaut.

minikube profile dev

Cette commande configure aussi kubectl pour utiliser le bon contexte.

Vérification :

kubectl config current-context

dev

Supprimer un profil

La suppression est définitive et ne demande aucune confirmation : le cluster, ses images en cache et ses volumes disparaissent en une commande.

minikube delete --profile=test

Cluster multi-nœuds (workers)

Pour simuler un environnement plus réaliste avec des workers dédiés :

minikube start --nodes=3 --driver=docker --cpus=2 --memory=2048 --profile=multinode

Cette commande crée :

1 control-plane (multinode)
2 workers (multinode-m02, multinode-m03)

Vérification :

kubectl get nodes -o wide

NAME            STATUS   ROLES           AGE   VERSION   INTERNAL-IP
multinode       Ready    control-plane   60s   v1.34.0   192.168.49.2
multinode-m02   Ready    <none>          30s   v1.34.0   192.168.49.3
multinode-m03   Ready    <none>          15s   v1.34.0   192.168.49.4

Ajouter un worker à un cluster existant

Le nœud ajouté est un worker par défaut. Il rejoint le cluster en quelques secondes et apparaît avec le rôle <none> dans kubectl get nodes.

minikube node add -p multinode

Supprimer un worker

L'argument attendu est le suffixe du nœud (m03), pas son nom complet. Les pods qui y tournaient sont replanifiés sur les nœuds restants.

minikube node delete m03 -p multinode

Cluster HA (haute disponibilité)

Le mode HA (High Availability) crée un cluster avec 3 control-planes, chacun exécutant son propre etcd. Cette topologie est identique à celle recommandée pour la production (stacked etcd).

Architecture HA Minikube avec kube-vip

Fonctionnement

Trois mécanismes se combinent dans ce mode. Le point à retenir est que la VIP (l'adresse IP virtuelle) devient le point d'entrée unique du cluster, à la place de l'adresse d'un nœud particulier : c'est ce qui rend la panne d'un control-plane transparente pour kubectl.

kube-vip gère une IP virtuelle (VIP) partagée entre les 3 control-planes
En mode ARP, kube-vip redirige le trafic vers le leader actuel
Si le leader tombe, un autre control-plane prend le relais automatiquement
Les 3 instances etcd se synchronisent entre elles

Créer un cluster HA

L'option --ha impose un minimum de trois control-planes. Attention aux valeurs de CPU et de mémoire : elles s'appliquent à chaque nœud, pas au cluster entier.

minikube start --ha --driver=docker --cpus=2 --memory=2048 --profile=ha-demo

Le démarrage prend quelques minutes (3 nœuds à provisionner).

Vérification :

kubectl get nodes -o wide

NAME          STATUS   ROLES           AGE   VERSION   INTERNAL-IP
ha-demo       Ready    control-plane   60s   v1.34.0   192.168.49.2
ha-demo-m02   Ready    control-plane   40s   v1.34.0   192.168.49.3
ha-demo-m03   Ready    control-plane   20s   v1.34.0   192.168.49.4

minikube profile list

|---------|--------|---------|----------------|---------|--------|-------|
| Profile | Driver | Runtime |       IP       | Version | Status | Nodes |
|---------|--------|---------|----------------|---------|--------|-------|
| ha-demo | docker | docker  | 192.168.49.254 | v1.34.0 | HAppy  | 3     |
|---------|--------|---------|----------------|---------|--------|-------|

Vérifier kube-vip et etcd

Deux séries de pods doivent apparaître, avec une instance de chaque par control-plane. Un pod manquant signale un nœud qui n'a pas terminé de rejoindre le cluster.

# Pods kube-vip (un par control-plane)
kubectl get pods -n kube-system | grep kube-vip

kube-vip-ha-demo       1/1     Running   0   2m
kube-vip-ha-demo-m02   1/1     Running   0   90s
kube-vip-ha-demo-m03   1/1     Running   0   60s

# Pods etcd (un par control-plane)
kubectl get pods -n kube-system | grep etcd

etcd-ha-demo       1/1     Running   0   2m
etcd-ha-demo-m02   1/1     Running   0   90s
etcd-ha-demo-m03   1/1     Running   0   60s

Vérifier la VIP dans kubeconfig

C'est le contrôle qui prouve que la haute disponibilité est réellement active : kubectl doit viser la VIP et non l'adresse d'un nœud précis.

kubectl config view --minify | grep server

server: https://192.168.49.254:8443

L'IP 192.168.49.254 est la VIP gérée par kube-vip, pas l'IP d'un nœud spécifique.

Ajouter un worker au cluster HA

Sans l'option --control-plane, le nœud rejoint le cluster comme simple worker : les trois control-planes restent inchangés.

minikube node add -p ha-demo

kubectl get nodes

NAME          STATUS   ROLES           AGE   VERSION
ha-demo       Ready    control-plane   5m    v1.34.0
ha-demo-m02   Ready    control-plane   4m    v1.34.0
ha-demo-m03   Ready    control-plane   3m    v1.34.0
ha-demo-m05   Ready    <none>          30s   v1.34.0

Simuler une panne de control-plane

Supprimer un control-plane sur trois laisse le quorum etcd intact, deux membres sur trois restant disponibles. Le cluster continue donc de répondre, c'est exactement ce que la topologie HA cherche à démontrer.

# Supprimer un control-plane
minikube node delete m02 -p ha-demo

minikube profile list

|---------|--------|---------|----------------|---------|----------|-------|
| Profile | Driver | Runtime |       IP       | Version |  Status  | Nodes |
|---------|--------|---------|----------------|---------|----------|-------|
| ha-demo | docker | docker  | 192.168.49.254 | v1.34.0 | Degraded | 2     |
|---------|--------|---------|----------------|---------|----------|-------|

Le cluster passe en Degraded mais reste fonctionnel.

Restaurer un control-plane

L'option --control-plane est indispensable ici : sans elle, Minikube ajoute un worker et le cluster reste affiché en Degraded.

minikube node add --control-plane -p ha-demo

Le status revient à HAppy une fois le nœud synchronisé.

Utiliser kubectl avec Minikube

Minikube et kubectl restent deux outils distincts : le premier fabrique le cluster, le second lui parle. Au démarrage, Minikube écrit un contexte dans votre fichier ~/.kube/config et le sélectionne, ce qui explique que kubectl fonctionne immédiatement après un minikube start.

kubectl intégré

Si kubectl n'est pas installé, Minikube fournit une version intégrée :

minikube kubectl -- get nodes

Configurer kubectl

Minikube configure automatiquement le contexte kubectl lors du minikube start. Pour basculer manuellement :

kubectl config use-context ha-demo

Vérifier l'état du cluster

cluster-info interroge réellement l'API du cluster. Une réponse confirme donc d'un coup que le certificat, le réseau et le contexte kubectl sont cohérents.

kubectl cluster-info

Kubernetes control plane is running at https://192.168.49.254:8443
CoreDNS is running at https://192.168.49.254:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Add-ons utiles

Les add-ons sont des extensions prêtes à l'emploi. Minikube en propose plus de 40.

Lister les add-ons

La liste est propre à chaque profil, d'où l'option -p. Un add-on activé sur un cluster ne l'est pas sur les autres.

minikube addons list -p ha-demo | grep -E "enabled|dashboard|ingress|metrics"

| dashboard       | ha-demo | disabled | Kubernetes |
| ingress         | ha-demo | disabled | Kubernetes |
| metrics-server  | ha-demo | disabled | Kubernetes |

Add-ons recommandés

Ces trois extensions couvrent la majorité des besoins en apprentissage. metrics-server conditionne la commande kubectl top, qui ne renvoie rien tant qu'il n'est pas activé.

Add-on	Description	Commande
metrics-server	Métriques CPU/RAM pour `kubectl top`	`minikube addons enable metrics-server`
dashboard	Interface web Kubernetes	`minikube addons enable dashboard`
ingress	Contrôleur Ingress NGINX	`minikube addons enable ingress`

Activer metrics-server

L'activation déploie le composant et rend la main immédiatement, mais les premières métriques n'apparaissent qu'après une à deux minutes de collecte.

minikube addons enable metrics-server -p ha-demo

Vérification (après 1-2 minutes) :

kubectl top nodes

NAME          CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
ha-demo       150m         7%     1200Mi          60%
ha-demo-m02   120m         6%     1100Mi          55%
ha-demo-m03   110m         5%     1050Mi          52%

Ouvrir le dashboard

La commande active l'add-on si nécessaire, ouvre un proxy local puis lance le navigateur. Le proxy vit le temps de la commande : l'interrompre coupe l'accès au tableau de bord.

minikube dashboard -p ha-demo

Cette commande ouvre automatiquement le navigateur.

Charger des images locales

Le problème : Vous avez buildé une image Docker sur votre machine, mais quand vous la déployez dans Minikube, Kubernetes ne la trouve pas.

Pourquoi ? Minikube utilise son propre daemon Docker (ou containerd) à l'intérieur du nœud. Votre image existe dans Docker sur l'hôte, pas dans le nœud Minikube. Ce sont deux environnements séparés.

Minikube propose plusieurs solutions, bien plus pratiques que Kind.

Méthode 1 : minikube image load (copier une image existante)

Copie une image depuis Docker local vers le cache d'images Minikube :

# Builder votre image (dans Docker local)
docker build -t mon-app:v1 .

# Copier vers Minikube
minikube image load mon-app:v1 -p demo

Vérifiez que l'image est disponible dans le cluster :

minikube image ls -p demo | grep mon-app

docker.io/library/mon-app:v1

Déployer l'image :

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: app
      image: mon-app:v1
      imagePullPolicy: Never  # IMPORTANT : ne pas tenter de pull

Méthode 2 : minikube image build (builder directement dans Minikube)

Avantage majeur : Pas besoin de copier l'image, elle est buildée directement dans le nœud Minikube.

# Créer un Dockerfile de test
cat > /tmp/Dockerfile << 'EOF'
FROM nginx:1.31.3-alpine@sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752
RUN echo "<h1>Built in Minikube!</h1>" > /usr/share/nginx/html/index.html
EOF

# Builder directement dans Minikube
minikube image build -t my-nginx:v1 /tmp -p demo

...
Successfully built abc123def456
Successfully tagged my-nginx:v1

Vérifiez :

minikube image ls -p demo | grep my-nginx

docker.io/library/my-nginx:v1

Quand utiliser image build vs image load ?

Méthode	Cas d'usage
`image load`	Vous avez déjà buildé l'image avec Docker
`image build`	Vous voulez builder dans le contexte Minikube directement

Pour builder avec Docker directement dans Minikube :

eval $(minikube docker-env -p demo)
docker build -t mon-app:v1 .

Toutes les commandes Docker utilisent maintenant le daemon du nœud Minikube. Pour revenir au Docker local : eval $(minikube docker-env -u)

Exposer des services

Un cluster local n'a ni adresse publique ni équilibreur de charge fourni par un cloud. Minikube comble ce manque de deux manières selon le type de Service : une URL directe pour un NodePort, et un tunnel réseau pour un LoadBalancer.

Services NodePort

Minikube simplifie l'accès aux services NodePort :

# Déployer une app
kubectl create deployment nginx --image=nginx:alpine
kubectl expose deployment nginx --type=NodePort --port=80

# Obtenir l'URL d'accès
minikube service nginx --url -p demo

http://192.168.49.2:31234

Pour ouvrir directement dans le navigateur :

minikube service nginx -p demo

Services LoadBalancer avec minikube tunnel

Le problème : En production, un service de type LoadBalancer obtient une IP externe du cloud provider. En local, Minikube ne peut pas attribuer d'IP, votre service reste en EXTERNAL-IP: <pending> indéfiniment.

La solution : minikube tunnel crée un tunnel réseau qui attribue des IPs externes aux services LoadBalancer.

Créer un service LoadBalancer :

kubectl create deployment echo --image=hashicorp/http-echo:0.2.3 \
  -- -text="Hello from Minikube"
kubectl expose deployment echo --type=LoadBalancer --port=80 --target-port=5678

Sans tunnel, le service reste en pending :

kubectl get svc echo

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
echo   LoadBalancer   10.96.7.228   <pending>     80:31234/TCP   10s

Lancer le tunnel (dans un terminal séparé) :
Fenêtre de terminal
```
minikube tunnel -p demo
```
Le tunnel demande le mot de passe sudo car il modifie les routes réseau.

Vérifier l'IP externe :

kubectl get svc echo

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
echo   LoadBalancer   10.96.7.228   10.96.7.228    80:31234/TCP   30s

Tester l'accès :

curl http://10.96.7.228

Hello from Minikube

Partager des fichiers avec minikube mount

Cas d'usage : Vous développez une application et voulez voir les modifications en temps réel sans rebuilder l'image à chaque changement.

minikube mount crée un montage réseau entre un dossier de votre machine et le nœud Minikube.

Créer un dossier de test :

mkdir -p /tmp/minikube-share
echo "<h1>Hello from host!</h1>" > /tmp/minikube-share/index.html

Monter le dossier (dans un terminal séparé) :

minikube mount /tmp/minikube-share:/mnt/share -p demo

📁  Montage hôte /tmp/minikube-share dans VM en tant que /mnt/share...
    ▪ Identifiant de montage: minikube-share
    ▪ Options de montage: map[]

Utiliser le montage dans un Pod :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-mounted
spec:
  containers:
    - name: nginx
      image: nginx:1.31.3-alpine
      volumeMounts:
        - name: host-files
          mountPath: /usr/share/nginx/html
  volumes:
    - name: host-files
      hostPath:
        path: /mnt/share  # Chemin DANS le nœud Minikube
        type: Directory

kubectl apply -f pod-with-mount.yaml
kubectl port-forward pod/nginx-mounted 8080:80 &
curl http://localhost:8080

<h1>Hello from host!</h1>

Modifier le fichier sur l'hôte :

echo "<h1>Modified!</h1>" > /tmp/minikube-share/index.html
curl http://localhost:8080

<h1>Modified!</h1>

Attention : Le montage utilise 9p sur réseau. C'est fonctionnel pour le développement mais pas pour des workloads intensifs en I/O.

Commandes essentielles

Ce tableau rassemble les commandes utilisées tout au long du guide. Notez la présence systématique de l'option -p : sans elle, Minikube agit sur le profil actif, qui n'est pas toujours celui que vous avez en tête.

Action	Commande
Démarrer un cluster	`minikube start -p <profil>`
Arrêter un cluster	`minikube stop -p <profil>`
Supprimer un cluster	`minikube delete -p <profil>`
Status d'un cluster	`minikube status -p <profil>`
SSH dans un nœud	`minikube ssh -p <profil>`
Logs Minikube	`minikube logs -p <profil>`
IP du cluster	`minikube ip -p <profil>`
Exposer un service	`minikube service <nom> -p <profil>`
Tunnel LoadBalancer	`minikube tunnel -p <profil>`
Charger une image	`minikube image load <image> -p <profil>`
Builder une image	`minikube image build -t <tag> <path> -p <profil>`
Lister les images	`minikube image ls -p <profil>`
Monter un dossier	`minikube mount <local>:<distant> -p <profil>`
Utiliser Docker Minikube	`eval $(minikube docker-env -p <profil>)`

Dépannage

Les pannes rencontrées avec Minikube sont peu nombreuses et très reproductibles. Trois causes dominent : le manque de mémoire allouée, les limites inotify du noyau Linux sur les clusters multi-nœuds, et la confusion entre le stock d'images de l'hôte et celui du nœud.

Problèmes courants

Le tableau donne la correspondance directe entre le symptôme affiché et le geste correctif. Les cas les plus fréquents sont détaillés juste après, avec le diagnostic complet.

Symptôme	Cause probable	Solution
"Too many open files"	Limites inotify	`sysctl fs.inotify.max_user_instances=512`
Nœud "NotReady" longtemps	Manque de RAM	Augmentez `--memory`, libérez de la RAM
`ImagePullBackOff` image locale	`imagePullPolicy: Always`	Utilisez `imagePullPolicy: Never`
LoadBalancer en `<pending>`	Pas de tunnel	Lancez `minikube tunnel`
Service inaccessible	Mauvaise IP	Utilisez `minikube service --url`
`minikube mount` échoue	Firewall bloque 9p	Autorisez le port 37453
Addon registry cassé	Bug v1.37.0	Utilisez `minikube image load` à la place

Erreur "Too many open files"

Symptôme : Le nœud ne démarre pas avec l'erreur "Failed to create control group inotify object".

Solution :

sudo sysctl -w fs.inotify.max_user_instances=512
sudo sysctl -w fs.inotify.max_user_watches=524288

Pour rendre permanent, ajoutez dans /etc/sysctl.conf :

fs.inotify.max_user_instances=512
fs.inotify.max_user_watches=524288

Erreur "kubelet is not healthy"

Symptôme : Un nœud reste en "NotReady" pendant plusieurs minutes.

Diagnostic :

# Vérifier les ressources Docker
docker stats --no-stream

# Voir les logs du nœud
minikube logs -p <profil> | tail -50

# SSH et vérifier systemd
minikube ssh -p <profil>
systemctl status kubelet

Solutions :

Augmentez la mémoire :

minikube delete -p <profil>
minikube start --memory=4096 -p <profil>

Vérifiez que Docker a assez de ressources (Docker Desktop → Preferences)

Image locale non trouvée (ImagePullBackOff)

Symptôme : Votre Pod reste en ImagePullBackOff alors que l'image existe.

Causes possibles :

L'image est dans Docker local mais pas dans Minikube
imagePullPolicy n'est pas configuré

Solution :

# Vérifier que l'image est dans Minikube
minikube image ls -p demo | grep mon-app

# Si absente, la charger
minikube image load mon-app:v1 -p demo

# Vérifier le manifest
# Doit avoir : imagePullPolicy: Never ou IfNotPresent

Cluster HA bloqué en "Starting"

Symptôme : Le 3ème control-plane ne démarre pas.

Solutions :

Augmentez les limites inotify (voir ci-dessus)
Libérez de la RAM (6 Go minimum pour 3 nœuds)

Supprimez et recréez :

minikube delete -p ha-demo
minikube start --ha -p ha-demo

minikube tunnel ne fonctionne pas

Symptôme : L'IP externe reste <pending> malgré le tunnel.

Diagnostic :

# Vérifier que le tunnel tourne
ps aux | grep "minikube tunnel"

# Vérifier les routes
ip route | grep 10.96

Solutions :

Relancez le tunnel avec --cleanup :
Fenêtre de terminal
```
minikube tunnel --cleanup -p demo
```
Vérifiez qu'aucun autre tunnel ne tourne

Réinitialiser complètement Minikube

À réserver au dernier recours. L'option --purge efface aussi les images mises en cache, que le prochain démarrage devra retélécharger intégralement.

minikube delete --all --purge

Cette commande supprime tous les clusters et le répertoire ~/.minikube.

À retenir

Minikube crée des clusters Kubernetes locaux pour l'apprentissage et le dev
Le driver docker est recommandé (léger), kvm2 pour l'isolation complète
Les profils permettent de gérer plusieurs clusters indépendants
Le mode multi-nœuds (--nodes=N) simule un cluster avec workers
Le mode HA (--ha) crée 3 control-planes avec kube-vip et etcd distribué
minikube image load copie une image locale vers le cluster
minikube image build builde directement dans le nœud (plus simple)
minikube tunnel attribue des IPs externes aux services LoadBalancer
minikube mount partage des fichiers entre l'hôte et le cluster
Les add-ons ajoutent des fonctionnalités (metrics, dashboard, ingress)
Augmentez inotify pour les clusters multi-nœuds sur Linux

Prochaines étapes

Maîtriser kubectl Commandes essentielles pour interagir avec Kubernetes

Déployer avec Helm Gestionnaire de packages pour Kubernetes

Kubernetes en production Concepts et bonnes pratiques pour la production

Kind pour la CI/CD Alternative légère pour les pipelines