Quelles raisons poussent les entreprises à déployer de multiples clusters Kubernetes dans divers fournisseurs de cloud ?

Nicolas Massé : Je dirais que la première raison concerne les contraintes réglementaires. De nombreux secteurs comme la Défense ou la Santé sont en effet tenus de stocker et traiter les données à des endroits différents pour des raisons, entre autres, de confidentialité et de souveraineté. En effet, certains hébergeurs mutualisent le stockage et le traitement des données clients. Le déploiement de multiples clusters découle donc avant tout des usages. En témoignent les domaines de la télécommunication où les consommateurs souhaitent bénéficier de temps de latence extrêmement faibles pour visionner leurs vidéos ou jouer en ligne.  Il y a également des enjeux autour de la disponibilité des applications et de la résilience des données. Aussi, le fait de scinder les clusters permet de moins impacter les applications en cas d’indisponibilité ou d’incidents.  En déployant les applications sur plusieurs cloud providers, on s’assure ainsi la portabilité des applications et de la flexibilité quant aux choix entrepris.

Pourquoi les entreprises qui déploient des clusters veulent-elles automatiser ce déploiement ?

Nicolas Massé : On a constaté chez nos clients deux grands besoins. Le premier est de pouvoir livrer aux équipes de développement des clusters par projet. Auparavant, on déployait un unique cluster pour l’ensemble de la société mais cette logique ne correspond plus aux besoins actuels des développeurs qui ont besoin de plus d’autonomie. Aussi, en déployant de plus en plus de clusters, le système d’information s’agrandit, ce qui rend difficile de gérer autant d’éléments en même temps avec les mêmes ressources. C’est dans des cas d’usage comme celui-ci que l’automatisation prend tout son sens car elle permet de libérer des ressources, mais aussi de travailler sur d’autres projets et ainsi d’accompagner la croissance de l’entreprise. 

Quelles sont les caractéristiques d’une distribution Kubernetes multi-cloud ?

Nicolas Massé : Une première caractéristique est la capacité à s’abstraire des services sous-jacents du fournisseur de cloud. Quand une entreprise déploie des projets dans Amazon ou Google, ces derniers vous incitent fortement à utiliser leurs services additionnels : “base de données as a service”, des systèmes de login et autres applicatifs en tout genre. Pour ces géants, l’idée est de se démarquer de la concurrence et de fidéliser le client car ces services sont spécifiques à chaque cloud provider, il devient donc difficile de changer de fournisseur si vous utilisez ces services.  Red Hat offre une couche d’abstraction qui permet à tous les clients d’avoir un ensemble de services communs, une même interface et de consommer les différents services de cloud providers sans en être dépendant. C’est aussi pour le client une facilité car il n’a pas à reconstruire lui-même toute cette pile logicielle, Red Hat la lui fournit clé en main, ce qui lui fait gagner du temps.

La deuxième caractéristique concerne la pile logicielle qui sert à s’abstraire du cloud provider et qui doit être de qualité, car l’objectif est de pouvoir passer de l’un à l’autre et de déplacer les applications sur différents fournisseurs en fonction de la disponibilité et de la charge de travail.

Dernière caractéristique : la réversibilité vers les centres de données on-premise. Même si ce n’est pas dans l’air du temps, ils peuvent être compétitifs donc il est important de laisser cette porte ouverte. On peut donc aller dans le cloud public et rapatrier la charge applicative dans le datacenter si c’est nécessaire.

Quel outillage est nécessaire pour gérer une flotte de clusters Kubernetes à large échelle ?

Nicolas Massé : Pour gérer une flotte de clusters Kubernetes à large échelle, un certain nombre de fonctionnalités sont nécessaires. Premièrement, l’observabilité, à savoir la capacité de collecter des données d’utilisation et de performance du cluster au travers de toute la flotte et à les présenter de manière unifiée. En un coup d'œil, il doit être possible de consulter la santé des clusters, l’usage des ressources et les éventuels ajouts de ressource et de capacité à programmer si l’occasion se présente.

Ensuite, nous avons le déploiement à la volée car lorsque les équipes applicatives ou de développement déploient leurs logiciels, elles n’ont pas connaissance du nombre de clusters sur lequel ils vont être déployés ni de la façon dont elles vont le déployer. Il faut donc prévoir des interfaces en libre-service, souvent programmatiques qu’on appelle aussi des API. Elles vont permettre à ces équipes de développement de programmer leur déploiement applicatif de façon automatisée. Au final, on a une chaîne de déploiement qui automatise la construction de l'application et son déploiement de bout en bout.

De la même manière, les mises à jour Kubernetes sont automatiquement télé-déployées sur tous les clusters, ce qui évite aux administrateurs d’effectuer ces tâches manuellement.

Comment se déroule la construction et le déploiement d’une application multi-cloud ?

Nicolas Massé : Le voyage vers le multi-cloud commence dès la conception de l’application. Cela implique le respect des 12 facteurs (12factor.net/fr) comme préalable pour avoir une application portable et déployable n’importe où. Mais c’est aussi concevoir l’application en regard des théories fondamentales de l’informatique comme le théorème CAP qui nous dit qu’entre la cohérence, la disponibilité et la tolérance aux partitions, on ne peut en avoir que deux sur trois. La base de données relationnelle n’a une place moins prépondérante dans le cloud et elle est complétée par des technologies de NoSQL, de flux d’évènements (Kafka pour ne pas le nommer), de grille de calcul “in-memory”.

Plus globalement, la construction et le déploiement de l’application se font très classiquement à l’aide de pipelines automatisés. Dans le monde du multi-cloud, les technologies diffèrent. Pour l’intégration continue, on utilise des technologies Kubernetes-native telles que Tekton.Alors que pour le déploiement continu, des processus de type “GitOps” sont utilisés en complément d’un outillage de type ArgoCD.

Comment assurer la sécurité du système d’information si l’on multiplie les points d’entrée ?

Nicolas Massé : Les outils et pratiques de sécurité telles que nous les connaissons aujourd’hui ne sont pas adaptés et il convient d’en changer. Le premier changement à opérer est au niveau des pratiques : inclure la sécurité dès les phases de développement (“shift left” en anglais). Cela consiste à intégrer les bonnes pratiques de sécurité, la détection de vulnérabilités dans les pipelines d’intégration et de déploiement continus, ce qui implique de laisser une certaine liberté aux développeurs, mais en contrepartie, l’équipe sécurité gagne en visibilité.

Le second changement est au niveau de l’outillage. Pour gérer la sécurité des clusters et des applications à large échelle, il faut se doter d’un tableau de bord central permettant de :

  • Détecter les vulnérabilités présentes dans l’orchestrateur sous-jacent mais aussi dans les applications déployées.
  • Détecter les applications au comportement anormal, signe d’une possible intrusion dans le système d’information, et lever une alerte.
  • Cartographier les flux réseaux applicatifs, les catégoriser (légitime / anormal) et télé déployer les règles de firewall (Network Policies).
  • Mener des audits de conformité automatisés vis à vis de standards de sécurité tels que PCI-DSS, CIS Kubernetes, NIST, HIPAA, etc. et suivre jour après jour, application par application l’évolution de cette conformité.
  • Et enfin, cela comprend également une analyse multicritère de chaque application afin de jauger le niveau de risque de chaque application. L’idée étant de faire porter ses efforts en priorité sur les applications les plus risquées. Et c’est tout l’intérêt de la solution “Advanced Cluster Security” que commercialise Red Hat !