Sur un Mac mini M4 loué à Singapour, Tokyo, Séoul, Hong Kong ou US Ouest pour Kind ou minikube, le mur est souvent la chaîne Docker ou Colima → kubelet → containerd et la RTT vers le registre, pas le GHz. Cette note livre scénarios, choix de nœud, une matrice (concurrence d’images, containerd, plafonds RAM/CPU, timeouts batch) et une FAQ. Croisez Docker/Podman couches & cache, latence batch & TCO et le runbook Docker durci. Tarifs, Achat, Aide : sans compte.
Scénarios
Les équipes posent un Kubernetes local sur Mac loué pour Apple Silicon, ingress multi-nœuds ou CI macOS sans parc acheté. Trois frictions 2026 :
- Rafales de pulls imbriqués. Chaque nœud Kind exécute son propre
containerd; unkubectl applymassif duplique les mêmes couches et remplit la file APFS alors quekubectl topaffiche encore un CPU calme. - Angles morts sur les quotas. Sans
LimitRangepar défaut, un chart Helm peut réquisitionner tout le CPU allouable d’un profil minikube mono-nœud tout en laissant kubelet sans marge pour le GC et l’extraction d’images. - Timeouts monolithiques. Fusionner attente de pull, préparation du bac à sable et
activeDeadlineSecondsd’un job batch dans un seul chiffre masque si vous devez rapprocher le registre ou simplement réduire la concurrence.
Batch : pré-pull, digest figés, moins de Pods mais plus de CPU requis. Interactif : déploiements légers, startupProbe courte, pulls parallèles modestes pour ménager APFS.
Sur les charges « calcul » qui consomment surtout du CPU une fois l’image présente, la décision se déplace vers la file d’attente : mieux vaut retarder la montée en charge des Pods que d’accepter des centaines de ImagePullBackOff qui réinitialisent le graphe de dépendances. Documentez pour chaque pipeline si le temps dominant est téléchargement, extraction ou exécution ; alignez alors parallelism des jobs et la concurrence containerd sur la même étiquette afin que l’astreinte ne confonde pas « cluster lent » et « registre lointain ».
Choix de nœud
Kind pour topologie, ingress, politiques ; chaque worker coûte de la RAM unifiée. minikube pour boucles Helm mono-contrôleur rapides.
16 Go : un worker Kind ou minikube serré. 24 Go : second worker possible en gardant ~4 Go pour le moteur hôte.
Si vos opérateurs mélangent jobs de données et services longue durée sur le même hôte, isolez les espaces de noms par profil de latence : un namespace « interactif » avec LimitRange serré et un namespace « batch » où les requêtes mémoire reflètent les pics mesurés sur fichiers volumineux.
Voici une séquence opérable en cinq étapes avant d’ouvrir le cluster à toute l’équipe :
- Pilote + SSD. Racine graphe sur SSD interne validé ; évitez disques externes saturés pour snapshots imbriqués.
- Registre proche. Même métropole que les artefacts (voir article TCO lié).
- Pré-pull bases. Scriptez les tags partagés avant de scaler les réplicas CI.
- Quotas avant Helm.
ResourceQuota+LimitRangedès le namespace. - Événements d’abord.
kubectl describe pod: pull vs sandbox avant de monter les limites CPU.
Matrice de paramètres
Bandes indicatives pour containerd imbriqué (Docker Desktop ou Colima) sur M4 loué ; validez avec RTT registre réelle.
| Profil de charge | Concurrence des pulls d’images | Points sensibles containerd | Plafonds mémoire et CPU (indicatifs) | Timeouts |
|---|---|---|---|---|
| Cluster de développement interactif | 2–3 couches / nœud ; pas cinq réplicas froids à la fois | Miroirs hosts.toml ; snapshotter ↑ seulement après chauffe disque |
Requêtes RAM < ~12 Go sur hôte 16 Go ; CPU requis < ~10 cœurs eq. avec kube-system | Pull image ≤ 600 s ; startupProbe courte (3–5 essais) |
| Fragment CI ou pré-commit | Tags lourds sérialisés puis 4–6 petites couches en parallèle | Discard couches si dispo ; config_path vers registre proche |
Namespace burst ≤ 8 CPU requis et ≤ 14 Go RAM requise sur hôte 24 Go | Backoff pull ≠ liveness ; Ready sandbox < ~180 s ; activeDeadlineSeconds > durée test + 40 % |
| Batch nocturne ou pipeline de données | 1–2 flux sur couches multi-Go ; pause entre charts | Image pause préchargée ; moins d’unpack parallèle si IO saturée | Jobs lourds : ≥ 4 CPU et 10 Go requis ; laissez ~2 cœurs hors requête pour kubelet | Deadline job heures ; pull toléré jusqu’à ~1200 s avant alerte |
Runbooks : ≥ 15 % APFS libre ; enquête après 15 min de pull coincé ; création Pods ~20/min tant que les couches ne sont pas stables.
Trois chiffres utiles en revue de conception : viser deux à quatre flux d’images simultanés sur liaison APAC transversale, porter la marge mémoire hôte à au moins trois gigaoctets non comptés dans les requêtes Kubernetes, et journaliser séparément durée de pull, temps jusqu’à Ready et durée utile batch pour éviter les conclusions hâtives lors des post-mortems.
FAQ de dépannage
Kind « vert » mais scheduling bloqué ? Souvent extraction ; describe avant de détruire le cluster.
Changer Docker → Colima en sprint ? Fenêtre maintenance + revalider la matrice.
cgroup / batch ? limits.cpu dur pour la latence ; batch : un gros Pod bat plusieurs petits throttle.
Les miroirs ralentissent-ils parfois ? Un miroir mal placé ajoute un saut TLS ; vérifiez la latence jusqu’au blob storage réel, pas seulement jusqu’au nom DNS du cache.
SSH / VNC : checklist première configuration.