Utilisation des contextes Kubernetes

Mise à jour : 17/02/2025

Dans un environnement Kubernetes multi-cluster, la gestion des contextes est essentielle pour naviguer efficacement entre différents environnements (développement, test, production). Un contexte permet de passer rapidement d’un environnement à un autre sans reconfigurer vos kubeconfig à chaque fois.

Sans une bonne organisation des contextes, on risque des erreurs critiques comme déployer une modification en production au lieu d’un environnement de test.

C’est quoi un contexte Kubernetes ?

Un contexte Kubernetes est une configuration qui associe :

Un cluster : l’ensemble des ressources Kubernetes gérées.
Un utilisateur : les identifiants et permissions pour interagir avec le cluster.
Un namespace : l’espace logique dans lequel les ressources sont organisées.

L’objectif est de permettre à kubectl de savoir quel cluster utiliser, avec quel utilisateur et dans quel namespace. Cela évite de répéter ces informations à chaque commande.

Pourquoi utiliser plusieurs contextes ?

Dans un environnement Kubernetes, il est courant de travailler avec plusieurs clusters :

Un cluster local pour le développement (kind, minikube, k3d).
Un cluster de test/staging pour valider les modifications.
Un cluster de production qui exécute les services en ligne.
Plusieurs clusters clients si on gère des infrastructures différentes.

Grâce aux contextes, on peut facilement basculer d’un environnement à l’autre sans risquer d’exécuter une commande sur le mauvais cluster.

Où sont stockés les contextes ?

Les contextes sont enregistrés dans le fichier kubeconfig (~/.kube/config par défaut). Ce fichier regroupe toutes les informations nécessaires pour se connecter aux clusters, y compris :

La liste des clusters disponibles.
Les informations d’authentification des utilisateurs.
La liste des contextes enregistrés.
Le contexte actif utilisé par défaut.

On peut afficher le fichier kubeconfig avec :

cat ~/.kube/config

Ou récupérer le contexte actif avec :

kubectl config current-context

Syntaxe et structure du fichier kubeconfig

Le fichier kubeconfig est un élément clé dans la gestion des contextes Kubernetes. Il permet à kubectl de savoir quel cluster utiliser, avec quel utilisateur et quel namespace. Ce fichier peut inclure plusieurs clusters, utilisateurs et contextes, et il est souvent stocké par défaut dans ~/.kube/config.

Dans ce chapitre, nous allons explorer la structure de kubeconfig, ses principaux éléments et comment inclure plusieurs fichiers kubeconfig.

Structure d’un fichier kubeconfig

Un fichier kubeconfig est un fichier YAML contenant trois sections principales :

clusters : définit les clusters disponibles
users : stocke les informations d’authentification
contexts : associe un cluster et un utilisateur
current-context : indique le contexte utilisé par défaut

Exemple de fichier ~/.kube/config :

apiVersion: v1
kind: Config
clusters:
- name: cluster-dev
  cluster:
    server: https://dev-cluster.example.com
    certificate-authority: /path/to/ca.crt
- name: cluster-prod
  cluster:
    server: https://prod-cluster.example.com
    certificate-authority: /path/to/ca.crt

users:
- name: dev-user
  user:
    client-certificate: /path/to/dev-user.crt
    client-key: /path/to/dev-user.key
- name: prod-user
  user:
    token: "xyz789"

contexts:
- name: dev-context
  context:
    cluster: cluster-dev
    user: dev-user
    namespace: dev-namespace
- name: prod-context
  context:
    cluster: cluster-prod
    user: prod-user
    namespace: prod-namespace

current-context: dev-context

Explication des éléments du fichier :

clusters :
- name : identifiant du cluster
- server : URL du serveur API Kubernetes
- certificate-authority : chemin du certificat CA pour sécuriser la connexion
users :
- name : identifiant de l’utilisateur
- client-certificate / client-key : authentification par certificat
- token : authentification par jeton
contexts :
- name : nom du contexte
- cluster : référence à un cluster défini
- user : référence à un utilisateur défini
- namespace : namespace par défaut utilisé
current-context :
- Indique quel contexte est actif par défaut

Gestion de plusieurs fichiers kubeconfig

Si on dois travailler avec plusieurs fichiers kubeconfig (par exemple, un fichier pour chaque cluster), on peut les fusionner sans modifier ~/.kube/config.

