Comprendre Kubernetes en 5 minutes

Kubernetes domine totalement le marché des orchestrateurs de conteneur avec 86% d’adoption. C’est phénoménal comme chiffre. Cette technologie est partout et si tu bosses pas déjà avec, y’a de fortes chances que ça t’arrive. Mais c’est quoi Kubernetes ? Et concrètement, comment ça marche ?

Il était une fois

Nous sommes en 2003, Google réunit une petite équipe de personnes pour un projet appelé Borg. Il s’agit alors d’un système de gestion de cluster interne à grande échelle, écrit entièrement en C++. Ce truc-là gère des centaines de milliers de jobs sur des milliers de machines réparties sur un paquet de clusters. Déjà à l’époque, le bordel c’est Star Wars. Et ce système continuera d’évoluer énormément au fil des années en interne chez Google.

En 2013, Borg est totalement en réécrit en Go et rebaptisé Kubernetes, toujours en interne. Milieu 2014, Google annonce pour la première fois Kubernetes. Le 21 juillet 2015, la version 1.0 atterrit sur les Internets et dans les mains de tout le monde. Et Google veut faire en sorte que tout le monde en parle.

Ils décident donc de s’associer avec la fondation Linux pour créer une nouvelle fondation : la Cloud Native Computing Foundation. Et je peux te dire qu’à l’époque tout ça faisait du bruit. Cette nouvelle organisation a pour rôle d’encourager l’avancée de technologies autour de la conteneurisation. Dont Kubernetes.

De 2015 à 2018, c’est la folle adoption de Kubernetes. À tel point qu’en 2018, l’équipe Kubernetes reçoit le prix du projet le plus impactant à l’OSCON.

Aujourd’hui, tout le monde est dessus. Et malgré le serverless qui gagne en popularité avec une philosophie inverse, je vois mal Kubernetes disparaître tout de suite. Mais c’est quoi exactement Kubernetes ?

C’est quoi Kubernetes ?

Kubernetes est un orchestrateur de conteneur qui permet le déploiement, le management et la gestion de charges de ton infrastructure. Concrètement Kubernetes te fournit un environnement de gestion pour ton infrastructure. Ça va gérer l’organisation, la mise en réseau ou encore la mise à l’échelle de tes conteneurs Linux (docker par exemple) sur un cluster. Et Kubernetes est capable de faire ça à très grandes échelles. C’est à dire gérer énormément de monde et de conteneurs en même temps.

Kubernetes est souvent remplacé par le diminutif K8S. C’est juste parce qu’il y a 8 lettres entre le K et le S de Kubernetes. C’est plus rapide à écrire. Kubernetes ça veut dire « pilote » en grec. Ces deux infos vont te servir à rien, mais maintenant tu le sais.

Kubernetes c’est aussi l’automatisation de tâches opérationnelles sur ta prod. Par exemple ton application va scaler up ou scaler down selon les quotas que tu auras spécifiés. Un déploiement d’une nouvelle version va se faire de façon safe. Si ta nouvelle version fail elle ne va pas remplacer l’ancienne qui marchait bien. Du coup, ta prod continue de tourner. Et plein d’autres trucs de fifou comme ça. Mais, concrètement, comment ça marche cette affaire ?

Comment ça marche ?

Le concept au cœur du fonctionnement de Kubernetes est le principe de l’état souhaité. Concrètement ça veut dire qu’on va définir une config bien spécifique d’un état désiré et Kubernetes va être responsable de l’honorer. Kubernetes suit une architecture maître / esclave dans un cluster. Une configuration au format YAML représentant ton organisation de conteneur va être feeder à un maître. Ce maître va envoyer des ordres à des workers esclave qui vont organiser tes conteneurs. Rentrons un peu plus dans les détails pour mieux comprendre.

Toi en tant en que développeur tu ne va parler qu’a l’unité maître de Kubernetes. Tu vas lui parler avec cette fameuse configuration YAML. L’unité maître va gérer les communications dans tout ton cluster. Il y a plusieurs composants dans cette unité maître. On va pas tout les citer, mais les plus importants sont le serveur API et le contrôleur manager.

L’API serveur va exposer l’api de Kubernetes pour que tu puisses l’utiliser. Le contrôleur manager est en fait composé de plusieurs contrôleurs qui vont chacun avoir une responsabilité comme : maintenir le bon nombre de ressources, détecter et réagir quand un worker esclave tombe ou encore gérer les accès à l’API.

Les unités esclaves sont des workers appelés Node, ou nœud en Français. Ces nœuds sont en fait des machines, physiques ou virtuelles, où vont être déployées tes conteneurs. Dans chaque nœud, on va trouver un processus très important qui s’appelle le Kubelet. Ce truc-là, va surveiller le démarrage, l’arrêt, et la maintenance de tes conteneurs. Si quelque chose se passe mal, il va notifier le maître qui va réagir en conséquence. Je sais, c’est compliqué tout ça, faisons un dessin.

C’est fou les efforts que je fais avec ces schémas dernièrement. Alors évidemment, j’ai simplifié les choses et les puristes vont hurler. Et je vais pas expliquer chaque partie sinon cet article va durer cinq ans.

Je te parlais de pods juste avant. Comme tu peux le voir, les pods se trouvent dans les nodes (workers esclaves). Un pod est un groupe d’un ou plusieurs conteneurs sur le même node et qui se partagent les mêmes ressources. Et c’est dans ces conteneurs que ton appli va vivre !

Fais voir le code

À la base je voulais te faire toute l’install de Kubectl, la création d’un cluster sur GCP jusqu’à l’exposition de ton application sur les Internets. Mais c’est juste trop long. On va rester sur une simple introduction. On va se concentrer sur le plus simple possible avec un Deployment basique.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jesuisundev-nginx
  labels:
    app: nginx
    version: v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
	spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Voilà à quoi ressemble la fameuse config YAML en Kubernetes. Ici on demande à utiliser la version 1 de l’api Kubernetes pour faire un « Deployment« . On lui file quelques metadatas et ensuite on indique qu’on veut deux replicas. Concrètement ça veut dire qu’on demande au cluster d’avoir deux pods répliqués pour ce Deployment.

Enfin dans les specs on spécifie que notre conteneur sera l’image docker nginx:1.7.9 et qu’on va exposer le port 80. À noter que le déploiement, le template et le selector spécifient tous des libellés « app: nginx ». Ça permet de faire la glue entre pods et déploiement.

On a plus qu’à appliquer cette configuration sur ton cluster. Le maître va dire aux esclaves de créer deux pods avec un nginx qui tourne dans chacun. Une fois que ces deux pods ont été créer là, ils vont être surveillés par le kubelet. Et c’est ainsi que tout est géré dans Kubernetes !

Épilogue

Kubernetes en seulement cinq minutes, c’était une folie ! Y’a beaucoup de choses que je ne dis pas. Même si ce format rapide n’est pas tout à fait adapté, j’espère t’avoir aidé à comprendre comment ça fonctionnait cette affaire. Sinon t’as une documentation de fou furieux par ici.