Après avoir développé des solutions d’orchestration interne (Borg et Omega), Google a rendu open source “Kubernetes” en 2014, une solution d’orchestration basée sur le savoir-faire acquis avec Borg et Omega.

Kubernetes est une solution dite d’orchestration, qui permet d’orchestrer (gérer) des conteneurs. Cette orchestration inclut : la réplication, la gestion de l’accès à des ressources et toute la partie réseau, la scalabilité et d’autres aspects que nous verrons par la suite.

Comprendre l’architecture d’un cluster Kubernetes :

un cluster Kubernetes est constitué de plusieurs “noeuds”. On distingue deux types de noeuds :

• Master Node : qui contient le “Kubernetes Control Plane” qui contrôle et gère tout l’écosystème Kubernetes.
• Worker Nodes : qui exécutent les applications déployées.

Le “Control Plane” contrôle tout le cluster et s’assure de son bon fonctionnement, il est constitué de plusieurs composants qui peuvent être exécuté sur un seul nœud master ou qui sont distribués sur plusieurs nœuds.

Le cas le plus classique consiste en un noeud master contant tout les composants du control plane. Le control Plane est constitué des composants suivants :

• Scheduler : assigne un nœud à une application, lorsque vous déployez une application le “scheduler” assigne un nœud à cette application
• Controller Manager : exécute des fonctions au niveau du cluster tel que la replication, surveiller les worker nodes et gérer les erreurs au niveau des noeuds
• etcd : un data store distribué qui stocke la configuration du cluster
• Kubernetes API Server : Permet de communiquer avec les noeuds workers et les composants du control plane.

Les “Worker Nodes” sont les machines qui exécutent les applications conteunerisées. Pour exécuter, surveiller et gérer l’accés à ces applications, un worker node fait appel à ces composants :

• Container runtime : un runtime, docker par exemple, pour exécuter les conteneurs
• Kubelet : communique avec le API Server and gére conteneur au niveau du noeud
• Kube-proxy : joue le role de load balancer entre les applications

Comment exécuter une application sur kubernetes ?

Pour exécuter une application sur Kubernetes, il faut tout d’abord packager l’application dans une ou plusieurs “container images”  et ensuite mettre ces images dans un registre d’images tel que docker hub, comme indiqué dans l’étape 1 ci-dessus.

Par la suite, à l’étape 2 du schéma, le développeur va spécifier un ficher “app descriptor” qui spécifie l’image du conteneur à exécuter, le nombre de replicas et d’autres spécifications liées à l’exécution du conteneur.

Dans les étapes suivantes, le control plane prend les informations de l’ “app descriptor” et communique avec le kubelet pour scheduler les conteneurs spécifiés sur le noeud qui correspond (étape 3 et 4).

Ensute, le kubelet donne les instructions au “Container Runtime” (docker) pour prendre l’image de conteneur et de l’exécuter (étape 5 et 6)

Conceptes et objets de base de kubernetes :

• Pods : Dans kubernetes les conteneurs ne sont pas gérés directement, le concept de conteneurs n’existe pas vraiment. Nous gérons ici des Pods, qui constituent, dans la hiérarchie des objets kubernets, l’objet le plus basique. On dit que les pods contiennent des conteneurs, et que les pods sont exécutés dans des neouds. Un conteneur est exécuté dans un pod qui est exécuté dans un noeud. Un pod peut contenir un ou plusieurs conteneur, et un noeud peux contenir plusieurs pods.

Liveness Probe : vérifie qu’un conteneur s’exécute correctement, en d’autres termes il vérifie qu’un conteneur est “vivant”. Par exemple on peut configurer un “Liveness Probe” sur un application node js, avec une requete https à exécuter sur un port spécifique pour vérifier que notre application s’exécute et qu’elle retourne une réponse 200. Si cette requete est en erreur, kubernetes se charge de redémarrer le pod, le schéma ci-dessous illustre le fonctionnement d’un “Liveness Probe”.

ReplicaSets : assure que les pods sont toujours exécutés, si un pod tombe en erreur ou disparait, à cause de la perte d’un noeud par exemple, le ReplicaSet va détecter l’absence d’un pod et va créer un nouveau pod qui le remplace. Dans le schéma ci-dessous, le ReplicaSet crée et gère deux pods A et B, qui sont exécutés dans le noeud “Node 1”. Le Node 1 tombe en erreur et les pods gérés par le ReplicaSet (Pod A et B ) disparaissent, le Replicaset détecte ce changement et va créer de nouveaux pods sur un autre noeud, ici “Node 2”.

Service : un service est une ressource qui permet de mettre en place un point d’entre constant et unique pour un groupe de pods offrant le même service. Chaque service a une adresse IP et un port qui ne change jamais tant que le service existe. Les pods étant éphémère et pouvant changer d’adresse IP il est important de mettre en place un service pour pourvoir accéder aux différents pods. Dans un service nous définissons un port ainsi qu’un sélecteur des différents pods concernés par le service (selon un label par exemple). Dans cet exemple le client interroge notre application à travers le service “test”, les pods appartenant au service “test” font appel au pod D qui constitue une base de données en passant par le service “db”.

Deployments : Un “Déployment” est une ressource plus haut niveau qu’un “ReplicaSet”, il permet de déployer et de mettre à jour des applications. Lorsqu’un “Deployment” est créé, une ressource du type “ReplicaSet” est aussi créé. La ressource “Deployment” a été introduite pour rendre le déploiement et l’update d’applications beaucoup plus simple qu’à travers des “ReplicaSet”, puisque dans le cas ou nous créons des “ReplicaSet” nous devons gérer nous même ces ReplicaSet et faire en sorte que l’ensemble fonctionne correctement, or avec un “Deployment” nous définissons l’état souhaité pour nos applications et nous nous déchargeons de la gestion des “ReplicaSet”.

Conclusion

Kubernetes permet d’avoir une infrastructure stable tout en étant capable de monter en puissance et en déployant plusieurs applications.

Kubernetes étant open source, c’est un orchestrateur qui reste efficace et à couts avantageux pour vos infrastructures, comparée à d’autres solutions d’orchestrations tel que OpenShift.