Kubie : Isolez vos contextes Kubernetes par shell

Ce guide vous permet d’éviter le risque #1 en multi-clusters : exécuter kubectl apply ou kubectl delete sur le mauvais contexte ou namespace. Kubie résout ce problème en isolant le contexte et namespace par terminal, sans modifier votre kubeconfig global. Vous apprendrez à basculer entre clusters en sécurité, exécuter des commandes sur plusieurs contextes avec des wildcards, et configurer Kubie pour votre workflow. Prérequis : kubectl installé et au moins un cluster Kubernetes accessible.

Le problème : contexte global = erreurs inévitables

Quand vous gérez plusieurs clusters (dev, staging, prod), le contexte Kubernetes est global : un kubectl config use-context prod dans un terminal affecte tous vos terminaux, scripts et outils.

Scénario catastrophe classique :

Terminal 1 : vous passez en contexte prod-cluster pour une vérification rapide
Terminal 2 : vous oubliez où vous êtes et lancez kubectl delete deployment mon-app
Résultat : suppression en production alors que vous pensiez être en dev

Ce problème existe aussi avec les namespaces. Vous travaillez dans monitoring, vous ouvrez un nouveau terminal, mais le namespace actif est toujours default. Votre kubectl apply atterrit au mauvais endroit.

Comment Kubie résout le problème

Kubie isole le contexte et namespace par shell. Chaque terminal devient indépendant des autres. Concrètement :

kubie ctx prod-cluster ouvre un nouveau shell avec son propre kubeconfig temporaire
Ce kubeconfig ne contient que le contexte sélectionné
Les autres terminaux ne sont pas affectés
Quand vous quittez (exit), le shell temporaire disparaît

kubectx/kubens	Kubie
Modifie ~/.kube/config globalement	Crée un kubeconfig temporaire par shell
Un changement affecte tous les terminaux	Chaque terminal est isolé
Risque d’erreur multi-terminal	Sécurité renforcée

Installation

Version actuelle : v0.26.1 (décembre 2025)

# Télécharger la dernière version
curl -Lo kubie https://github.com/sbstp/kubie/releases/latest/download/kubie-linux-amd64

# Rendre exécutable et installer
chmod +x kubie
sudo install kubie /usr/local/bin/

# Vérifier l'installation
kubie --version

brew install kubie
kubie --version

pacman -S kubie
kubie --version

cargo install kubie
kubie --version

Vérification :

kubie --version

kubie 0.26.1

Démarrage rapide

kubie ctx

Cette commande affiche un menu interactif listant tous vos contextes. Sélectionnez-en un et Kubie ouvre un shell isolé.

Entrer dans un contexte spécifique

kubie ctx prod-cluster

Vous êtes maintenant dans un shell isolé, connecté à prod-cluster. Le prompt affiche le contexte actif :

[prod-cluster|default] user@host:~$

Changer de namespace

kubie ns monitoring

Le namespace change uniquement dans ce shell :

[prod-cluster|monitoring] user@host:~$

Revenir au contexte/namespace précédent

kubie ctx -    # Contexte précédent
kubie ns -     # Namespace précédent

Vérifier où vous êtes

kubie info ctx    # Affiche le contexte actuel
kubie info ns     # Affiche le namespace actuel
kubie info depth  # Niveau d'imbrication des shells Kubie

prod-cluster
monitoring
1

Quitter le shell Kubie

exit

Vous revenez à votre shell normal, sans avoir modifié le kubeconfig global.

Utilisation au quotidien

Recette A : Exécuter UNE commande sans changer de shell

Vous voulez vérifier quelque chose en prod sans ouvrir un nouveau shell :

kubie exec prod-cluster monitoring -- kubectl get pods

Sortie :

CONTEXT => prod-cluster
NAME                          READY   STATUS    RESTARTS   AGE
prometheus-0                  2/2     Running   0          3d
grafana-7b6d8c5f4d-x2k9m     1/1     Running   0          3d
--------------------

Recette B : Exécuter sur plusieurs clusters (wildcards)

Vérifier les nodes sur tous les clusters de dev :

kubie exec 'dev-*' kube-system -- kubectl get nodes

Kubie exécute la commande sur chaque contexte correspondant au pattern.

Arrêter en cas d’échec avec -e :

kubie exec -e '*-cluster' default -- kubectl apply -f deployment.yaml

L’option -e (ou --exit-early) stoppe l’exécution dès qu’une commande échoue.

Recette C : Générer un kubeconfig isolé pour un outil externe

Certains outils (Terraform, Ansible, scripts) n’utilisent pas le contexte kubectl. Kubie génère un kubeconfig isolé :

kubie export prod-cluster monitoring

Sortie :

/tmp/kubie-configXXXXXX.yaml

Utilisez ce fichier avec l’outil externe :

KUBECONFIG=$(kubie export prod-cluster monitoring) terraform apply

Recette D : Valider vos kubeconfigs

Détecter les erreurs de configuration avant qu’elles ne posent problème :

kubie lint

Si tout est valide, la commande ne renvoie rien. En cas de problème, elle affiche les erreurs détectées.

Recette E : Éditer un contexte

Modifier directement la configuration d’un contexte :

kubie edit prod-cluster

