Gartner estime qu’en 2022, 75% des organisations exécuteront des conteneurs en production.

Cela fait maintenant quelques années que l’on parle de micro-services, de solutions d’orchestrations pour conteneurs et de comment ces outils peuvent changer les projets de développements informatiques. L’objectif aujourd’hui n’est pas de revenir sur certaines notions fondamentales, mais de donner aux décideurs IT les bonnes questions à se poser et des pistes de réflexion pour intégrer au mieux la solution Kubernetes dans le SI de leur entreprise.

En effet, d’un point de vue technique, Kubernetes est complexe mais les offres managées telles qu’AKS le sont moins. C’est pour cela que nous vous invitons à prendre le problème dans le bon sens pour réellement vous poser les bonnes questions :

• Quel projet migrer en premier ?
• Quel écosystème privilégier en termes d’outillage ?
• Sous quel prisme aborder cette implémentation ?
• Comment maximiser les chances d’aller en production rapidement ?

Nous ne répondrons pas forcément à toutes les questions, mais il est important d’avoir en tête toutes ces pistes de réflexion.

Nous évoquerons donc les points suivants :

• Quelle offre choisir parmi les différentes possibilités existantes ?
• Quelle est la maturité des outils de la communauté ? Nous apporterons une première vision des solutions à mettre en place.
• Enfin, nous évoquerons plusieurs retours d’expériences sur différents sujets.

Quelle offre choisir ?

« Les organisations sous-estiment souvent l’effort pour opérer des conteneurs en production », (Gartner)

La première question à se poser est de savoir quel type de service d’orchestration Azure Kubernetes Services (AKS) je souhaite pour mon entreprise. En effet, il existe 3 grandes familles de solutions avec chacune leurs avantages et inconvénients.

Installer Kubernetes sur un environnement on-premise

La première solution est d’installer Kubernetes (ou K8S) sur un environnement on-premise sur des machines physiques / virtuelles ou sur le Cloud en mode IaaS. Cela permet d’avoir un contrôle complet sur la stack technique mais implique plus de responsabilités.

