Le web d’aujourd’hui passe beaucoup par le cloud, privé, public ou encore hybride, et ce pour de nombreuses raisons économiques, de simplicité de management, d’autonomie des équipes et j’en passe.

Dans beaucoup de cas, on a tendance aujourd’hui à abandonner les sempiternelles machines virtuelles, lourdes et difficiles à faire évoluer, scaler, maintenir, etc…

Kubernetes, un outil de management de conteneurs

Au profit des conteneurs, petites unités d’exécutions permettant d’atteindre des niveaux de scalabilité et de rapidité de déploiement que les VMs traditionnelles ont du mal à égaler. Et dans la catégorie des outils permettant de déployer et manager de nombreux conteneurs en production, Kubernetes est souvent abordé immédiatement comme l’outil à utiliser. Présent dans les systèmes d’informations des plus petites aux plus grandes entreprises, Kubernetes a en effet réussi à s’imposer comme la technologie de prédilection lorsque l’on parle de management de conteneurs.

Du fait de sa nature et des limitations que la technologie impose, de nombreuses grandes entreprises ont parfois la volonté de créer plusieurs clusters Kubernetes au sein de leur système d’information, que ce soit pour des raisons de sécurité, de partitionnement, de séparation de responsabilité ou d’équipes, de nombreuses raisons peuvent amener une équipe à vouloir répartir les applications de leur entreprise dans différents clusters, les isolant de fait. Cependant, il peut arriver que, malgré cette isolation, on veuille pouvoir faire communiquer entre eux différents services présents dans différents clusters.

La solution la plus simple serait d’exposer les services du cluster B auquel le cluster A doit avoir accès internet/intranet, et éventuellement de sécuriser le tout avec des règles de firewall. C’est une solution simple et peu coûteuse à mettre en place…. mais pas à maintenir, car si tous les services que l’on veut exposer d’un cluster à un autre demandent les mêmes manipulations…. et que se passe-t-il lorsque l’on a 6 clusters avec des services qui veulent pouvoir communiquer entre eux ? Cela devient rapidement ingérable.

Heureusement, un outil existe aujourd’hui permettant la communication inter-cluster, le tout sans faire de mic-macs réseau : Submariner.

Comment Submariner permet la communication inter-cluster ?

Submariner est un outil permettant l’interconnexion de clusters Kubernetes, exposant des services d’un cluster au sein d’un autre, rendant de fait accessibles les applications déployées dans le premier cluster depuis les applications du deuxième.

Sans rentrer dans les détails techniques du fonctionnement ou de la mise en place de l’outil, une fois installé dans plusieurs clusters Kubernetes, il permet en une commande d’exposer un ou plusieurs services d’un cluster dans les autres, le rendant accessible de partout sans connexion directe, tout en bénéficiant de la résolution de DNS native de Kubernetes.

L’outil se déploie facilement dans un cluster existant en utilisant le CLI de submariner, qui installera un opérateur (CRDs) dans les différents clusters, qui s’occupera de gérer le déploiement de Submariner, facile !

Question monitoring, Submariner s’entend parfaitement bien avec Prometheus, probablement déjà en place dans votre cluster, et permet l’exposition d’informations comme le nombre de services, partagés, le nombre de connexion entre clusters ou encore le volume de données échangé par deux clusters autour d’un service donné, etc…

Côté compatibilité, l’outil est étudié pour être agnostique, sensé fonctionner partout, et a été testé avec les principaux drivers réseau utilisés pour la création de clusters Kubernetes.

Des outils sécurisants

Dans un contexte où Kubernetes est amené à être de plus en plus utilisé, et les applications déployées dessus de plus en plus regardantes en matière de sécurité, il est important de s’armer de tous les outils qui peuvent nous aider dans notre travail, les opérations d’audit et de sécurisation des clusters étant souvent faites à la main, il est important de les intégrer au plus tôt dans la création des clusters.

Des outils comme Submariner permettent d’apporter une sécurité supplémentaire à la conception de notre SI en permettant l’interconnexion et le monitoring de services qui ne pourraient normalement communiquer entre eux que dangereusement via une exposition externe au cluster.

© Julien PONTILLO | Consultant & expert Klanik