Kubernetes 008 – Kubectl et Curl pour debutant : commandes et certificats clients

TL;DR

kubectl lit un kubeconfig, contacte l’API Server, s’authentifie puis envoie des requetes. Comprendre ce mecanisme aide a depanner les erreurs de contexte, certificats, droits et endpoints API. curl permet de voir plus directement la nature HTTP de l’API Kubernetes.

La video de reference

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

Elle relie l’usage quotidien de kubectl au fonctionnement interne de l’API Server.

Kubectl, un client de l’API Kubernetes

Quand on tape kubectl get pods, on ne lit pas un fichier local. On interroge l’API Server du cluster courant. Les informations de connexion viennent du kubeconfig: clusters, users et contexts.

Le role des certificats

Selon la configuration, Kubernetes peut utiliser des certificats clients pour authentifier les requetes. Cela explique pourquoi les erreurs TLS, certificats expires ou mauvais contextes peuvent bloquer toute commande.

Commandes utiles

kubectl config view
kubectl config current-context
kubectl get --raw /api
kubectl get --raw /apis
kubectl api-resources

kubectl get --raw est particulierement interessant pour visualiser l’API sans passer par un objet haut niveau.

Liens utiles

• Video: https://www.youtube.com/watch?v=AskMZMtjk2g
• Reference kubectl: https://kubernetes.io/docs/reference/kubectl/
• Kubeconfig: https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/
• Acces a l’API Kubernetes: https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/

FAQ

Kubectl parle-t-il directement aux noeuds ?

Non. Il parle a l’API Server du cluster courant.

Ou sont stockes les contexts ?

Dans le kubeconfig, souvent ~/.kube/config.

Pourquoi utiliser curl ?

Pour comprendre que Kubernetes expose une API HTTP et pour diagnostiquer certains problemes bas niveau.

Lire un kubeconfig sans se perdre

Un kubeconfig peut paraitre intimidant, mais il est organise autour de trois blocs: clusters, users et contexts. Le bloc clusters indique ou se trouve l’API Server. Le bloc users indique comment s’authentifier. Le bloc contexts relie les deux et ajoute parfois un namespace par defaut.

Cette organisation explique pourquoi une erreur peut venir de plusieurs endroits: mauvaise URL d’API, certificat invalide, utilisateur incorrect, contexte mal selectionne ou namespace inattendu.

Explorer l’API avec kubectl

Avant meme d’utiliser curl, kubectl permet de lire des chemins bruts:

kubectl get --raw /version
kubectl get --raw /api
kubectl get --raw /apis

Ces commandes montrent que Kubernetes expose une API structuree. Les ressources core sont sous /api, et les groupes plus specialises sous /apis.

Quand curl devient utile

curl est interessant pour comprendre TLS, certificats et tokens. Dans un contexte de formation, il permet de voir que kubectl n’est pas magique: il prepare simplement les bons headers, certificats et endpoints.

En production, on evite de manipuler des certificats sans methode claire. Les credentials Kubernetes donnent souvent beaucoup de pouvoir. Il faut les stocker proprement et limiter leur diffusion.

Erreurs frequentes

• Copier un kubeconfig sans savoir a quel cluster il correspond.
• Lancer une commande dans le mauvais contexte.
• Confondre probleme TLS et probleme RBAC.
• Oublier que kubectl config view --raw peut afficher des donnees sensibles.

Pour pratiquer

Comparez les sorties suivantes:

kubectl version
kubectl get --raw /version
kubectl api-resources
kubectl explain pod.spec.containers

Elles montrent plusieurs niveaux: version du client/serveur, endpoint brut, ressources disponibles et documentation de schema.

Comprendre une commande kubectl comme une requete

Une commande kubectl get pods -n default peut se lire comme une requete a l’API Server: l’utilisateur courant demande la liste des pods dans le namespace default. Kubernetes authentifie la requete, verifie les droits, puis retourne une representation des objets.

Cette lecture change la facon de diagnostiquer. Si la commande ne trouve rien, ce n’est pas forcement que les pods n’existent pas: on peut etre dans le mauvais namespace ou le mauvais contexte. Si la commande est refusee, le probleme peut etre RBAC. Si elle ne contacte pas le serveur, il faut regarder le kubeconfig, le reseau ou TLS.

Kubeconfig et donnees sensibles

Un kubeconfig peut contenir des certificats, des tokens ou des references vers des fichiers de credentials. Il ne faut donc pas le coller dans un ticket public, un depot Git ou une documentation partagee sans nettoyage.

Quelques precautions simples:

• eviter de partager kubectl config view --raw sans relecture;
• creer des acces limites pour les demonstrations;
• separer les kubeconfigs de lab et de production;
• supprimer les contexts inutiles;
• proteger les fichiers contenant des tokens ou certificats.

Curl pour visualiser, pas pour remplacer kubectl

curl est utile pour apprendre et diagnostiquer, mais il ne remplace pas kubectl au quotidien. kubectl gere la configuration, les formats de sortie, la decouverte d’API, les ressources Kubernetes et de nombreuses operations pratiques.

L’interet de curl est pedagogique: il montre que Kubernetes repose sur une API HTTP securisee. Une fois ce point compris, kubectl devient moins magique et les erreurs deviennent plus lisibles.

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 009 – Premiers Pods : kubectl run, describe, delete.

Conclusion

Maitriser kubectl, ce n’est pas seulement memoriser des commandes. C’est comprendre comment un client s’authentifie, choisit un contexte et dialogue avec l’API Kubernetes.