Kubernetes for Beginners mis à jour : du cluster au rollback

L’installation d’un cluster ne devrait pas être le premier obstacle d’un cours Kubernetes pour débutants. Avant même d’avoir compris les relations entre Pods, Deployments et Services, les choix d’installation, le runtime et le réseau peuvent imposer une seconde série de problèmes.

Nous avons donc restructuré Kubernetes for Beginners. Chaque laboratoire fournit désormais un cluster Kubernetes v1.35.5 préconfiguré. Le parcours commence par la lecture de l’état du cluster, puis couvre le déploiement, le diagnostic, l’exposition par Service, la mise à l’échelle, la mise à jour et le rollback.

Observer le cluster avant de créer des ressources

Le premier Guided Lab, Explore the Kubernetes Cluster, ne demande pas de créer immédiatement un Pod. Il commence par vérifier le contexte actif, l’état des nœuds et les composants principaux déjà présents dans le cluster.

Copier une commande kubectl est simple. Il faut encore savoir quel cluster elle interroge, comprendre l’état renvoyé et relier les objets Kubernetes entre eux. Cette méthode d’observation fournit un point de référence pour les déploiements et diagnostics suivants.

Le client et le serveur Kubernetes du laboratoire utilisent tous deux la version v1.35.5. Une fois l’environnement prêt, des commandes en lecture seule permettent de confirmer la version et l’état du nœud, sans installer ni démarrer le cluster.

Six paires d’exercices suivent le cycle de l’application

Le cours comprend six Guided Labs et six Challenges correspondants. Les commandes prennent place dans le cycle de vie d’une application plutôt que dans une liste de notions isolées :

1. Explorer le cluster et contrôler l’état de Kubernetes
2. Déployer une application et lancer un premier Pod
3. Lire l’état de l’application et diagnostiquer un Deployment NGINX
4. Exposer l’application avec un Service et vérifier l’accès
5. Mettre l’application à l’échelle et observer la répartition de charge
6. Mettre l’application à jour et effectuer un rollback si nécessaire

Les notions restent utiles d’un laboratoire au suivant. L’état des nœuds et des Pods sert d’abord à évaluer la santé du cluster, puis à diagnostiquer un Deployment. Les labels et sélecteurs reviennent au moment d’examiner les backends d’un Service et les Pods créés par la mise à l’échelle.

Trois questions pour chaque opération

La mise à jour apporte davantage de contexte fondamental et développe la première explication de chaque commande, option et champ YAML. Chaque opération précise pourquoi elle est exécutée, quel résultat est attendu et comment lire la sortie.

La création d’un Service, par exemple, ne prouve pas que l’application est accessible. Il faut aussi vérifier que le sélecteur correspond aux bons labels, que le Service trouve les Pods attendus, que le DNS du cluster résout le nom et qu’une requête atteint réellement l’application.

Cette méthode vaut aussi pour l’état des Pods, les déploiements, la mise à l’échelle, les mises à jour et les rollbacks. La réussite se lit dans l’état final du système, pas seulement dans l’absence d’erreur de la commande.

La convergence Kubernetes fait partie de l’exercice

Kubernetes rapproche continuellement l’état réel de l’état désiré déclaré. Ce processus n’est pas instantané. Un Pod nouvellement créé peut encore télécharger son image, les réplicas d’un Deployment peuvent démarrer et les backends d’un Service peuvent ne pas être prêts.

Les laboratoires révisés améliorent l’attente et les nouvelles tentatives pendant le démarrage des ressources et les contrôles réseau. La validation laisse un délai raisonnable à la convergence, puis contrôle toujours l’état final. Elle évite ainsi les échecs dus à une transition brève sans confondre une erreur de configuration avec une attente normale.

Les commandes, sorties et exemples ont également été actualisés pour v1.35.5. Tous les laboratoires ont été revérifiés et le parcours principal a été testé dans des environnements neufs.

Les Challenges portent sur les acquis déjà travaillés

Chaque Guided Lab est suivi d’un Challenge associé. Les instructions détaillées disparaissent, mais seuls les commandes, objets et méthodes de diagnostic déjà expliqués et pratiqués sont évalués.

Après avoir travaillé sur l’état des Pods, les labels et les backends de Services, il faut par exemple refaire ces contrôles de façon autonome. Le défi n’introduit pas soudainement une commande inconnue : il vérifie qu’il est possible d’atteindre et de valider l’état demandé sans disposer de la procédure complète.

Si vous n’avez encore jamais exploité de cluster Kubernetes, commencez par la nouvelle version de Kubernetes for Beginners. La première tâche n’est pas de déployer une application, mais de comprendre ce que le cluster exécute déjà.