Dans le post précédent, nous vous avons introduit la notion de cluster et d'orchestration. Nous revenons sur ces idées pour expliquer les principales composantes de Kubernetes à travers trois plans :
- Le plan fonctionnel
- Le plan conceptuel
- Le plan système
Le plan fonctionnel
Sur le plan fonctionnel, la "promesse utilisateur" de Kubernetes, que vous trouverez directement depuis sa page d'accueil est :
- Découverte (exploration?) de service et partage de charge
- Orchestration du stockage
- Déploiement et retour-arrière automatiques
- Gestion du mode batch et du mode synchrone
- Libération automatique des ressources non utilisées
- Auto-réparation
- Gestion de la configuration et des secrets
- Ajout et suppression de ressources sans couture à la demande
L'ensemble de ces services, correctement agencés entre eux, constituent l'orchestrateur Kubernetes. Mais qu'est-ce qu'un orchestrateur ? L'image de l'orchestre, sans être un expert en musique, est assez simple à comprendre. Pour jouer une partition de manière harmonieuse, il est nécessaire qu'il y ait un chef d'orchestre, dont les tâches sont multiples, choix de la composition de l'orchestre, des musiciens, de leur position, choix de la partition. Il y a également des règles qui s'appliquent à tous, le solfège, la partition, ... Et enfin, des canaux de communication, visuels, sonores, entre le chef et les musiciens. Si vous remplacez le chef d'orchestre par un serveur contrôleur, les canaux par du TCP/IP sur ethernet, les musiciens par divers types de serveurs, vous avez une idée assez claire, mais peu poétique, du rôle de l'orchestrateur. La difficulté réside dans le fait que l'on souhaite jouer un scénario de manière cohérente et coordonnée.
Quant à vous, vous jouez le rôle (ardu) du compositeur chef d'orchestre qui écrit un fichier de déploiement. Vous avez besoin de (3) déployer des containers, travaillant en mode synchrone ou batch, de leur fournir une couche de stockage (2) pour la persistance de leur données, de permettre à chaque container d'échanger des données avec les autres (1), d'adapter leur capacité de traitement à la charge (5, 8), de réagir à des pannes pour retrouver le mode de fonctionnement nominal (6).
Le plan conceptuel
Le niveau conceptuel est décrit sur la page Wikipedia de Kubernetes.
Plusieurs hiérarchies se superposent ou s'entrecroisent du fait du caractère orthogonal des concepts manipulés.
Les namespaces séparent les objets appartenant à des projet différents (multi-tenancy). Une application est déployée dans un namespace. Elle est constituée de services. Les services contiennent des pods, qui contiennent des containers colocalisés.
Des services transverses sont accessibles aux pods :
- Les Volumes qui constituent la couche de persistance des pods
- Les Secrets gèrent les clés et les moyens de chiffrement utilisés par les pods
- Les déploiements permettent scaling horizontal des pods
Le plan système
Une vue détaillée des composants systèmes est disponible dans la documentation. Les principaux composants sont :
- un ou des contrôleurs qui hébergent les composants maîtres, ou encore que l'on peut appeler le plan de contrôle du cluster :
- un serveur d'API qui expose l'interface programmable à l'exterieur : kube-apiserver
- une base de données de configuration et d'inventaire : etcd
- un ordonnanceur des workloads : kube-scheduler
- un processus en boucle contrôlant l'ensemble : kube-controller-manager
- une abstraction (optionnelle) du controller-manager permettant aux fournisseurs cloud de développer des fonctionnalités indépendants du controller manager racine : cloud-controller-manager
- des noeuds (workers) qui fournissent la capacité de calculs (qui produisent) et comportent les composants suivants :
- un client (agent) de la couche controle : kubelet
- une interface réseau : kube-proxy
- une machine pour faire fonctionner les containers : container runtime
- des services transverses :
- DNS
- Serveur interface web (dashboard)
- Service de monitoring des containers
- service de logging (traçabilité)
Compétences ou maturité d'une organisation vis-à-vis de Kubernetes
Les trois niveaux ci-dessus définissent une hiérarchie des compétences Kubernetes :
- Niveau 1 : Connaître les bases de l'API (le plan fonctionnel) permet d'utiliser Kubernetes sur un service cloud, lancer des applications, faire des démonstrations : niveau prototypage et administration
- Niveau 2: Maîtriser complètement la partie fonctionnelle nécessite de connaître le modèle conceptuel qui s'y rattache : niveau design et implémentation cloud
- Niveau 3 : Déployer Kubernetes sur sa propre infrastructure implique de connaître en plus le fonctionnement de la partie système.
Les anti-patterns de Kubernetes
Première barrière : les micro-services
Aujourd'hui, Kubernetes est adapté au déploiement d'architectures micro-services basées sur des containers (principalement docker). Beaucoup d'applications ne sont pas actuellement compatibles avec ce modèle. Si vos applications ne sont pas construites selon cette architecture, vous ne tirerez probablement pas beaucoup de profit à utiliser Kubernetes.
Deuxième barrière : les containers
Si vos applications ne sont pas containerisées (cf point précédent), migrer vers kubernetes vous oblige à franchir deux marches, la containerisation et kubernetes. Il semble donc plus raisonnable d'étudier ce qui peut être containerisé - qui est un sujet à part entière - et d'intégrer Kubernetes ensuite, en franchissant une marche à la fois.
Troisième barrière : la complexité d'un environnement distribué
Il se manifeste à plusieurs niveaux :
- en admettant que vous installiez tous les services contrôleurs sur un même noeud, vous vous retrouvez avec une machine qui tourne avec 4 ou 5 services complexes, qu'il va falloir administrer et redonder
- si vous répartissez les services sur plusieurs machines, vous multipliez les serveurs de contrôle. Mais les contrôleurs ne sont pas des travailleurs. Si vous avez dix serveurs dans un environnement, dont trois contrôleurs pour sept travailleurs... vous perdez 30% d'infrastructure. Il faut être sûr que cela ait une utilité.
Il y a donc une taille minimale de clusters en dessus de laquelle ce genre de projets a peu d'intérêt. Notre remarque ne constitue qu'un élément, parmi les plus simples, des questions que vous allez devoir traiter pour monter votre cluster.
Quatrième barrière : la persistance des données (ou la couche stockage) et le réseau
Vous n'hébergez pas que des services sans état avec des données éphémères, qui peuvent être perdues lorsqu'une machine reboote. Vous avez donc besoin d'une couche de persistance distribuée et compatible avec Kubernetes et vos workloads.
Enfin, lorsque vos workloads se déplacent au gré des stratégies du scheduler, le réseau doit évidemment suivre.
Cinquième barrière : les middlewares qui embarquent déjà leur propre solution de clustering
Si vous déployez MongoDB ou Couchbase, ou Cassandra, ou n'importe quelle base NoSQL, celle-ci intègre une technologie distribuée et de clustering avec des mécanismes voisins mais spécialisés (serveur maître, catalogue, etc...). Avez-vous réellement besoin d'empiler ces deux technologies et si oui, pourquoi ? Pour faire tourner indifféremment du NodeJS, du MongoDB, du Redis sur une machine mutualisée ? Compliqué mais pourquoi pas si vous en avez réellement besoin.
Les cas d'utilisation de Kubernetes
Si vous êtes clients de cloud providers, l'API Kubernetes et notamment la CLI Kubectl est une sorte de standard de fait qui vous permet de déployer des containers sur des environnements fournis par des cloud providers différents. La situation est voisine de celle que nous avions signalé pour Openstack dans un autre post.
Si vous êtes cloud provider, vous êtes en miroir du client cité précédemment. Vous avez donc un intérêt à lui apporter une interface standard.
Enfin, si vous avez un volume significatif d'applications en architecture micro-service, la technologie de cluster Kubernetes est une solution possible parmi celle que nous citions dans le post précédent.
Ceci étant dit, Kubernetes va nécessairement évoluer pour essayer de devenir l'OS universel distribué de votre infrastructure SI. Polyvalence et hégémonie sont les tentations de tous les développements. Si le secteur de la mécanique s'inspirait de l'informatique, les fabricants de voitures seraient tous des fabricants de motos. Une moto est juste une voiture coupée en deux où l'on remplace la ceinture de sécurité par un casque. Un tracteur n'est jamais qu'une voiture dont on a grossi les roues arrières pour passer dans les champs. Reconnaissons cependant que Linux a réussi ce tour de force au niveau des OS non distribués. Ce qui n'est pas pensable en mécanique est possible en informatique. A suivre donc...
