Le workflow adapté au Mac
Un cluster Kubernetes sur un ordinateur portable est une copie de quelque chose qui tourne réellement ailleurs. Pour une grande partie du travail sur les plateformes et les applications, cette copie n'est pas nécessaire : il faut un retour rapide sur le conteneur lui-même, les services auxquels il parle et un terminal ouvert sur le vrai cluster. Sur un Mac à puce Apple, cela se divise en quatre tâches.
| Tâche | Outil | Sur Oxcart |
|---|---|---|
| Inspecter et administrer les clusters | kubectl, k9s | Outils Mac natifs ; connexion à tout contexte kubeconfig |
| Construire les images du cluster | docker buildx build | Construire ensemble les images amd64 et arm64 |
| Exécuter l'application et ses dépendances | docker compose | Démarrer votre stack avec des contrôles de santé, up --wait et des ports publiés |
| Tester les manifestes contre un serveur API | kwok | Vérifier les manifestes avec un vrai plan de contrôle et des nœuds et pods simulés |
Utiliser kubectl et k9s avec vos clusters
kubectl et k9s lisent le même kubeconfig : tout ce que vous pouvez atteindre avec l'un peut être exploré avec l'autre. Les CLI cloud y écrivent les contextes pour vous : aws eks update-kubeconfig, az aks get-credentials et gcloud container clusters get-credentials ajoutent chacun un contexte.
kubectl config get-contexts # every cluster in your kubeconfig
kubectl config use-context my-eks # switch the current context
kubectl get pods -A # works against the current context
k9s # the same context, in a terminal UI
k9s --context my-aks --readonly # another context, read-only Installez k9s avec Homebrew ou MacPorts, comme indiqué sur sa page d'installation. Gardez des fichiers kubeconfig distincts par environnement et choisissez-en un avec KUBECONFIG=~/.kube/staging k9s pour garder la production hors de portée.
Construire les images du cluster
La plupart des clusters utilisent des nœuds amd64, alors que votre Mac est arm64. Buildx sur Oxcart construit les deux depuis un seul Dockerfile avec le builder par défaut :
docker buildx ls # default builder: linux/amd64, linux/arm64
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:dev .
docker run --rm --platform linux/amd64 myapp:dev # runs through Rosetta
docker run --rm --platform linux/arm64 myapp:dev # runs natively Passez --platform linux/amd64 lorsque vous exécutez une image exclusivement amd64 construite localement. Pour le déploiement, envoyez un tag par plateforme, ou laissez la CI publier un manifeste multiarchitecture qui sélectionne la bonne image pour chaque nœud :
docker buildx build --platform linux/amd64 --load -t registry.example.com/myapp:1.4.0-amd64 .
docker push registry.example.com/myapp:1.4.0-amd64 Les constructions sont rapides : Oxcart a mesuré 341 ms pour une construction sans cache d'un petit contexte local et 121 ms avec cache, les meilleurs résultats des trois environnements testés. docker login conserve les mots de passe des registres dans le Trousseau macOS.
Exécuter les dépendances de l'application avec Compose
Pendant que le service que vous modifiez communique avec un cluster distant, sa base de données, son cache et sa file d'attente peuvent tourner sur votre Mac. Un compose.yaml avec des contrôles de santé et depends_on: condition: service_healthy démarre avec docker compose up -d --wait, qui ne se termine que lorsque chaque service est sain. Voir Docker Compose sur puce Apple pour un exemple complet. Les conteneurs démarrent assez vite pour être supprimés entre les tests : 42 ms pour docker run --rm et 77 ms pour arrêter et supprimer 20 conteneurs.
Une vraie API Kubernetes sur votre Mac avec kwok
kwok (Kubernetes WithOut Kubelet) démarre les vrais composants du plan de contrôle sous forme de conteneurs et simule les nœuds et pods. Sur Oxcart, kwokctl a démarré etcd, kube-apiserver, kube-scheduler et kube-controller-manager (v1.36.1) en environ 15 secondes, téléchargements d'images compris, et kubectl ainsi que k9s sur le Mac s'y sont connectés.
kwokctl create cluster --name dev --runtime docker
kwokctl scale node --replicas 2 --name dev
kubectl apply -f deploy.yaml
kubectl rollout status deploy/web # "successfully rolled out"
kubectl get pods -o wide # 3/3 Running on simulated nodes
k9s # browse it like any cluster
kwokctl delete cluster --name dev Utilisez-le pour vérifier que les manifestes s'appliquent, que les règles RBAC autorisent ce que vous attendez, qu'un contrôleur ou opérateur communique correctement avec l'API, et pour apprendre k9s sans toucher à un cluster partagé. Aucun conteneur de votre Deployment ne s'exécute réellement : les pods sont des enregistrements dans le serveur API, marqués Running par kwok.
Choisir où votre cluster réside
Gardez votre cycle de développement rapide sur le Mac et utilisez le cluster adapté à votre équipe. Un cluster de développement partagé donne à chacun les mêmes contrôleurs, politiques et intégrations cloud. Un cluster local est utile lorsque vous avez besoin de vrais pods sans être connecté à cet environnement.
Oxcart prend en charge les conteneurs privilégiés pour les workloads nécessitant des autorisations élevées dans Linux. Un cluster Kubernetes complet dépend aussi du réseau et de la configuration d'exécution de l'outil de cluster. Pour un cluster inclus dans une application de bureau, voir le comparatif des applications de conteneurs pour Mac ; pour le développement quotidien, les workflows Compose, Buildx et kwok ci-dessus gardent les itérations en local.
Les clusters cloud depuis votre Mac
- EKS : construisez et envoyez vers ECR, puis
aws eks update-kubeconfig. Voir AWS ECS, EKS, Fargate et Lambda en local. - AKS : envoyez vers Azure Container Registry, puis
az aks get-credentials. Voir Azure Container Apps et AKS en local. - GKE et Cloud Run : envoyez vers Artifact Registry ; Cloud Run nécessite
linux/amd64. Voir Cloud Run en local.
Questions
Comment Oxcart s'intègre-t-il à un workflow Kubernetes ?
Utilisez Oxcart pour construire vos images, exécuter localement l'application et ses dépendances et tester des manifestes avec un serveur API kwok local. Les conteneurs privilégiés font partie de la plateforme. Utilisez kubectl et k9s sur votre Mac pour votre cluster partagé ou cloud ; Oxcart n'inclut pas de cluster Kubernetes.
Existe-t-il une API Kubernetes locale utilisable avec Oxcart ?
Oui. kwok exécute un vrai plan de contrôle Kubernetes (etcd, kube-apiserver, kube-scheduler et kube-controller-manager, v1.36 dans notre test) comme conteneurs Oxcart, auxquels kubectl et k9s sur votre Mac se connectent. Ses nœuds et pods sont simulés : il sert donc à tester les manifestes, RBAC et le comportement de l'API, pas à exécuter les conteneurs de votre application.
kubectl et k9s fonctionnent-ils sur un Mac à puce Apple ?
Oui. Ce sont deux outils en ligne de commande natifs de macOS. Ils utilisent votre kubeconfig et fonctionnent donc avec tout cluster qu'il désigne : EKS, AKS, GKE, un cluster au travail ou un serveur API local. k9s documente l'installation avec Homebrew et MacPorts.
Comment construire sur un Mac à puce Apple des images pour un cluster Kubernetes amd64 ?
Utilisez Buildx avec --platform linux/amd64, ou --platform linux/amd64,linux/arm64 pour les deux. Sur Oxcart, la construction multiplateforme aboutit avec le builder par défaut et les deux architectures s'exécutent localement. L'envoi d'une image multiplateforme depuis Oxcart n'est pas pris en charge : envoyez un tag par plateforme ou laissez la CI publier le manifeste multiarchitecture.
Où exécuter un cluster Kubernetes local complet sur Mac ?
Plusieurs applications de conteneurs pour Mac incluent un cluster à un seul nœud. Elles sont comparées, sources à l'appui, sur la page des comparatifs. De nombreuses équipes développent plutôt avec un cluster partagé ou cloud et n'exécutent localement que les dépendances de l'application : c'est le workflow présenté dans ce guide.
k9s a-t-il besoin d'un serveur de métriques ?
k9s se connecte sans serveur de métriques ; il consigne un avertissement et laisse les colonnes CPU et mémoire vides lorsque le cluster n'a pas d'API de métriques. Dans notre test kwok, il a indiqué « Kubernetes connectivity OK » avec cet avertissement.
Sources et méthode
- Exemple d'API locale : Oxcart 0.1.2, Mac17,14, macOS 27.2, 2026-10-10 ; kwokctl v0.8.0, k9s v0.51.0 et kubectl v1.33.9.
- kwok : https://kwok.sigs.k8s.io/ ; k9s : https://k9scli.io/ et https://k9scli.io/topics/install/ ; kind : https://kind.sigs.k8s.io/docs/user/known-issues/ ; k3d : https://k3d.io/stable/ ; pilotes minikube : https://minikube.sigs.k8s.io/docs/drivers/. Vérifié le 2026-10-10.
- Vitesse des constructions et des conteneurs : Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPU et 12 GiB, médianes de cinq échantillons ; les autres environnements ont été mesurés plus tôt le même jour sur le même Mac et avec le même dispositif de mesure, avec le client docker 29.4.