Clusters Kubernetes et registres

Certains travaux demandent plus d'une machine : un service déployé sur Kubernetes, une image construite à un endroit et exécutée à un autre, une API cloud contre laquelle tester. Bromure Agentic Coding peut faire tourner cette infrastructure pour vous, sur ce Mac, à côté de vos machines (espaces de travail, dans l'éditeur de réglages) :

• Un cluster Kubernetes est un ensemble de VM de nœud faisant tourner k3s, avec en option du stockage répliqué, un équilibreur de charge, un contrôleur d'ingress et des émulateurs cloud locaux. Les machines que vous autorisez le reçoivent comme contexte dans ~/.kube/config.
• Un registre est un registre Docker privé dans sa propre petite VM. Les machines que vous autorisez peuvent y pousser ; tout cluster peut y tirer.

Les deux sont des ressources partagées : un cluster ou un registre sert plusieurs machines, et leurs agents en prennent connaissance par le serveur MCP d'infrastructure.

Note : ne confondez pas ces clusters avec les identifiants Kubernetes du volet Identifiants d'une machine. Ceux-là importent des contextes pour des clusters qui existent ailleurs (EKS, GKE, un cluster au travail) et relaient leurs identifiants sur le fil. Les clusters de ce chapitre sont des VM que Bromure crée et fait tourner sur ce Mac.

Où les trouver

• Espaces de travail › Infrastructure › Créer un cluster Kubernetes… et Créer un registre… ouvrent les feuilles de création. Avec une fenêtre de miroir d'un Mac distant au premier plan, ces éléments créent le cluster ou le registre sur ce Mac-là (voir Accès distant).
• Dès qu'il en existe un, la section Machines virtuelles de la barre latérale gagne une liste Kubernetes et une liste Registres, chacune avec un + pour en créer un autre. Une ligne montre un point d'état, le nom et un état d'une ligne ; cliquez-la pour mettre son tableau de bord sur la scène. Son menu ⋯ propose Démarrer, ou Redémarrer et Arrêter pendant qu'il tourne, Accès des espaces de travail… et Supprimer….

Créer un cluster

La feuille Nouveau cluster a une barre latérale de six volets — Général, Nœuds, Stockage, Réseau, Extensions, Accès — comme l'éditeur de réglages d'une machine. Créer reste désactivé tant que la feuille n'est pas valide ; une courte ligne à côté dit pourquoi (par exemple « Donnez un nom au cluster. »).

Général

Un Résumé liste les nœuds, le stockage, l'équilibreur de charge et les extensions que vous avez choisis.

Nœuds

Avec un seul nœud, il fait tourner le plan de contrôle et vos charges de travail ensemble. Avec plusieurs, le nœud 1 est le plan de contrôle (et fait toujours tourner des charges) et les autres rejoignent comme workers. Le volet montre la RAM totale, et avertit « Cela fait N Go sur les M Go de ce Mac — les espaces de travail ont aussi besoin de place. » quand le cluster laisserait moins de 4 Go pour tout le reste.

Stockage

• Stockage distribué Longhorn (activé par défaut) — des volumes bloc répliqués servis par iSCSI depuis un Disque de données par nœud dédié (40 Go par défaut, 10–2000 Go). Les disques sont creux : seuls les blocs écrits prennent de la place sur le Mac. Longhorn garde jusqu'à trois répliques, jamais plus que le nombre de nœuds. Sa classe de stockage est bromure-longhorn, celle par défaut du cluster. Désactivé, il ne reste que la classe local-path locale au nœud de k3s, qui épingle un pod à son nœud.
• NAS Synology — des volumes persistants sur votre NAS via le pilote CSI de Synology. Remplissez Adresse DSM, Port, HTTPS, Utilisateur DSM et Mot de passe DSM, des Volumes facultatifs (par exemple /volume1, /volume3), le Protocole — iSCSI (LUN bloc) ou SMB (dossiers partagés) — et le Système de fichiers. Sans volume nommé, DSM en choisit un avec de la place libre et la classe est bromure-synology ; nommer des volumes donne une classe par volume (bromure-synology-volume1, …). La première classe Synology devient celle par défaut du cluster ; Longhorn reste disponible par son nom. Le compte DSM a besoin des droits de gestionnaire de stockage. Le mot de passe est stocké chiffré sur ce Mac et n'atterrit jamais ailleurs que dans les Secrets propres au cluster.

Réseau

Équilibreur de charge choisit comment les Services de type LoadBalancer reçoivent une adresse :

Avec l'équilibreur de charge LAN Bromure, deux annotations de Service changent le défaut par Service : bromure.io/scope: vm le garde privé (une adresse sur le réseau VM, pour les machines et ce Mac seulement), et bromure.io/loadBalancerIP demande une adresse précise.

Contrôleur d'ingress Traefik (activé par défaut) garde l'ingress fourni avec k3s. Avec l'équilibreur de charge LAN, il publie les ports 80 et 443 sur ce Mac.

Avertissement : l'équilibreur de charge LAN Bromure rend les services du cluster joignables par n'importe qui sur votre réseau. Choisissez-le délibérément ; le défaut MetalLB garde tout sur ce Mac.

Extensions

Des émulateurs cloud locaux de la famille open source floci, chacun un Service LoadBalancer sur son propre port, avec ses données sur la classe de stockage par défaut du cluster :

