Passez quelques minutes avec l'un de nos experts techniques Red Hat, Matthieu Rethers, alors qu'il discute des avantages et des inconvénients des clusters gérés, ainsi que des différences entre eux sur diverses plates-formes cloud, quand vous devriez les utiliser, des alternatives aux clusters, et comment Red Hat OpenShift s'intègre dans l'image.
Quand les développeurs doivent-ils utiliser des clusters gérés?
C'est une question sans intérêt pour les développeurs car, de leur point de vue, il est toujours géré que ce soit par votre organisation ou un IaaS vendeur. Mais je dirais que l'objectif principal d'un développeur est la livraison, donc tout ce qui les aide à le faire plus rapidement est en or. C’est la même raison pour laquelle nous ne programmons plus en assemblage – nous avons construit ces couches d’abstraction afin de pouvoir nous concentrer sur les différenciateurs et la valeur commerciale. De plus, je ne pense pas que de nombreux développeurs sous pression souhaitent passer des semaines à apprendre à déployer un cluster Kubernetes, donc pour eux, la gestion est définitivement la voie à suivre.
Beaucoup ont déjà appris à faire confiance aux fournisseurs IaaS avec leur matériel pour les gens de l'infrastructure, donc le logiciel est la prochaine étape logique. Un service géré: 1) leur donne la possibilité de se familiariser avec la technologie et de se forger une opinion au fil du temps, peut-être au point où ils se sentiraient à l'aise de prendre le relais; 2) réduit leurs dépenses en capital; et 3) leur permet presque immédiatement, de se concentrer sur d’autres éléments critiques comme l’automatisation, la sécurité, la fiabilité, etc.
En ce qui me concerne, je recommanderai toujours l’approche gérée en premier, puis l’évaluerai. Mais j'admets qu'il y a des moments où avoir un contrôle complet est une exigence – mais rappelez-vous que géré ne veut pas dire scellé non plus. Vous pouvez toujours configurer beaucoup de choses vous-même.
Quels sont les avantages et les inconvénients de tirer parti d'un cluster géré sur Amazon EKS, Google Kubernetes Engine (GKE) et Azure Kubernetes Service (AKS)?
Comme avec tout service géré, vous bénéficiez de nombreux avantages dès la sortie de la boîte. Une organisation qui est nouvelle dans Kubernetes peut être productive immédiatement. Si tout ce que vous voulez faire est d'exécuter quelques services Java sur votre cluster et que l'on vous dit que cela prendra deux semaines avant de pouvoir les publier dans un environnement de production, vous pouvez reconsidérer l'utilisation de conteneurs pour le moment. Pour être honnête, l'installation de Kubernetes est devenue beaucoup plus facile au cours des deux dernières années, mais toute charge de travail de production aura des exigences au-delà des bases, et vous perdrez cet élan initial.
Si vous êtes nouveau dans le cloud, ceux-ci sont gérés services vous permettront de sauter quelques étapes et de vous concentrer principalement sur Kubernetes. Si, en revanche, vous utilisez déjà un fournisseur de cloud, vous aurez l'impression d'utiliser n'importe quel autre service. Maintenant, si vous vous interrogez sur un cluster autogéré sur site, ce sera un parcours cahoteux – je ne considérerais même pas cela comme une option si vous essayez d'entrer rapidement dans des conteneurs.
Avantages divers des services gérés incluent:
- Mises à niveau de cluster
- Approche prescriptive
- Provisionnement facile (EKS s'intègre désormais à Fargate mais surveillez les limitations comme le stockage)
- Intégration avec d'autres services du fournisseur
Maintenant, la grande préoccupation devrait être verrouillage du fournisseur. Étant donné que Kubernetes est très flexible, les fournisseurs doivent faire plusieurs choix pour fournir un service de qualité production, donc si vous n'aimez pas ces choix à l'avenir, il ne sera peut-être pas facile de revenir à un cluster autogéré. ou transférer à un autre fournisseur. Vous êtes également à la merci du fournisseur pour les mises à niveau et la disponibilité des fonctionnalités – la plupart d'entre elles seront en retard et ne fourniront que le dénominateur le plus courant, et c'est compréhensible. Pour les situations non nouvelles, cela pourrait même ne pas être une bonne solution, pour commencer.
Existe-t-il des différences majeures entre le fonctionnement des clusters gérés sur ces plates-formes?
Il existe quelques différences, car les fournisseurs essaieront de configurer les clusters Kubernetes de manière à s'intégrer à leurs autres services, et c'est une bonne chose – de cette façon, c'est un guichet unique pour tous les besoins d'infrastructure. Ils exécutent différentes versions du moteur et des fonctionnalités et regroupent les fonctionnalités différemment selon le point de vue et les meilleures pratiques. Assurez-vous que vous êtes à l'aise avec ces choix car, comme je l'ai déjà dit, une fois que vous êtes engagé auprès d'un fournisseur, il peut être difficile de changer. Bien sûr, si vous utilisez actuellement des produits IBM ou Microsoft, ils facilitent considérablement la transition, c'est donc certainement quelque chose qui pèsera lourd dans la balance. La plupart des IaaS ont des niveaux gratuits – je recommande fortement d'essayer avant d'acheter, et parfois, cela se résume simplement à des sentiments.
Quelles alternatives sont disponibles aux clusters gérés?
Kubernetes est de plus en plus facile à installer et prend en charge un large une gamme d'options de déploiement allant des environnements bare-metal aux environnements virtualisés en passant par le cloud, l'autogestion est donc toujours une option.
Pour les applications nouvelles, vous n'aurez pas à faire face à toutes les contraintes d'une ère pré-conteneur, et vous devriez pouvoir démarrer rapidement. Si vous avez beaucoup d'héritages à gérer, les choses peuvent devenir un peu risquées.
Maintenant, si vous avez déjà beaucoup investi dans votre infrastructure bare metal, l'autogestion est un bon moyen d'en tirer parti et d'en tirer le meilleur parti. dernier dépôt de vos machines. Si vous avez de la chance et que vous disposez déjà d'un environnement virtualisé solide, vous aurez une bonne longueur d'avance.
Où OpenShift, une plate-forme de conteneurs, s'intègre-t-il dans ces autres options?
OpenShift est une plate-forme d'entreprise de Red Hat qui exécute Kubernetes en son cœur. J'aime penser à Kubernetes comme Tony Stark et OpenShift comme Iron Man. Vous avez le cerveau génial, mais habillez-vous, et maintenant vous pouvez aller faire sauter des vaisseaux extraterrestres géants dans des galaxies lointaines.
Comme je l'ai déjà expliqué, Kubernetes seul ne suffit pas – vous avez besoin de sécurité, de réseautage, de journalisation, de surveillance, intégration avec votre infrastructure cloud, etc. La plupart du temps, vous en obtenez une forme ou une autre via le service géré dans IaaS, mais vous êtes confiné aux frontières du fournisseur.
OpenShift offre tout cela et plus encore, mais dans un cloud – mode diagnostique. Vous pouvez également l'exécuter sur votre propre infrastructure sur site ou dans le cloud. Étant donné que toutes ces fonctionnalités sont encapsulées dans le cluster lui-même, vous pouvez facilement déplacer l'ensemble de votre infrastructure d'un cloud à un autre, et vous pouvez faire du multi-cloud. Le principal avantage est que vous ne devez l'apprendre qu'une seule fois et appliquer les mêmes principes partout où vous allez.
N'oubliez pas que les fournisseurs de cloud ne font pas partie du secteur des logiciels. Ils utilisent généralement des outils créés par d'autres personnes et les conditionnent de manière à les aider à vendre davantage de services d'infrastructure. C’est formidable, mais l’objectif de Red Hat, en revanche, est de fournir un excellent outil quel que soit votre environnement, et leur engagement à long terme envers Open signifie qu’il n’ya pas de verrouillage. En fait, de nombreuses améliorations d'OpenShift le ramènent au projet Kubernetes en amont et éventuellement à EKS, AKS et autres. Il est très révélateur que tous les principaux fournisseurs de cloud proposent désormais un service OpenShift géré dans leur catalogue.
En passant, les raisons de gérer la gestion sont les mêmes que celles énumérées ci-dessus, mais OpenShift est livré avec de nombreuses options dès la sortie de la boîte, la courbe d'apprentissage n'est donc pas un facteur aussi important si vous décidez de vous autogérer. Dans le cloud, les coûts initiaux seront plus élevés que ceux d'EKS, GKE ou AKS, mais les licences OpenShift sont probablement une goutte d'eau dans la plupart des organisations, à partir d'environ 20 000 $ lorsque vous apportez votre propre infrastructure. Lorsque vous considérez ce que vous obtenez en retour, cela devrait être une évidence (une étude montre un retour sur investissement supérieur à 500%) – il s'agit de la plate-forme d'entreprise.
Une dernière réflexion?
Sachez simplement que l'exécution d'un cluster Kubernetes à grande échelle seul, ce n'est pas une promenade dans le parc – ne vous laissez pas berner par l'apparente simplicité de cette vidéo «bonjour le monde» sur YouTube. Bien sûr, vous pouvez faire fonctionner rapidement un cluster n'importe où, mais il y a beaucoup de choses à considérer pour passer de ce premier service à l'exécution de n'importe quoi dans un environnement de production.
Il y a une raison pour laquelle les fournisseurs peuvent facturer un supplément pour ces services. À moins que vous n'ayez déjà une équipe d'experts en Kubernetes (et je suppose que vous ne liriez pas ceci si vous le faisiez), comptez passer beaucoup de temps et d'argent à vous mettre à niveau. Il s’agit certainement de bien plus qu’un abonnement à un service géré, et si les choses tournent mal, vous êtes seul.
Donc, s'il y a une chance que vous puissiez être géré, faites-le. Notre équipe d'experts est là pour vous aider.
Source link