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)

Glissez pour voir

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)

Alternative pour la CI

Pour les pipelines CI/CD, préférez Kind qui démarre plus vite et consomme moins de ressources.

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 :

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 :

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 :

1. Docker de l’hôte : celui que vous utilisez avec docker build
2. 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

Linux

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

macOS

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

Windows

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

Limites temporaires

Ces changements sont perdus au redémarrage. Pour les rendre permanents, ajoutez-les dans /etc/sysctl.conf.

Installer Minikube

Linux

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

macOS

brew install minikube

Windows

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)

Glissez pour voir

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

Glissez pour voir

Définir un driver par défaut

minikube config set driver docker

Vérifier le driver utilisé

minikube profile list

La colonne Driver indique le driver de chaque cluster.

Driver et performances

Le driver docker est le plus simple à configurer. Pour de meilleures performances sur Linux, utilisez kvm2 avec libvirt.

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

# 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

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

minikube profile dev

Cette commande configure aussi kubectl pour utiliser le bon contexte.

Vérification :

kubectl config current-context

dev

Supprimer un profil

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

minikube node add -p multinode

Supprimer un worker

minikube node delete m03 -p multinode

Ressources requises

Chaque nœud consomme les ressources spécifiées. Un cluster de 3 nœuds avec --memory=2048 utilise 6 Go de RAM au total.

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).

Fonctionnement

• 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

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     |
|---------|--------|---------|----------------|---------|--------|-------|

Status HAppy

Le status HAppy indique que tous les control-planes sont opérationnels. Degraded signifie qu’un nœud est en panne (mais le cluster reste fonctionnel).

Vérifier kube-vip et etcd

# 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

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

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
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

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

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

Caveat storage-provisioner

Le storage-provisioner de Minikube est attaché au control-plane primaire. Si ce nœud tombe, les PersistentVolumeClaims peuvent être impactés.

Utiliser kubectl avec Minikube

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

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

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

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

Glissez pour voir

Addon registry cassé (v1.37.0)

L’addon registry a un bug connu : l’image kube-registry-proxy n’existe plus sur GCR. Utilisez plutôt minikube image load ou minikube image build (voir section “Charger des images locales”).

Activer metrics-server

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

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 :

pod.yaml

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

imagePullPolicy obligatoire

Sans imagePullPolicy: Never ou IfNotPresent, Kubernetes tentera de télécharger l’image depuis Docker Hub et échouera. C’est la cause n°1 des erreurs “ImagePullBackOff” avec des images locales.

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:alpine
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

Glissez pour voir

Astuce : utiliser le daemon Docker de Minikube

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

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.

1. 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

2. Lancer le tunnel (dans un terminal séparé) :

   minikube tunnel -p demo

   Le tunnel demande le mot de passe sudo car il modifie les routes réseau.

3. 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

4. Tester l’accès :

   curl http://10.96.7.228

   Hello from Minikube

Comment fonctionne minikube tunnel

minikube tunnel ajoute des routes réseau sur votre machine pour diriger le trafic vers les ClusterIPs de Minikube. C’est pourquoi il nécessite des droits root. Le tunnel doit rester actif pour que les IPs externes fonctionnent.

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.

1. Créer un dossier de test :

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

2. 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[]

3. Utiliser le montage dans un Pod :

   pod-with-mount.yaml

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-mounted
   spec:
     containers:
       - name: nginx
         image: nginx: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>

4. 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.

Le terminal doit rester ouvert

Le processus minikube mount doit rester actif. Si vous fermez le terminal, le montage est perdu et les Pods qui l’utilisent auront des erreurs.

Commandes essentielles

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>)

Glissez pour voir

Dépannage

Problèmes courants

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

Glissez pour voir

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 :

1. Augmentez la mémoire :

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

2. 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 :

1. L’image est dans Docker local mais pas dans Minikube
2. 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 :

1. Augmentez les limites inotify (voir ci-dessus)

2. Libérez de la RAM (6 Go minimum pour 3 nœuds)

3. 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 :

1. Relancez le tunnel avec --cleanup :

   minikube tunnel --cleanup -p demo

2. Vérifiez qu’aucun autre tunnel ne tourne

Réinitialiser complètement Minikube

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

×

📖 Voir la documentation →