Kubernetes 101 — Les bases de Kubernetes
Plus vous avez d’applications deployés dans votre écosytème plus il est compliqué de gérer ces applcations. Google, fait partie des premières entreprises à se pencher sur le sujet de l’orchestration et de la gestion de l’infrastructure et des déploiements d’une manière efficace.
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 controle et gère tout l’écosystme Kubernetes.
- Worker Nodes : qui exécutent les applications deployées.
Le “Control Plane” controle tout le cluster et fait en sorte qu’il soit fonctionnel, il est constitué de plusieurs composants qui peuvent etre exécuté sur un seul noeud master ou etre distribué sur plusieurs noeuds.
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 node à une application, lorsque vous déployez une application le schedular assigne un noeud à 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 plusieur “container images” puis de pousser 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 meme service. Chaque service a une addresse 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 interrogge 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ée. 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 meme 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
Chez PI SQUARE nous formons nos ingénieurs en permanence sur kubernetes.
Nous avons pris le choix d’aller vers cette technologie puisqu’elle permet de réduire les couts liés à l’infrastructure, elle permet de déployer facilement des applications en gérant les différents aspects de scaling et de fiabilité.
C’est un sujet qui nous passionne puisqu’il est en constante évolution et que les projets liés à des migrations sur kubernetes offrent beaucoup de challenge.
Pour débuter sur kubernetes voici quelques ressources utiles :
