ku est un TUI Kubernetes rapide, pensé pour naviguer dans un cluster sans quitter le terminal. Mon verdict court : ça mérite clairement un essai si tu vis déjà dans kubectl, mais je ne le mettrais pas encore comme console unique d’exploitation en prod sans le tester sur ton vrai cluster.
ku, c’est quoi ?
ku, pour Kubernetes, est une interface terminal qui reprend l’idée de k9s, Lens et lazygit : une navigation au clavier, une colonne de ressources à gauche, une table centrale, puis des actions directes sur l’objet sélectionné.
Le projet promet de parcourir les ressources, lire les YAML, suivre les logs, éditer des objets, ouvrir un shell dans un pod, redémarrer un déploiement, scaler, déclencher un CronJob, et afficher la commande kubectl équivalente.
Ce qui m’a intéressé côté freelance sécu/DevOps, c’est le mode par défaut : ku démarre en lecture seule. Les actions qui modifient le cluster sont désactivées tant qu’on ne passe pas explicitement en mode édition. Pour un outil de terminal qui peut toucher un cluster Kubernetes, ce détail compte.
| Point testé | Résultat observé |
|---|---|
| Version testée | ku v0.6.2 |
| Installation | binaire Linux amd64 depuis la release GitHub |
| Source | dépôt cloné à 4b3ca5b |
| Runtime | TUI terminal Bubble Tea |
| Cluster de test | API Kubernetes locale compatible, avec pods, deployment, node, namespaces et event |
| Mode par défaut | lecture seule |
Installation de ku
J’ai cloné le dépôt dans /tmp, lu le README, les docs et le Makefile. Le projet est écrit en Go et le go.mod demande Go 1.26.3. Dans mon conteneur de test, Go n’était pas installé, donc je suis passé par le binaire Linux amd64 publié en release.
Les commandes utiles ressemblent à ceci :
git clone https://github.com/bjarneo/ku.git /tmp/ku
curl -fsSL -o ku https://github.com/bjarneo/ku/releases/download/v0.6.2/ku-linux-amd64
chmod +x ku
./ku --version
Résultat :
ku v0.6.2
J’ai aussi testé la génération de configuration :
ku config init --force
ku config path
ku écrit un fichier YAML avec une sidebar structurée par sections, par exemple Workloads, Network, Config, Storage et Cluster. C’est pratique si tu veux ajouter des CRD dans le menu, KEDA, cert-manager, OpenTelemetry, ou des ressources maison.
ku à l’usage sur Kubernetes
Je voulais éviter le faux test qui consiste juste à demander la version. Le sandbox n’avait ni Docker, ni kind, ni kubectl, et les cgroups étaient en lecture seule. Donc je n’ai pas pu démarrer un vrai kind local dans ce conteneur.
Pour pousser le test quand même, j’ai monté une petite API Kubernetes locale compatible avec les endpoints utilisés par ku : découverte API, version serveur, tables pods, deployments, nodes, namespaces, et events. Elle exposait un cas volontairement réaliste : deux pods applicatifs dans default, dont un en ImagePullBackOff, un pod coredns dans kube-system, un deployment api à 1/2 prêt, un node Ready, et un event Warning.
Ensuite j’ai pointé ku dessus via un kubeconfig local et lancé le contrôle de connectivité :
ku --kubeconfig kubeconfig.yaml --check --resource pods
ku --kubeconfig kubeconfig.yaml --check --resource deploy
Ce que ku a produit : il a découvert 5 ressources, négocié les tables Kubernetes côté serveur, listé les pods avec 6 colonnes et 3 lignes, puis listé le deployment apps avec 6 colonnes et 1 ligne.
J’ai ensuite lancé le TUI en mode pods. Là, ku affiche bien la colonne de navigation, le contexte scout, le namespace default, la ressource pods, le badge READ-ONLY, puis une table avec les deux pods du namespace :
api-6d8f9b77c6-4s2hf, prêt en1/1, statutRunning;worker-7c9d8b5f8d-q2x9z, prêt en0/1, statutImagePullBackOff.
Le footer affiche les actions disponibles : config, describe, logs, edit mode, filtre, tri, docs, commande kubectl, navigation par tabulation. C’est exactement le genre d’écran que je veux voir en astreinte, pas une page marketing.
Ce que j’aime dans ku
Premier bon point : la sécurité par défaut. Le mode lecture seule est visible et les actions dangereuses ne sont pas seulement cachées dans la doc, elles sont désactivées dans l’interface. Pour une équipe où plusieurs profils touchent Kubernetes, c’est sain.
Deuxième point : ku utilise les tables serveur de Kubernetes. Ça veut dire que l’affichage ressemble à ce que Kubernetes sait déjà imprimer, au lieu de réinventer toutes les colonnes côté client. Pour les ressources classiques, c’est cohérent avec l’expérience kubectl.
Troisième point : le démarrage est simple. Un binaire, un kubeconfig, et l’outil part. Pas besoin d’Electron, pas de serveur web local, pas de base de données.
J’aime aussi l’idée du raccourci qui montre la commande kubectl équivalente. En audit ou en runbook, c’est utile : tu peux explorer vite dans le TUI, puis copier une commande explicite pour documenter ce qui a été fait.
Les limites de ku
La limite principale de mon test : je n’ai pas pu valider ku contre un vrai cluster kind dans ce sandbox. J’ai validé le binaire, la découverte, les tables, la configuration et le rendu TUI contre une API Kubernetes locale compatible, mais pas les chemins lourds comme exec dans un pod, édition réelle d’objet, restart, scale ou logs en follow sur un kubelet réel.
Deuxième limite : ku est jeune. Le dépôt est petit, la surface est claire, mais l’écosystème autour de k9s est beaucoup plus mature. Si tu as déjà des plugins, des habitudes et des scripts k9s, ku ne remplace pas tout du jour au lendemain.
Troisième limite : la capture TUI en environnement non interactif reste fragile. En terminal normal, l’interface est lisible. Dans un sandbox automatisé, il faut capturer via pseudo terminal, sinon Bubble Tea refuse l’ouverture du TTY. Ce n’est pas un bug bloquant pour l’utilisateur final, mais ça compte pour les tests CI ou les revues automatisées.
Est-ce que ku marche vraiment ?
Oui, pour la partie que j’ai pu exercer sérieusement. Le binaire démarre, lit un kubeconfig, interroge l’API Kubernetes, découvre les ressources, négocie les tables, affiche une interface exploitable et garde le mode lecture seule par défaut.
Non, je ne vais pas prétendre avoir validé tous les chemins de modification cluster. Sans cluster réel dans ce conteneur, ce serait malhonnête. Pour une adoption en prod, je ferais un second test sur un cluster de staging, avec ces scénarios : logs d’un pod multi-conteneur, describe d’un pod en erreur, édition d’un ConfigMap, scale d’un deployment, restart, et vérification des RBAC.
Faut-il adopter ku ?
Mon verdict : essayer, pas encore adopter aveuglément.
ku est intéressant pour les profils qui passent déjà leurs journées dans le terminal et veulent une interface plus fluide que des boucles kubectl get, describe, logs. Je le vois bien comme outil personnel de diagnostic, en complément de kubectl, surtout grâce au mode lecture seule.
Pour une équipe DevOps ou SRE, je le mettrais d’abord sur un cluster de staging avec des permissions limitées. S’il tient bien sur vos CRD et vos workflows de logs, il peut devenir un bon cockpit léger. Si vous avez besoin d’un outil ultra mature avec tout l’écosystème déjà éprouvé, k9s reste probablement le choix plus sûr aujourd’hui.
FAQ
ku remplace-t-il kubectl ?
Non. ku aide à naviguer, lire et agir plus vite, mais kubectl reste la référence pour les scripts, les runbooks et les commandes reproductibles.
ku est-il dangereux sur un cluster de production ?
Par défaut, ku démarre en lecture seule, ce qui réduit le risque de fausse manipulation. Les actions mutantes demandent de passer en mode édition, mais il faut quand même compter sur des RBAC propres.
ku fonctionne-t-il avec les CRD ?
Oui, le README indique qu’on peut ajouter des CRD dans la sidebar via ku config init, puis édition du YAML. Je n’ai pas validé une vraie CRD dans ce test, seulement la génération de configuration et les ressources Kubernetes de base.