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 open source. Vous pourriez alors penser qu'il s'agit d'une plate-forme indépendante du fournisseur, ce qui signifie que vous pouvez facilement passer d'une implémentation 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 cloud Kubernetes semblent agnostiques augmente également leur attrait. À première vue, il peut sembler qu’il serait assez facile de passer d’une plateforme SaaS Kubernetes à une autre. Toutes ces plateformes sont basées sur Kubernetes standard et open source. Ils 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 de réseau. Sous cet angle, ils semblent assez indépendants 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.