Aller au contenu
medium

00, Setup : Minikube, Helm et kubectl

11 min de lecture

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

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

  • RAM : 8 Go minimum (16 Go recommandés)
  • CPU : 4 cœurs disponibles
  • Disque : 20 Go libres

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.

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

Fenêtre de terminal
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

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.

Fenêtre de terminal
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 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 cette formation.

Fenêtre de terminal
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

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

Fenêtre de terminal
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

Créez votre cluster avec suffisamment de ressources pour la formation. 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.

Fenêtre de terminal
minikube start \
--memory=10240 \
--cpus=4 \
--driver=docker \
--kubernetes-version=v1.32.0

Vérifiez que le cluster fonctionne :

Fenêtre de terminal
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

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.

Fenêtre de terminal
# 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 :

Fenêtre de terminal
minikube addons list | grep enabled

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 la formation. 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.

Fenêtre de terminal
# 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 :

Fenêtre de terminal
helm repo list

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.

Fenêtre de terminal
# Namespace pour les outils d'observabilité
kubectl create namespace observability
# Namespace pour l'application démo
kubectl create namespace otel-demo

Vérifiez :

Fenêtre de terminal
kubectl get namespaces

Ces six commandes couvrent le cycle de vie du cluster pendant toute la formation. 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.

CommandeDescription
minikube startDémarrer le cluster
minikube stopArrêter (sans perdre les données)
minikube deleteSupprimer (reset complet)
minikube dashboardOuvrir le dashboard K8s
minikube service <svc> -n <ns>Ouvrir un service dans le navigateur
minikube tunnelExposer les LoadBalancer

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.

Réduisez la mémoire allouée (minimum 4 Go, mais 8 Go recommandés) :

Fenêtre de terminal
minikube delete
minikube start --memory=4096 --cpus=2

Vérifiez que Docker est démarré :

Fenêtre de terminal
docker ps

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

Fenêtre de terminal
sudo usermod -aG docker $USER
newgrp docker

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

Fenêtre de terminal
minikube start
kubectl config use-context minikube

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.

Fenêtre de terminal
# 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, vous êtes prêt pour le module suivant.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn