kind, minikube et k3d vous donnent chacun une API Kubernetes sur un ordinateur portable. Ils diffèrent par le temps que prend le premier démarrage, la façon dont ils dépensent la RAM, et comment un LoadBalancer ou Ingress devient un port que vous pouvez ouvrir. Créez un cluster avec les commandes ci-dessous et chargez une image locale sans la pousser vers un registre.

Réponse courte

Utilisez kind quand le cluster doit se comporter comme le Kubernetes upstream et quand les mêmes commandes doivent s’exécuter dans CI. Utilisez minikube quand vous voulez minikube addons enable ingress, un driver qui n’est pas Docker, ou un tunnel qui donne aux Services LoadBalancer une adresse. Utilisez k3d quand vous voulez k3s, une petite empreinte, et un port hôte sur le load balancer bundlé sans installer de contrôleurs supplémentaires.

Tous les trois parlent par défaut au moteur Docker. docker info doit réussir. S’il échoue avec une erreur de socket, corrigez Permission Docker socket refusée avant de déboguer l’outil cluster. Les noms de contexte kubectl et les commandes quotidiennes sont dans l’aide-mémoire kubectl.

Côte à côte

kind minikube k3d
Ce qu’il exécute Kubernetes upstream via kubeadm, un conteneur par nœud Kubernetes upstream dans un conteneur ou une VM k3s dans Docker
Runtime par défaut Docker Docker, ou un driver VM Docker
Multi-nœud Fichier de configuration, role: worker --nodes --servers et --agents
Ingress Vous installez un contrôleur minikube addons enable ingress Traefik, sauf si vous le désactivez
LoadBalancer Pending jusqu’à cloud-provider-kind ou MetalLB minikube tunnel (gardez le processus en cours d’exécution) k3s ServiceLB plus le proxy k3d
Mettre une image locale sur les nœuds kind load docker-image minikube image load k3d image import
Contexte kubeconfig kind-<name> Nom du profil (minikube par défaut) k3d-<name>
CI Choix habituel ; aucune étape addon Fonctionne avec --driver=docker ; plus lourd Fonctionne ; le balanceur intégré économise les étapes

Le premier create attend le téléchargement de l’image de nœud pour les trois. Après que cette image soit mise en cache, kind et k3d atteignent généralement Ready plus vite que minikube, et un driver VM minikube démarre aussi un système d’exploitation invité. Traitez cela comme un ordre, pas un benchmark.

k3s exécute le plan de contrôle en un seul processus, donc k3d est généralement le plus léger sur la RAM. kind exécute les processus normaux du plan de contrôle dans le conteneur de nœud. Un driver VM minikube réserve le --memory que vous définissez. Le driver Docker s’assoit plus près de kind, plus tout addon que vous activez.

Créer un cluster

kind

brew install kind
winget install Kubernetes.kind

brew est macOS ou Linux. winget est Windows. Chocolatey expédie choco install kind.

Un nœud :

kind create cluster --name dev
kubectl cluster-info --context kind-dev
kind delete cluster --name dev

Plus d’un nœud, et ports hôtes 80 et 443 visant le conteneur du plan de contrôle, ont besoin d’un fichier de configuration. kind n’a pas de drapeau --nodes.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 80
        hostPort: 80
      - containerPort: 443
        hostPort: 443
  - role: worker
  - role: worker
kind create cluster --name dev --config kind-config.yaml

Épinglez l’image de nœud quand vous avez besoin d’une mineure Kubernetes spécifique, par exemple --image kindest/node:v1.31.0. Le tag doit exister pour cette version de kind.

minikube

brew install minikube
winget install Kubernetes.minikube
minikube start -p dev --driver=docker --nodes=3 --cpus=2 --memory=4g
minikube status -p dev
minikube delete -p dev

--nodes=3 est un plan de contrôle plus deux workers. --driver est docker ou podman quand vous avez déjà un moteur de conteneur, ou kvm2, qemu2, hyperv, virtualbox, ou vfkit pour une VM. --ha signifie plusieurs nœuds du plan de contrôle, pas « plus de workers ».

