Introduction
Les applications modernes sont souvent empaquetées dans des conteneurs. Un conteneur regroupe une application avec les bibliothèques et les paramètres dont elle a besoin, ce qui facilite son exécution de manière cohérente. Exécuter un seul conteneur est simple. Exécuter de nombreux conteneurs de façon fiable est plus complexe : il faut décider où les exécuter, redémarrer ceux qui échouent, connecter les applications entre elles et déployer les modifications en toute sécurité.
Kubernetes est un système d'orchestration de conteneurs qui prend en charge ces responsabilités à l'échelle du cluster. Vous décrivez l'état souhaité — par exemple, « exécuter trois instances de cette application web » — et Kubernetes s'efforce en permanence d'aligner l'état réel sur cet état souhaité.
Un cluster Kubernetes se compose d'une ou plusieurs machines appelées nœuds. Le plan de contrôle gère le cluster, tandis que les nœuds fournissent le processeur, la mémoire, le réseau et le moteur d'exécution des conteneurs utilisés par les applications. Les applications s'exécutent dans des objets Kubernetes tels que les Pods, les Deployments et les Services.
Dans ce premier laboratoire, vous ne déploierez pas encore d'application. Vous allez d'abord apprendre à vous repérer dans un cluster réel :
- Identifier les outils, le cluster actif, la version de Kubernetes et l'état des nœuds.
- Repérer les composants du plan de contrôle et des nœuds qui permettent à Kubernetes de fonctionner.
- Examiner les points de terminaison du cluster et les informations détaillées sur les nœuds.
- Explorer les Pods, les Deployments et les Services dans les différents espaces de noms.
L'environnement est déjà préparé afin que vous puissiez vous concentrer sur les concepts Kubernetes plutôt que sur l'installation. Il utilise Minikube v1.38.1 avec un profil nommé labex-v135, exécutant Kubernetes v1.35.5. Minikube exécute un cluster Kubernetes complet dans un conteneur Docker sur la machine virtuelle LabEx. Il s'agit d'un environnement d'apprentissage à nœud unique, mais les commandes et les concepts Kubernetes que vous allez pratiquer s'appliquent également aux clusters plus importants.
Vous travaillerez entièrement dans le terminal. Lisez les explications avant d'exécuter chaque commande, puis comparez la sortie réelle avec les éléments décrits. Les durées exactes, le nombre de redémarrages et les noms générés peuvent varier ; c'est normal dans un système actif.
Vérifier le cluster préconfiguré
Démarrage de l’environnement : Ce lab démarre pour vous un cluster Kubernetes complet. La configuration du plan de contrôle, du nœud et des composants réseau prend généralement 2 à 3 minutes. Veuillez patienter jusqu’à la fin du chargement de l’environnement avant de commencer.
Dans cette étape, vous découvrirez comment les outils du terminal se connectent à Kubernetes, vous identifierez les versions logicielles fournies et vous confirmerez que le cluster est prêt. Avant de modifier un cluster, un administrateur doit toujours savoir quel cluster est actif et vérifier qu'il est en bonne santé.
Comprendre les outils
Vous utiliserez deux outils en ligne de commande associés :
minikubecrée et gère des clusters Kubernetes locaux. Un environnement Minikube nommé est appelé un profil. Ce laboratoire utilise le profillabex-v135.kubectlest le client standard en ligne de commande de Kubernetes. Il envoie des requêtes au serveur d'API Kubernetes pour lister, créer, mettre à jour et supprimer des objets.
Le cluster est déjà démarré. N'exécutez pas minikube start : cette commande est inutile et pourrait vous faire attendre pendant que Minikube vérifie à nouveau l'environnement existant.
Accéder au répertoire de travail
Placez-vous dans le répertoire du projet, où les laboratoires suivants enregistreront les manifestes et les autres fichiers créés par l'apprenant :
cd /home/labex/project
La commande cd modifie le répertoire courant du shell. En cas de réussite, elle n'affiche normalement aucune sortie.
Vérifier la version de Minikube
Affichez la version installée de Minikube. Une option commençant par -- modifie le comportement de la commande. Ici, --short demande d'afficher uniquement le numéro de version.
minikube version --short
v1.38.1
Il s'agit de la version de l'outil de gestion du cluster, et non de la version de Kubernetes. Minikube et Kubernetes sont deux projets distincts, avec des numéros de version différents.
Vérifier les versions du client et du serveur
Demandez à kubectl les informations de version. Cette commande contacte le cluster ; elle vérifie donc à la fois le client local et le serveur d'API distant :
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version correspond à la version de kubectl installée ; Server Version est fournie par le serveur d'API Kubernetes. La présence de la ligne du serveur prouve que kubectl a bien réussi à joindre un cluster. Kustomize est une fonctionnalité intégrée de personnalisation des manifestes, dont vous n'aurez pas besoin dans ce laboratoire.
Confirmer le contexte actif
Un ordinateur peut stocker les informations d'accès à plusieurs clusters dans un fichier kubeconfig. Un contexte kubeconfig sélectionne un cluster, des identifiants utilisateur et un espace de noms par défaut. Vérifier le contexte évite de travailler accidentellement dans le mauvais cluster.
kubectl config current-context
labex-v135
Cela correspond au profil Kubernetes v1.35 préparé pour le laboratoire.
Lister et sélectionner les contextes
Les fichiers kubeconfig réels contiennent souvent plusieurs contextes. Listez-les avant d'effectuer une sélection afin de ne pas avoir à deviner leur nom :
kubectl config get-contexts
La colonne NAME contient les noms des contextes, et la colonne CURRENT indique le contexte actif à l'aide de *. Le cluster, les informations d'authentification et l'espace de noms par défaut associés à chaque contexte apparaissent dans les autres colonnes.
Utilisez use-context lorsque vous devez sélectionner l'un de ces noms. Sélectionner à nouveau labex-v135 est sans risque même s'il est déjà actif, et vous permet de pratiquer le processus exact de changement de contexte :
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context répond à la question « lequel est sélectionné ? », get-contexts à la question « quelles options existent ? », et use-context NAME modifie la sélection. Ces commandes ne changent que le choix du client local ; elles ne démarrent, n'arrêtent et ne modifient aucun cluster.
Vérifier le profil Minikube
Demandez à Minikube l'état de ce profil. L'option courte -p signifie profile et est suivie de son nom.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host signifie que le conteneur du nœud Minikube est en cours d'exécution. kubelet est l'agent du nœud. apiserver est le point de terminaison de l'API Kubernetes. kubeconfig: Configured indique que la configuration du client local pointe vers ce cluster. Tous ces éléments doivent être sains.
Lister les nœuds
La plupart des commandes kubectl suivent la forme kubectl <verb> <resource>. Ici, get lit les objets et nodes désigne le type de ressource :
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME identifie le nœud. STATUS=Ready signifie qu'il peut exécuter des charges de travail. ROLES indique qu'il héberge le plan de contrôle. AGE peut être antérieur à cette session, car l'image restaure un instantané préparé. VERSION correspond à la version de kubelet.
Dans ce laboratoire, un seul nœud assure à la fois les fonctions du plan de contrôle et celles d'exécution des charges de travail. Dans les clusters de production, ces fonctions sont généralement réparties entre plusieurs machines.
Point de contrôle de l'étape
Vous avez vérifié que kubectl atteint le cluster labex-v135 prévu et que son nœud est Ready sous Kubernetes v1.35.5. Cette routine d'orientation est utile chaque fois que vous accédez à un cluster que vous ne connaissez pas encore.
Identifier les composants de l'architecture Kubernetes
Dans cette étape, vous allez relier le modèle d'architecture Kubernetes à des composants réels. Les noms tels que serveur d'API, ordonnanceur et kubelet sont plus faciles à retenir lorsque vous observez leurs Pods en cours d'exécution.
Suivre une requête dans Kubernetes
Imaginez que vous demandiez à Kubernetes d'exécuter une application web. Tout d'abord, kubectl envoie la requête à kube-apiserver, qui la valide et stocke l'état souhaité dans etcd.
Ensuite, kube-scheduler choisit un nœud pour chaque nouveau Pod. kube-controller-manager surveille le cluster et s'efforce d'aligner l'état réel sur l'état souhaité.
Enfin, le kubelet du nœud sélectionné demande au moteur d'exécution des conteneurs de démarrer les conteneurs du Pod. Les composants réseau permettent aux Pods et aux Services de communiquer.
Cette comparaison continue entre l'état souhaité et l'état réel s'appelle la réconciliation. Si un Deployment demande trois Pods mais que seuls deux existent, un contrôleur crée le Pod manquant.
Comprendre les Pods et les espaces de noms système
Un Pod est la plus petite unité Kubernetes pouvant être déployée. Il regroupe un ou plusieurs conteneurs étroitement liés et leur fournit un contexte réseau et de stockage partagé.
Un espace de noms définit une portée logique pour les objets qui lui sont associés. kube-system contient l'infrastructure du cluster. L'option -n kube-system indique à kubectl d'effectuer la recherche dans cet espace plutôt que dans l'espace de noms par défaut. Son équivalent long est --namespace=kube-system ; les deux formes sélectionnent la même portée.
Minikube exécute les composants du plan de contrôle sous forme de Pods statiques. Le kubelet les crée directement à partir de fichiers présents sur le nœud, ce qui permet au plan de contrôle de démarrer avant que la planification ordinaire soit disponible.
Lister le plan de contrôle
Les objets peuvent porter des étiquettes, c'est-à-dire des métadonnées clé-valeur utilisées pour les regrouper et les sélectionner. Utilisez -l tier=control-plane pour sélectionner les Pods portant cette étiquette :
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
Le serveur d'API est la porte d'entrée de Kubernetes. etcd stocke l'état du cluster. L'ordonnanceur choisit l'emplacement des Pods. Le gestionnaire de contrôleurs exécute les contrôleurs de réconciliation.
READY=1/1 signifie que l'unique conteneur du Pod est prêt. Les composants qui fonctionnent en continu doivent être Running. RESTARTS peut être différent de zéro après la reprise du cluster sauvegardé. AGE indique l'âge de l'objet, et non le temps écoulé depuis le début de ce laboratoire.
Examiner les étiquettes
Affichez les étiquettes dans une dernière colonne :
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Recherchez component=kube-apiserver et tier=control-plane. La première étiquette identifie un composant ; la seconde regroupe tous les Pods du plan de contrôle. Les étiquettes identifient les objets et les sélecteurs permettent de trouver les objets correspondants.
Examiner les composants réseau des nœuds
Utilisez un sélecteur basé sur des ensembles, indiquant que k8s-app vaut soit kube-proxy, soit calico-node. Les guillemets empêchent le shell d'interpréter les parenthèses.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico configure le réseau des Pods. kube-proxy maintient les règles du nœud qui aident les Services à diriger le trafic vers les Pods. Le kubelet n'apparaît pas dans cette liste, car il s'agit de l'agent hôte chargé de gérer les Pods ; il s'exécute donc comme un service de l'hôte et non comme un Pod ordinaire géré par lui-même.
Point de contrôle de l'étape
Le serveur d'API accepte les requêtes, etcd stocke l'état, l'ordonnanceur choisit l'emplacement des Pods, les contrôleurs réconcilient l'état, le kubelet gère le nœud, et Calico ainsi que kube-proxy assurent la prise en charge du réseau.
Examiner les détails du cluster et des nœuds
Dans cette étape, vous passerez d'une simple vérification de l'état à une inspection détaillée. Kubernetes propose des vues synthétiques sous forme de listes ainsi que des descriptions détaillées ; savoir quand utiliser chacune d'elles est une habitude essentielle pour le dépannage.
Localiser les points de terminaison du cluster
kubectl cluster-info est une commande spécialement conçue pour s'orienter dans un cluster. Contrairement à kubectl get, elle ne liste pas un type de ressource précis ; elle demande au cluster actif de fournir les adresses de services importants tels que le serveur d'API et CoreDNS.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
L'URL du plan de contrôle est le point de terminaison du serveur d'API. CoreDNS fournit la découverte de services DNS, ce qui permet aux charges de travail de trouver les Services par leur nom au lieu de suivre des adresses IP susceptibles de changer. Les adresses varient ; concentrez-vous donc sur is running, qui indique que le serveur d'API a renvoyé des informations. Cela ne prouve pas que toutes les charges de travail sont saines.
Développer la liste des nœuds
Ajoutez -o wide pour demander davantage de colonnes :
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP est l'adresse du nœud sur le réseau du cluster. EXTERNAL-IP=<none> signifie qu'aucune adresse publique gérée par Kubernetes ne lui est attribuée. OS-IMAGE, KERNEL-VERSION et CONTAINER-RUNTIME décrivent les logiciels du nœud.
L'infrastructure LabEx utilise Ubuntu 22.04, tandis que Minikube représente le nœud Kubernetes avec un conteneur Docker basé sur Debian. Il est donc normal de voir Debian ici.
Décrire le nœud
Utilisez describe lorsqu'une ligne de liste ne fournit pas suffisamment de détails. Sa syntaxe est kubectl describe <resource-type> <name> ; ici, le type de ressource est node et le nom de l'objet est labex-v135 :
kubectl describe node labex-v135
Vers le début de la sortie, examinez l'identité et la planification :
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Les taints peuvent empêcher le placement des Pods qui ne les tolèrent pas. <none> signifie que ce nœud d'apprentissage n'en possède aucun. Unschedulable: false signifie que Kubernetes peut y placer des charges de travail.
Repérez le tableau Conditions :
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
Pour les conditions de pression et d'indisponibilité, False est un état sain, car le problème est absent. Pour Ready, True est l'état sain. Interprétez toujours le nom de la condition avec sa valeur.
Capacity correspond à l'ensemble des ressources déclarées par le nœud. Allocatable représente les ressources que Kubernetes peut proposer aux Pods après les réservations du système. System Info fournit des informations sur le moteur d'exécution et le kubelet. Les sections suivantes répertorient les Pods, les demandes et limites de ressources allouées, ainsi que les événements. Les valeurs exactes et les horodatages peuvent varier.
Point de contrôle de l'étape
Utilisez get pour obtenir rapidement un tableau, get -o wide pour afficher des colonnes supplémentaires et describe pour consulter les conditions, la capacité, les détails du moteur d'exécution et les événements d'un objet donné.
Examiner les ressources dans les différents espaces de noms
Dans cette étape, vous allez établir une première cartographie des objets courants : les espaces de noms organisent les ressources, les Pods exécutent les conteneurs, les Deployments gèrent les Pods et les Services fournissent un accès réseau stable.
Comprendre les relations entre les objets
- Un Pod est la plus petite unité pouvant être déployée et contient un ou plusieurs conteneurs.
- Un Deployment déclare le nombre d'instances d'une application sans état à exécuter et gère les Pods par l'intermédiaire d'un ReplicaSet.
- Un Service attribue une adresse IP virtuelle et un nom DNS stables aux Pods sélectionnés, car les adresses IP des Pods remplaçables peuvent changer.
- Un espace de noms regroupe les objets associés et permet d'utiliser le même nom dans des portées différentes.
Le chemin simplifié est le suivant : un Deployment gère des Pods, tandis qu'un Service sélectionne ces Pods et fournit aux clients un point de terminaison stable. Tous les objets ne sont pas associés à un espace de noms ; les nœuds appartiennent à l'ensemble du cluster.
Lister les Pods dans tous les espaces de noms
Sans option d'espace de noms, kubectl get pods recherche uniquement dans l'espace de noms courant. -A signifie --all-namespaces :
kubectl get pods -A
NAMESPACE indique la portée logique. NAME identifie le Pod dans cette portée. READY correspond au nombre de conteneurs prêts divisé par le nombre total de conteneurs. STATUS indique la phase du cycle de vie. RESTARTS compte les redémarrages et AGE indique l'âge de l'objet.
Les composants d'infrastructure fonctionnant en continu doivent être Running. Certains Pods d'admission d'Ingress peuvent être Completed avec une disponibilité 0/1, car ils ont exécuté des Jobs ponctuels puis se sont arrêtés correctement. L'état de santé doit être interprété en fonction du rôle de la charge de travail.
Lister les Deployments
Le nom de ressource au pluriel deployments demande les objets Deployment. Conservez -A, car les Deployments système se trouvent en dehors de l'espace de noms courant default :
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY correspond au nombre de réplicas prêts divisé par le nombre de réplicas souhaités. UP-TO-DATE compte les réplicas utilisant le modèle actuel de Pod. AVAILABLE compte les réplicas disponibles pour leur fonction. Le Pod coredns-... observé précédemment est géré par le Deployment coredns.
Lister les Services
Les Pods étant remplaçables, les clients ne doivent pas dépendre de l'adresse IP d'un Pod. Listez les points de terminaison stables des Services :
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE décrit le mode d'exposition. ClusterIP est accessible à l'intérieur du cluster ; NodePort ouvre également un port sur un nœud. CLUSTER-IP est l'adresse virtuelle stable. EXTERNAL-IP=<none> signifie qu'aucune adresse externe n'est attribuée. PORT(S) répertorie les protocoles et les ports exposés.
Le Service kubernetes expose l'API à l'intérieur du cluster. kube-dns fournit un accès stable à CoreDNS. Les Services Ingress prennent en charge le trafic HTTP et HTTPS entrant.
Obtenir une vue d'ensemble combinée
Lorsque vous ne savez pas encore quel type de charge de travail courant est présent, kubectl get all fournit une vue d'orientation combinée. L'ajout de -A applique la portée « tous les espaces de noms » utilisée précédemment :
kubectl get all -A
Cette commande regroupe les ressources courantes telles que les Pods, les Services, les DaemonSets, les Deployments, les ReplicaSets et les Jobs. Un même composant peut apparaître à plusieurs niveaux : Deployment, ReplicaSet et Pod.
Malgré son nom, get all ne renvoie pas toutes les ressources. Les ConfigMaps, les Secrets, les NetworkPolicies et bien d'autres objets en sont exclus. Utilisez cette commande pour vous orienter, puis demandez le type de ressource exact.
Point de contrôle de l'étape
Les espaces de noms définissent une portée, les Pods exécutent les conteneurs, les Deployments maintiennent le nombre souhaité de réplicas de Pods et les Services fournissent un accès réseau stable à des Pods susceptibles de changer.
Résumé
Vous avez terminé votre première exploration guidée d'un cluster Kubernetes. Vous avez appris que Kubernetes gère l'état souhaité sur plusieurs nœuds et que kubectl communique avec le serveur d'API en utilisant le contexte kubeconfig actif.
Vous avez appris à distinguer les versions de Minikube, de Kubernetes et de kubectl, à confirmer le contexte et l'état des nœuds, à identifier les composants du plan de contrôle, des nœuds et du réseau, à utiliser les étiquettes et les sélecteurs, à choisir entre get, get -o wide et describe, à interpréter les conditions et la capacité des nœuds, ainsi qu'à comprendre les relations entre les espaces de noms, les Pods, les Deployments et les Services.
La principale habitude à adopter est d'inspecter avant de modifier quoi que ce soit : confirmez le contexte, vérifiez l'état des nœuds, identifiez l'espace de noms et le type de ressource concernés, puis examinez attentivement l'état rapporté. Les prochains laboratoires s'appuieront sur ce modèle lorsque vous créerez vos propres charges de travail.
