Les fondamentaux de Kubernetes en 5 minutes

Kubernetes est une des technologies les plus en vogue en ce moment. À l‘origine projet Open Source de Google, son succès est tel qu’il est désormais proposé en tant que service par tous les fournisseurs de cloud. Même s’il y a une pléthore d’articles et de vidéos sur ce sujet, il n’est pas simple de trouver une documentation, lisible en quelques minutes, avec une vue d’ensemble concise de l’architecture et des concepts fondamentaux de Kubernetes. Il s’agit de l’objectif principal de cet article qui vous permettra par la suite d’aborder plus aisément les documentations plus détaillées.

Concepts fondamentaux

Une application qui se déploie sur un cluster Kubernetes se compose d’un ensemble d’objets manipulés par les nodes. Il s’agit principalement des Pods, Services et Namespaces.

En outre, Kubernetes contient un certain nombre d’abstractions de niveau supérieur appelées controllers. Ces derniers s’appuient sur les Pods et les Services et fournissent des fonctionnalités supplémentaires. Il s’agit notamment de ReplicatSet, Deployment et StatefulSet.

Étant donné qu’un Pod est déployé dans un node du cluster, si ce dernier tombe en panne, redémarre ou est supprimé pour une raison quelconque alors le Pod disparaît. Afin de garantir aux utilisateurs que leur application s’exécute toujours, Kubernetes offre via son controller ReplicatSet, la possibilité de définir un nombre de réplicats du Pod à déployer et à maintenir constamment en vie. Plus récemment, Kubernetes a mis au point un controller de plus haut niveau nommé Deployment et qui permet de gérer plus facilement le cycle de vie des Pods en définissant un état désiré de son application, c’est-à-dire le nombre de réplicats désiré et la définition des pods à répliquer. Il est recommandé d’utiliser ce dernier controller.

Dans le cas où l’application nécessite de persister des données, telle une base de données ou un système de messagerie distribué, il est recommandé d’utiliser le controller StatefulSet. Contrairement au controller Deployment, les Pods ne sont pas interchangeables même s’ils sont créés à partir de la même spécification. En effet, dans une application de type master-slave, il est nécessaire de préserver le Pod qui joue le rôle du master et les Pods qui jouent le rôle des slaves. Chacun conserve un unique identifiant à travers n’importe quelle replanification. Les Pods sont associés à des volumes persistants (PersistentVolumes) et lorsqu’un Pod disparait le controller le recrée avec le même identifiant, tout en le rattachant au même volume.

Namespace

Dernier objet Kubernetes intéressant à connaitre : Namespace. Ce dernier permet de créer des clusters virtuels sur le même cluster, c’est-à-dire des environnements indépendants. Cela donne la possibilité de faire cohabiter des projets sur le même cluster sans interférences.

Créer son cluster Kubernetes

La création d’un cluster kubernetes peut se faire de trois manières :

1. Via un service d’un fournisseur de cloud (GKE pour GCP, EKS pour AWS, AKS pour Microsoft Azure, sur OVHCloud ou sur Scaleway)
2. L’installer sur ses propres serveurs
3. Sur son poste en local en installant Minikube

Pour démarrer avec Kubernetes, il est conseillé d’utiliser Minikube. Cependant, dans le cas d’un apprentissage plus poussé envisagez d’utiliser le service d’un des fournisseurs de cloud cités sachant que GKE est celui qui propose le plus de fonctionnalités à jour.

Command Line – CLI

L’outil kubectl est une interface en ligne de commande (command line en anglais) qui permet de déployer, mettre à jour, visualiser ou supprimer des applications en exécutant des commandes sur des clusters Kubernetes. L’installation de cet outil et la configuration pour accéder à un cluster Kubernetes existant sont indiquées dans la documentation officielle.

Kubernetes permet grâce à un template, c’est-à-dire un fichier au format YAML, de déclarer toutes les ressources Kubernetes que l’on souhaite manipuler afin de déployer son application. Voici un exemple ci-dessous d’un fichier YAML (nginx-deployment.yaml) décrivant une application Nginx que l’on souhaite déployer via un controller Deployment qui comprend 2 Pods dans lesquels se trouve un conteneur Nginx.

apiVersion: apps/v1
kind: Deployment # Utiliser le controller Deployment pour gérer le cycle de vie des pods à déployer
metadata:
  name: nginx-deployment # Nom du déploiement
  namespace: dev # name for namespace
spec:
  selector:
    matchLabels:
      app: nginx # Label associé aux Pods
  replicas: 2 # Indiquer au controller Deployment d'exécuter 2 Pods ayant la spécification ci-dessous
  template:
    metadata:
      labels:
        app: nginx
    spec: # Spécification du Pod
      containers: # Le Pod possède un seul conteneur
      - name: nginx
        image: docker.io/nginx:1.18.0 # Image docker à utiliser pour créer le conteneur
        ports:
        - containerPort: 80

Ci-dessous, les commandes principales à utiliser pour créer, mettre à jour, visualiser ou supprimer le déploiement.

kubectl apply -f nginx-deployment.yaml # Créer/Mettre à jour le déploiement
kubectl describe deployment nginx-deployment -n dev # Visualiser le déploiement dans le namespace dev
kubectl get pods -l app=nginx  -n dev # Récupérer la liste filtrée de tous les Pods créés dans le namespace dev
kubectl delete deployment nginx-deployment -n dev # Supprimer le déploiement
kubectl delete -f nginx-deployment.yaml # Supprimer toutes les ressources dans le template

Helm : Simplifier les déploiements

Lorsque l’on souhaite déployer une application complexe qui fait appel à des dizaines voire des centaines de ressources Kubernetes, l’outil kubectl devient inadapté. C’est pourquoi l’outil Helm a été mis au point. Il s’agit d’un package manager pour Kubernetes qui s’appuie sur kubectl et qui simplifie les déploiements d’applications.

Dans le vocabulaire Helm, une application est appelée une release et est associée à un chart c’est-à-dire une collection de fichiers de configuration au format YAML contenant des variables globales et des templates décrivant les ressources Kubernetes. Il existe un dépôt officiel pour Helm qui fournit une large gamme de charts. Voici des exemples d’utilisation de la commande en ligne helm :

helm version # Visualiser la version courante d'helm
helm repo add stable  # Ajouter le dépôt officiel d'helm contenant un ensemble de projets
helm search repo stable # Liste de tous les projets du dépôt officiel
helm install my-nginx-ingress stable/nginx-ingress # Créer une release nommée my-nginx-ingress s'appuyant le chart de nginx-ingress
helm del my-nginx-ingress # Supprimer la release nommée my-nginx-ingress

Pour certains projets Open Source, l’éditeur propose ses propres charts de déploiement sur Kubernetes plus optimisés et évolués que ceux qu’on retrouve dans les charts du dépôt officiel. Il faut alors suivre les instruction sur leur site comme par exemple avec Elastic Cloud on Kubernetes qui permet d’installer un cluster Elasticsearch.

Aller plus loin

Si vous souhaitez en savoir davantage sur Kubernetes voici des liens intéressants :

• La documentation officielle de Kubernetes
• Les vidéos d’IBM Cloud
• La documentation GKE
• Les vidéos de VMWare
• La documentation officielle de Helm