Kubernetes no Mac em 2026: kubectl, k9s e clusters locais

Um fluxo de trabalho adequado ao Mac

Um cluster Kubernetes no notebook é uma cópia de algo que roda de verdade em outro lugar. Para boa parte do trabalho com plataformas e aplicações, você não precisa dessa cópia: precisa de feedback rápido sobre o contêiner, os serviços com que ele se comunica e um terminal aberto no cluster real. Em um Mac com Apple silicon, isso se divide em quatro tarefas.

kubectl e k9s nos seus clusters

kubectl e k9s leem o mesmo kubeconfig, então tudo que você acessa com um pode explorar com o outro. As CLIs de nuvem gravam os contextos para você: aws eks update-kubeconfig, az aks get-credentials e gcloud container clusters get-credentials adicionam um contexto cada.

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

Instale o k9s com Homebrew ou MacPorts, conforme sua página de instalação. Mantenha arquivos kubeconfig separados por ambiente e escolha um com KUBECONFIG=~/.kube/staging k9s quando quiser deixar produção fora do alcance.

Compilar imagens para o cluster

A maioria dos clusters usa nós amd64, e seu Mac é arm64. O Buildx no Oxcart compila ambos a partir de um Dockerfile no builder padrão:

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

Passe --platform linux/amd64 ao executar uma imagem exclusiva de amd64 compilada localmente. Para implantação, envie uma tag por plataforma ou deixe o CI publicar um manifesto multi-arquitetura que selecione a imagem correta para cada nó:

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

Os builds são rápidos: o Oxcart registrou 341 ms para um build sem cache de um pequeno contexto local e 121 ms com cache, o mais rápido dos três ambientes testados. docker login mantém as senhas dos registros nas Chaves do macOS.

Execute as dependências do app com Compose

Enquanto o serviço que você altera se comunica com um cluster remoto, o banco, o cache e a fila podem rodar no Mac. Um compose.yaml com healthchecks e depends_on: condition: service_healthy sobe com docker compose up -d --wait e só retorna quando todos os serviços estão saudáveis. Veja um exemplo completo em Docker Compose no Apple silicon. Os contêineres iniciam rápido o bastante para serem recriados entre testes: 42 ms para docker run --rm e 77 ms para parar e remover 20 contêineres.

Uma API Kubernetes real no Mac com kwok

O kwok (Kubernetes WithOut Kubelet) inicia os componentes reais do plano de controle como contêineres e simula nós e pods. No Oxcart, kwokctl iniciou etcd, kube-apiserver, kube-scheduler e kube-controller-manager (v1.36.1) em cerca de 15 segundos, incluindo os downloads das imagens, e o kubectl e o k9s no Mac se conectaram a ele.

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

Use para verificar se manifestos são aplicados, se as regras RBAC permitem o esperado, se um controller ou operator se comunica corretamente com a API e para aprender k9s sem mexer em um cluster compartilhado. Nenhum contêiner do seu Deployment realmente roda: os pods são registros no servidor de API, marcados como Running pelo kwok.

Escolha onde seu cluster roda

Mantenha o ciclo rápido de feedback no Mac e use o cluster adequado à equipe. Um cluster de desenvolvimento compartilhado oferece a todos os mesmos controllers, políticas e integrações de nuvem. Um cluster local é útil quando você precisa de pods reais sem conexão com esse ambiente.

O Oxcart oferece contêineres privilegiados para cargas que precisam de permissões elevadas no Linux. Um cluster Kubernetes completo também depende da configuração de rede e runtime da ferramenta de cluster. Para um cluster incluído em um app desktop, veja a comparação de apps de contêineres para Mac; para o desenvolvimento diário, os fluxos com Compose, Buildx e kwok acima mantêm a iteração local.

Clusters de nuvem a partir do Mac

• EKS: compile e envie ao ECR e depois execute aws eks update-kubeconfig. Consulte AWS ECS, EKS, Fargate e Lambda localmente.
• AKS: envie ao Azure Container Registry e depois execute az aks get-credentials. Consulte Azure Container Apps e AKS localmente.
• GKE e Cloud Run: envie ao Artifact Registry; o Cloud Run exige linux/amd64. Consulte Cloud Run localmente.

Perguntas

Como o Oxcart se encaixa em um fluxo com Kubernetes?

Use o Oxcart para compilar imagens, executar o app e suas dependências localmente e testar manifestos com um servidor de API kwok local. Contêineres privilegiados fazem parte da plataforma. Use kubectl e k9s no Mac para seu cluster compartilhado ou na nuvem; o Oxcart não inclui um cluster Kubernetes.

Existe alguma API Kubernetes local que posso usar com o Oxcart?

Sim. O kwok executa um plano de controle Kubernetes real (etcd, kube-apiserver, kube-scheduler e kube-controller-manager, v1.36 no nosso teste) como contêineres do Oxcart, e o kubectl e o k9s no Mac se conectam a ele. Os nós e pods são simulados, então serve para testar manifestos, RBAC e comportamento da API, não para executar os contêineres do app.

kubectl e k9s funcionam em um Mac com Apple silicon?

Sim. Ambos são ferramentas nativas de linha de comando do macOS. Usam seu kubeconfig, então funcionam com qualquer cluster apontado nele: EKS, AKS, GKE, um cluster no trabalho ou um servidor de API local. O k9s documenta a instalação com Homebrew e MacPorts.

Como compilo imagens para um cluster Kubernetes amd64 em um Mac com Apple silicon?

Use Buildx com --platform linux/amd64 ou --platform linux/amd64,linux/arm64 para ambas. No Oxcart, o build multiplataforma termina no builder padrão e as duas arquiteturas rodam localmente. O envio de uma imagem multiplataforma pelo Oxcart não é suportado; envie uma tag por plataforma ou deixe o CI publicar o manifesto multi-arquitetura.

Onde posso executar um cluster Kubernetes local completo no Mac?

Vários apps de contêineres para Mac incluem um cluster de nó único. Eles são comparados, com fontes, na página de comparações. Muitas equipes preferem desenvolver com um cluster compartilhado ou na nuvem e executar apenas as dependências do app localmente, que é o fluxo abordado neste guia.

O k9s precisa de um servidor de métricas?

O k9s se conecta sem um; registra um aviso e deixa as colunas de CPU e memória vazias quando o cluster não tem API de métricas. No nosso teste com kwok, informou “Kubernetes connectivity OK” junto com esse aviso.

Fontes e método

• Exemplo de API local: Oxcart 0.1.2, Mac17,14, macOS 27.2, 2026-10-10; kwokctl v0.8.0, k9s v0.51.0 e kubectl v1.33.9.
• kwok: https://kwok.sigs.k8s.io/; k9s: https://k9scli.io/ e https://k9scli.io/topics/install/; kind: https://kind.sigs.k8s.io/docs/user/known-issues/; k3d: https://k3d.io/stable/; drivers do minikube: https://minikube.sigs.k8s.io/docs/drivers/. Verificados em 2026-10-10.
• Velocidade de builds e contêineres: Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPUs e 12 GiB, medianas de cinco amostras; os outros ambientes foram medidos mais cedo no mesmo dia, no mesmo Mac e com a mesma estrutura de testes, usando o cliente docker 29.4.