Cette commande ouvre le fichier kubeconfig contenant ce contexte dans votre éditeur par défaut.

Configuration (kubie.yaml)

Kubie se configure via le fichier ~/.kube/kubie.yaml.

Créer une configuration de base

kubie edit-config

Cette commande ouvre le fichier de configuration dans votre éditeur (le crée si besoin).

Gérer plusieurs fichiers kubeconfig

Par défaut, Kubie cherche les contextes dans plusieurs emplacements. Vous pouvez personnaliser avec configs.include et configs.exclude :

configs:
  include:
    - ~/.kube/config
    - ~/.kube/configs/*.yaml
    - ~/projets/*/kubeconfig.yaml
  exclude:
    - ~/.kube/kubie.yaml

Cette configuration permet de séparer vos kubeconfigs par projet ou par environnement.

Désactiver le prompt Kubie (pour Powerlevel10k/Starship)

Si vous utilisez un prompt avancé (Powerlevel10k, Starship) qui affiche déjà le contexte Kubernetes, désactivez le prompt Kubie pour éviter les doublons :

prompt:
  disable: true

Pour zsh avec RPS1 (prompt à droite) :

prompt:
  zsh_use_rps1: true

RBAC : désactiver la validation des namespaces

Si votre utilisateur n’a pas les droits de lister les namespaces (list namespaces), Kubie échoue par défaut lors du changement de namespace. Désactivez cette validation :

behavior:
  validate_namespaces: false

Afficher le contexte dans kubie exec

Par défaut, kubie exec affiche le contexte avant chaque sortie de commande. Vous pouvez contrôler ce comportement :

behavior:
  print_context_in_exec: true  # true, false, ou "auto"

Hooks personnalisés

Kubie permet d’exécuter des commandes à l’entrée et la sortie d’un contexte :

hooks:
  start_ctx: |
    echo -en "\033]1; $(kubie info ctx)|$(kubie info ns) \007"
  stop_ctx: |
    echo -en "\033]1; $SHELL \007"

Ces hooks permettent par exemple de modifier le titre de l’onglet terminal.

Exemple de configuration complète

configs:
  include:
    - ~/.kube/config
    - ~/.kube/configs/*.yaml
  exclude:
    - ~/.kube/kubie.yaml

prompt:
  disable: false  # true si vous utilisez p10k/starship
  zsh_use_rps1: false

behavior:
  validate_namespaces: true
  print_context_in_exec: auto

hooks:
  start_ctx: |
    echo "Contexte: $(kubie info ctx) | Namespace: $(kubie info ns)"

Bonnes pratiques

Nommage des contextes

Incluez l’environnement et la région dans le nom du contexte :

prod-eu-west-1
staging-eu-west-1
dev-local

Ce nommage réduit le risque d’erreur humaine : prod-* identifie immédiatement la production.

Un fichier kubeconfig par cluster

Plutôt qu’un seul ~/.kube/config gigantesque, séparez par cluster :

~/.kube/configs/
├── prod-eu-west-1.yaml
├── staging-eu-west-1.yaml
└── dev-local.yaml

Puis configurez Kubie :

configs:
  include:
    - ~/.kube/configs/*.yaml

Un seul système d’affichage du contexte

Choisissez un seul système pour afficher le contexte Kubernetes :

Prompt Kubie OU Powerlevel10k/Starship
Jamais les deux simultanément

Si vous avez déjà un prompt avancé, utilisez prompt.disable: true.

Scripts et automatisation

Dans les scripts, privilégiez kubie exec pour ne pas dépendre de l’état du terminal :

#!/bin/bash
# Mauvais : dépend du contexte actif
kubectl get pods

# Bon : explicite et reproductible
kubie exec prod-cluster monitoring -- kubectl get pods

CI/CD

En pipeline, restez explicite avec un kubeconfig dédié. Kubie n’est pas conçu pour les environnements headless où il n’y a pas de shell interactif.

Dépannage

Symptôme	Cause probable	Solution
`kubie ns` échoue avec “permission denied”	RBAC : pas de droit `list namespaces`	`behavior.validate_namespaces: false`
Prompt dupliqué (contexte affiché 2 fois)	Kubie + p10k/starship actifs	`prompt.disable: true`
Contexte non trouvé	Kubeconfig non dans le chemin par défaut	Ajouter dans `configs.include`
`kubie update` échoue	Installation via package manager	Mettre à jour via le même package manager
Shell se ferme immédiatement	Shell mal configuré	Vérifier `$SHELL` et les fichiers rc

À retenir

Kubie isole le contexte et namespace par shell, évitant les erreurs multi-terminal
La configuration se fait dans ~/.kube/kubie.yaml
Pour plusieurs kubeconfigs : configs.include / configs.exclude
Pour prompts avancés (p10k, Starship) : prompt.disable: true
Pour scripts multi-context : kubie exec avec wildcards et -e

Prochaines étapes

kubectl : les bases Maîtrisez les commandes kubectl essentielles avant d'aller plus loin

kubectx et kubens Alternative plus simple pour le switch global de contexte

Gérer les contextes kubectl Comprendre le fonctionnement des contextes Kubernetes

K9s : interface terminal Interface interactive pour gérer vos clusters Kubernetes