Kubernetes est-il trop complexe ?

En réalité, ce n’est pas moi qui le dis mais le créateur de Kubernetes lui-même, en 2018, ici.

Kubernetes n’est pas applicable à tout le monde.

De nombreuses entreprises s’interrogent en effet sur la nécessité de déployer une solution d’orchestrateur de conteneurs de type Kubernetes, dans leurs environnements. Certaines ont déjà franchi le cap et font face à une charge de travail très importante pour opérer cette nouvelle plateforme.

Kubernetes représente un changement aussi important que la virtualisation en son temps. La manière dont les applications sont packagées, déployées, et opérées, nécessite des processus et des outils complètement différents de ce que nous avions l’habitude d’utiliser en environnement « Serveur Physique Classique » ou dans des « Machines Virtuelles ».

Pour vous en convaincre, il suffit de jeter un œil ci-dessous à la constellation de produits répertoriés par la CNCF (Cloud Native Computing Foundation) :

La vue globale sur la constellation est ici.

Tout simplement étourdissant : on comprend aisément la difficulté à appréhender, choisir, tester et éprouver dans son propre contexte, l’étendue des possibilités offertes par le marché. Certaines solutions sont très spécifiques et d’autres se recoupent fonctionnellement
Les entreprises ayant déjà entrepris de déployer des conteneurs (principalement à base de Docker), ont déjà entamé en partie la transformation nécessaire pour profiter de ce changement de paradigme. La route est toutefois encore longue et les pièges nombreux.

Une montée en compétence difficile et une réorganisation des équipes nécessaire

La mise en place d’un orchestrateur de conteneurs vient généralement de pair avec la construction ou la refonte d’applications en architecture micro-services.
Sans rentrer dans la polémique du micro-services comme réponse à tous les problèmes de développement, il est indispensable de comprendre la dépendance entre ces architectures et la manière dont la plateforme et l’infrastructure sous-jacente permettent de supporter l’ensemble.
La principale force des micro-services est de pouvoir découpler les composants techniques et de faire travailler en parallèle les équipes de développement (ex : « Feature Teams »).
Dans ce contexte de développement, deux approches sont possibles :

• laisser la main aux Développeurs pour déployer en autonomie (idéalement à travers la chaîne d’intégration, de livraison et de déploiement continu),
• ou confier la tâche à l’équipe SRE (communément appelé DevOps) interne ou externe à l’entreprise.

Les équipes de Développement doivent connaître le fonctionnement intrinsèque de Kubernetes, comme par exemple le composant de service-mesh, ou certaines primitives pour déclarer les services (ex : StatefulSets, DeploymentSets, DaemonSets…), et déterminer les raisons des dysfonctionnements potentiellement rencontrés
Cette courbe d’apprentissage est raide, et il est comme toujours question d’équilibre entre l’investissement en temps et le retour de productivité ou de valeur espéré.

Est-ce que la livraison répétée de fonctionnalité est bien accélérée, au regard du temps investi pour maitriser et gérer une telle solution ?

Il n’y a pas de réponse unique à cette question, qui dépend grandement du contexte de chaque entreprise, voire de chaque département.

D’autres solutions, davantage prêtes à l’emploi, auraient-elles plus de pertinence ?
Avant d’évoquer les alternatives à Kubernetes, il est intéressant de rappeler qu’une partie de l’administration des clusters K8s est confiée aux fournisseurs de Cloud, comme en témoigne à nouveau le sondage de la CNCF : 90% des clusters sont confiés à des fournisseurs de services managés (AKS, EKS, GKE, Scaleway Kapsule, OVHcloud Managed Kubernetes, Claranet Kubernetes...).

Cette délégation d’une partie de la charge de maintien en condition opérationnelle permet de gommer partiellement cette complexité, ainsi que le travail inhérent, historiquement confié aux équipes de production.

Portabilité et protection des données

En plus d’une livraison plus rapide (le fameux Time To Market) et un passage à l’échelle plus facile et rapide, un autre argument en faveur de Kubernetes est la portabilité d’une infrastructure A à une infrastructure B.

En effet, sur le papier, rien de plus simple que de déplacer un conteneur d’une plateforme à l’autre pour répondre à des problématiques de charge, de disponibilité ou pour optimiser les coûts en passant d’un fournisseur à l’autre.

