Kubernetes 014 – Kubectl : les contextes

TL;DR

Un contexte Kubernetes associe un cluster, un utilisateur et parfois un namespace. kubectl utilise le contexte courant pour toutes les commandes. Bien gerer ses contexts est indispensable quand on travaille avec plusieurs clusters ou environnements.

La video de reference

Video: https://www.youtube.com/watch?v=xX14RxILY0Q

Elle prolonge l’episode sur kubectl, la configuration et l’acces a l’API.

Le kubeconfig en trois parties

Le kubeconfig contient generalement:

• des clusters, avec l’adresse de l’API Server et les informations TLS;
• des users, avec les donnees d’authentification;
• des contexts, qui combinent un cluster, un user et un namespace.

Le contexte courant indique a kubectl ou envoyer les commandes.

Commandes indispensables

kubectl config get-contexts
kubectl config current-context
kubectl config use-context <nom-du-contexte>
kubectl config set-context --current --namespace=<namespace>
kubectl config view

Ces commandes doivent devenir des reflexes avant toute manipulation sensible.

Eviter les erreurs dangereuses

Le risque classique est de croire travailler sur un cluster de test alors que le contexte pointe vers un autre environnement. Avant une suppression, une modification de RBAC ou une operation large, verifier le contexte courant est une discipline simple mais essentielle.

Liens utiles

• Video: https://www.youtube.com/watch?v=xX14RxILY0Q
• Kubeconfig: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/
• Reference kubectl config: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_config/
• Kubectl: https://kubernetes.io/docs/reference/kubectl/

FAQ

Un contexte est-il un cluster ?

Non. Un contexte reference un cluster, un utilisateur et parfois un namespace.

Comment savoir ou pointe kubectl ?

Avec kubectl config current-context, puis kubectl config view si besoin.

Peut-on avoir plusieurs fichiers kubeconfig ?

Oui, via la variable KUBECONFIG, que kubectl peut fusionner logiquement.

Pourquoi les contextes sont critiques

Les contextes deviennent importants des que l’on manipule plusieurs environnements: lab local, cluster de test, staging, production, cluster client, cluster cloud. La commande kubectl delete n’a pas du tout le meme impact selon le contexte courant.

Un bon reflexe consiste a afficher le contexte dans son prompt shell, ou a verifier explicitement avant toute action sensible:

kubectl config current-context
kubectl get namespace

Changer seulement le namespace courant

On n’a pas toujours besoin de changer de cluster. Parfois, on veut seulement cibler un autre namespace dans le meme contexte:

kubectl config set-context --current --namespace=dev
kubectl config view --minify

--minify affiche la partie active de la configuration, ce qui rend la lecture plus simple.

Travailler avec plusieurs kubeconfigs

La variable KUBECONFIG permet de combiner plusieurs fichiers:

export KUBECONFIG=~/.kube/config:~/clusters/lab.yaml
kubectl config get-contexts

Cette pratique est utile, mais elle demande de la discipline. Plus il y a de contextes, plus le risque de se tromper augmente.

Erreurs frequentes

• Lancer une commande destructrice sans verifier le contexte.
• Croire que changer de namespace change de cluster.
• Garder des noms de contextes peu explicites.
• Partager un kubeconfig contenant trop de droits.

Pour pratiquer

kubectl config get-contexts
kubectl config current-context
kubectl config set-context --current --namespace=default
kubectl config view --minify

Ensuite, creez un namespace de test et basculez dessus pour voir l’effet sur les commandes sans option -n.

A retenir

Le contexte courant est une information de securite operationnelle. Savoir le lire et le changer proprement evite les erreurs les plus couteuses dans un environnement Kubernetes.

Nommer les contextes clairement

Des noms explicites reduisent les erreurs. Un contexte nomme prod-eu-west-admin ou lab-local-dev donne plus d’information qu’un nom genere automatiquement et difficile a reconnaitre. Le but n’est pas d’avoir des noms longs, mais de distinguer rapidement environnement, cluster et niveau de privilege.

On peut renommer un contexte avec:

kubectl config rename-context ancien-nom nouveau-nom
kubectl config get-contexts

Cette petite discipline devient tres utile quand on manipule plusieurs clusters cloud, des labs locaux et des environnements clients.

Utiliser le namespace courant avec prudence

Definir un namespace par defaut dans un contexte evite de repeter -n, mais cela peut aussi cacher une information importante. Quand on change souvent de projet, il faut verifier le namespace courant aussi serieusement que le cluster courant.

kubectl config view --minify --output 'jsonpath={..namespace}'
kubectl get pods
kubectl get pods -n autre-namespace

Si aucun namespace n’est defini dans le contexte, Kubernetes utilise generalement default. Ce comportement peut surprendre au debut, surtout quand les ressources attendues sont dans un namespace applicatif.

Bonnes pratiques avant une action sensible

Avant une suppression large, un changement RBAC ou une modification en production, prendre quelques secondes pour verifier:

• le contexte courant;
• le namespace courant;
• la ressource ciblee;
• l’etendue de la commande;
• les droits utilises.

Exemple simple:

kubectl config current-context
kubectl config view --minify
kubectl get all

Ce n’est pas de la bureaucratie. C’est une protection contre l’erreur humaine, qui reste une des causes les plus courantes d’incident operationnel.

Notions et definitions

• Control plane: ensemble des composants qui exposent l’API et prennent les decisions.
• Worker node: machine qui execute les pods applicatifs.
• Runtime et kubelet: briques locales responsables du lancement et du suivi des conteneurs.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Dans un cluster kubeadm, l’API Server recoit les manifests, le scheduler choisit un noeud, puis le kubelet demande au runtime de lancer les conteneurs.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Verifier les prerequis systeme: swap, modules kernel, runtime, reseau.
• Initialiser ou rejoindre le cluster selon le role du noeud.
• Installer un CNI avant d’attendre des pods applicatifs fonctionnels.
• Valider CoreDNS, nodes Ready et un deploiement de test.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser les composants d’un cluster, leur installation et les responsabilites entre control plane, workers et runtime. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get nodes -o wide
• kubectl -n kube-system get pods -o wide
• sudo crictl ps ou sudo systemctl status containerd kubelet sur les noeuds

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre installation reussie et cluster exploitable dans la duree
• ne pas verifier DNS, CNI, certificats et horloge apres l’installation
• oublier que la haute disponibilite depend aussi du load balancer et du reseau

Exercice conseille

Preparez une checklist post-installation: nodes Ready, CoreDNS fonctionnel, CNI actif, pod de test joignable et redemarrage d’un composant kube-system observe.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 015 – CLI kubectl : astuces pour gagner en efficacite.

Conclusion

Les contextes sont un petit sujet qui evite de gros problemes. Les maitriser permet de travailler proprement avec plusieurs clusters et de reduire les erreurs d’environnement.