Comprendre les bases de Kubernetes

Introduction

Vous avez, probablement, entendu une des prononciations suivantes : ku-ber-nay-tess , koo-ber-nay-tess, ku-ber-ni-tiss…

Laquelle est correcte ?

Nous pensons que c’est un simple détail. Surement la personne en face de vous comprendra de quoi vous parler. Il y a plein de choses à apprendre beaucoup plus importante que la prononciation. Dans cet article, on évoque l’origine de ce produit ainsi que quelques concepts de base.

Origine

Kubernetes est un produit Google qui a été annoncé au public en 2014. Il était déjà utilisé en interne depuis une dizaine d’années avant de devenir open-source. En effet, Kubernetes est la suite du projet Borg (appelé ultérieurement Omega) qui permet de faire tourner des services dans des conteneurs.

Kubernetes (ku-ber-ni-tiss) est un mot grec qui veut dire timonier (qui s’occupe de la direction du navire). Il y avait l’intention de le nommer Seven of Nine. En faisant référence au personnage de Star Trek qui était un ex-Borg. Bien-sûr pour des raisons de droits d’auteur ceci n’était pas possible. Le fait d’avoir sept barres dans le logo (sous forme de gouvernail) a potentiellement un lien avec le nom original car souvent c’est un nombre paire (6 ou 8). L’écriture abrégée de Kubernetes est k8s. Le nombre 8 remplace les huit caractères entre ‘k’ et ‘s’.

Google a offert Kubernetes en 2015 à la CNCF (Cloud Native Computing Foundation), qui fait partie de la Linux Foundation. Il s’agit de son premier produit.

Principe

Avec le passage d’une application monolithe vers les micro-services, le nombre de composants à déployer et à gérer est devenu assez important. Même si la conteneurisation facilite la tâche, il est indispensable d’avoir une couche plus haute permettant de bien organiser les conteneurs sur des centaines voir des milliers de nœuds comme s’ils étaient sur le même nœud. Kubernetes est une plate-forme d’orchestration des services conteneurisés.

Architecture

Un cluster Kubernetes est constitué d’un ensemble de nœuds qui peuvent être des machines Linux bare metal, des VMs ou des instances dans le cloud. On peut distinguer deux types de nœuds :

• Master (control plane) : contrôle et gère l’ensemble du système Kubernetes.
• Worker : exécute le travail affecté (l’application déployée).

Concepts

Dans cette section, on va parler des principaux objets Kubernetes nécessaires pour déployer une application.

Pod

Il s’agit de l’unité de base dans Kubernetes. C’est l’équivalent à un conteneur dans Docker ou une machine virtuelle dans le monde virtualisation. Un pod est un groupe de conteneurs. En anglais, pod of whales est un groupe de baleines.
Il est cependant recommandé d’avoir un conteneur par pod. En fait, Kubernetes surveille l’état du pod en se basant sur l’état de son conteneur. Si le pod contient plusieurs conteneurs, c’est plus compliqué de savoir comment réagir si un conteneur n’est plus en vie. L’utilisation de plusieurs conteneurs par pod est limitée à certains cas, comme un conteneur helper (par exemple pour externaliser les logs) ou un conteneur d’initialisation (par exemple pour cloner un projet). Un pod qui contient plusieurs conteneurs les fait tourner sur le même nœud et jamais sur deux nœuds séparés.

Ci-dessous, un exemple de fichier descriptif d’un pod.

apiVersion: v1
kind: Pod
metadata:
 name: sample-pod
 labels:
   app: real-world
   tier: presentation
spec:
  containers:
  - image: real-world
    name: real-world-in-sample-pod

• apiVersion : la version de l’API utilisée.
• kind : le type de la ressource à créer.
• metadata/name : le nom à attribuer à la ressource.
• metadata/labels : les labels affectés à la ressource. Ils seront utilisés par d’autres ressources pour sélectionner le pod.
• spec/containers : la liste de conteneurs à créer.

Les contrôleurs de pods

Kubernetes offre plusieurs objets qui assurent l’existence et la disponibilité de ses pods. Si un ou plusieurs pods venaient à disparaître à la suite d’une indisponibilité d’un nœud ou d’une éjection pour manque de ressources, ces objets vont détecter cette absence et remplacer le(s) pod(s).

Deployments, ReplicaSet, ReplicationController, StatfulSet
Ces objets se ressemblent et se composent de la même façon :

• Sélection de labels : permet de determiner les pods à surveiller.
• Nombre de replicas : le nombre de pods qui tournent.
• Pod template : définit la structure de pod à construire.

• Le ReplicaSet est la nouvelle génération du ReplicationController. En effet, le ReplicaSet est plus riche dans la partie ‘sélection des labels’.
  Un Deployement est le niveau le plus élevé. En comparaison avec le ReplicaSet, Il apporte la gestion du rollout et du rollback. Il permet de déployer une nouvelle version de l’application d’une manière abstraite.
• La particularité du StatfulSet par rapport au ReplicaSet est, comme indique son nom, le fait de sauvegarder l’état du pod. Par exemple, en perdant un pod nommé pod-A-1, le StatefulSet va recréer un pod avec le même nom et la même adresse IP.

DaemonSet
Fait tourner un seul pod par noeud dans tout le cluster Kubernetes. Un exemple d’utilisation est la surveillance du cluster.

Job
Fait tourner un ou plusieurs pods afin d’exécuter une tâche précise.

CronJob
Permet de planifier des jobs pour tourner régulièrement.

Services

Que ce soit dans une architecture 3-tier (front, back, base de données) ou de type micro-services, nous avons besoin de faire communiquer des composants entre eux. On pourrait le faire en utilisant des adresses IPs. Cependant, ce n’est pas la bonne pratique dans Kubernetes, car un pod est éphémère. Il peut disparaître et être remplacé par un autre pod avec une autre adresse IP. Ce besoin a donné naissance à l’objet Service.
Un service est un point d’entrée unique à un groupe de pods.

Ci-dessous, un exemple de fichier descriptif d’un service Kubernetes.

apiVersion: v1
kind: Service
metadata:
 name: sample-service
spec:
  selector:
   app: real-world
   tier: presentation
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

• apiVersion : la version de l’API utilisée.
• kind : le type de la ressource à créer.
• metadata/name : le nom à attribuer à la ressource.
• spec/selector : les libellés utilisés pour sélectionner le pod.
• spec/ports : le mapping du port entre le service et le pod.

Namespace

Dans un contexte professionnel, plusieurs équipes peuvent travailler sur le même cluster Kubernetes. Afin de garantir une meilleure séparation entre les ressources de chaque équipe, Kubernetes propose la notion de namespace qu’on peut considérer comme étant un cluster virtuel. Deux namespaces différents peuvent contenir une ressource avec le même nom. Même si la majorité des ressources est classée par namespace, certaines ressources ne le sont pas, comme par exemple les nœuds.

Conclusion

Nous avons présenté dans cet article une brève introduction à Kubernetes avec les concepts clés pour déployer une application. Le produit est assez riche et définit d’autres concepts importants liés à la sécurité, le monitoring et la personnalisation des ressources.