Dans la pratique, l’opération s’avère beaucoup plus complexe. Une application, ou par extension un service, ne se limite pas simplement à un service sans état (ex : frontaux web), il dépend de données, généralement persistantes, qui devront être synchronisées.

La nature n’aimant pas le vide, des éditeurs ont saisi cette opportunité pour proposer des solutions de réplication permettant de basculer d’une plateforme K8s à une autre (ex : Veeam Kasten, Trilio ou encore PureStorage Portworx). A noter toutefois, un enjeu majeur subsiste sur la protection des données stockées dans ces clusters (ex : base de données hébergée dans le Cluster). Ces mêmes solutions prendront alors tout leur sens sur cette problématique de protection, là où la portabilité reste un argument qui à encore du mal à trouver son business case et donc à nous convaincre.

Un enjeu majeur de sécurité

Qui dit plus de complexité, dit également un accroissement du risque de sécurité, avec potentiellement de mauvaises configurations laissant échapper des accès trop permissifs aux plateformes.

La surface d’attaque est donc plus large, et nécessite de cadrer, durcir et surveiller ces nouvelles plateformes.

Sécurisation du cluster, analyse de vulnérabilité des images stockées dans le registre, ou encore celles présentes dans les conteneurs en cours de fonctionnement (runtime), …, ne sont que quelques exemples qui nécessitent une attention particulière de la part des équipes déployant et opérant ces environnements.

Au même titre que des notions telles que (FinOps, Full Observability, CI/CD..., l’écosystème K8s se dotent tous les jours de nouvelles solutions pour palier à ces nouveaux enjeux et à ce changement de paradigme.

Les alternatives

Le constat est clair, qu’en est-il des solutions actuellement disponibles qui pourraient gommer cette complexité ?

Il est acquis que packager l’application dans des images de conteneur offre plus d’avantages que d’inconvénients.
L’approche permet de déployer rapidement des patchs (sécurité, fonctionnels ou techniques) et offre ce caractère immutable qui garantit la reproductibilité sur l’ensemble des environnements (Dev, UAT, Staging/Preprod, Prod).

Des produits comme buildpacks.io permettent justement de construire une image de vos applications simplement et quasiment universelle, quelle que soit la plateforme de destination.

Ensuite on distinguera deux familles de produits :

• 1. Les purs PaaS proposant une solution clé en main extrêmement accessible permettant de déployer votre application en une fraction de temps. On pourrait lister Heroku (le précurseur), Platform.sh ou encore Fly.io plus récent.
• 2. Les multiples produits permettant d’exécuter des conteneurs avec des fonctionnalités et des niveaux d’abstraction pouvant varier d’un service à l’autre (AWS ECS/Fargate, AWS Elasticbeanstalk, Azure ACI, Azure Container App, Google Cloud Run…)

La première option est particulièrement pertinente quand votre application doit fonctionner comme une île - elle se suffit à elle-même-, ou si les interfaces avec le reste de votre IT sont limitées à des accès d’API dites publiques.

La deuxième option offre plus de souplesse et un meilleur contrôle sur ce qui se passe au détriment d’une charge plus importante pour construire et opérer l’infrastructure Cloud (ex : gestion des accès plus complexe, interconnexion réseau sécurisé entre les différentes zones...).

Les deux approches peuvent bien sûr cohabiter au gré des besoins de votre entreprise.

NB : le sondage CNCF est par définition biaisé car il s’adresse à une population qui a déjà connaissance de ces technologies, et par conséquent déjà sensible aux gains et difficultés associés. Il reste néanmoins une source très intéressante d’informations.

Source : https://www.cncf.io/wp-content/uploads/2022/02/CNCF-AR_FINAL-edits-15.2....

Cas d’usage : Cloud AWS, conteneurs et micro-services pour soutenir la croissance de Kizeo, Editeur SaaS

Kizeo accompagne en douceur la transition vers le cloud AWS et les micro-services, avec une solution conteneurisée, automatisée et collaborative pour sesapplications.

En savoir plus sur la REX Kizeo

Auteur : Adrien Pestel, CTO de Claranet France