Le nom du profil est le contexte kubectl : -p dev est kubectl config use-context dev. Le profil par défaut est minikube. Épinglez une version avec --kubernetes-version=v1.31.0 ou stable.

k3d

k3d a besoin de Docker. macOS et Linux :

brew install k3d

Windows : choco install k3d ou scoop install k3d. Le projet publie également un programme d’installation :

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash
k3d cluster create dev --agents 2 --port "8080:80@loadbalancer"
kubectl cluster-info --context k3d-dev
k3d cluster delete dev

--agents 2 ajoute deux workers à côté d’un serveur. Le contexte est k3d-dev. Sans nom, le cluster est k3s-default et le contexte est k3d-k3s-default.

--port publie un port hôte via le proxy k3d. Sans cela, k3d imprime les ports élevés qu’il a choisis. @server:0 suffit pour désactiver Traefik sur le premier serveur :

k3d cluster create dev --agents 2 --k3s-arg "--disable=traefik@server:0" --port "8080:80@loadbalancer"

Installez votre propre contrôleur d’ingress après cela, et pointez-le sur le port publié.

Images, ingress et LoadBalancer

Construisez avec la CLI Docker, puis copiez l’image dans les nœuds. Un registre n’est pas requis pour une seule machine.

docker build -t example/web:1.4.0 ./web
kind load docker-image example/web:1.4.0 --name dev
minikube image load example/web:1.4.0 -p dev
k3d image import example/web:1.4.0 -c dev

kind accepte plusieurs tags en un seul appel. minikube accepte également une tarball (minikube image load web.tar).

Évitez le tag latest. Kubernetes traite latest et un tag manquant comme imagePullPolicy: Always, donc le kubelet contacte toujours un registre. Tout autre tag par défaut est IfNotPresent. Si le pull s’exécute et le tag n’est pas publié, le Pod est ImagePullBackOff.

Sur le Docker actuel, kind load docker-image peut échouer quand le daemon utilise le magasin d’images containerd (une erreur de digest de ctr). Enregistrez une plateforme et chargez l’archive à la place. La plateforme doit correspondre au nœud. Une archive amd64 sur un nœud arm64 échoue au démarrage avec une erreur de format d’exécution.

docker image save --platform linux/amd64 --output web.tar example/web:1.4.0
kind load image-archive web.tar --name dev

Utilisez linux/arm64 quand les nœuds kind sont Apple Silicon.

Ingress et LoadBalancer sont des portes différentes :

  • kind n’installe pas de contrôleur d’ingress ou de load balancer cloud. extraPortMappings publie seulement les ports du conteneur. Installez le contrôleur que vous utilisez en production et liez-le à 80 et 443 sur ce nœud. Un Service LoadBalancer reste <pending> jusqu’à ce qu’il en existe un. Exécutez cloud-provider-kind sur l’hôte (go install sigs.k8s.io/cloud-provider-kind@latest, puis le binaire, resté au premier plan). Il a besoin de la permission d’ouvrir les ports. MetalLB est l’autre option.
  • minikube active ingress-nginx avec minikube addons enable ingress -p dev. Pour LoadBalancer, laissez minikube tunnel -p dev s’exécuter. L’arrêter dépose les routes. Il peut vous demander un mot de passe administrateur pour modifier les routes hôtes.
  • k3d installe Traefik et k3s ServiceLB. Accédez-y avec --port ...@loadbalancer. Désactivez Traefik avant d’installer un deuxième contrôleur.

Les noms StorageClass diffèrent, c’est pourquoi un manifeste qui a fonctionné sur un ordinateur portable reste Pending sur un autre. Vérifiez avec kubectl get storageclass. Un cluster kind par défaut et un cluster minikube par défaut appelent la classe standard. Un cluster k3d par défaut l’appelle local-path. Une déclaration qui définit storageClassName au mauvais nom ne se lie pas. Voir Pod Pending / FailedScheduling.

Quand choisir kind