A noter : l’installation de K8S est longue, fastidieuse et nécessite de solides compétences (par exemple regarder comment installer K8s from scratch : https://github.com/mmumshad/kubernetes-the-hard-way).

De plus, il faut penser à avoir une équipe pour administrer les machines et un plan de mise à niveau continue . En effet, l’écosystème évolue constamment et une équipe dédiée est nécessaire pour suivre les dernières releases, tester les outils et surtout planifier les montées de versions pour assurer le support. Dans le cas des offres managées, c’est le Cloud Solution Provider (CSP) qui vous impose son rythme.

Installer Kubernetes via un fournisseur de Cloud public

La deuxième possibilité, qui est clairement la tendance actuelle, consiste à passer par un Cloud public provider :

• Amazon avec la solution Amazon EKS;
• Google avec GKE (Google Kubernetes Engine);
• Ou Microsoft avec AKS (pour les principaux).

Le gros avantage ici est qu’une grande partie de services sont managés pour vous : les nœuds (master et slaves) ainsi que le control plan API, qui constitue la partie centrale de Kubernetes. Sans elle, le cluster est tout simplement inopérant.

⚠️ Attention : chacun des Cloud providers possède ses propres spécificités. Par exemple, l’accès aux Azure Key Vaults n’est pas identique dans Azure que pour Google Cloud Platfom (GCP). Autrement dit : l’agnosticité apportée par Kubernetes est limitée dès lors que l’on interagit avec des ressources fournies par le Cloud provider. C’est pourquoi il faut être vigilant et choisir des interfaces de type CSI, ou se baser sur des solutions open-source par exemple. De manière simpliste, on ne peut pas transposer « As-Is » un cluster AKS vers GKE de manière simple.

Utiliser RedHat Open Shift (un exemple d’une solution sur étagère)

Enfin, dernière situation : l’entreprise souhaite limiter au maximum le travail d’administration ou avoir une réelle solution déployable facilement. On achète un écosystème sur étagère et on réutilise au maximum les composants fournis par le service. Il faut alors regarder vers RedHat Open Shift. L’interface d’administration y est simplifiée : tout est fait pour que l’application soit rapidement et facilement déployable, afin de bénéficier d’un time to market intéressant. Cependant, il faut garder en tête qu’ici l’entreprise aura une adhérence forte avec l’éditeur : il ne sera pas possible de sortir simplement de cette solution pour migrer vers l’un des deux scenarios précédents.

Pour vous faire un choix en résumé, voici un rapide récapitulatif :

Mesure de la maturité des outils de la communauté

Une fois l’offre choisie, l’étape suivante dépendra du type de population :

• Pour les décideurs/DevSecOps: choisir les outils à intégrer tout autour de votre orchestrateur.
• Pour les développeurs/Devops: se transformer pour savoir développer avec l’approche « micro-services ».

Pour les décideurs / DevSecOps

Tout d’abord, il importe d’adopter les bons réflexes pour les décideurs & DevOps, garants de la bonne intégration dans le SI. En effet aujourd’hui, intégrer K8s on-premise ou via des Cloud providers sans aucun outil tiers est une utopie. Quelle solution choisir pour la partie CI/CD ? Comment appliquer la gouvernance et les policies dictées par le service sécurité ou gérer les coûts ? Commet garder un certain niveau de contrôle sur les ressources mises à disposition des équipes de développement ? Fournir un environnement (cluster) Kubernetes à une ou plusieurs équipes de développement comporte des avantages (liberté, autonomie) mais il faut garder un certain niveau de contrôle (on parle de cluster multi-tenant).

Très vite, vous allez tomber sur la principale communauté : la Cloud Native Computing Foundation (CNCF), qui est un projet de la communauté Linux. C’est ici que se trouvent l’ensemble des produits que l’on peut implémenter selon plusieurs degrés de maturité : charge à vous de les choisir, de les tester ou de les ignorer. Le monde est immense : on s’y perd et cette carte vous permet de vous repérer. On dit souvent que Kubernetes est un Cloud dans le Cloud : sans repère, difficile de s’en sortir !

Nous vous recommandons vivement de jeter un œil à la vision globale. Toutes les solutions y sont regroupées par thème : développement d’application, base de données, intégration logicielle, services d’infrastructure (proxy, mesh, sécurité).

Source : CNCF Landscape

Vous pouvez cliquer sur chaque solution afin d’obtenir plus d’informations telles que :

• Description succincte ;
• Langage sur lequel repose la solution ;
• Activité GitHub (pour savoir si la communauté est active) ;
• Maturité au sein de la CNCF : Graduated, incubating ou Sandbox.

Bref, avant de faire son choix, il est indispensable de se renseigner et ce portail est la porte d’entrée.

Pour la communauté des Développeurs

Les développeurs doivent absolument s’approprier les 12 principes édictés par « The twelve-Factor App ». Développer des solutions avec une approche micro-service est différent de ce que l’on a pu avoir par rapport au mode on-premise ou IaaS : on pense plus serverless, microcomposants, scalabilité et résilience. Ce document oriente les équipes sur les thématiques telles que la gestion de la configuration, la gestion du contrôle de code source et des dépendances, les services externes, la robustesse, la gestion des environnements. Bref, on peut avoir l’environnement K8s le plus optimisé et qui réponde au besoin, mais si on ne respecte aucun de ces facteurs, le projet est voué à l’échec.

Voici les principes recommandés pour adopter un environnement Kubernetes dans le SI :

• Choisir un projet peu critique pour commencer ;
• Identifier l’équipe en fonction des appétences ;
• Se mettre d’accord sur un planning ambitieux mais réaliste;
• Choisir les outils à intégrer qui correspondent au besoin : inutile de trop en mettre…
• Procéder par itération.

La solution technique doit toujours être au service d’un besoin business et non l’inverse. C’est fondamental.

 

Retours d’expériences sur la mise en place de Kubernetes

Partageons à présent quelques retours d’expériences en termes d’approche et d’outillage.

Il faut avoir une approche par itération, avec des échéances de 2 à 4 semaines dans lesquelles les objectifs sont clairs et partagés par un maximum d’acteurs de l’entreprise : développeurs, managers, DevOps, sécurité, infra… Plus il y aura du monde, mieux ce sera. De plus, bénéficier d’un engagement fort de la part d’un sponsor haut placé est primordial.

DevOps

La partie relative à l’Infrastructure as Code (IaC) est importante. C’est pour cela que nous avons utilisé Terraform pour la création de ressources Azure, associé à Jenkins ou Azure Devops. Pour ce qui concerne les Registry, le choix logique lorsqu’on est dans l’écosystème Microsoft est d’utiliser Azure Container Registry (ACR), mais on peut aussi utiliser Harbor qui est indépendant du Cloud provider. Il a aussi l’avantage de stocker des charts Helm et réaliser des scans de sécurité.

Enfin, pour K8s, ArgoCD a été déployé : à chaque fois qu’un commit sur un manifeste YAML a lieu, la configuration est automatiquement déployée sur le cluster (nous vous invitons à consulter notre article sur le CI/CD qui aborder cette thématique). Par exemple, créer des pipelines Jenkins pour réaliser le provisionning réseau et un autre pour la création de cluster AKS. Ce que nous avons fait chez un client est d’adopter l’approche Blue/Green d’un point de vue infrastructure pour les montées de version de Kubernetes. Tous les 3 à 5 mois, nous leur mettons à disposition un nouveau cluster dans lequel les équipes de développements doivent migrer les applicatifs. Un accompagnement est nécessaire lors de l’onboarding pour leur expliquer les bonnes pratiques et les éléments du support, leur présenter l’architecture, etc.

Sécurité

Parler de la sécurité dans K8s est un vaste sujet. En effet, la sécurité concerne l’authentification RBAC pour accéder aux API masters, le scan des images dans les registries, le principe de least privilege dans les pods, la configuration de Open Policy Agent (OPA), la bonne configuration des Ingress controlers ou encore le stockage des secrets/certificats/clés dans les services managés tels qu’Azure Key Vault… C’est pourquoi nous recommandons d’intégrer les équipes de sécurité au plus tôt dans le processus de conception pour implémenter les bonnes pratiques.

Finops

La refacturation par équipe des ressources K8s est un sujet à part entière. En effet, si chaque projet possède son propre cluster, le calcul est simple. Mais quid des clusters multi-projets ? Doit-on refacturer par nœud ? Par namespace ? Et comment faire pour les ressources partagées telles que le réseau, les comptes de stockage ou les base de données ? Pour cela, nous recommandons Kubecost : cet article vous sera d’une grande aide pour alimenter votre réflexion.

Policies

Avant de mettre à disposition les clusters aux équipes projets, un certain nombre de composants techniques sont installés dans des namespaces dédiés. En effet, voici une liste (non exhaustive) d’éléments :

• Mettre des webhooks pour contrôler que les images proviennent de registry validés par l’entreprise ;
• Installer Open Policy Agent pour intégrer vos propres règles avant de créer des objets Kubernetes (sur la gestion du réseau, des droits utilisateurs, des droits OS, etc.). Cet outil est désormais parfaitement intégré à la plateforme Microsoft par exemple ;
• Kiosk est également une bonne option pour une meilleure gestion de la sécurité de vos namespaces ;
• Enfin bien sûr, pensez à mettre des policies propres à votre Cloud provider pour éviter par exemple que les équipes puissent modifier la taille des nodes pools ou s’octroyer plus de droits que ceux fournis par l’équipe sécurité. Sur Azure, l’installation de blueprint contenant des Azure policies est un bon choix.

Accompagnement des équipes

Un accompagnement des équipes de développement est primordial : si vous voulez faciliter l’adoption de K8s, il faut impliquer ces équipes et leur montrer que les développements seront facilités et sécurisés. Par exemple, nous conseillons d’organiser toutes les deux semaines des sessions d’onboarding au cours desquelles vous présenterez l’architecture, ce que peuvent faire les équipes lorsqu’elles auront un cluster à disposition, les éléments techniques qu’elles pourront utiliser (ingress controler, registres privés, les synchronisations des secrets/certificats, accès aux bases de données…).

Ne pas oublier également de leur fournir du support, de la documentation et si besoin, organiser des réunions d’aide adaptées et personnalisables. Fournir un cluster doit donner aux équipes suffisamment de libertés pour fournir de la valeur rapidement (c’est-à-dire du code répondant à un besoin métier) : c’est là que votre succès interviendra.

Liens utiles :

• https://containerjournal.com/topics/container-ecosystems/gartners-6-best-practices-for-containers-kubernetes/
• https://devstats.cncf.io/pour suivre les activités sur github

Pour aller plus loin sur Kubernetes

Pour mettre en pratique tout ce que vous avez appris au cours du Mois du Conteneur, Cellenza vous propose de voir le replay du webinaire de clôture. Pendant une heure, Benoît Sautière (Senior Technical Officer chez Cellenza), Stanislas Quastana (Cloud Solution Architect chez Microsoft) et Louis-Guillaume Morand (Cloud Solution Architect chez Microsoft) vous présentent les différentes étapes à suivre pour adopter Kubernetes dans votre entreprise !

Retrouvez également tous les articles du Mois du Conteneur :

• Un mois pour tout savoir sur Kubernetes
• Kubernetes au service de votre stratégie applicative
• Kubernetes : un écosystème à construire
• Stratégie de CI/CD sur Kubernetes
• Mettre en place sa stratégie de migration vers Kubernetes
• Comment intégrer Kubernetes dans sa stratégie de monitoring ?
• Sécuriser son service Kubernetes

Tous ces articles sont compilés dans un livre blanc téléchargeable gratuitement.