Contactez-nous

Exploration de base d'un cluster (cluster-info, get nodes)

Apprenez les commandes kubectl de base pour explorer votre cluster Kubernetes : vérifiez la connectivité avec cluster-info et listez les noeuds avec get nodes.

Premier contact : vérifier la connexion et la structure

Maintenant que vous disposez d'un environnement Kubernetes et que `kubectl` est installé et configuré pour s'y connecter via `kubeconfig`, il est temps de faire vos premiers pas dans l'exploration de ce nouvel espace. Avant de déployer des applications ou de manipuler des objets complexes, il est essentiel de vérifier que votre connexion au cluster fonctionne correctement et d'avoir une première idée de sa composition.

Nous allons utiliser deux commandes `kubectl` fondamentales qui sont souvent les toutes premières à être exécutées après la configuration : `kubectl cluster-info` pour vérifier la connectivité aux points d'accès principaux du cluster, et `kubectl get nodes` pour lister les machines qui composent effectivement votre cluster.

Ces commandes simples vous donneront une confirmation rapide que tout est en ordre et une vue d'ensemble de l'infrastructure sur laquelle vous allez travailler. Elles constituent la base de toute interaction ultérieure avec Kubernetes.

Vérifier les points d'accès avec `kubectl cluster-info`

La commande `kubectl cluster-info` est idéale pour obtenir une vue rapide des adresses (endpoints) des composants principaux du cluster, notamment le Control Plane (via l'API Server) et les services essentiels comme le serveur DNS interne (généralement CoreDNS).

Exécutez simplement :

kubectl cluster-info

La sortie ressemblera typiquement à ceci (les URLs et adresses IP varieront en fonction de votre environnement) :

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Que nous apprend cette sortie ?

  • `Kubernetes control plane is running at ...` : C'est l'information la plus importante. Elle confirme que `kubectl` a pu contacter avec succès l'API Server à l'adresse spécifiée dans votre `kubeconfig`. Si vous obtenez une erreur ici, cela indique un problème de connectivité ou de configuration de votre `kubeconfig`.
  • `CoreDNS is running at ...` : Indique l'adresse pour accéder au service CoreDNS (le serveur DNS interne du cluster) via un proxy de l'API Server. Cela confirme que le service DNS, crucial pour la découverte de services, est déployé et accessible.

La dernière ligne suggère `kubectl cluster-info dump` pour un diagnostic plus poussé. Cette commande génère une grande quantité d'informations sur l'état actuel du cluster, utile pour le débogage avancé, mais nous n'en avons pas besoin pour une exploration de base.

Si `kubectl cluster-info` s'exécute sans erreur et affiche les adresses, c'est un excellent signe : votre `kubectl` communique bien avec le Control Plane.

Lister les machines du cluster avec `kubectl get nodes`

La commande suivante la plus courante est `kubectl get nodes`. Elle permet de lister toutes les machines (noeuds) qui sont enregistrées et gérées par le Control Plane Kubernetes. Cela inclut à la fois les noeuds workers (où vos applications s'exécuteront) et potentiellement les noeuds du control plane eux-mêmes, selon la configuration de votre cluster.

Exécutez :

kubectl get nodes

Vous obtiendrez une sortie tabulaire comme celle-ci :

NAME           STATUS   ROLES           AGE   VERSION
minikube       Ready    control-plane   15h   v1.28.3
worker-node-1  Ready              14h   v1.28.3
worker-node-2  Ready              14h   v1.28.3

Décortiquons les colonnes :

  • `NAME` : Le nom d'hôte du noeud tel qu'enregistré dans Kubernetes.
  • `STATUS` : Indique l'état de santé du noeud du point de vue de Kubernetes. L'état le plus important est `Ready`, signifiant que le noeud est sain, accepte de nouveaux Pods et que le Kubelet communique correctement avec le Control Plane. D'autres états comme `NotReady` indiquent un problème, et `SchedulingDisabled` signifie que le noeud est en maintenance et n'accepte pas de nouveaux Pods.
  • `ROLES` : Les rôles attribués au noeud. `control-plane` (ou parfois `master`) indique un noeud hébergeant les composants du Control Plane. `` ou l'absence de rôle spécifique indique généralement un noeud worker standard. Des rôles personnalisés peuvent aussi apparaître.
  • `AGE` : Depuis combien de temps le noeud est enregistré dans le cluster.
  • `VERSION` : La version du Kubelet (et donc généralement de Kubernetes) qui s'exécute sur ce noeud.

Pour obtenir plus de détails, utilisez le flag `-o wide` :

kubectl get nodes -o wide

Cela ajoute des colonnes utiles :

NAME           STATUS   ROLES           AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
minikube       Ready    control-plane   15h   v1.28.3   192.168.49.2            Ubuntu 22.04.3 LTS   5.15.133.1-microsoft-standard-WSL2   docker://24.0.7
worker-node-1  Ready              14h   v1.28.3   10.0.0.10               Ubuntu 20.04.5 LTS   5.4.0-110-generic   containerd://1.6.24
worker-node-2  Ready              14h   v1.28.3   10.0.0.11               Ubuntu 20.04.5 LTS   5.4.0-110-generic   containerd://1.6.24

Les nouvelles colonnes montrent l'adresse IP interne du noeud, son IP externe (si applicable, typiquement dans le cloud), l'image du système d'exploitation, la version du noyau et le runtime de conteneur utilisé (Docker, containerd, etc.). Ces informations sont précieuses pour le diagnostic.

Vous pouvez également afficher les labels associés aux noeuds avec `kubectl get nodes --show-labels`. Les labels sont utilisés par Kubernetes, notamment par le Scheduler, pour prendre des décisions de placement des Pods.

Interprétation et prochaines étapes

Si `kubectl cluster-info` réussit et que `kubectl get nodes` affiche tous les noeuds attendus avec le statut `Ready`, félicitations ! Votre environnement Kubernetes est opérationnel et vous êtes prêt à interagir avec lui.

Ces commandes simples mais fondamentales vous ont permis de :

  • Confirmer la connectivité à l'API Server.
  • Vérifier la disponibilité du DNS interne.
  • Lister les machines constituant votre cluster.
  • Vérifier l'état de santé et la version de chaque noeud.
  • Obtenir des informations réseau et système de base sur les noeuds.

Cette exploration initiale pose les fondations. Vous avez maintenant une vision claire de l'infrastructure de base de votre cluster. Dans le chapitre suivant, nous allons nous intéresser aux briques fondamentales que Kubernetes utilise pour gérer les applications : les objets de l'API Kubernetes, en commençant par les Pods, les Namespaces et les Labels.