Il est partout : on ne peut pas parcourir un site d’information, lire l’actualité de notre secteur ou encore consulter les Meetups du jour sans en entendre parler… il s’agit de Kubernetes.
Net4All vous propose une série d’articles rédigés par des experts techniques afin d’appréhender au mieux ce nouvel incontournable !
Docker
Docker, ou la conteneurisation de manière générale, est un concept introduit depuis quelques années et bien installé dans le monde informatique. Il offre des avantages en termes de gestion de l’environnement nécessaire au fonctionnement de l’application et est largement utilisé par les entreprises de toutes tailles.
Kubernetes vs docker
Pour faire un parallèle avec le monde de la virtualisation “classique”, kubernetes est à docker ce qu’un hyperviseur est à une machine virtuelle avec une gestion de cluster.
Kubernetes est aujourd’hui le standard de facto concernant la gestion de containers à large échelle. Son but est d’automatiser le cycle de vie ainsi que le maintien des containers sur un environnement donné.
Kubernetes est aujourd’hui utilisé et supporté par les acteurs majeurs du cloud. Son concept permet de faire fonctionner des containers de manière indépendante de la couche d’infrastructure sous-jacente.
Kubernetes permet, en plus d’être agnostique de l’infrastructure sous-jacente, d’élaborer des infrastructures hybrides, entre plusieurs cloud providers de types différents (cloud privé et cloud publique). Openshift, produit développé par Redhat et reposant sur kubernetes, met un axe prépondérant sur l’hybridation et l’instrumentalisation de la solution.
Pourquoi Kubernetes ?
Kubernetes est devenu un outil à la mode que chacun souhaite tester car, globalement, tout le monde s’accorde à le dire : Kubernetes, c’est cool.
Mais concrètement, comment et pourquoi utiliser Kubernetes ?
Kubernetes permet de transformer les containerisations en instruments de déploiement à large échelle : l’avantage principal est que ceci permet d’intégrer des processus de déploiement en termes d’intégration continue/développement continue afin de pouvoir faire évoluer votre applicatif en passant à travers les étapes de développement, staging et production de manière maîtrisée.
Si vous avez des processus de développement rapides et que votre applicatif change très souvent, il est clair qu’associé à de la CI/CD, Kubernetes est le lien qui permet d’appliquer le dynamisme tout au long de la chaîne.
Ceci ne va tout de même pas sans ajouter un certain nombre de risques : La containérisation redistribue les responsabilités en termes de maintien à jour des interpréteurs à des équipes qui n’ont pas forcément l’habitude de gérer ces sujets.
L’infrastructure n’est pas en reste, certaines intégrations cloud ne prennent que difficilement en charge les mises à jour. Ces éléments sont essentiels à prendre en compte avant une implémentation de production afin d’éviter de se retrouver avec une implémentation obsolète dès sa mise en place.
Architecture type
Kubernetes repose sur des concepts relativement simples :
Le “control plane” est composé d’un API server, d’un scheduler et d’un controller manager. L’ensemble de ces composants sont réunis au sein d’une machine que nous appelons “Kubernetes master”. Cette instance est le chef d’orchestre, c’est lui qui va gérer les différents Nodes kubernetes chargés de faire fonctionner le workload.
Une infrastructure de départ est par conséquent composée d’un master et des minimum 2 nodes
Comme évoqué, le but principal de kubernetes est l’abstraction de la partie “hardware” : ceci a pour avantage de vous permettre de démarrer un cluster kubernetes sur n’importe quelle infrastructure de base : hyperviseur classique, bare metal, cloud publique ou même raspberry pour les plus courageux.
Cet avantage rend kubernetes très facilement prototypable, bien que la technologie en elle même demeure complexe.
Concept généraux kubernetes
Pod
Le pod est la plus petite entité à l’intérieur du cluster Kubernetes. Il s’agit d’un container, ou d’un ensemble de containers, destinés à faire fonctionner une part de l’application. Le modèle “un container par pod” reste cependant le plus répandu.
Il est important de prendre en compte que chaque pod doit rester stateless, étant donné que ces derniers peuvent être démarrés puis arrêtés à la volée par le maître du cluster. Tout ce qui est dans le stockage local est donc éphémère par défaut. Il est néanmoins possible de créer des volumes persistants afin de pouvoir garder les données intéressantes générées au cours de la vie du pod.
Au niveau du réseau, chaque Pod se voit attribuer une adresse IP du cluster, mais n’est pas accessible depuis l’extérieur. Il est possible d’accéder aux services fournis par le pod directement grâce à cette adresse, mais cette façon de faire n’est pas conseillée, étant donné que cette dernière est éphémère. Il sera donc plus judicieux de passer par un Service afin de pouvoir faire communiquer les pods entre eux.
Service
On peut se représenter les services Kubernetes comme étant des load balancers pour les pods. Ceux-ci s’occupent de rediriger les requêtes qui les atteignent à un des pod faisant partie de ce dernier. Chaque service est renseigné dans le serveur DNS du cluster, ce qui permet d’accéder à un ensemble de pods avec un identifiant qui reste fixe.
L’enregistrement des pods sur un service est effectué à l’aide d’un sélecteur. Cela fonctionne simplement comme un tag, et tous les pods portant ce tag sont automatiquement utilisés comme cible du service.
Mais il existe d’autres manières de définir un service. Il est par exemple possible de renseigner une adresse IP fixe comme cible du service, afin d’utiliser le service pour accéder à un service externe au cluster, tel qu’une base de données par exemple.
Les services sont accessibles uniquement depuis l’intérieur du cluster, mais ils peuvent être la cible d’un Ingress Controller afin d’être accessible depuis l’extérieur.
Ingress controller
L’ingress controller est une partie essentielle du cluster Kubernetes, il s’agit du point d’entrée public pour les applications. Celui-ci fonctionne comme un reverse proxy devant une infrastructure, et permet, par exemple, d’effectuer un premier filtrage sur les requêtes entrantes, si l’ingress controller choisi le permet.
Cela rend donc possible l’accès à un service Kubernetes spécifique, en fonction du domaine accédé, ou d’un “dossier” particulier.
Les ingress controllers supportés officiellement par le projet Kubernetes sont nginx ou Google Cloud. Cependant il existe d’autres solutions parfaitement compatibles telles que HAProxy, Traefik ou F5 par exemple.
Dans le cas de l’utilisation d’un cluster Kubernetes managé sur un cloud public, il sera conseillé d’utiliser l’ingress controller proposé par le cloud en question, afin de pouvoir mieux s’interfacer sur l’infrastructure fournie.
Kubelet et Container Runtime
Kubelet est un agent tournant sur chaque nœud du cluster. Il s’occupe des pods tournant sur chaque node, en faisant l’intermédiaire entre l’orchestrateur et le Container Runtime.
Le Container Runtime est le logiciel se chargeant de faire fonctionner les containers. Historiquement, ce rôle était rempli par Docker, mais depuis d’autres logiciels sont capables de remplir ce rôle, tels que containerd ou CRI-O. Depuis l’intégration de CRI (Container Runtime Interface), le container runtime utilisé est totalement transparent au niveau du cluster, et également du point de vue utilisateur.
Deployments et DaemonSets
Les Deployments et les DaemonSets sont des moyens de s’assurer que les pods soient bien fonctionnels dans le cluster. Ils gèrent donc l’exécution de ces derniers, mais également leur lifecycle, autrement dit leur création et leur destruction.
De ces manières de faire, le Deployment est la plus fréquemment utilisée. Elle permet d’avoir constamment un nombre défini de répliques d’un pod dans le cluster, tout en gardant la possibilité d’augmenter ce nombre manuellement, ou en fonction de métriques.
Les DaemonSets, de leur côté, servent plutôt à déployer des services internes au cluster (tel que l’agrégation de logs) étant donné que leur spécificité est de s’assurer qu’une réplique de pod est disponible sur chaque nœud du cluster.
Il existe encore d’autres types de moyens de gérer les pods sur un cluster Kubernetes, tel que le ReplicaSet, qui s’assure qu’il y ait toujours un nombre donné de répliques d’un pod sur un cluster, mais ce dernier est souvent remplacé par le Deployment, qui permet d’effectuer le même travail tout en étant plus flexible.
Vous avez des questions ou besoins concernant Kubernetes ? Nos experts techniques sont à disposition pour échanger sur votre projet.
Rédacteurs
Guillaume Petitpierre, Administrateur Système Linux
Après un apprentissage d’informaticien (spécialité en développement Android), Guillaume poursuit ses études dans le développement logiciel et obtient son Bachelor. Depuis 2017, Guillaume gère pour Net4All le déploiement et le maintien en condition opérationnelle des plateformes clients.
Kevin Chollet, Responsable Pôle Linux
Kevin est Ingénieur HES en Télécommunications avec une expérience en tant qu’indépendant. Il rejoint Net4All en 2014 avec mission principale la gestion du pôle linux et des infrastructures.
