Clusters Kubernetes e registos

Alguns trabalhos precisam de mais do que uma máquina: um serviço implantado em Kubernetes, uma imagem construída num lugar e corrida noutro, uma API na nuvem contra a qual testar. O Bromure Agentic Coding pode correr essa infraestrutura por você, neste Mac, ao lado das suas máquinas (espaços de trabalho, no editor de definições):

• Um cluster Kubernetes é um conjunto de VM de nó a correr k3s, com armazenamento replicado opcional, um balanceador de carga, um controlador de ingress e emuladores de nuvem locais. As máquinas que permitir recebem-no como contexto em ~/.kube/config.
• Um registo é um registo Docker privado na sua própria VM pequena. As máquinas que permitir podem enviar para lá; qualquer cluster pode obter dele.

Ambos são recursos partilhados: um cluster ou registo serve várias máquinas, e os agentes delas ficam a saber dele através do servidor MCP de infraestrutura.

Nota: não confunda estes clusters com as credenciais Kubernetes no painel Credenciais de uma máquina. Essas importam contextos de clusters que existem noutro lugar (EKS, GKE, um cluster no trabalho) e intermediam as credenciais deles no fio. Os clusters deste capítulo são VM que o Bromure cria e corre neste Mac.

Onde encontrá-los

• Espaços de trabalho › Infraestrutura › Criar cluster Kubernetes… e Criar registo… abrem as folhas de criação. Com uma janela de espelho de um Mac remoto à frente, estes itens criam o cluster ou o registo nesse Mac (ver Acesso remoto).
• Quando existir um, a secção Máquinas virtuais da barra lateral ganha uma lista Kubernetes e uma lista Registos, cada uma com um + para criar outro. Uma linha mostra um ponto de estado, o nome e um estado de uma linha; clique nela para pôr o painel dele no palco. O menu ⋯ oferece Iniciar, ou Reiniciar e Parar enquanto corre, Acesso dos espaços de trabalho… e Eliminar….

Criar um cluster

A folha Novo cluster tem uma barra lateral de seis painéis — Geral, Nós, Armazenamento, Rede, Complementos, Acesso — como o editor de definições de uma máquina. Criar fica desativado até a folha ser válida; uma linha curta ao lado diz porquê (por exemplo «Dê um nome ao cluster.»).

Geral

Um Resumo lista os nós, o armazenamento, o balanceador de carga e os complementos que escolheu.

Nós

Com um nó, ele corre o plano de controlo e as suas cargas de trabalho em conjunto. Com mais, o nó 1 é o plano de controlo (e continua a correr cargas) e os outros juntam-se como workers. O painel mostra a RAM total, e avisa «São N GB dos M GB deste Mac — os espaços de trabalho também precisam de espaço.» quando o cluster deixaria menos de 4 GB para todo o resto.

Armazenamento

• Armazenamento distribuído Longhorn (ligado por omissão) — volumes de bloco replicados servidos por iSCSI a partir de um Disco de dados por nó dedicado (40 GB por omissão, 10–2000 GB). Os discos são esparsos: só os blocos escritos ocupam espaço no Mac. O Longhorn mantém até três réplicas, nunca mais do que o número de nós. A sua classe de armazenamento é bromure-longhorn, a predefinida do cluster. Desligado, fica apenas a classe local-path local ao nó do k3s, que fixa um pod ao seu nó.
• NAS Synology — volumes persistentes no seu NAS através do controlador CSI da Synology. Preencha Endereço DSM, Porta, HTTPS, Utilizador DSM e Palavra-passe DSM, Volumes opcionais (por exemplo /volume1, /volume3), Protocolo — iSCSI (LUN de bloco) ou SMB (pastas partilhadas) — e Sistema de ficheiros. Sem volumes nomeados, o DSM escolhe um com espaço livre e a classe é bromure-synology; nomear volumes dá uma classe a cada um (bromure-synology-volume1, …). A primeira classe Synology passa a ser a predefinida do cluster; o Longhorn continua disponível pelo nome. A conta DSM precisa de direitos de gestor de armazenamento. A palavra-passe é guardada cifrada neste Mac e só aterra nos Secrets do próprio cluster.

Rede

Balanceador de carga escolhe como os Services do tipo LoadBalancer obtêm um endereço:

Com o balanceador de carga LAN do Bromure, duas anotações de Service mudam a predefinição por Service: bromure.io/scope: vm mantém-no privado (um endereço na rede de VM, só para as máquinas e este Mac), e bromure.io/loadBalancerIP pede um endereço específico.

Controlador de ingress Traefik (ligado por omissão) mantém o ingress incluído no k3s. Com o balanceador de carga LAN, publica as portas 80 e 443 neste Mac.

Aviso: o balanceador de carga LAN do Bromure torna os serviços do cluster alcançáveis por qualquer pessoa na sua rede. Escolha-o de propósito; a predefinição MetalLB mantém tudo neste Mac.

Complementos

Emuladores de nuvem locais da família open-source floci, cada um um Service LoadBalancer na sua própria porta, com os dados na classe de armazenamento predefinida do cluster:

