Kubernetes, son architecture

Kubernetes, son architecture

150 150 Loick JONCOUR

Comme nous l’avons compris dans les articles précédents, Kubernetes est une plateforme de gestion de containers, il orchestre, entre autres, des ressources de computing, leur overlay réseau, des ressources de stockage, etc…

Pour ce faire et pour rester dans la philosophie de Kubernetes, il a été créé un type de ressources abstraites nous permettant d’exploiter les ressources de nos machines de la même façon, qu’elles soient physiques ou virtuelles, les ‘nodes’.
Un cluster Kubernetes est donc un ensemble de nodes, ils contiendront les éléments nécessaires pour faire tourner nos containers, c’est-à-dire :

  • le container-runtime,
  • kubelet,
  • kube-proxy.

Contrairement au pod, les nodes ne seront pas construits par Kubernetes, il faudra les préparer en amont, ce qui reste logique, sans l’agent kubelet, Kubernetes n’a pas d’interface pour communiquer avec nos nodes.

Cela peut être fait manuellement où managé comme c’est le cas dans les solutions de cloud public.

Kubelet

Kubelet est un agent qui tournera sur chaque node de notre cluster. Vous pouvez vous le représenter comme un superviseur qui est focalisé sur le run des containers sur son node.

Le kubelet recevra les specs de chaque pod, lui donnant les informations lui permettant de faire tourner les containers. Il ne managera et ne surveillera que les containers qui serons créé à travers Kubernetes.

Kube-proxy

Chaque node aura aussi un kube-proxy installer, c’est ce dernier qui lui permettra d’interpréter les abstractions résaux de Kubernetes. En effet nous savons que nos containers peuvent mourir ou être déplacés. C’est kube-proxy qui nous permettra de garder de la cohérence dans notre overlay réseau.

Paramètres de bases d’un node

Addresse
Une adresse ip ou un hostName de la machine dont ce node sera l’abstraction.

Condition
Une forme de ‘status’ de notre node, c’est grâce à lui que nous saurons si notre node est en bonne santé.

Capacity
Décrit les ressources disponibles et pouvant être exploitées par Kubernetes sur ce node en CPU, RAM ou espace Disk.

Info
Sorte de métadata du node, telle que la version du kubelet et du kube-proxy installée dessus, le nom et version de l’os de la machine etc…

Teinte

Certains de ces nodes auront, en plus, un rôle spécifique dans le cluster, tels que les masters nodes qui hébergeront les composants nécessaires à Kubernetes pour orchestrer nos ressources. D’autres n’auront pour vocation que d’héberger nos containers, tels que les worker nodes.
Ceci dit, même les workers peuvent être « teintés » pour n’héberger que certains types de workloads, par exemple nous pourrions dédier certains worker nodes aux bases de données et attribuer une surveillance plus avancée à ces workers nodes tous en s’assurant que les autres workloads ne viennent pas interférer avec nos bases de données sensibles. Pour éviter qu’une mauvaise manipulation vienne à faire disparaitre nos bases de données ou encore pour réserver de l’espace au sein du cluster à ce type de workloads sensible.

Master node

Vous l’aurez compris, c’est ici que ce passe le gros du spectacle.

En effet les master nodes hébergent une grande partie de l’intelligence de Kubernetes à travers l’apiserver, le scheduler, le controller-manager et l’etcd.
Tous ces composants tourneront sur les masters nodes, s’ils peuvent être containerisés, ils ne peuvent pas être managés par Kubernetes, ils devront être gérés par Docker (ou équivalent) ou tourner directement sur les machines en tant que processus.

Si un cluster Kubernetes peut tourner avec un master nodes, il est plus que recommandé d’en avoir 3 ou 5, en effet si nous n’en avons qu’un et que ce dernier venait à tomber, c’est l’intégralité de notre cluster qui tomberait, n’ayant plus de ressources pour le manager.

Kube-apiserver

C’est l’api qui nous permettra de dialoguer avec notre cluster, nous pourrons taper dessus comme une api standard, ou à travers la cli kubectl.

Il faut aussi savoir qu’elle est scalable (horizontalement) pour pouvoir assurer la charge de request envoyée à notre cluster.

Kube-scheduler

Je l’ai évoqué dans de précédents articles, c’est le composant qui va gérer le positionnement de nos pods.

Lorsque nous avons envoyé les configs d’un nouveau pod à notre cluster, c’est le scheduler qui va déterminer sur quel node il devra être lancer, à partir de différentes métriques, telles que les ressources demandées par ce pod, les ressources encore disponibles sur les nodes etc…
Il se chargera de nous trouver le meilleur emplacement pour notre pod au sein de notre cluster en faisant en sorte qu’aucun node ne soit trop surchargé.

Jusqu’à la version 1.9, le scheduler utilisait une mécanique plutôt simple de premier arrivé premier servi, si vous tentiez de lancer un pod alors que le cluster ne disposait pas des ressources minimum pour le faire tourner, il restait en statut ‘unschedulable’.
Depuis, Kubernetes a introduit une notion de priorité, nous permettant de définir une valeur d’importance à nos pods, ainsi un pod de priorité 100 pourrait être démissionné par le scheduler pour faire de la place pour un pod de priorité 1000.

En savoir plus sur la notion de priorité

Kube-controller-manager

C’est dans ce composant que tourneront nos Controllers (tel que nos ReplicaSet ou nos Deployment).

Ces controllers comprennent les « node Controllers » qui surveillent le statut des nodes, les « replication Controllers » qui surveillent et maintiennent le bon nombre de pods pour chaque pod procédant des réplicas, les Endpoints Controllers qui ce chargeront des endpoints tels que les ressources « Service » et les Service Accounts & Token Controllers qui s’occuperont de créer les ServiceAccounts par défaut et leurs tokens pour chaque nouveau namespace.

etcd

L’etcd est la base de données de Kubernetes. Elle est Consistent et highly-available, elle contient toute les informations de notre cluster et de l’état attendu de toute nos ressources qui y sont hébergées.

Vous l’aurez compris, c’est un composant majeur qu’il faudra protéger et backuper.

Laisser une réponse