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 :

1. Terminal 1 : vous passez en contexte prod-cluster pour une vérification rapide
2. Terminal 2 : vous oubliez où vous êtes et lancez kubectl delete deployment mon-app
3. 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.

Risque réel

Le contexte kubectl est partagé entre tous les terminaux. Changer de contexte dans un terminal affecte tous les autres. C'est le problème que Kubie résout.

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

Glissez pour voir

Quand utiliser Kubie vs kubectx

• Kubie : plusieurs terminaux ouverts, plusieurs clusters, scripts multi-context
• kubectx/kubens : un seul terminal, un seul cluster, changements ponctuels

Installation

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

Version variable

La version peut varier selon le gestionnaire de paquets. Vérifiez toujours avec kubie --version.

Binaire (Linux)

Épinglez la version plutôt que d'utiliser latest, et vérifiez l'empreinte du binaire avant de l'installer : la somme SHA-256 ci-dessous est celle publiée par GitHub pour l'artefact kubie-linux-amd64 de la version v0.26.1.

cd "$(mktemp -d)"
KUBIE_VERSION=v0.26.1
KUBIE_SHA256=e10ab6b929adf805deac47aecd6d316202f3bb729b5bbeb66e62f0bdb394fb2c

curl -sSLf -O \
  "https://github.com/kubie-org/kubie/releases/download/${KUBIE_VERSION}/kubie-linux-amd64"

# Vérification obligatoire : doit afficher "kubie-linux-amd64: OK"
echo "${KUBIE_SHA256}  kubie-linux-amd64" | sha256sum --check

# Installation seulement si la vérification a réussi
sudo install -m 0755 kubie-linux-amd64 /usr/local/bin/kubie

# Vérifier l'installation
kubie --version

Si sha256sum affiche FAILED, n'installez pas le fichier. Pour une autre version, relevez l'empreinte sur la page de la release correspondante ; ne réutilisez pas celle-ci.

Homebrew

brew install kubie
kubie --version

Arch Linux

pacman -S kubie
kubie --version

Cargo

cargo install kubie
kubie --version

Vérification :

kubie --version

kubie 0.26.1

Démarrage rapide

Kubie ne remplace pas kubectl, il encapsule un shell dans lequel kubectl trouvera un kubeconfig temporaire. Toutes les commandes qui suivent partent donc du même principe : elles agissent sur le shell courant et disparaissent avec lui. Les deux commandes centrales sont kubie ctx pour le contexte et kubie ns pour le namespace.

Choisir un contexte (menu interactif)

Sans argument, Kubie liste les contextes trouvés dans tous les kubeconfigs qu'il connaît, pas seulement dans ~/.kube/config.

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

Passer le nom du contexte en argument saute le menu. Kubie lance alors un sous-shell : votre shell d'origine reste ouvert derrière, inchangé.

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 s'utilise à l'intérieur d'un shell Kubie et accepte lui aussi un menu interactif si vous omettez le nom.

kubie ns monitoring

Le namespace change uniquement dans ce shell :

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

Revenir au contexte/namespace précédent

Le tiret rappelle la valeur précédente, sur le modèle de cd -. L'historique se limite à un cran en arrière.

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

Vérifier où vous êtes

Ces commandes écrivent une seule valeur sur la sortie standard, ce qui les rend utilisables dans un script ou un prompt. Hors d'un shell Kubie, elles échouent avec Error: Not in a kubie shell! et un code de retour 1 : c'est le contrôle le plus simple pour savoir si l'isolation est réellement active.

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

La sortie se fait avec la commande habituelle du shell, sans commande Kubie dédiée. Le kubeconfig temporaire est supprimé au passage.

exit

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

Utilisation au quotidien

Ouvrir un sous-shell n'est pas toujours ce qu'on veut : pour une vérification ponctuelle, pour une boucle sur plusieurs clusters ou pour un outil qui lit KUBECONFIG sans passer par kubectl, Kubie propose des sous-commandes qui n'ouvrent aucun shell. Les cinq recettes ci-dessous couvrent ces cas, de la commande unique à la validation des fichiers de configuration.

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
--------------------

Le double tiret est obligatoire

Le -- sépare les arguments de kubie exec de la commande à exécuter. Sans lui, Kubie peut confondre les options.

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.

Chemin correct

Le fichier de configuration est ~/.kube/kubie.yaml, pas ~/.config/kubie.yaml.

Créer une configuration de base

Le fichier n'existe pas après l'installation : Kubie fonctionne entièrement avec ses valeurs par défaut tant que vous ne le créez pas.

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

Powerlevel10k

Powerlevel10k affiche nativement le contexte Kubernetes via son segment kubecontext. Avec prompt.disable: true, vous gardez un seul indicateur visuel. Voir l'issue #1008 de p10k pour les détails.

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

Ce fichier reprend les quatre sections vues plus haut avec leurs valeurs par défaut, sauf configs.include : les commenter ou les supprimer produit exactement le même comportement, l'exemple sert surtout de point de départ à personnaliser.

~/.kube/kubie.yaml

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

Kubie supprime le risque de fuite de contexte entre terminaux, mais pas celui de se tromper de cluster à l'intérieur d'un terminal. Les règles ci-dessous ferment cet angle mort : des noms de contextes qui rendent la production reconnaissable au premier coup d'œil, des kubeconfigs séparés, un seul indicateur visuel, et des scripts qui ne dépendent jamais de l'état du shell.

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

Les incidents Kubie viennent presque tous de son environnement plutôt que de l'outil : droits RBAC insuffisants, kubeconfig hors des chemins scrutés, ou prompt déjà géré par un autre outil. Avant de chercher plus loin, vérifiez avec kubie info depth que vous êtes bien dans un shell Kubie, et avec kubie lint que vos fichiers de configuration sont valides.

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

Glissez pour voir

À 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

×

📖 Voir la documentation →