Il suffit de définir la variable KUBECONFIG pour charger plusieurs fichiers simultanément :

export KUBECONFIG=/chemin/vers/kubeconfig1:/chemin/vers/kubeconfig2

On peut ensuite afficher tous les contextes disponibles :

kubectl config get-contexts

Gestion les contextes existants

Maintenant que nous avons une idée de la structure de mon fichier kubeconfig, on peut commencer à gérer les contextes Kubernetes. Cela inclut l’affichage des contextes disponibles ,la modification du contexte actuel, le renommage et la suppression des contextes.

Lister les contextes disponibles

Avant de manipuler les contextes Kubernetes, il est essentiel de savoir lesquels sont déjà configurés. Pour afficher la liste des contextes disponibles dans le fichier kubeconfig, j’utilise la commande :

kubectl config get-contexts

Cette commande affiche une sortie similaire à ceci :

CURRENT   NAME          CLUSTER       AUTHINFO      NAMESPACE
*         dev-context   cluster-dev   dev-user      dev-namespace
          prod-context  cluster-prod  prod-user     prod-namespace

La colonne CURRENT indique quel est le contexte actif (avec *).
NAME est le nom du contexte.
CLUSTER correspond au cluster associé.
AUTHINFO indique l’utilisateur utilisé pour l’authentification.
NAMESPACE (optionnel) montre le namespace par défaut utilisé avec ce contexte.

Vérifier le contexte actif

Si on veut savoir sur quel contexte on travaille actuellement, on utilise :

kubectl config current-context

Exemple de sortie :

multinode-demo

Cela signifie que toutes mes commandes kubectl s’exécuteront sur le cluster associé à ce contexte.

Définir un contexte par défaut

Si on travaille régulièrement avec un contexte spécifique, il est utile de le définir comme contexte actif pour éviter d’avoir à le spécifier à chaque commande.

kubectl config use-context prod-context

Après cela, toutes mes commandes kubectl seront exécutées sur le cluster de production

Renommer un contexte

Si on a un contexte avec un nom peu explicite, on peut le renommer :

kubectl config rename-context ancien-nom nouveau-nom

Exemple :

kubectl config rename-context prod-context production

Cela met à jour la configuration sans affecter le cluster ou l’utilisateur.

Supprimer un contexte

Si un contexte n’est plus utile, on peut le supprimer avec :

kubectl config delete-context nom-du-contexte

Exemple :

kubectl config delete-context old-context

Bonnes pratiques pour gérer les contextes Kubernetes

Nommer les contextes clairement :

Utiliser une convention explicite :

✅ prod-ecommerce-cluster1 / dev-fintech-cluster2

🚫 test / mon-cluster (trop vague)

Définir un contexte par défaut sécurisé :

Ne pas laisser production actif par défaut :

kubectl config use-context staging-cluster

Vérifier le contexte avant chaque action :

Afficher le contexte actif avant toute commande sensible :

kubectl config current-context

Sécuriser le kubeconfig :

Protéger l’accès au fichier :

chmod 600 ~/.kube/config

Stocker les kubeconfig sensibles dans Vault ou AWS Secrets Manager.

Sauvegarder le kubeconfig :

Garder une copie de sauvegarde du fichier kubeconfig :

cp ~/.kube/config ~/.kube/config.bak

Nettoyer les contextes inutilisés :

Lister et supprimer les contextes obsolètes :

kubectl config get-contexts
kubectl config delete-context ancien-contexte

Utiliser des alias pour les commandes fréquentes :

Simplifier les commandes kubectl avec des alias :

alias k=kubectl
alias kprod='kubectl config use-context prod-cluster'
alias kdev='kubectl config use-context dev-cluster'

Utiliser kubectx :

Changer rapidement de contexte :

kubectx prod-cluster

Conclusion

La gestion des contextes Kubernetes est essentielle pour travailler efficacement et de manière sécurisée avec plusieurs clusters. Grâce aux contextes, on peut facilement naviguer entre différents environnements sans risque d’erreur.

En appliquant les bonnes pratiques, comme nommer clairement les contextes, sécuriser le kubeconfig et vérifier systématiquement le contexte actif, on évite des erreurs critiques, notamment en production. L’utilisation d’outils comme kubectx et l’automatisation via des alias simplifie encore la gestion quotidienne.