Pourquoi Cloud Kubernetes n'est pas aussi indépendant des fournisseurs qu'il y paraît – et que faire à ce sujet ?

Kubernetes est une plateforme libre. Vous pourriez donc penser qu'elle est indépendante des fournisseurs, et qu'il est facile de passer d'une version de Kubernetes à une autre.

Mais vous auriez tort. La réalité est que de nombreuses solutions Kubernetes, en particulier celles qui sont liées à un cloud public spécifique, sont beaucoup moins indépendantes des fournisseurs que vous pourriez le penser.

Heureusement, cela ne signifie pas que vous ne pouvez pas profiter du cloud public en tant que solution d’hébergement Kubernetes si vous souhaitez éviter le verrouillage. Vous le pouvez, mais vous devez concevoir votre stratégie Kubernetes de manière à ne plus être lié au service Kubernetes d'un fournisseur de cloud particulier, tout en vous permettant de profiter des avantages de Kubernetes basé sur le cloud.

Options Kubernetes basées sur le cloud

Aujourd’hui, tous les principaux clouds publics proposent des services Kubernetes hébergés via une architecture SaaS. Amazon dispose du service Elastic Kubernetes. Azure fournit Azure Kubernetes Service. Google propose Google Kubernetes Engine. IBM dispose du service IBM Cloud Kubernetes.

Étant donné que ces services associent une infrastructure basée sur le cloud à un logiciel qui permet d’automatiser le déploiement et la gestion de Kubernetes, ils constituent une solution intéressante pour les organisations qui cherchent à être rapidement opérationnelles avec Kubernetes.

Risques de verrouillage du cloud Kubernetes

Le fait que ces services Kubernetes dans le cloud soient neutres renforce aussi leur attractivité. Vous pourriez penser qu’il serait simple de basculer d’une plateforme SaaS Kubernetes à une autre. Toutes ces plateformes utilisent Kubernetes standard, un logiciel libre. Elles vous donnent accès aux mêmes outils Kubernetes (comme kubectl) et prennent généralement en charge les mêmes types de configurations de stockage et réseaux. Dans ces conditions, elles apparaissent clairement indépendantes des fournisseurs.

Cependant, lorsque vous creusez plus profondément, vous réalisez que les clouds publics qui proposent Kubernetes en tant que service hébergé ne sont pas aussi flexibles et génériques qu'ils peuvent le paraître. Ils s’intègrent et dépendent de diverses manières d’autres services exécutés dans les clouds publics qui les hébergent. Vous devez créer des politiques IAM sur le cloud que vous utilisez pour gérer vos clusters Kubernetes. Vous pouvez finir par utiliser des services spécifiques au fournisseur, comme Azure Active Directory dans le cas d’Azure Kubernetes Service, pour l’authentification. Et dans de nombreux cas, il existe des outils complémentaires ou de remplacement que les services Kubernetes préfèrent que vous utilisiez, même s'ils ne les exigent pas strictement. Google Kubernetes Engine souhaite que vous utilisiez gke-deploy au lieu de kubectl, par exemple, tandis qu'Elastic Kubernetes Service est conçu pour être utilisé avec eksctl, l'outil propriétaire d'Amazon.

Ainsi, même si le code Kubernetes sous-jacent peut être le même quel que soit le cloud que vous utilisez pour héberger Kubernetes, et même si vous pouvez techniquement vous en tenir à des outils génériques si vous essayez vraiment, les outils et les configurations que vous finirez probablement par utiliser ne sont pas indépendants du fournisseur. Ils sont spécifiques au service Kubernetes que vous utilisez.

Cela crée un obstacle majeur si vous souhaitez passer, par exemple, d’Azure Kubernetes Service à Google Kubernetes Engine. Même si vous pouvez soulever et déplacer vos charges de travail Kubernetes, vous ne pouvez pas faire de même avec les chaînes d'outils et les fichiers de configuration qui les prennent en charge.

Évitez le blocage de Cloud Kubernetes

Si vous souhaitez profiter de la commodité et de l'évolutivité du cloud public lors du déploiement de clusters Kubernetes mais que vous ne voulez pas de verrouillage, il existe deux solutions de base.

L’une d’entre elles consiste à configurer vos propres clusters manuellement à l’aide de machines virtuelles basées sur le cloud, puis à les gérer vous-même. Avec cette approche, vous n’obtenez pas l’automatisation et les intégrations fournies avec les offres SaaS Kubernetes des fournisseurs de cloud, mais vous bénéficiez toujours de l’infrastructure. Étant donné que vous n’utilisez pas d’outils spécialisés, il est plus facile de migrer vos clusters d’un hôte cloud vers un autre sans tout reconstruire. Bien sûr, l’inconvénient ici est qu’il faut beaucoup d’efforts manuels pour configurer et gérer vos clusters.

L’autre approche, plus automatisée et évolutive, consiste à utiliser une solution comme le service VoltStack® de Volterra pour gérer vos clusters, quels que soient les clouds sur lesquels ils résident. Avec cette stratégie, vous remplacez essentiellement les outils spécifiques au cloud de la plate-forme de chaque fournisseur par un centre de commande et de contrôle centralisé qui fonctionne avec n'importe quel cloud public, ce qui facilite la migration ou la réplication de clusters entre différents clouds publics. Vous bénéficiez de la même facilité de gestion que celle dont vous bénéficieriez avec des services tels que Google Kubernetes Engine et Azure Kubernetes Engine sans être lié à des clouds publics spécifiques.

Conclusion

Ne faites pas l’erreur de supposer que Kubernetes est Kubernetes, peu importe où et comment vous l’exécutez. Il existe des différences majeures entre les différents services Kubernetes basés sur le cloud, ce qui peut entraver la portabilité des clusters Kubernetes d'un cloud à un autre (sans parler du fait qu'il est difficile de gérer les clusters sur différents clouds, car chacun dispose d'un ensemble d'outils différent).

La bonne nouvelle est qu'il existe une solution : en utilisant une solution de gestion Kubernetes indépendante du cloud comme le service VoltStack de Volterra pour gérer tous vos clusters, vous vous libérez de la dépendance à un fournisseur de cloud particulier tout en profitant de la facilité d'utilisation de Kubernetes basé sur le cloud.