Kubernetes est une plateforme open source. Vous pourriez donc penser qu’elle est indépendante des fournisseurs, ce qui signifie que vous pouvez facilement passer d’une implémentation de Kubernetes à une autre.
Mais vous auriez tort. En réalité, de nombreuses solutions Kubernetes, notamment celles qui sont liées à un cloud public spécifique, sont bien moins indépendantes des fournisseurs qu’on pourrait le penser.
Heureusement, cela ne signifie pas que vous ne pouvez pas tirer parti du cloud public comme solution d’hébergement de Kubernetes si vous souhaitez éviter toute dépendance vis-à-vis d’un fournisseur. C’est possible, mais vous devez concevoir votre stratégie Kubernetes de manière à ne pas être captif du service Kubernetes d’un fournisseur de cloud particulier, tout en continuant à bénéficier des avantages de Kubernetes dans le cloud.
Options Kubernetes basées sur le cloud
Aujourd’hui, tous les principaux clouds publics proposent des services Kubernetes hébergés reposant sur une architecture SaaS. Amazon propose Elastic Kubernetes Service. Azure fournit Azure Kubernetes Service. Google propose Google Kubernetes Engine. IBM dispose d’IBM Cloud Kubernetes Service.
Parce que ces services associent une infrastructure cloud à des logiciels qui facilitent l’automatisation du déploiement et de la gestion de Kubernetes, ils constituent une solution intéressante pour les organisations qui souhaitent être rapidement opérationnelles avec Kubernetes.
Risques de dépendance liés à Kubernetes dans le cloud
Le fait que ces services Kubernetes dans le cloud semblent indépendants de tout fournisseur renforce également leur attrait. À première vue, il peut sembler assez facile de passer d’une plateforme SaaS Kubernetes à une autre. Toutes ces plateformes reposent sur la version standard et open source de Kubernetes. Elles 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, elles paraissent relativement indépendantes des fournisseurs.
Cependant, en y regardant de plus près, on constate que les clouds publics qui proposent Kubernetes sous forme de service hébergé ne sont pas aussi flexibles et génériques qu’ils peuvent le paraître. Ils s’intègrent à d’autres services exécutés dans les clouds publics qui les hébergent et en dépendent de diverses manières. Vous devez créer des politiques IAM sur le cloud que vous utilisez pour gérer vos clusters Kubernetes. Vous pouvez être amené à utiliser des services propres à un fournisseur pour l’authentification, comme Azure Active Directory dans le cas d’Azure Kubernetes Service. Et dans de nombreux cas, les services Kubernetes privilégient certains outils complémentaires ou de remplacement, même s’ils ne les imposent pas à proprement parler. Par exemple, Google Kubernetes Engine vous incite à utiliser gke-deploy plutôt que kubectl, 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 identique quel que soit le cloud utilisé pour héberger Kubernetes, et même s’il est techniquement possible de s’en tenir à des outils génériques en faisant les efforts nécessaires, les outils et les configurations que vous finirez très probablement par utiliser ne sont pas indépendants du fournisseur. Ils sont propres au service Kubernetes que vous utilisez.
Cela constitue un obstacle majeur si vous souhaitez migrer, par exemple, d’Azure Kubernetes Service vers Google Kubernetes Engine. Même si vous pouvez transférer vos charges de travail Kubernetes telles quelles, vous ne pouvez pas en faire autant avec les chaînes d’outils et les fichiers de configuration qui les prennent en charge.
Évitez la dépendance à un fournisseur Kubernetes cloud
Si vous souhaitez profiter de la simplicité et de l’évolutivité du cloud public pour déployer des clusters Kubernetes sans pour autant être captif d’un fournisseur, deux solutions principales s’offrent à vous.
La première consiste à configurer manuellement vos propres clusters à l’aide de machines virtuelles dans le cloud, puis à les gérer vous-même. Avec cette approche, vous ne bénéficiez pas de l’automatisation ni des intégrations proposées par les offres Kubernetes SaaS des fournisseurs de cloud, mais vous disposez tout de même de l’infrastructure. Comme vous n’utilisez pas d’outils spécialisés, il est plus facile de migrer vos clusters d’un hébergeur cloud à un autre sans avoir à tout reconstruire. Bien entendu, l’inconvénient est que la configuration et la gestion de vos clusters nécessitent un travail manuel considérable.
L’autre approche, plus automatisée et évolutive, consiste à utiliser une solution telle que le service VoltStack® de Volterra pour gérer vos clusters, quels que soient les clouds sur lesquels ils sont hébergés. Avec cette stratégie, vous remplacez essentiellement les outils propres à la plateforme cloud de chaque fournisseur par un centre de commande et de contrôle centralisé compatible avec n’importe quel cloud public, ce qui facilite la migration ou la réplication des clusters entre différents clouds publics. Vous bénéficiez ainsi des mêmes capacités de gestion qu’avec des services tels que Google Kubernetes Engine et Azure Kubernetes Engine, sans être captif de clouds publics spécifiques.
Conclusion
Ne faites pas l’erreur de penser que Kubernetes reste identique, quel que soit l’endroit ou la manière dont vous l’exécutez. Il existe des différences majeures entre les divers services Kubernetes dans le cloud, qui peuvent entraver la portabilité des clusters Kubernetes d’un cloud à un autre (sans compter qu’elles compliquent la gestion de clusters sur différents clouds, chacun disposant de son propre ensemble d’outils).
La bonne nouvelle, c’est qu’il existe une solution : en utilisant une solution de gestion de Kubernetes indépendante du cloud, telle que le service VoltStack de Volterra, pour gérer l’ensemble de vos clusters, vous vous affranchissez de toute dépendance à un fournisseur de cloud particulier, tout en continuant à profiter de la simplicité d’utilisation de Kubernetes dans le cloud.
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.