🐈 sofka : une TUI Kubernetes en Rust qui explique les pannes

📚 Introduction

Quand je dois fouiller un cluster Kubernetes, j’ouvre rarement kubectl en premier. J’ouvre une TUI. Pendant des années, ce réflexe s’appelait k9s, et il le reste pour beaucoup de monde.

sofka se présente comme une alternative directe. Écrite en Rust sur kube-rs et ratatui, elle reprend l’ergonomie clavier de k9s et revendique ouvertement l’inspiration. Son slogan résume l’angle choisi : « The cluster tells you it’s broken. sofka tells you why. »

Le projet est jeune (premier paquet sur crates.io en juillet 2026) mais avance vite : la version 0.31.9 est sortie aujourd’hui même. Il vaut un coup d’œil, surtout si vous gérez des clusters pilotés par Flux CD ou Argo CD.

🔍 Qu’est-ce que sofka apporte de plus que k9s ?

Surtout du diagnostic, et des intégrations GitOps qui se passent de binaires externes. Le reste (navigation, filtres, CRD, port-forwards, skins) existe déjà des deux côtés, et la documentation de sofka a l’honnêteté de le dire dans sa comparaison avec k9s.

La fonction phare tient sur une touche : X. Sur une ressource en souffrance, elle ouvre une vue d’incident qui rassemble l’état du rollout, les conditions dégradées, les pods bloquants, les raisons d’échec des conteneurs et les événements Warning récents. Jobs, CronJobs, PVC et Nodes ont leurs propres vérifications. Le point qui m’intéresse : cette vue est déterministe. Pas d’IA, pas de service tiers, juste des règles appliquées aux données du cluster. Pour un outil qu’on dégaine en plein incident, je préfère ce choix.

À côté, T affiche une timeline des changements observés par le watch pendant la session (réplicas, phases, redémarrages, bascules de conditions). Elle vit en mémoire et disparaît à la fermeture, ce n’est donc pas un journal d’audit.

🧰 GitOps sans CLI externe, Helm en lecture native

La touche t ouvre un menu d’actions sur les ressources Flux CD : suspend, resume, reconcile now, sur les Kustomizations, HelmReleases, sources et l’image automation. Même logique pour Argo CD, avec suspend, resume et sync des Applications. Tout passe par des patchs envoyés directement à l’API Kubernetes, sans binaire flux ni argocd installé sur le poste.

Pour Helm, la commande :helm ouvre un inspecteur qui décode lui-même les Secrets de release : historique, values, manifests rendus, NOTES. Si vous avez lu mon article sur Helm 4, vous savez que ces Secrets contiennent tout l’état d’une release. sofka les lit sans passer par la CLI. Pour agir, c’est différent : le rollback (r) et la désinstallation (ctrl-d) appellent le vrai binaire helm, qu’il faut donc garder installé.

Quelques autres fonctions que je n’ai pas croisées ailleurs sous cette forme :

• Capacité engagée par nœud (:nodes) : les requests et limits CPU/mémoire des pods rapportées à l’allocatable. C’est ce qui explique qu’un pod refuse de se planifier sur un nœud qui a l’air calme, et ça fonctionne sans Metrics Server.
• Édition de Secrets décodés : e ouvre les valeurs en clair dans $EDITOR, sofka les réencode et ne patche que les clés modifiées, après confirmation.
• Contenu des volumes : x sur une PVC permet de parcourir les fichiers et de les copier dans les deux sens.
• Logs combinés : on marque plusieurs pods avec space, puis l pour lire leurs logs ensemble.
• Filtres typés : texte flou, !inverse, sélecteurs de labels et de champs, comparaisons comme restarts>=5 ou age<2h.

🚀 Installation et premiers pas

Le choix est large. Homebrew, Nix et Cargo couvrent la majorité des postes de dev :

brew install sofka                     # tap officiel Homebrew (macOS/Linux)
nix run github:nklmilojevic/sofka      # sans rien installer
cargo install sofka

