<<< Chap 2 | Sommaire | Chap 4 >>>
Chap 3. Kubectl et Premiers pas avec kubernetes
I. Master vs Worker
Comme nous l’avons déjà vu, Kubernetes fonctionne avec un modèle de type Master/Worker.
Le Master (Plan de Contrôle), est comme un chef d’orchestre du système. C’est lui qui dirige tout, comme par exemole, de la distribution des resources entre les différents Nodes, etc.
Les Workers (aussi appelé, Nodes ou Minions), eux par contre, ne s’occupent que de créer ou détruire les Pods (on ne parle pas de conteneurs avec kubernetes).
De ce fait, une fois le cluster kubernetes créé, tout se passera au niveau du Master. Il n’y a pas besoin de se connecter sur les différents nodes pour la suite.
Je vais reprendre ici, une des images de mon précédent article, pour illustrer la suite.
Les pods générés dans le plan de contrôle (Master).
- API Server
Valide et configure les données pour les objets API (Pods, Services, etc.) - Controller Manager
Daemon qui intègre les boucles de contrôle principales de kubernetes (replication controller, namespace controller, etc.) - Scheduler
Assigne les Pods aux différent Nodes - etcd
Stocke les données de configuration du cluster
Les Pods ci-dessous exisent aussi bien, au niveau des différents Nodes que du Master, afin que garantir le bon fonctionnement du traffic réseau.
- kube-proxy
- canal
Par contre, les Pods qui gèrent le service de DNS en local n’existent qu’au niveau des Pods, pour la raison simple qu’il n’est pas possible (en théorie) d’installer des Pods sur le Master.
- CoreDNS
II. Namespace
Après déployement du cluster kubernetes, le status des Pods créés par défaut, devrait être sur « RUNNING ». Si l’un de ces pods tombe en panne, le clusteur risque de ne pas fonctionner correctement.
student@k8sn01:~$ kubectl get pods --namespace kube-system
Pour séparer les pods créés par l’utilisateur avec ceux du système, kubernetes utilise les « namespaces » pour cloisonner ces Pods, qui vont ainsi se retrouver dans au moins deux types d’environnements différents.
La liste des différents namespaces est donnée par la commande
student@k8sn01:~$ kubectl get namespaces student@k8sn01:~$ kubectl get ns
De cette liste, vous devriez reconnaître « kube-system », qui contient l’ensemble de Pods du système. Les pods créés par l’utilisateur devraients se trouver dans le namespace « kube-default », à moins que vous ne décidez autrement.
Ainsi, pour avoir la liste de tous les pods du le cluster,
student@k8sn01:~$ kubectl get pods --all-namespaces student@k8sn01:~$ kubectl get po -A
Par contre, ce qui nous intéresse pour la suite, ce sont les pods dans notre environnement de travail. Ces pods se trouvent dans le namespace « default ».
student@k8sn01:~$ kubectl get pods --namespace default
No resources found in default namespace.
Ou, plus simplement
student@k8sn01:~$ kubectl get pods
No resources found in default namespace.
Ici, il n’y a aucun Pod de créé, d’où le message.
Ce qu’il faut retenir ici, c’est la conception du système fait en sorte que les pods entre les différentes namespaces (par exemple « default » et « kube-system ») ne peuvent pas se comminiquer entre eux.
III. Les primitives
Une primitive, dont je vous donne la liste ci-dessous, est l’ensemble d’outils nécessaires à la construction d’un cluster kubernetes. Il nous faut,
- Pods
Peuvent contenir un ou plusieurs conteneurs - Labels
Sont des étiquettes qui peuvent être attachés à des objets Kubernetes comme les Pods - Contrôleurs (Replication, Daemon, Job et Deployment)
Comme son nom l’indique, permet de contrôler l’état du cluster - Services
Un groupe de pods peut avoir une interface unique accessible de l’extérieur
En une seule ligne de commande, vous pouvez avoir l’état du primitive.
student@k8sn01:~$ kubectl get ns,svc,pods,deploy,rs,ds -A
Cette même commande peut être décomposée en plusieurs commandes.
- Information sur les pods (pods ou po)
$ kubectl get pods -A $ kubectl get po -A
- Information sur les différents types de contrôleurs
(replicasets ou rs)
$ kubectl get replicasets -A $ kubectl get rs-A
(daemonset ou ds)
$ kubectl get daemonsets -A $ kubectl get ds -A
(deployments ou deploy)
$ kubectl get deployments -A $ kubectl get deploy -A
- Information sur les services (services ou svc)
$ kubectl get services -A $ kubectl get svc -A
Pour avoir une idée de comment interagissent les contrôleurs avec les Pods,
C’est un peu le fouilli, c’est pour celà que je vous ai fait un récapitulatif ci-dessous.
IV. Les différents services de kubeadm
Voyons la liste de services nécessaire à Kubeadm pour fonctionner correctement.
student@k8sn01:~$ apt-cache depends kubeadm
kubeadm
Depends: kubelet
Depends: kubectl
Depends: kubernetes-cni
Depends: cri-tools
Kubelet, l’agent installé sur chacun des Workers (Minions), sert d’intermédiare entre ces Nodes et le Master. L’une de ces fonctions est de recevoir la spécification des Pods (podspecs) dans le format YAML our JSON, pour pouvoir les déployer sur l’un des nodes.
Je ne vous présent plus l’outil kubectl, puisque c’est celui qu’on a utilisé pour
- Initialiser le cluster (kubectl init)
- Joindre les différents nodes au Master (kubectl join)
- Obtenir des informations du cluster (kubectl get)
On n’en a parlé aussi des CNIs, avec l’installation de Canal qui est un plugin réseau pour conteneur.
Pour une utilisation avancée de kubernetes, il a été introduit depuis la version 1.5 le CRI ou Interface d’Exécution du conteneur.
V. Création d’un pod
Une nouvelle commande kubectl à connaîte, est « kubectl run » pour télécharger une image à partir du Hub de Docker, qui est un grand centre de stockage d’images pour conteneurs.
Comme test, je vais créer un serveur web nginx.
student@k8sn01:~$ kubectl run nginx --image=nginx
Récupérer le nom du node sur lequel le serveur est installé, puis son adress IP.
student@k8sn01:~$ kubectl describe pods/nginx
A partir du Master, vérifier que le serveurs nginx s’est bien lancé en utilisant la commande curl.
student@k8sn01:~$ curl <adresse_ip_de_nginx-app>
Et voilà, vous avez un serveur web qui tourne sur kubernetes.
Voyons maintenant la liste de Pods installés dans le cluster.
Ici, j’ai rajouté deux pods suplémentaires (« nginx-app » et « nginx-serv »),
- afin de bien pouvoir voir la différence entre les pods créés par défaut (namespace: « kube-system ») (2) et ceux créés par l’utilisateur (1)
- les Pods sont répartis entre les différents Nodes disponibles
- « nginx » et « nginx-app » sur k8sn03
- « nginx-serv » sur k8sn02
Je suppose qu’à ce stage, vous avez créé un ou plusieurs pods. Pour supprimer ceux dont vous n’avec pas besoin, lancer la commande.
k8sn02:~$ kubectl delete pod <nom_du_pod>
Je ne vous l’ai pas implicitement annoncé, mais jusqu’ici, nous avons vu deux méthodes pour créer un pod avec kubernetes.
- Avec le fichier yaml téléchargé sur internet, nous avons créé un pod pour la gestion du réseau cannal
$ kubectl apply -f canal.yaml- La suppression de tel type de pode se fait grâce à la commande
$ kubectl delete -f monFichier.yaml
- La suppression de tel type de pode se fait grâce à la commande
- En passant par un hub de Docker, nous avons téléchargé un pod prêt à l’emploi
$ kubectl run nginx --image=nginx- Pour la suppression du pod
$ kubectl delete monPod
- Pour la suppression du pod
Ma Vie de Linuxien, dans les Nuages! 
