Objectifs du chapitre et prérequis

Les chapitres précédents ont abordé les différents types d’objets utilisables dans Kubernetes du déploiement au volume persistant.

Ce chapitre sera consacré à l’étude des éléments système d’un cluster Kubernetes parmi lesquels l’espace de noms kube-system.

Espace de noms kube-system

1. Pods présents dans l’espace de noms kube-system

Le classement des éléments dans Kubernetes se fait à l’aide d’espaces de noms (namespace). Dans le cas des éléments système du cluster, ces derniers sont hébergés dans l’espace de noms kube-system.

Récupérez la liste des pods de l’espace de noms kube-system :

kubectl -n kube-system get pods

Ci-dessous le contenu de l’espace de noms d’un cluster Minikube :

NAME                              READY   STATUS    RESTARTS  AGE 
coredns-64897985d-d8mnm           1/1     Running   0         6d6h 
etcd-minikube                     1/1     Running   0         6d6h 
kindnet-mktfs                     1/1     Running   0         6d6h ...

Configuration des serveurs maîtres

1. Principe de lancement des pods système

La brique etcd stocke l’ensemble des informations du cluster. De fait, son lancement ne peut pas être géré directement par Kubernetes.

Dans le cas des services système, les pods correspondants seront lancés à l’aide d’un fichier manifest. Ces fichiers sont présents sur les machines du cluster dans le répertoire /etc/kubernetes/manifests.

2. Contenu du répertoire /etc/kubernetes/manifests

Afin de consulter le contenu de ce répertoire, sous Minikube, lancez la commande suivante :

$ minikube ssh

Une fois connecté, récupérez le contenu du répertoire /etc/kubernetes/manifests avec la commande ls :

$ cd /etc/kubernetes/manifests 
$ ls -l

Ci-dessous un extrait de la commande indiquant le contenu du répertoire :

total 16 
-rw------- 1 root root 2309 Dec 22 20:32 etcd.yaml 
-rw------- 1 root root 4071 Dec 22 20:32 kube-apiserver.yaml 
-rw------- 1 root root 3390 Dec 22 20:32 kube-controller-manager.yaml 
-rw------- 1 root root 1436 Dec 22 20:32 kube-scheduler.yaml

3. Contenu des fichiers

Ces fichiers correspondent à la définition de cinq pods.

Consultez le contenu du fichier etcd.yaml :

$ sudo cat etcd.yaml

Ci-dessous un extrait du fichier :

apiVersion: v1 
kind: Pod 
metadata: 
 annotations: 
   scheduler.alpha.kubernetes.io/critical-pod:...

Monitoring des conteneurs du cluster avec Glances

1. Origine du besoin

Vous avez abordé le fonctionnement interne d’un cluster et notamment les différentes briques déployées (Deployment, StatefulSet, ReplicaSet, Pod) et le mécanisme qui permet de les mettre à jour.

Un dernier type d’objets n’a pas été abordé : les DaemonSets (raccourci ds). Il permet de piloter des déploiements sur les nœuds du cluster comme l’ajout d’un agent de surveillance.

2. Consultation des DaemonSets

Dans le cas de Minikube, un seul objet de ce type existe : kube-proxy (dans l’espace de noms kube-system).

Afin de le consulter, lancez la commande suivante :

$ kubectl get daemonset -n kube-system

La commande doit alors afficher le résultat suivant :

NAME        DESIRED   CURRENT   READY   ... NODE SELECTOR   AGE 
kube-proxy  1         1         1           <none>          43d

3. Présentation de Glances

Un cluster Kubernetes (surtout de développement) est par nature très actif. En conséquence, les moteurs de conteneur sous-jacents auront une activité importante.

L’outil Glances (développé par Nicolas Hennion) répond à un besoin simple : inspecter ce qui est en train de se passer sur une machine. Il fonctionne de deux manières différentes :

en ligne de commande ;
au travers d’une interface web.

Dans le cas de l’interface web, la commande glances sera lancée avec l’option -w.

Pour plus de détails, consultez le site suivant : https://github.com/nicolargo/glances

4. Définition du DaemonSet

a. Structure de la déclaration

Tout comme pour un déploiement, le DaemonSet prendra la forme d’une déclaration au format YAML avec les champs suivants :

les champs apiVersion (apps/v1) et kind (DaemonSet) ;
l’enregistrement namespace avec les champs suivants :

name : nom de la ressource (glances) ;
namespace : espace de noms où déployer le pod (kube-system).

l’enregistrement spec --> template avec les champs suivants :

la structure metadata avec les labels à positionner ;
la structure...

Gestion des briques internes de Kubernetes