Cada emulador ativado recebe um campo versão do projeto. Deixe-o vazio (versão mais recente) para obter a versão mais nova no Docker Hub quando o cluster é configurado; escreva uma etiqueta (2.1.0) ou uma referência de imagem completa para a fixar. Se o Docker Hub não puder ser alcançado, é usada a etiqueta latest. Os serviços que criam contentores (Lambda, Cloud Run e afins) usam o Docker do nó e são de melhor esforço.

Acesso

Que máquinas recebem o cluster:

• Todos os espaços de trabalho, incluindo os novos (predefinição), ou
• Só estes espaços de trabalho, com uma caixa por máquina. «Pelo menos um espaço de trabalho tem de manter o acesso.»

As máquinas da lista recebem o cluster no seu ~/.kube/config (o contexto tem o nome do cluster) e vêem-no através do MCP de infraestrutura. Pode alterar isto mais tarde a partir do painel.

Clique em Criar. O provisionamento leva alguns minutos; o separador Log do painel mostra cada passo.

O painel do cluster

O cabeçalho do painel mostra o nome do cluster, uma cápsula de fase e um resumo (nós, vCPU e memória de cada um, a versão do k3s, o tempo ativo), com Iniciar, ou Reiniciar e Parar, e um menu Ações do cluster: Copiar kubeconfig, Acesso dos espaços de trabalho…, Iniciar com o Bromure e Eliminar cluster….

Seis separadores, com um campo de filtro para as listas:

Eliminar cluster… «Pára todos os nós e elimina os discos deles, incluindo todos os volumes Longhorn. Os espaços de trabalho perdem o cluster do kubeconfig. Isto não pode ser desfeito.»

Usar um cluster a partir de uma máquina

Numa máquina permitida, o kubectl simplesmente funciona: o contexto do cluster está em ~/.kube/config, e o kubectl fala diretamente com o nó do plano de controlo pela rede de VM. Esse tráfego não passa pelo proxy interceptor do anfitrião — os endereços dos nós estão excluídos das definições de proxy da máquina — pelo que não aparece no rastro da máquina.

A ação Copiar kubeconfig dá-lhe um kubeconfig autónomo para ferramentas no próprio Mac. As VM de nó também são alcançáveis pela CLI, por exemplo bromure-cli vm exec k8s-dev-1 -- kubectl get nodes (ver CLI, API e MCP).

Registos

Criar um registo

Criar registo… abre uma folha: «Um registo Docker privado na sua própria VM: construa num espaço de trabalho, envie para aqui, corra num cluster. HTTP simples na rede de VM; nunca sai deste Mac.»

O disco de imagens é esparso: só as camadas enviadas ocupam espaço. Qualquer cluster pode obter de qualquer registo; o acesso de envio é por máquina.

O painel do registo

O cabeçalho mostra o endereço do registo (<ip>:5000), a memória e o disco, Iniciar / Reiniciar / Parar, e um menu com Copiar endereço, Acesso dos espaços de trabalho…, Iniciar com o Bromure e Eliminar registo…. Separadores: Imagens (cartões de Repositórios, Disco e Endereço, um trecho Enviar de um espaço de trabalho, e a lista de imagens e etiquetas), Acesso e Log.

Numa máquina com acesso de envio, o Docker já confia no endereço do registo, e $BROMURE_REGISTRY contém-no (com acesso a vários registos, o do primeiro), pelo que pode enviar de imediato:

docker build -t $BROMURE_REGISTRY/myapp:dev .
docker push $BROMURE_REGISTRY/myapp:dev
kubectl run myapp --image=$BROMURE_REGISTRY/myapp:dev

Os clusters estão configurados para obter de todos os registos automaticamente; quando um registo é criado, muda de endereço ou é eliminado, os clusters em execução são atualizados. Enquanto um registo estiver parado, as obtenções dele falham como em qualquer indisponibilidade de registo.

Eliminar registo… «Pára a VM do registo e elimina todas as imagens que ele tem. Os espaços de trabalho e os clusters deixam de confiar no endereço dele. Isto não pode ser desfeito.»

Agentes e o MCP de infraestrutura

Os agentes de cada máquina recebem um servidor MCP bromure-infrastructure (porta vsock 5834), limitado aos clusters e registos que essa máquina pode usar. As suas ferramentas:

Um cluster ou registo que um agente crie é partilhado com todas as máquinas (Todos os espaços de trabalho) e arranca com o Bromure.

Ciclo de vida

• Sair da aplicação suspende os nós do cluster e os registos (um instantâneo da memória deles), e o arranque seguinte retoma-os. Um instantâneo que não se restaure recai num arranque novo.
• Parar desliga o k3s e os contentores de forma limpa antes de desligar as VM, dando até 60 segundos por máquina.
• Se uma VM de nó ou de registo falhar a verificação do sistema de ficheiros no arranque, o Bromure deteta-o, pára a VM, repara os discos de sistema e de dados, e arranca-a outra vez.
• Um cluster cuja primeira configuração nunca terminou é configurado de novo no arranque seguinte.
• Eliminar uma máquina remove-a de todas as listas de acesso; uma lista que ficasse vazia recai em todas as máquinas.
• Os clusters e registos aparecem na janela de espelho de um Mac remoto como tudo o mais (ver Acesso remoto).

Os registos de cluster vivem em ~/Library/Application Support/BromureAC/kube/clusters.json; os discos de nó de cada cluster estão sob ~/Library/Application Support/BromureAC/kube/<id-do-cluster>/.