C’est la star de ces derniers mois, on le voit partout. Que ce soit dans les colonnes du Monde Informatique ou dans les messages du chat interne de la #SynalTeam, Kubernetes est dans tous les esprits et peut-être même dans tous les SI. Mais qu’est-ce que c’est que Kubernetes ? A quoi ça sert et comment ça marche ? Si ces questions vous démangent, nous avons quelques réponses pour vous !

Kubernetes (K8s pour les intimes !) est ce qu’on appelle un « orchestrateur de conteneurs » et sert à gérer un ensemble de serveurs sur lesquels nous souhaitons déployer des applications packagées dans des conteneurs (le plus souvent c’est Docker mais pas que !). Il va s’occuper de choisir une machine pour déployer notre application et va ensuite la surveiller. Si quelque chose se passe mal, que l’application est tombée ou le serveur ne fonctionne plus, il va redéployer l’application sur une autre machine.

L’architecture de K8S

 

Un cluster Kubernetes est composé de plusieurs serveurs (c’est mieux !) qui vont avoir un ou plusieurs rôles parmi les rôles suivant:

• ControlPlane ou Master : Ce type de nœud sert à gérer le cluster, il héberge notamment le Scheduler qui s’occupe de choisir la machine sur laquelle il va déployer nos applications.
• Etcd: Ces nœuds hébergent une base Etcd, c’est une base de donnée distribuée dans laquelle K8s va stocker toutes ses informations.
• Worker ou Minions: Ces nœuds sont destinés à héberger les applications déployées dans le cluster.

Si l’on prend pour exemple le cluster de la #SynalTeam qui comprend 7 serveurs (3 masters et 4 workers), nous avons 3 masters avec les rôles ControlPlane et Etcd et 4 Workers qui ne sont “que” workers.

Il est possible de fonctionner avec un seul Master mais forcément si ce nœud est défaillant, les applications ne sont plus supervisées.

Il est également possible d’avoir par exemple 3 machines qui auraient les 3 rôles, cependant si les applications déployées prennent toutes les ressources (CPU ou RAM), le cluster ne fonctionne plus de manière optimale.

Les types de ressources

Après l’architecture globale de K8s, voyons un peu plus en détail comment il fonctionne et notamment les types de ressources gérées par K8s.

Dans K8s, tout est instancié de manière déclarative. On déclare une ressource, définie dans un fichier yaml (ou json), et on va l’envoyer dans Kubernetes avec l’outil (CLI) kubectl. Kubernetes va alors stocker cette demande de ressource dans Etcd et la créer (ou la modifier si elle existe et qu’elle ne correspond plus aux spécification décrites dans le fichier envoyé).

Le gros avantage c’est que tout l’état “souhaité” du cluster est stocké en base et K8s va ensuite s’occuper de faire correspondre l’état réel et l’état souhaité. Il sera alors tout à fait possible de supprimer n’importe quelle machine et Kubernetes va recréer les ressources manquantes sur d’autres machines.

 

Vous trouverez une explication détaillée sur cette présentation de Satham Singh disponible sur Slideshare.

Détaillons maintenant un peu les ressources principales et à quoi elles servent.

Namespace

La ressource de plus haut niveau dans un cluster est le Namespace. Il s’agit d’un regroupement d’applications. On peut donner des droits d’accès sur un Namespace à certains utilisateurs ou services et en limiter les ressources (CPU et RAM).

ServiceAccount et Role

Les ressources utilisées pour la sécurité sont les ServiceAccount (compte de service qui fait tourner une application), Roles (ensemble de droits sur le cluster, le Namespace et les autres ressources) et RoleBinding (le couple ServiceAccount+Role).

 

Labels et Selector

Pour chacune des ressources il est possible de définir des Labels. Ces Labels pourront être utilisés pour “requêter” une ressource. Ainsi une ressource pourra “cibler” précisément sur quelle autre ressource elle souhaite agir en la sélectionnant via ses Labels

 

 

Ressources de gestion des conteneurs

Ce type de ressource va gérer le cycle de vie des conteurs, il en existe 3 :

• Pod: Elle déclare 1 ou plusieurs conteneurs (l’image, les variables, etc…)
• ReplicaSet : Elle déclare le nombre de Pod (ci-dessus) devant être actifs
• Deployment : Elle gère les Replicasets

 

Ressources autour des pods

Pour faire tourner les conteneurs, il nous faut un endroit pour stocker les choses, K8s nous propose 3 types de stockage :

• Storage : Elle permet de gérer le stockage sur disque des données. On peut définir plusieurs StorageClass (nfs, gluster, rook, host, …) sur lesquelles on va pouvoir s’appuyer pour stocker les informations des conteneurs du disque.
• Secrets : Il s’agit ici de stocker des informations confidentielles (certificats, mots de passe, etc …). Ils sont stockés dans Etcd
• ConfigMap : Cette ressource nous permet de stocker la configuration des dockers (sous forme de fichier ou de variables d’environnement)

Les Secret et ConfigMap pourront être utilisés comme n’importe quel stockage sous docker et on va pouvoir monter ces ressources sous forme de fichier ou de variable d’environnement dans le conteneur.

Ressources d’accès aux autres ressources

Une fois les conteneurs déployés il faut qu’ils puissent discuter entre eux et qu’on puisse les atteindre depuis l’extérieur (pour les application frontend), pour cela on a 2 ressources :

• Service : il s’agit en fait d’un Selector pour sélectionner la ressource à exposer (un pod la plupart du temps). Une entrée DNS va être créée (avec le nom du service) et va pointer vers l’ensemble des ressources correspondant au Selector. Les autres pod pourront ainsi communiquer avec la ressource ciblée par le service directement par le nom DNS du service.
  

A noter qu’il existe 3 types de services qui vont exposer de manière différente le port ciblé:

• ClusterIP (défaut) : expose le service sur le réseau interne K8S,
• NodePort : expose le service sur tous les nœuds du cluster sur un port spécifique,
• Loadbalancer : expose le service via un loadbalancer externe fourni pas votre cloud provider.
• Ingress: Il est possible de définir un ou plusieurs Ingress, il s’agit d’un loadbalancer accessible depuis l’extérieur (Nginx, HAProxy, …), l’IngressController va permettre de déclarer quel Service exposer dans le loadbalancer.

A noter qu’il est possible de définir d’autres ressources, les CustomResourceDefinition.

Nous pourrions par exemple définir une ressource de type Crontab et l’utiliser ensuite comme une ressource “standard”

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image

A suivre !

Maintenant qu’on a vu ce qu’était K8S, on va pouvoir commencer à déployer le cluster. L’installation de Kubernetes n’est pas simple si on veut la faire manuellement mais de nombreux outils commencent à émerger afin de nous faciliter la vie. Chez Synaltic, nous avons tenté de le faire avec Rancher (car nous avions déjà utilisé Rancher sur des versions précédentes) et nous avons voulu tester la dernière mouture, entièrement basée sur K8S. Mais ça, nous vous le raconterons dans un prochain article !