Choisissez kind pour tester contre kubeadm, ou pour exécuter les mêmes étapes create-load-apply dans CI. Multi-nœud est un fichier de configuration. Ingress et LoadBalancer sont des installations supplémentaires. Un travail typique est kind create cluster, kind load docker-image, kubectl apply, puis kubectl wait.

kubectl wait --for=condition=available deployment/api --timeout=120s

Quand choisir minikube

Choisissez minikube quand vous voulez minikube addons list et une commande pour ingress, ou une VM Hyper-V, KVM, ou QEMU parce que Docker n’est pas disponible. minikube tunnel remplace un processus de fournisseur cloud. C’est un défaut CI plus faible : le driver Docker fonctionne, mais un tunnel est un processus de longue durée qu’un travail rarement veut.

Quand choisir k3d

Choisissez k3d quand la RAM est serrée, la production est déjà k3s, ou vous voulez Traefik et un load balancer sur le premier create. L’API est Kubernetes. Traefik, ServiceLB, local-path et un plan de contrôle plus mince sont des défauts k3s, pas des défauts kubeadm.

Chemin de migration

Déplacer entre ces outils n’exporte pas le cluster. Les manifestes dans git sont la source de vérité.

  1. Listez les images qui ne sont pas dans un registre (docker images). Vous les chargerez à nouveau.
  2. Libérez les ports hôtes 80 et 443 si vous les aviez mappés.
  3. Créez le nouveau cluster. N’attachez pas les ports hôtes 80 et 443 sur deux clusters à la fois.
  4. Chargez les images avec la commande de cet outil. Une archive kind n’est pas un k3d image import.
  5. kubectl config use-context pour kind-dev, dev, ou k3d-dev.
  6. kubectl apply -f ou kubectl apply -k. Corriger storageClassName si un PVC reste Pending, et la classe ingress si le trafic n’arrive jamais (nginx sur l’addon minikube, traefik sur le k3d par défaut).
  7. Supprimez l’ancien cluster : kind delete cluster --name dev, minikube delete -p dev, ou k3d cluster delete dev.

Sur un cluster partagé, poussez les tags vers un registre et supprimez les cartes de ports hôtes. Docker Compose vs Kubernetes couvre le côté application : Compose sur un moteur, ces outils pour une API locale, un vrai cluster quand vous avez plus d’une machine.

FAQ

Quel outil Kubernetes local ressemble le plus à un cluster de production ?

kind. Chaque nœud est un cluster kubeadm dans un conteneur, ce qui est le même bootstrap que la plupart des clusters upstream utilisent. k3d est une vraie API Kubernetes sur k3s, avec Traefik et un service load balancer déjà installés. minikube est aussi une vraie API ; ses addons et drivers sont les parties qui ne correspondent pas à votre cluster de production.

Comment utiliser une image construite localement sans registre ?

Chargez-la dans les nœuds du cluster avant d’appliquer. kind utilise kind load docker-image, minikube utilise minikube image load, et k3d utilise k3d image import. Épinglez une étiquette autre que latest, ou définissez imagePullPolicy: IfNotPresent, sinon le kubelet essaiera le registre de toute façon.

Pourquoi un Service LoadBalancer reste en Pending ?

Rien sur kind ne met en œuvre ce type de Service jusqu’à ce que vous exécutiez cloud-provider-kind ou installiez MetalLB. minikube a besoin de minikube tunnel qui continue à s’exécuter dans un autre terminal. k3d est livré avec k3s ServiceLB et un conteneur proxy, donc l’adresse apparaît une fois le cluster démarré et que vous publiez un port hôte.

Puis-je exécuter kind, minikube et k3d en même temps ?

Oui, si Docker a la mémoire et que les ports hôtes 80 et 443 ne sont pas revendiqués deux fois. Chaque outil écrit son propre contexte kubeconfig : kind-<name>, le nom du profil minikube, et k3d-<name>. Changez avec kubectl config use-context.

Comment ce guide a été vérifié

Rédigé à la main à partir de la documentation officielle, chaque commande revérifiée, puis relu une seconde fois avant publication. Dernière relecture le .

Sources officielles consultées pour cet article

Share.

Les commentaires sont fermés.