Setup : Minikube, Helm et kubectl

Ce module installe l'environnement nécessaire à tout le lab. À la fin, vous aurez un cluster Kubernetes local prêt à recevoir la stack d'observabilité.

Durée estimée

20 minutes (plus si téléchargements lents)

Prérequis système

Ces valeurs sont celles de la machine hôte, pas du cluster : Minikube y taillera ensuite une VM ou un conteneur. Le cluster en réserve 10 Go, et le poste doit garder de la marge au-delà, sinon l'hôte se met à swapper dès que l'application de démonstration démarre.

• RAM : 16 Go recommandés. Un poste de 8 Go démarre un cluster réduit, au risque de pods bloqués en Pending au module 01
• CPU : 4 cœurs disponibles
• Disque : 20 Go libres

Installation

Trois binaires sont nécessaires : kubectl pour parler au cluster, minikube pour le créer, helm pour installer les composants d'observabilité. Sous Linux, ils s'installent en téléchargeant l'archive officielle et sa somme de contrôle, puis en vérifiant l'empreinte avec sha256sum --check avant d'installer quoi que ce soit : c'est ce qui garantit que le binaire posé dans /usr/local/bin est bien celui publié par le projet. Sous macOS et Windows, le gestionnaire de paquets fait cette vérification pour vous.

Linux

kubectl

stable.txt renvoie le numéro de la dernière version stable, réutilisé pour télécharger le binaire et son empreinte. sha256sum --check doit répondre kubectl: Réussi (kubectl: OK en anglais) : si ce n'est pas le cas, arrêtez-vous là.

KUBECTL_VERSION="$(curl -L -s https://dl.k8s.io/release/stable.txt)"
curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
rm kubectl kubectl.sha256
kubectl version --client

Minikube

Le fichier .sha256 publié à côté du binaire ne contient que l'empreinte, sans nom de fichier : la commande echo reconstitue le format attendu par sha256sum --check.

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64.sha256
echo "$(cat minikube-linux-amd64.sha256)  minikube-linux-amd64" | sha256sum --check
sudo install minikube-linux-amd64 /usr/local/bin/minikube
rm minikube-linux-amd64 minikube-linux-amd64.sha256
minikube version

Helm

Helm publie une archive et un fichier .sha256sum par version : on vérifie l'archive avant de l'extraire, jamais l'inverse. Adaptez HELM_VERSION si vous visez une autre version que celle utilisée dans ce lab.

HELM_VERSION="v4.1.0"
curl -LO "https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz"
curl -LO "https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz.sha256sum"
sha256sum --check "helm-${HELM_VERSION}-linux-amd64.tar.gz.sha256sum"
tar -xzf "helm-${HELM_VERSION}-linux-amd64.tar.gz"
sudo install -o root -g root -m 0755 linux-amd64/helm /usr/local/bin/helm
rm -rf linux-amd64 "helm-${HELM_VERSION}-linux-amd64.tar.gz" "helm-${HELM_VERSION}-linux-amd64.tar.gz.sha256sum"
helm version

macOS

kubectl

Homebrew vérifie l'empreinte de la formule lors de l'installation, aucune vérification manuelle n'est nécessaire.

brew install kubectl
kubectl version --client

Minikube

Sur macOS, Minikube s'appuie par défaut sur Docker Desktop : installez-le avant de lancer le cluster.

brew install minikube
minikube version

Helm

helm version doit renvoyer une version 4.x pour rester aligné avec les commandes de ce lab.

brew install helm
helm version

Windows

kubectl

Ces commandes s'exécutent dans un terminal PowerShell ouvert en administrateur, sinon Chocolatey refuse d'écrire dans son répertoire d'installation.

choco install kubernetes-cli
kubectl version --client

Minikube

Le paquet installe le binaire mais pas d'hyperviseur : Docker Desktop ou Hyper-V doit être opérationnel avant le premier minikube start.

choco install minikube
minikube version

Helm

Le paquet Chocolatey s'appelle kubernetes-helm, pas helm.

choco install kubernetes-helm
helm version

Vérification automatique

Si vous avez cloné le dépôt, utilisez le script de vérification :

git clone https://github.com/stephrobert/lab-observability.git
cd lab-observability
chmod +x 00-setup/verify.sh
./00-setup/verify.sh

Sortie attendue :

=== Vérification des prérequis ===

✅ minikube : minikube version: v1.37.0
✅ kubectl : error: unknown flag: --short
✅ helm : v4.1.0+g4553a0a
✅ docker : Docker version 29.1.3, build f52814d

=== Vérification des ressources ===
✅ RAM : 46 Go disponibles

✅ Tous les prérequis sont satisfaits !

Prochaine étape :
  minikube start --memory=10240 --cpus=4 --driver=docker

La ligne kubectl de cette sortie trahit un défaut du script : il interroge kubectl avec --short, une option retirée des versions récentes, et l'affiche en vert malgré l'erreur. Contrôlez kubectl vous-même avec kubectl version --client, qui doit afficher un numéro de version.

Démarrer Minikube

Créez votre cluster avec suffisamment de ressources pour le lab. Les valeurs passées ici sont figées à la création : changer --memory ou --cpus plus tard suppose de détruire le cluster avec minikube delete puis de le recréer. Le premier démarrage télécharge l'image de base et prend plusieurs minutes ; les suivants sont bien plus rapides. --kubernetes-version fige la version du cluster pour que les sorties des modules suivants correspondent aux vôtres.

minikube start \
  --memory=10240 \
  --cpus=4 \
  --driver=docker \
  --kubernetes-version=v1.32.0

10 Go de RAM minimum