Sur Linux, pkg.sofka.rs sert des dépôts signés apt, dnf, zypper, pacman et apk, ce qui permet de garder l’outil à jour avec le reste du système. Des binaires sont publiés pour macOS, Linux et Windows (aarch64 et x86_64) à chaque release.

Le lancement ressemble à k9s, avec quelques options utiles :

sofka                      # pods du contexte courant
sofka dp -A                # deployments, tous namespaces
sofka --context prod --readonly
sofka ctx                  # sélecteur de contexte avant connexion

Pour tester, un cluster local k3s ou k3d fait parfaitement l’affaire.

Deux modes sans TTY méritent d’être signalés, parce qu’ils servent de smoke tests en CI : sofka --check se connecte, lance la découverte et imprime un résumé, sofka pods --snapshot rend une seule frame d’une vue sur la sortie standard.

🛠️ Venir de k9s

C’est souvent là que tout se joue : personne n’a envie de réécrire sa config. sofka import k9s convertit alias, plugins, hotkeys, vues, skins et réglages par contexte, puis liste honnêtement ce qui n’a pas pu l’être.

La configuration se fait en TOML ou en YAML sous ~/.config/sofka (ou $XDG_CONFIG_HOME/sofka), découpable en fichiers conf.d/, et :reload la recharge à chaud. Le mode lecture seule peut être forcé par contexte, ce qui rend la règle « on ne supprime rien en prod » bloquante au lieu de reposer sur la mémoire de chacun.

Depuis la 0.26.0, un registre officiel de plugins relus est aussi disponible (sofka plugin search, sofka plugin install popeye). Popeye et Trivy y figurent, à condition d’avoir le binaire correspondant dans le PATH.

⚠️ Quelques précautions

Benchmark à prendre pour ce qu’il est. Le rapport du dépôt, refait le 6 octobre 2026 avec sofka 0.31.0 et k9s 0.51.0, donne une vue des pods affichée en 2,82 s contre 3,85 s (médianes) et 324 Mio de RSS contre 738 Mio. Le site affiche encore une mesure plus ancienne, plus flatteuse (59 % de gain), que ce rapport remplace. Tout tourne sur un seul Apple M3 Max, et l’auteur détaille lui-même les limites du test. C’est un indice, pas une vérité générale.

Projet très jeune. Trois mois d’existence publique et des versions qui s’enchaînent rapidement : attendez-vous à des changements de comportement entre deux mises à jour.

Parité imparfaite avec k9s. Pulse, Xray et Popeye existent mais ne fonctionnent pas comme dans k9s. Si votre routine en dépend, comparez avant de basculer.

Plugins non sandboxés. Les paquets du registre sont relus et vérifiés par checksum, mais ils s’exécutent avec vos permissions.

Gatekeeper sur macOS. Les binaires ne sont pas encore signés : un tarball téléchargé depuis le navigateur sera bloqué. xattr -d com.apple.quarantine sofka règle le problème, ou passez par Homebrew ou Nix.

🎉 Conclusion

sofka ne remplace pas k9s par magie, et ne prétend pas le faire. Ce qu’il propose est ciblé : une vue X qui rassemble les preuves d’une panne, Flux et Argo CD pilotables sans CLI annexe, un inspecteur Helm natif, et quelques vues pensées pour l’exploitation (capacité engagée, Secrets décodés, volumes).

Si vous vivez déjà dans k9s, l’import de config rend l’essai presque gratuit. Je le garderais en lecture seule sur les clusters de prod le temps de se faire la main. Et pour ceux qui découvrent l’écosystème, mon article sur les bases de Kubernetes pose le décor.

Le nom, au passage, vient de Sophie, le chat de l’auteur : un bleu russe qui surveille l’écran en permanence. « sofka » est le diminutif serbe de Sophia.

🔗 Liens utiles

• Site officiel de sofka
• Dépôt GitHub nklmilojevic/sofka
• Documentation
• Liste complète des fonctionnalités
• Comparaison sofka / k9s
• Rapport de benchmark face à k9s
• sofka sur crates.io