Gérer des clusters Talos, de la machine vierge à la mise à jour. Tourne à côté du cluster, pas dedans.
À côté du cluster
Reste joignable même quand le cluster est à l’arrêt.
Direct vers Talos
Parle à l’API des machines. Pas d’agent, pas de talosctl.
Du métal au nœud
Trouver, vérifier, configurer et intégrer les machines.
Mises à jour sûres
Nœud par nœud, avec un plan, un snapshot etcd frais et un contrôle de santé.
Alpha 0.8.0 : holzkube-manager en est à ses débuts et change beaucoup. Fonctions, réglages et formats de données peuvent changer à chaque version. Sauvegardez avant une mise à jour et lisez les notes de version.
holzkube-manager gère des clusters Kubernetes sur Talos Linux. Un seul binaire Go tourne en dehors du cluster et parle directement à l’API des machines Talos. Il n’exige ni agent dans le cluster ni service cloud. C’est une alternative auto-hébergée à Sidero Omni, sous AGPL-3.0 au lieu de BUSL-1.1.
Qui doit remettre un cluster en route ne peut pas compter sur un outil qui tourne dedans. D’où un binaire, un dossier de données, HTTPS dès le premier démarrage, par exemple sur un Raspberry Pi 5 à côté du cluster. L’interface fonctionne de l’écran mural au téléphone.
Version 0.8.0 — version sur GitHub. Fonctionne avec un vrai cluster Talos ; les builds n’existent que pour linux/arm64 (Raspberry Pi 5). La surveillance des certificats dans le cluster n’a été testée que sur un simulateur ; capteurs en direct, Wake-on-LAN et actions Talos forcées n’ont pas encore été essayés sur du vrai matériel. La dérive de configuration n’a jamais tourné sur un vrai cluster Talos : que Talos ne réécrive pas lui-même la configuration, qu’un nœud renvoie après un apply ce qui a été envoyé, le délai après un redémarrage et la bannière après de vraies heures ne sont pas vérifiés. Une valeur de secret modifiée seule reste invisible.
Fonctions
De la machine vierge au nœud
Un assistant trouve les machines démarrées depuis l’ISO Talos, vérifie l’empreinte de leur certificat et écrit la configuration. Disque d’installation, nom d’hôte et chiffrement TPM se choisissent avant.
Inventaire et nœuds
Chaque machine avec état, rôle, adresse et versions, même si elle ne répond pas. Redémarrage, reset ou suppression redemandent une confirmation. Un nœud est supprimé par une tâche : sortie d’etcd, effacement du disque système, oubli. La tâche reprend après un redémarrage.
Kubernetes en un coup d’œil
Dix vues, des workloads aux événements. Cordon et drain des nœuds, mise à l’échelle ou redéploiement, et pour un pod en panne le journal de l’exécution plantée juste à côté.
Mises à jour avec ceinture
Talos et Kubernetes sont mis à jour nœud par nœud. Un plan montre d’abord chaque étape. Une mise à jour de Talos ne démarre qu’avec un snapshot etcd frais, et avant chaque nœud un contrôle de santé vérifie le quorum etcd. Quand la cible est à plusieurs versions mineures, le plan nomme le dernier correctif de chaque version intermédiaire.
Sauvegardes etcd planifiées
Toutes les 6 heures, chaque jour ou chaque semaine, avec le nombre de snapshots à garder. La liste montre taille et SHA-256. Si la dernière sauvegarde a plus de deux intervalles, le cluster est signalé en retard. Les sauvegardes restent sur l’appareil et ne survivent pas à la perte de sa carte SD : copiez les importantes ailleurs.
Certificats
La carte du cluster montre la durée de validité restante du certificat client et, sous « Cluster certificates », celle des certificats du cluster (API Talos, etcd, Kubernetes et leurs autorités), lus sur chaque nœud de plan de contrôle et classés du plus proche échéant au plus lointain. Quand l’un devient court, une bannière apparaît sur chaque page, une ligne sur l’affichage mural et une valeur dans /metrics. Le certificat client se renouvelle, la CA Talos se renouvelle par une tâche reprenable. talosconfig, kubeconfig et bundle de support se téléchargent, chaque téléchargement entre dans le journal d’audit.
Dérive de configuration
La configuration active de chaque nœud est lue toutes les 3 heures et comparée à ce que holzkube-manager savait en dernier ou avait lui-même écrit. La référence est une copie dont les secrets sont noircis. Une modification faite sur le nœud (talosctl, un autre opérateur) apparaît avec son diff sur la page du nœud, sous forme de ligne « Configuration » sur la carte du cluster et dans /metrics, et sous forme de bannière dès qu’elle reste 24 heures sans confirmation. « Confirm as intended » fait de l’état actuel la nouvelle référence, exige le rôle admin et la saisie du mot de passe, entre dans le journal d’audit et ne change rien sur le nœud. Les modifications que holzkube-manager fait lui-même (patch, mise à jour de Kubernetes, rotation de la CA) ne comptent pas comme dérive. Le dossier de données passe pour cela au schéma 7 ; une ancienne version restaurée le refuse, le guide indique comment revenir en arrière.
Affichage mural
Une vue plein écran pour le moniteur du bureau. Chaque nœud et chaque namespace est une tuile ; ce qui ne tourne pas apparaît en grand et en couleur. Un lien en lecture seule, révocable, la garde ouverte.
En plus : reprendre un cluster existant via talosconfig (en lecture seule jusqu’à sa libération), patcher la MachineConfig avec un diff, diagnostic des volumes orphelins et des liaisons RBAC mortes, vue de l’hôte (le Pi) avec températures et systèmes de fichiers, journal d’audit en chaîne de hachage, rôles et connexion OIDC, la CLI holzkubectl et /metrics pour Prometheus. Le script de mise à jour vérifie la somme de contrôle et revient en arrière tout seul si le contrôle de santé échoue.
Installation
Télécharger l’archive linux_arm64 de la version. C’est la seule architecture. Là où holzkube-manager tourne déjà, sudo holzkube-manager-update suffit. Le reste est dans le guide.
Autres projets
holzcloud-CMS, le CMS sans JavaScript, holzBar, le gestionnaire de barre des menus pour macOS, et holzWave, le terminal écrit en Rust. Retour à l’accueil.