L'application OpenTelemetry Demo déploie ~25 pods. Avec 8 Go, certains pods risquent de rester en Pending par manque de ressources. 10 Go est le minimum recommandé.

Driver Docker recommandé. Le driver Docker est le plus stable. Si vous préférez VirtualBox ou KVM, adaptez --driver.

Vérifiez que le cluster fonctionne :

kubectl cluster-info
kubectl get nodes

Sortie attendue :

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

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m14s   v1.32.0

Configurer les addons utiles

Les addons Minikube sont des composants préconfigurés que le cluster déploie à la demande. metrics-server est le seul réellement indispensable ici : sans lui, kubectl top répond Metrics API not available et vous ne pourrez pas comparer les mesures de la stack d'observabilité avec celles de Kubernetes. Chaque activation crée des pods dans kube-system, comptez quelques dizaines de secondes avant qu'ils soient Running.

# Metrics server (pour kubectl top)
minikube addons enable metrics-server

# Dashboard Kubernetes (optionnel)
minikube addons enable dashboard

# Ingress (pour exposer les services)
minikube addons enable ingress

Vérifiez les addons actifs :

minikube addons list | grep enabled

Ajouter les repos Helm

Un repository Helm est un index de charts hébergé en HTTP ; Helm ne connaît que ceux que vous déclarez localement. Ces trois dépôts couvrent l'ensemble des composants installés dans le lab. helm repo update est obligatoire après un add : sans lui, l'index local reste vide et les helm install échouent avec chart not found.

# Prometheus Community (Prometheus, Alertmanager)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# Grafana (Grafana, Loki, Tempo)
helm repo add grafana-community https://grafana-community.github.io/helm-charts

# OpenTelemetry
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

# Mettre à jour les repos
helm repo update

Vérifiez :

helm repo list

Créer les namespaces

Séparer les outils d'observabilité de l'application observée facilite le nettoyage : un kubectl delete namespace otel-demo retire toute la démo sans toucher à Prometheus ni Grafana. Ces deux namespaces sont utilisés tels quels par les modules suivants, gardez ces noms exacts. La suppression d'un namespace supprime tout ce qu'il contient, y compris les volumes persistants qui y sont rattachés.

# Namespace pour les outils d'observabilité
kubectl create namespace observability

# Namespace pour l'application démo
kubectl create namespace otel-demo

Vérifiez :

kubectl get namespaces

Commandes utiles à retenir

Ces six commandes couvrent le cycle de vie du cluster pendant tout le lab. Retenez surtout la différence entre minikube stop, qui éteint la VM en conservant l'état, et minikube delete, qui détruit tout : cluster, namespaces, releases Helm et données. minikube tunnel doit rester ouvert dans un terminal tant que vous avez besoin des adresses de type LoadBalancer.

Commande	Description
minikube start	Démarrer le cluster
minikube stop	Arrêter (sans perdre les données)
minikube delete	Supprimer (reset complet)
minikube dashboard	Ouvrir le dashboard K8s
minikube service <svc> -n <ns>	Ouvrir un service dans le navigateur
minikube tunnel	Exposer les LoadBalancer

Glissez pour voir

Dépannage

Les trois erreurs ci-dessous couvrent la quasi-totalité des échecs de mise en route. Elles ont un point commun : le message porte sur Minikube ou kubectl, alors que la cause se trouve en dessous, dans les ressources de l'hôte ou dans le démon Docker. Vérifiez toujours cette couche avant de recréer le cluster.

"Not enough memory"

L'hôte ne peut pas fournir la mémoire demandée. Libérez de la mémoire en fermant des applications, ou recréez un cluster réduit à 8 Go en sachant qu'une partie des pods de l'application de démonstration restera alors en Pending au module 01 :

minikube delete
minikube start --memory=8192 --cpus=4 --driver=docker --kubernetes-version=v1.32.0

"Driver docker not found"

Vérifiez que Docker est démarré :

docker ps

Si Docker tourne mais Minikube ne le trouve pas, ajoutez votre utilisateur au groupe docker :

sudo usermod -aG docker $USER
newgrp docker

"kubectl connection refused"

Le cluster n'est pas démarré ou le contexte n'est pas bon :

minikube start
kubectl config use-context minikube

Validation

Avant de passer au module suivant, vérifiez que tout fonctionne. Les trois commandes doivent réussir dans l'ordre : un nœud Ready, deux namespaces Active, et trois dépôts Helm listés. Un échec sur la dernière signifie généralement qu'un helm repo add a été saisi dans un autre shell ou sous un autre utilisateur, la configuration Helm étant stockée dans le répertoire personnel.

# Cluster actif
kubectl get nodes

# Namespaces créés
kubectl get ns observability otel-demo

# Repos Helm configurés
helm repo list | grep -E "prometheus|grafana|open-telemetry"

Si tout est vert, le cluster est prêt à recevoir l'application de démonstration.

À retenir

• Le lab tourne sur un cluster Minikube local, créé avec 10 Go de mémoire et 4 CPU : ces valeurs sont figées à la création, les changer impose minikube delete puis un nouveau minikube start.
• Sous Linux, chaque binaire (kubectl, minikube, helm) s'installe après vérification de son empreinte avec sha256sum --check.
• --kubernetes-version=v1.32.0 fige la version du cluster pour que vos sorties correspondent à celles du lab.
• L'addon metrics-server est le seul indispensable : sans lui, kubectl top répond Metrics API not available.
• Trois dépôts Helm sont déclarés (prometheus-community, grafana-community, open-telemetry), suivis d'un helm repo update.
• Deux namespaces séparent les outils (observability) de l'application observée (otel-demo).
• minikube stop conserve l'état du cluster, minikube delete le détruit entièrement.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →