Kubernetes n’est pas ce que vous imaginez [partie 2]

Comment ne pas être déçu après la lecture de la partie 1 ?!
Kubernetes ne serait donc que du vent ? Une technologie dans la hype qui va s’évanouir ?

La réponse est clair : nope! Kubernetes n’est pas prêt de disparaître et va surement faire partie de notre quotidien pour la prochaine décennie à venir.

TL;DR
kubernetes doit être appréhendé comme un kernel de conteneurs, tout comme Linux pour le Posix.

Kubernetes est flexible, léger et portable !
Même si nous avons vu que ce n’était pas forcément signe de performance brut, ce sont les bases d’une infrastructure fiable.

Portable

La première chose que l’on doit faire avant d’utiliser kubernetes : trouver un bon éditeur YAML.
En effet, ce format de description est utilisé pour définir toutes les ressources et les besoins métiers.

Bien que le YAML ne signifie pas obligatoirement portabilité, kubernetes repose sur une description très précise et visionnaire de ses ressources.

Kubernetes agit au final comme un abstracteur de ressources.
Artefacts, configurations, disques, processeur, mémoire… toutes ces ressources sont génériques pour un client du cluster.

Encore plus loin, kubernetes possède des primitives de base nécessaire à des applications distribuées modernes.
Le principal exemple est la notion de “job” : pour maintenir des performances maximales et déléguer la charge, beaucoup d’actions asynchrones sont réalisées (mise à jour d’une statistique…). Ces taches ont besoin d’une queue, d’un worker et d’un job. Tous ces composants sont traditionnellement des composants uniques à maintenir.
Au sein de kubernetes, une resource job existe et peut être utilisée pour exécuter des actions asynchrones. L’API servant de queue, les nœuds existant de worker.

Cette portabilité des configurations a un effet immédiat : un comportement similaire dans toutes les étapes d’un projet, du développement à la production.

Flexible

En plus de reposer sur une définition claire des ressources, kubernetes fonctionne entièrement autour d’une API ouverte.

Aucun composant n’utilise une porte d’entrée cachée ou avec des droits privilégiés. Tous les composants peuvent être remplacés par une autre implémentation.

Grâce aux CRD, il est même possible d’étendre les ressources intégrées pour y ajouter ses propres règles et définitions.

En associant plusieurs ressources ensemble, on peut très facilement adapter le cluster aux besoins métiers.
À ce moment, cette flexibilité viens enrichir la portabilité : les besoins très “haut niveau” sont définis dans un format descriptif clair et ouvert à tous.

Tout comme les autres composants du clusters, ces éléments métiers peuvent être implémentés par différents système au cours du cycle de vie.

Léger

Reprenons l’architecture de kubernetes :

Bien que l’on ai vu que maintenir kubernetes ne soit pas chose forcément aisée, l’architecture de kubernetes limite drastiquement les ressources utilisées comparé à d’autres système de clustering.

• Peu de composants à maintenir pour un cluster
• Chaque composant est un binaire unique
• L’exécution des conteneurs est délégué à des composants existants.

Cette légèreté a un impact direct dans les choix d’architecture :

• Le coût d’infrastructure lié à un cluster kubernetes ne justifie pas de mutualiser les ressources au sein d’un seul mono-tenant.
• kubernetes se prête extrêmement bien au déploiement sur des infrastructures immutable et particulièrement sur des machines physique.
• l’empreinte d’exécution permet même d’utiliser des nœuds très léger à la Raspberry Pi comme worker du cluster. Cette capacité permet d’inclure de nouveaux nœuds très hétérogènes dans le cluster en vue d’un débordement ou du recyclage de machines.

Comme on peut le voir, kubernetes est complexe (mais pas compliqué).
Il implique des changements de paradigmes qui ne sont que le début d’un chemin.

Nous reviendrons dans d’autres articles sur les changements concret que l’utilisation de kubernetes apporte / impose.