kubectx et kubens : Basculer rapidement entre contextes et namespaces

Ce guide vous permet de basculer entre contextes et namespaces Kubernetes en une seule commande, au lieu de taper kubectl config use-context ... ou kubectl config set-context --current --namespace=.... kubectx et kubens sont parfaits pour le travail interactif quotidien. Vous apprendrez à les installer, les utiliser efficacement, et éviter le piège principal : l’état global partagé entre terminaux.

État global = risque d'erreur

kubectx et kubens modifient le contexte/namespace dans votre kubeconfig (~/.kube/config). Ce changement est global : tous vos terminaux sont affectés. Si vous travaillez avec plusieurs terminaux ouverts, voyez aussi Kubie qui isole le contexte par shell.

Le problème : commandes kubectl trop longues

Changer de contexte ou namespace avec kubectl natif est fastidieux :

# Changer de contexte (long et sujet aux erreurs de frappe)
kubectl config use-context gke_projet1-europe-west1-prod

# Changer de namespace (encore pire)
kubectl config set-context --current --namespace=monitoring

Problèmes concrets :

• Noms de contextes longs générés par les clouds (GKE, EKS, AKS)
• Erreurs de frappe fréquentes
• Impossible de revenir rapidement au contexte précédent
• Pas de visibilité sur le contexte actif

La solution : kubectx et kubens

Outil	Fonction	Commande classique équivalente
kubectx	Change de contexte	kubectl config use-context ...
kubens	Change de namespace	kubectl config set-context --current --namespace=...

Glissez pour voir

Ce qui change :

# Avant (kubectl)
kubectl config use-context gke_projet1-europe-west1-prod
kubectl config set-context --current --namespace=monitoring

# Après (kubectx/kubens)
kubectx prod       # Si vous avez créé l'alias
kubens monitoring

Installation

Version actuelle : 0.9.5 (stable)

Bash ou Go ?

Historiquement, kubectx/kubens étaient des scripts Bash. Depuis la version 0.9.x, une implémentation en Go est disponible. Selon la méthode d’installation, vous pouvez avoir l’un ou l’autre. Les deux sont fonctionnellement équivalents.

mise (recommandé)

mise est un gestionnaire de versions universel.

mise install kubectx@latest kubens@latest
mise use -g kubectx@latest kubens@latest

Vérification :

kubectx --version
kubens --version

0.9.5
0.9.5

Homebrew

Homebrew installe les deux outils automatiquement :

brew install kubectx

Vérification :

kubectx --version

Krew

Krew est le gestionnaire de plugins officiel pour kubectl.

Installer Krew (voir documentation officielle) :

kubectl krew install ctx ns

Les commandes sont accessibles via kubectl ctx et kubectl ns.

Binaire

Téléchargement direct depuis GitHub :

# kubectx
curl -Lo kubectx https://github.com/ahmetb/kubectx/releases/latest/download/kubectx_v0.9.5_linux_x86_64.tar.gz
tar -xzf kubectx*.tar.gz
sudo install kubectx /usr/local/bin/

# kubens
curl -Lo kubens https://github.com/ahmetb/kubectx/releases/latest/download/kubens_v0.9.5_linux_x86_64.tar.gz
tar -xzf kubens*.tar.gz
sudo install kubens /usr/local/bin/

Arch Linux

pacman -S kubectx

Démarrage rapide

Lister les contextes et namespaces

kubectx    # Liste les contextes (le * indique l'actif)
kubens     # Liste les namespaces

Exemple de sortie :

dev-cluster
* minikube
prod-cluster

Changer de contexte/namespace

kubectx prod-cluster      # Passe au contexte prod-cluster
kubens monitoring         # Passe au namespace monitoring

Sortie :

✔ Switched to context "prod-cluster".
✔ Active namespace is "monitoring"

Revenir au précédent

kubectx -    # Contexte précédent
kubens -     # Namespace précédent

Cette fonction est particulièrement utile quand vous alternez entre deux environnements.

Vérifier l’état actuel

kubectl config current-context                                        # Contexte
kubectl config view --minify -o jsonpath='{..namespace}' && echo     # Namespace

Utilisation avancée

Renommer un contexte avec un alias

Les noms générés par les clouds sont souvent longs :

gke_projet1-europe-west1-prod
arn:aws:eks:eu-west-1:123456789:cluster/my-cluster

