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

En travaillant dans l’infrastructure en 2018, il est difficile de passer à côté de kubernetes.
Tout comme Docker avant lui, Kubernetes commence à s’installer dans beaucoup d’entreprises de tout les secteurs.

Les avantages attendus sont nombreux :

• Performances
• Densification
• Maintenance réduite
• Rapidité du déploiement d’applications

Un instant… Cela ressemble aux promesses du IaaS !

Croyances et biais cognitif

L’Infrastructure as a Service est un composant essentiel des SI de ces 10 dernières années.
En utilisant la virtualisation, de nombreux logiciels peuvent cohabiter sur une même machine physique.

Donc reprenons un par un les avantages attendus dans le cas d’une entreprise possédant déjà un IaaS (privé ou public).

Performances

Les conteneurs sont plus rapide que les VM

De manière brut, il est souvent vrai qu’un conteneur dans kubernetes sera plus rapide qu’une machine virtuelle ayant son propre OS.

Mais en dépensant un peu de temps d’optimisation sur l’infrastructure de virtualisation, il n’est pas rare de faire tomber le surplus de CPU à moins de 2%.
Il en va d’ailleurs de même avec les IO disques et réseau.

Enfin, les infrastructures kubernetes déployées vont souvent reposer sur un IaaS préexistant annulant tout bénéfice possible.

Densification

Avec les conteneurs nous pouvons mettre des centaines de logiciels sur nos serveurs

La partage d’un même kernel par plusieurs conteneurs permet souvent de se représenter cette solution comme moins lourde en mémoire.

Dans les faits, des solutions techniques comme KSM permettent de partager l’espace mémoire commun entre plusieurs VM.
Une experimentation de RedHat a même permis de lancer 52 Windows™XP avec 1G de Ram sur une machine de 16G de Ram.

Un autre avantage perçu du conteneur est sa gestion plus fine de la mémoire. Le kernel connait exactement la mémoire prise par une application et peut lancer un nouveau conteneur dans l’espace restant.

Mais c’est oublier la technologie dite de ballooning permettant de réduire la mémoire prise sur le nœud hôte à ce qui est utilisé par la machine virtuelle.
Cela permet un ajustement précis de l’espace mémoire occupé.

Enfin, il faut savoir que la sur-densification peut avoir des effets néfastes sur l’infrastucture.
En effet une augmentation temporaire de charge peut déclencher des OOM impactant directement la qualité de service.
C’est pour cette raison que la réservation de mémoire est fortement recommandé pour des conteneurs. À noter que cela permet aussi souvent à l’orchestrateur de répartir plus efficacement les applications entre les nœuds.

Maintenance réduite

Openstack est beaucoup trop complexe pour ce qu’on veut faire

L’architecture de kubernetes est assez simple et peut être résumé ainsi :

Peu de composants à état (seulement etcd), une communication par des API, des composants mono-binaire. Nous avons là quelque chose de simple à comprendre.

Il est donc normal d’imaginer que la maintenance va être facilité comparée à des architectures plus complexes.
Openstack a de nombreux composants, eux même en modules.

Malheureusement, cette apparente simplicité de gestion est assez trompeuse.
Oui il est simple de faire sa première infrastructure en suivant un tutoriel sur une ou plusieurs machines.
Non il n’est pas simple de maintenir une infrastructure comme kubernetes en production.

“Le diable est dans les détails.”
Kubernetes repose sur beaucoup de prérequis dont il ne s’occupe pas : réseau, stockage, conteneurisation…
Tous ces composants ont également leur propre logique, cycle de vie, maintenance etc.

Tous ces prérequis sont à choisir et opérer dans le temps.

• Réseau : ACI, Big Cloud Fabric, Cilium, Contiv, Contrail, Flannel, GCE, Kube-router, L2 networks and linux bridging, Multus, NSX-T, Nuage, OpenVSwitch, OVN, Project Calico, Romana, Weave Net, CNI-Genie…
• Conteneurisation : docker (CE / EE), rkt, cri-containerd, containerd (1.1), cri-o, katacontainers…
• Stockage : GCE, AWS, Azure, Fibre Channel, FlexVolume, Flocker, NFS, iSCSI, Ceph, Cinder, Glusterfs, Vsphere, Quobyte, HostPath, Portworx, ScaleIO, StorageOS.

De plus, via son cloud-controller, kubernetes va avoir un comportement spécifique en fonction de l’architecture sous-jacente configurée.

Toute cette matrice de choix ne rend pas kubernetes plus complexe qu’un autre système. Juste des problématiques à prendre en compte.

Rapidité du déploiement d’applications

Les conteneurs vont résoudre nos problèmes de déploiement

Le système de conteneur rend le déploiement d’une application existante extrêmement simple.
Récupération de l’image →lancement du processus.

Cette simplicité face à des cas simples (hello-world…) fausse l’évaluation de sa mise en place dans l’entreprise.

Au final, un conteneur n’est qu’un artefact de développement immutable : lLe même code compilé peut passer toutes les étapes du développement à la production sans être modifié (et donc introduire de possibles erreurs/bugs).

Cette particularité n’est pas intrinsèque aux conteneurs.
Vous pouvez générer des images de virtualisation immutables (via packer par exemple).
Vous pouvez également créer des conteneurs après la phase de développement avant la mise en production (le conteneur n’étant plus le livrable du développement, mais un vecteur de mise en production).

On vois donc que le choix n’est plus technique, mais politique et organisationnel.

Si votre organisation ne permettait pas de faire des images de virtualisation immutable, il y a peu de chance que la conteneurisation le permette.

Des mythes et légendes urbaines circulent forcément sur un sujet nouveau et attractif.
On le vois, il est particulièrement simple d’y croire quand tout ceci repose sur des assomptions logiques simples.

Par exemple “c’est flexible”, “c’est léger”, “c’est portable” ne sont absolument pas une raison pour des performances accrues.

Mais alors, pourquoi kubernetes est une technologie formidable ?

Parce que “c’est flexible”, “c’est léger”, “c’est portable” !