Chaque émulateur activé reçoit un champ version de projet. Laissez-le vide (dernière version) pour obtenir la version la plus récente sur Docker Hub à la configuration du cluster ; tapez une étiquette (2.1.0) ou une référence d'image complète pour l'épingler. Si Docker Hub n'est pas joignable, l'étiquette latest est utilisée. Les services qui créent des conteneurs (Lambda, Cloud Run et compagnie) utilisent le Docker du nœud et sont au mieux.

Accès

Quelles machines reçoivent le cluster :

• Tous les espaces de travail, y compris les nouveaux (défaut), ou
• Seulement ces espaces de travail, avec une case par machine. « Au moins un espace de travail doit garder l'accès. »

Les machines de la liste reçoivent le cluster dans leur ~/.kube/config (le contexte porte le nom du cluster) et le voient par le MCP d'infrastructure. Vous pouvez changer cela plus tard depuis le tableau de bord.

Cliquez Créer. Le provisionnement prend quelques minutes ; l'onglet Journal du tableau de bord montre chaque étape.

Le tableau de bord du cluster

L'en-tête du tableau de bord montre le nom du cluster, une pastille de phase et un résumé (nœuds, vCPU et mémoire chacun, la version de k3s, la durée de fonctionnement), avec Démarrer, ou Redémarrer et Arrêter, et un menu Actions du cluster : Copier le kubeconfig, Accès des espaces de travail…, Démarrer avec Bromure et Supprimer le cluster….

Six onglets, avec un champ de filtre pour les listes :

Supprimer le cluster… « Arrête chaque nœud et supprime leurs disques, y compris tous les volumes Longhorn. Les espaces de travail perdent le cluster de leur kubeconfig. C'est irréversible. »

Utiliser un cluster depuis une machine

Dans une machine autorisée, kubectl marche simplement : le contexte du cluster est dans ~/.kube/config, et kubectl parle directement au nœud du plan de contrôle par le réseau VM. Ce trafic ne passe pas par le proxy interceptant de l'hôte — les adresses des nœuds sont exclues des réglages de proxy de la machine — il n'apparaît donc pas dans la trace de la machine.

L'action Copier le kubeconfig vous donne un kubeconfig autonome pour les outils sur le Mac lui-même. Les VM de nœud sont aussi joignables avec la CLI, par exemple bromure-cli vm exec k8s-dev-1 -- kubectl get nodes (voir CLI, API et MCP).

Les registres

Créer un registre

Créer un registre… ouvre une feuille : « Un registre Docker privé dans sa propre VM : construisez dans un espace de travail, poussez ici, exécutez dans un cluster. HTTP simple sur le réseau VM ; il ne quitte jamais ce Mac. »

Le disque d'images est creux : seules les couches poussées prennent de la place. Tout cluster peut tirer de tout registre ; l'accès en écriture est par machine.

Le tableau de bord du registre

L'en-tête montre l'adresse du registre (<ip>:5000), sa mémoire et son disque, Démarrer / Redémarrer / Arrêter, et un menu avec Copier l'adresse, Accès des espaces de travail…, Démarrer avec Bromure et Supprimer le registre…. Onglets : Images (des cartes Dépôts, Disque et Adresse, un extrait Pousser depuis un espace de travail, et la liste des images et étiquettes), Accès et Journal.

Dans une machine avec accès en écriture, Docker fait déjà confiance à l'adresse du registre, et $BROMURE_REGISTRY la contient (avec l'accès à plusieurs registres, celle du premier), si bien que vous pouvez pousser tout de suite :

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

Les clusters sont configurés pour tirer de tout registre automatiquement ; quand un registre est créé, change d'adresse ou est supprimé, les clusters en cours d'exécution sont mis à jour. Pendant qu'un registre est arrêté, les tirages depuis lui échouent comme toute panne de registre.

Supprimer le registre… « Arrête la VM du registre et supprime chaque image qu'il contient. Les espaces de travail et les clusters cessent de faire confiance à son adresse. C'est irréversible. »

Les agents et le MCP d'infrastructure

Les agents de chaque machine reçoivent un serveur MCP bromure-infrastructure (port vsock 5834), limité aux clusters et registres que cette machine peut utiliser. Ses outils :

Un cluster ou un registre qu'un agent crée est partagé avec chaque machine (Tous les espaces de travail) et démarre avec Bromure.

Cycle de vie

• Quitter l'application suspend les nœuds du cluster et les registres (un instantané de leur mémoire), et le démarrage suivant les reprend. Un instantané qui ne se restaure pas retombe sur un amorçage à neuf.
• Arrêter arrête proprement k3s et les conteneurs avant d'éteindre les VM, en accordant jusqu'à 60 secondes par machine.
• Si une VM de nœud ou de registre échoue à sa vérification de système de fichiers à l'amorçage, Bromure le détecte, arrête la VM, répare ses disques système et de données, et la réamorce.
• Un cluster dont la première configuration n'a jamais abouti est configuré à nouveau à son démarrage suivant.
• Supprimer une machine la retire de chaque liste d'accès ; une liste qui deviendrait vide retombe sur toutes les machines.
• Les clusters et les registres apparaissent dans la fenêtre de miroir d'un Mac distant comme tout le reste (voir Accès distant).

Les enregistrements de cluster vivent dans ~/Library/Application Support/BromureAC/kube/clusters.json ; les disques de nœud de chaque cluster sont sous ~/Library/Application Support/BromureAC/kube/<id-cluster>/.