Kubernetes 015 – CLI kubectl : astuces pour gagner en efficacite

TL;DR

kubectl reste le client principal de Kubernetes, mais il devient vite verbeux. Les alias, la completion shell, les raccourcis de contexte, l’affichage du contexte dans le prompt et les interfaces comme k9s reduisent les erreurs et accelerent le debug.

La video de reference

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

Elle complete les episodes sur kubectl, le kubeconfig et les contextes en ajoutant une couche de confort pour le travail quotidien.

Pourquoi optimiser la CLI ?

Dans Kubernetes, on repete souvent les memes commandes: lister des pods, changer de namespace, lire des logs, decrire une ressource, suivre un rollout. Sans outillage, on perd du temps et on augmente le risque de cibler le mauvais cluster.

L’objectif n’est pas de cacher Kubernetes, mais de rendre les gestes courants plus rapides et plus visibles.

Alias utiles

alias k=kubectl
alias kgp='kubectl get pods'
alias kga='kubectl get all'
alias kdp='kubectl describe pod'
alias kaf='kubectl apply -f'
alias kdel='kubectl delete -f'

Il faut rester raisonnable: un alias doit etre evident. Si personne ne comprend kxqz, il devient dangereux.

Completion shell

kubectl completion bash
kubectl completion zsh
source <(kubectl completion zsh)

Avec l’alias k, on peut aussi activer la completion pour celui-ci selon le shell utilise. C’est un gain enorme pour les noms de ressources, namespaces et options.

kubectx et kubens

kubectx permet de changer rapidement de contexte. kubens permet de changer rapidement de namespace courant.

kubectx
kubectx mon-cluster-dev
kubens
kubens monitoring

Ces outils sont tres pratiques, mais ils ne remplacent pas la verification avant une action sensible.

kube-ps1 dans le prompt

kube-ps1 affiche le contexte et le namespace dans le prompt. C’est une protection visuelle simple quand on passe souvent d’un cluster a l’autre.

Exemple d’information utile dans le prompt:

(dev-cluster:default) $
(prod-eu:payments) $

k9s pour explorer

k9s fournit une interface terminal pour naviguer dans les pods, services, deployments, logs et events. Il est tres efficace pour lire vite, filtrer et inspecter.

Il ne faut pas l’utiliser comme une boite noire: les commandes kubectl equivalentes doivent rester connues pour automatiser et documenter les actions.

Commandes a garder

kubectl config current-context
kubectl get pods -A
kubectl get deploy -A
kubectl logs -f deploy/<nom>
kubectl describe pod <pod>
kubectl explain deployment.spec

Liens utiles

• Video: https://www.youtube.com/watch?v=PiBY4taQYq4
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Documentation kubectl: https://kubernetes.io/docs/reference/kubectl/
• kubectx: https://github.com/ahmetb/kubectx
• k9s: https://k9scli.io/

FAQ

Les alias sont-ils dangereux ?

Ils peuvent l’etre si leur nom est obscur. Un bon alias raccourcit sans masquer l’intention.

k9s remplace-t-il kubectl ?

Non. k9s aide a explorer, mais kubectl reste la reference pour comprendre, reproduire et automatiser.

Faut-il afficher le contexte dans le prompt ?

Oui, surtout si plusieurs clusters sont manipules. C’est une barriere simple contre les erreurs.

Erreurs frequentes

• Installer beaucoup d’outils sans maitriser les commandes de base.
• Changer de contexte sans verifier le namespace.
• Utiliser des alias destructeurs trop courts.
• Croire que l’interface k9s explique toujours pourquoi un objet est en erreur.

Pour pratiquer

Installez la completion, creez deux alias lisibles, puis observez votre contexte courant avant et apres un changement de namespace.

kubectl config current-context
kubectl config view --minify
kubens default
kubectl get pods

Notions et definitions

• API Server: porte d’entree de toutes les operations Kubernetes.
• Objet declaratif: document qui decrit l’etat voulu plutot qu’une suite d’actions imperatives.
• Controleur: composant qui agit pour rapprocher le reel du desire.

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

Un manifest Deployment ne dit pas comment creer chaque pod pas a pas; il declare le resultat attendu, et Kubernetes se charge de converger vers cet etat.

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

• Explorer le schema de l’objet avec kubectl explain.
• Creer l’objet declarativement avec kubectl apply -f.
• Observer status, conditions et events.
• Modifier le YAML puis reappliquer pour comprendre la reconciliation.

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 le modele mental Kubernetes: API declarative, etat desire, controleurs et observation continue du cluster. 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 api-resources pour lister les objets disponibles
• kubectl explain <ressource> pour comprendre le schema d’un objet
• kubectl get events --sort-by=.lastTimestamp pour suivre ce que le cluster decide

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

• voir Kubernetes comme une suite de commandes au lieu d’une API d’etat
• oublier la difference entre creer un objet et obtenir un workload fonctionnel
• ne pas regarder les events et les conditions avant de chercher trop loin

Exercice conseille

Prenez un objet simple, creez-le en imperatif, exportez son YAML, supprimez-le, puis recréez-le en declaratif pour comparer les deux approches.

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 016 – Un Deployment c’est quoi ?.

Conclusion

Les astuces autour de kubectl ne sont pas des gadgets. Elles accelerent les operations courantes et rendent le contexte plus visible. Le bon compromis consiste a gagner en confort sans perdre la comprehension des objets Kubernetes.