Introduction du cours pour apprendre l'orchestrateur Kubernetes (k8s)

Cours complet pour débutants afin d'apprendre pas à pas les différents fonctionnements et notions de l'orchestrateur Kubernetes (k8s).

Introduction

Hello world, Vous allez bien ? Prêt pour attaquer un nouveau cours ? C'mon here we go !

Motivé pour apprendre le nouveau cours

Chose promise chose due, Je m'étais engagé dans le cours complet sur la technologie Docker, plus précisément dans le chapitre sur Docker Swarm, à faire un cours sur un autre orchestrateur autre que Docker Swarm. Et voilà, nous y sommes, ça sera donc un cours destiner complètement à l'orchestrateur de conteneur Kubernetes, commençons d'abord par découvrir son histoire.

Histoire de Kubernetes

Lorsque nous examinons l'histoire de Kubernetes , il est facile de comprendre la motivation qui a poussé les inventeurs de l'outil, à créer ce système d'orchestration de conteneurs, atteignant aujourd'hui un seuil de maturité assez exceptionnel.

Pourquoi cet intérêt pour les conteneurs ?

L'histoire de Kubernetes a commencé chez Google, la société avait besoin d'une infrastructure énorme afin de mettre à la portée de tous, son moteur de recherche et les publicités associées. La croissance prévue est juste astronomique, pour lequel diverses idées ont été soulevées.

Nous avions déjà abordé dans cet article les différences entre la virtualisation et la conteneurisation , où j'avais expliqué entre autres, que les machines virtuelles intègrent elles-mêmes un OS pouvant aller jusqu’à des Giga-octets, cependant, ce n'est pas le cas du conteneur. Le conteneur appelle directement l'OS pour réaliser ses appels système et exécuter ses applications. Il est par conséquent beaucoup moins gourmand en ressources.

Et c'est exactement le même problème qu'avait rencontré Google à l'époque. En effet, malgré la mise en place d'un système de virtualisation, le potentiel des ressources n'était pas encore pleinement exploité de manière appropriée, ainsi les coûts informatiques n'étaient pas totalement maîtrisés, étant donné que le géant du web payait pour des ressources qu'il ne consommait pas.

Clairement, la solution était les conteneurs. Bien que l'intérêt général pour les conteneurs de logiciels soit un phénomène relativement récent, Google gère depuis plus de dix ans les conteneurs Linux à grande échelle et a construit trois systèmes de gestion de conteneurs.

Création de la première solution, le projet Borg

Il avait notamment commencé par construire un système de gestion de cluster appelé Borg. Voici une explication simple du mode de fonctionnement du système Borg de Google :

Lorsque vous avez une machine standard et que vous souhaitez exécuter plusieurs processus dessus, c'est le système d'exploitation qui gère l'ordonnancement. C'est lui qui détermine quel processus a accès à quel processeur, quel processus a accès à quelles parties mémoire, quels sont les processus qui doivent être gelés ou disparaître dans les cas de pénurie de ressources. Véritablement Borg fait la même chose mais à l'échelle d'un cluster, c'est en quelque sorte, un OS pour cluster. Lorsque vous désirez exécuter un job, vous le faite depuis Borg, vous dites simplement au planificateur de cluster Borg ce que vous voulez, comme par exemple "lance-moi 300 répliques de mon application web". Ensuite le planificateur Borg identifie les machines du cluster qui disposeront de la capacité disponible pour exécuter votre service et envoie une demande d'exécution du service aux nœuds (machines qui constituent votre Cluster).

Architecture du système Borg conçu par Google

Google a initialement conçu Borg pour répondre à ses propres besoins internes, Borg restait le principal système de gestion des conteneurs au sein de Google en raison de son ampleur et de l'étendue de ses fonctionnalités. Par la suite Google développe Omega, qui est une progéniture de Borg, afin d'améliorer l'ingénierie logicielle de l'écosystème Borg.

L'arrivé du projet Kubernetes

Arrive alors en 2014 Kubernetes souvent abrégé k8s, "k + 8 caractères + s", écrit en Go (j'ai d'ailleurs fait un cours complet sur le langage Go, ici ) et né à partir du projet Borg et Omega. Ces deux derniers ont été développés en tant que systèmes purement internes à Google, à l'inverse de Kubernetes, qui est quant à lui maintenant devenu une version opensource (code source disponible ici) de ses prédécesseurs avec des fonctionnalités améliorées permettant de résoudre les anciens problèmes de gestion des clusters, ainsi qu'un support accru de la part d'IBM, Cisco et Redhat.

De nos jours le projet n'appartient plus vraiment à Google, car Google a fait don du projet Kubernetes en 2015 à la toute récente Cloud Native Computing Foundation.

Public visé

Ce tutoriel est conçu pour les débutants ayant besoin de comprendre la technologie Kubernetes à partir de zéro. Ce tutoriel vous donnera une compréhension suffisante de la technologie, qui vous permettra plus tard d’atteindre des niveaux d’expertise beaucoup plus élevés.

Prérequis