Créez des alias courts et mémorisables :

kubectx prod=gke_projet1-europe-west1-prod
kubectx staging=gke_projet1-europe-west1-staging
kubectx dev=gke_projet1-europe-west1-dev

Désormais, vous pouvez simplement taper :

kubectx prod

Supprimer un contexte

kubectx -d mon-ancien-contexte
# Équivalent à : kubectl config delete-context mon-ancien-contexte

Suppression du contexte uniquement

Supprimer un contexte ne supprime pas le cluster lui-même. Vous supprimez seulement la référence dans votre fichier kubeconfig.

Créer un contexte personnalisé

Pour créer un contexte avec un namespace par défaut spécifique :

kubectl config set-context dev-monitoring \
  --cluster=dev-cluster \
  --namespace=monitoring \
  --user=dev-cluster

Le nouveau contexte apparaît automatiquement dans kubectx.

Bonnes pratiques

Toujours afficher le contexte dans le prompt

L’erreur la plus courante : exécuter une commande sur le mauvais cluster parce qu’on a oublié où on était.

Solution 1 : kube-ps1

kube-ps1 ajoute le contexte et namespace à votre prompt Bash/Zsh :

(⎈|prod-cluster:monitoring) user@host:~$

Solution 2 : Powerlevel10k

Si vous utilisez Powerlevel10k, activez le segment kubecontext dans votre configuration.

Solution 3 : Vérification manuelle

À défaut d’un prompt configuré, prenez l’habitude de vérifier avant toute commande critique :

kubectl config current-context

Nommer les contextes intelligemment

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

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

Ce nommage rend les erreurs plus difficiles : prod-* est immédiatement identifiable comme production.

Scripts et CI : ne jamais dépendre du contexte courant

kubectx/kubens sont parfaits pour le travail interactif. En script ou pipeline CI, toujours être explicite :

# ❌ Mauvais : dépend de l'état global
kubectl get pods

# ✅ Bon : explicite et reproductible
kubectl --context prod-cluster -n monitoring get pods

Mieux encore, utilisez un kubeconfig dédié en CI :

export KUBECONFIG=/path/to/ci-kubeconfig.yaml
kubectl get pods

Un kubeconfig par projet (optionnel)

Si vous gérez beaucoup de clusters, séparez les kubeconfigs :

~/.kube/
├── config           # Contextes courants
├── configs/
│   ├── projet-a.yaml
│   └── projet-b.yaml

Puis fusionnez-les dans KUBECONFIG :

export KUBECONFIG=~/.kube/config:~/.kube/configs/projet-a.yaml

Quand utiliser Kubie à la place ?

Situation	Outil recommandé
Un seul terminal, travail interactif simple	kubectx/kubens
Plusieurs terminaux, risque d’erreur multi-cluster	Kubie
Scripts et automatisation	kubectl --context ... -n ...
Pipeline CI/CD	Kubeconfig dédié + variables d’environnement

Glissez pour voir

La différence clé :

• kubectx/kubens → changement global (tous les terminaux affectés)
• Kubie → isolation par shell (chaque terminal est indépendant)

Dépannage

Symptôme	Cause probable	Solution
error: no contexts	Pas de kubeconfig configuré	Vérifier ~/.kube/config
Contexte non trouvé	Nom incorrect ou kubeconfig non chargé	kubectl config get-contexts
Changement n’affecte pas un autre terminal	Normal : le shell lit le fichier à chaque commande	C’est le comportement attendu
fzf s’ouvre au lieu de lister	fzf installé → mode interactif	Passez le nom du contexte directement

Glissez pour voir

À retenir

• kubectx et kubens = productivité interactive (switch rapide, alias, toggle avec -)
• Ils modifient l’état global du kubeconfig → toujours afficher le contexte dans votre prompt
• Créez des alias courts pour vos contextes fréquents (prod, staging, dev)
• En scripts/CI : toujours utiliser --context et -n explicitement
• Pour l’isolation par terminal : passez à Kubie

Prochaines étapes

Kubie : isolation par shell Alternative plus sûre pour le travail multi-terminal

Gérer les contextes kubectl Comprendre le fonctionnement des contextes en détail

K9s : interface terminal Interface interactive complète pour vos clusters

kubectl : les bases Maîtrisez les commandes kubectl essentielles

×

📖 Voir la documentation →