Publié par

Il y a 3 mois -

Temps de lecture 9 minutes

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.

Architecture

Kubernetes est utilisé en tant qu’orchestrateur de conteneurs Linux, et permet donc d’automatiser plus facilement leur exploitation au sein de clusters. Ces clusters peuvent être situés dans des clouds publics, privés ou hybrides. Un cluster Kubernetes, comme schématisé ci-contre, est constitué de deux types de ressources :

  • Le master coordonne toutes les activités du cluster, comme la planification des applications, la gestion de leur état souhaité et le déploiement de nouvelles mises à jour,
  • Les nodes sont des serveurs virtuels ou physiques qui exécutent et hébergent des applications. Chaque node est doté d’un Kubelet, c’est-à-dire un agent qui communique avec le master pour faciliter la gestion du node et des applications. Docker (ou rkt) est également installé pour l’exécution de containers. En production, le nombre minimal de nodes est de 3.

Source : https://kubernetes.io

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.

Pod

Un Pod représente un ensemble de processus en cours d’exécution au sein d’un node du cluster. Un Pod est donc une unité d’exécution de base d’une application Kubernetes, il s’agit du plus petit et du plus simple modèle d’objets. Comme indiqué dans l’image ci-contre, un Pod au sein d’un node possède :

  • Une adresse IP locale,
  • Un ou plusieurs conteneurs Linux . Docker est le runtime de conteneurs le plus courant utilisé dans un Pod, mais d’autres runtimes de conteneurs sont possibles,
  • Un ou plusieurs volumes associés à ces containers, c’est-à-dire des ressources de stockage persistant.

Source : https://kubernetes.io

É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.

Service

Une application est susceptible d’être déployée au sein de plusieurs Pods répartis sur plusieurs nodes. Une première approche pour communiquer avec cette application serait d’utiliser les adresses IP des Pods. Cependant, cette approche présente de nombreuses contraintes car il faut constamment être capable de récupérer une ou plusieurs adresses IP. En effet, si un Pod est supprimé puis redéployé alors son adresse IP change. Pour palier à cette problématique, Kubernetes dispose d’un objet appelé Service qui permet d’associer, grâce à des LabelSelector (des labels pour identifier des objets), à un déploiement (c’est-à-dire un ensemble commun de Pods) une adresse IP et une URL (voir l’image ci-contre). Ainsi, l’objet Service permet d’exposer une application afin de recevoir du trafic de différentes manières en spécifiant un type dans sa définition :

  • ClusterIP (type par défaut) : permet d’être joignable par n’importe quelle autre application uniquement au sein du cluster grâce à une IP interne,
  • NodePort : permet d’exposer le Service sur le même port de chaque node sélectionné dans le cluster en utlisant le NAT (Network Address Translation). Ainsi, l’application est joignable depuis l’extérieur du cluster avec l’adresse :,
  • LoadBalancer : permet d’être joignable par n’importe quelle autre application au sein et l’extérieur du cluster grâce à une IP interne et une IP externe fournies par Kubernetes,
  • ExternalName : permet d’être joignable par n’importe quelle autre application au sein et l’extérieur du cluster en associant le Service à un nom DNS (Domain Name System).

Source : https://kubernetes.io

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 https://kubernetes-charts.storage.googleapis.com/ # 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 :

Publié par

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.