Avant de poursuivre ce cours, vous devez au minimum avoir une compréhension de base sur les commandes Linux et sur la technologie Docker, si vous n'avez jamais touché à Docker de votre vie, alors je vous conseille grandement dire lire mon cours complet sur Docker. Si vous maîtrisez Docker, plus précisément Docker Swarm, alors il vous sera très facile de comprendre les concepts de Kubernetes et d’avancer rapidement sur la piste d’apprentissage, mais ce n'est pas non plus indispensable.

Êtes-vous prêt pour découvrir des nouveaux horizons ? alors c'est parti !

Espace commentaire

Écrire un commentaire

Rejoignez la discussion

Vous devez être connecté pour poster un message.

39 commentaires

ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

N'oubliez pas de checker régulièrement vos kubelet avec journalctl -u kubelet -f si vous voyez des comportements bizarres sur vos nodes.

02/08/2019 à 08:56
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Utilise les resources dans ton spec de conteneur. C'est la base pour éviter le OOMKill en prod.

resources:
  limits:
    memory: "128Mi"
    cpu: "500m"
  requests:
    memory: "64Mi"
    cpu: "250m"
02/08/2019 à 02:02
leveque-aurore
Membre Actif
Avatar de leveque-aurore
leveque-aurore
Membre Actif

Comment je fais pour limiter les ressources CPU/RAM d'un pod ? J'ai peur qu'un conteneur bouffe tout.

01/08/2019 à 19:47
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Absolument pas. C'est nécessaire si tu veux contribuer au code source de Kubernetes, mais pour l'opérer, le YAML suffit largement.

01/08/2019 à 13:23
ufaure
Membre Actif
Avatar de ufaure
ufaure
Membre Actif

Le cours mentionne Go pour k8s, c'est indispensable de savoir coder en Go pour gérer un cluster ?

01/08/2019 à 08:19
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
01/08/2019 à 06:17
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

C'est souvent une ressource qui bloque. Fais un kubectl get namespace [nom] -o json pour voir ce qui reste.

Sinon force la suppression en éditant le json du namespace pour virer le finalizers.

01/08/2019 à 03:09
georges-ramos
Membre Actif
Avatar de georges-ramos
georges-ramos
Membre Actif

Je n'arrive pas à supprimer un namespace, il reste bloqué en Terminating. Help.

31/07/2019 à 22:08
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Oui, mais c'est une usine à gaz. Faut des labels de node et des nodeSelector spécifiques dans tes manifests.

31/07/2019 à 17:51
fernandez-monique
Membre Actif
Avatar de fernandez-monique
fernandez-monique
Membre Actif

Est-ce qu'on peut mélanger des conteneurs Windows et Linux dans le même cluster ?

31/07/2019 à 12:23

super! merci beaucoup 🙏

31/07/2019 à 08:23
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

T'as vérifié les règles de ton pare-feu (ufw ou iptables) sur les nodes ?

Le NodePort doit être autorisé sur les interfaces réseau de tes workers.

31/07/2019 à 06:26
alice21
Membre Actif
Avatar de alice21
alice21
Membre Actif

J'ai un souci avec l'exposition de mon service en NodePort, ça ne répond pas depuis l'extérieur alors que le port est ouvert.

31/07/2019 à 00:42
foucher-catherine
Membre Actif
Avatar de foucher-catherine
foucher-catherine
Membre Actif

kubectl logs [nom-du-pod]. Ajoute -f pour le stream en direct.

30/07/2019 à 20:14
benoit-pons
Membre Actif
Avatar de benoit-pons
benoit-pons
Membre Actif

C'est quoi la commande pour voir les logs d'un pod spécifique ? Je galère à debug mon conteneur web.

30/07/2019 à 15:40
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Bonjour @nibizien 

Merci pour ton message et bon apprentissage 😁 !

30/07/2019 à 15:20
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Vérifie la date de tes serveurs. Si l'horloge est décalée, les certificats sont rejetés.

Utilise timedatectl status pour checker ta synchro NTP.

30/07/2019 à 08:42
nibizien
Membre
Avatar de nibizien
nibizien
Membre

Bonjour, bravo, tes tutos sont très bien faits.

Merci pour le partage, j'apprends plein de choses

30/07/2019 à 04:22
alexandre80
Membre Actif
Avatar de alexandre80
alexandre80
Membre Actif

Mon kube-apiserver refuse de démarrer sur mon serveur dédié. Il me sort un souci de certificat.

30/07/2019 à 00:54
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Exact, kind utilise des conteneurs pour simuler les nodes. C'est propre et rapide.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
29/07/2019 à 18:39
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

De rien :)

29/07/2019 à 18:01
robert46
Membre Actif
Avatar de robert46
robert46
Membre Actif

kind est beaucoup plus léger pour tester des clusters multi-nodes sur une machine locale, surtout si t'as déjà Docker qui tourne.

29/07/2019 à 12:19
pierre06
Membre Actif
Avatar de pierre06
pierre06
Membre Actif

Pour débuter, vous conseillez minikube ou kind ?

29/07/2019 à 05:35
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Vérifie ton CNI. Si tu n'as pas installé de plugin réseau (Calico, Flannel, etc.), tes nodes ne pourront jamais communiquer.

Regarde les logs avec kubectl describe node [nom-du-node].

29/07/2019 à 00:16

Merci,c'est bien expliqué

28/07/2019 à 21:01

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire