K8s/Kubernetes : AWS contre GCP contre Azure

Kubernetes (souvent stylisé « K8 ») a remporté la bataille des outils d'orchestration de conteneurs il y a des années. Néanmoins, il existe encore de nombreuses façons de mettre en œuvre Kubernetes aujourd'hui et de le faire fonctionner avec diverses infrastructures et de nombreux outils, certains mieux entretenus que d'autres. Cependant, le développement le plus intéressant à cet égard est peut-être que les principaux fournisseurs de cloud ont décidé de publier leurs propres versions gérées de Kubernetes :

• Microsoft Azure propose le service Azure Kubernetes (AKS)
• AWS propose le service Amazon Elastic Kubernetes (EKS)
• Google Cloud propose le moteur Google Kubernetes (GKE)

D'un point de vue DevOps, que proposent ces plateformes ? Tiennent-ils leurs promesses ? Comment se comparent leur temps de création et d'autres repères ? Dans quelle mesure s'intègrent-ils à leurs plates-formes respectives, en particulier leurs outils CLI ? Qu'est-ce que ça fait de les entretenir et de travailler avec eux ? Ci-dessous, nous allons approfondir ces questions, et plus encore.

Remarque : Pour les lecteurs qui souhaitent que les concepts d'un cluster Kubernetes soient expliqués avant de poursuivre leur lecture, Dmitriy Kononov propose une excellente introduction.

AKS contre EKS contre GKE : fonctionnalités annoncées

Nous avons décidé de regrouper les différentes fonctionnalités disponibles pour chaque version managée de Kubernetes en silos :

• Présentation globale
• La mise en réseau
• Évolutivité et performances
• Sécurité et Surveillance
• Écosystème
• Tarification

Remarque : ces détails peuvent changer au fil du temps, car les fournisseurs de cloud mettent régulièrement à jour leurs produits.

Présentation globale

Kubernetes lui-même était le projet de Google, il est donc logique qu'ils aient été les premiers à proposer une version hébergée en 2014.

Sur les trois comparés ici, Azure était le suivant avec AKS et a eu un peu de temps pour s'améliorer : si vous vous souvenez d'acs-engine, qui avait été utilisé pour provisionner Kubernetes sur Azure il y a quelques années, vous apprécierez les efforts de Microsoft pour son remplacement, aks-moteur.

AWS a été le dernier à déployer sa propre version, EKS, il peut donc parfois sembler être en retard sur le front des fonctionnalités, mais ils rattrapent leur retard.

En termes de prix, bien sûr, les choses bougent toujours, et Google a décidé de rejoindre AWS dans son prix de 0,10 $/heure, à compter de juin 2020. Azure est l'outsider ici en offrant gratuitement le service AKS, mais on ne sait pas comment longtemps que cela peut durer.

Une autre différence principale réside dans la fonctionnalité de mise à niveau du cluster. Les mises à niveau les plus automatisées se trouvent dans GKE et sont activées par défaut. Cependant, AKS et EKS sont similaires ici, en ce sens que les deux nécessitent des demandes manuelles pour pouvoir mettre à niveau les nœuds maître ou travailleur.

La mise en réseau

Côté réseau, les trois fournisseurs de cloud sont très proches les uns des autres. Ils permettent tous aux clients de mettre en œuvre des politiques de réseau avec Calico, par exemple. Concernant l'équilibrage de charge, ils implémentent tous leur intégration avec leurs propres ressources d'équilibrage de charge et donnent aux ingénieurs le choix de ce qu'ils doivent utiliser.

La principale différence constatée ici repose sur la valeur ajoutée du maillage de services. AKS ne prend en charge aucun maillage de service prêt à l'emploi (bien que les ingénieurs puissent installer manuellement Istio). AWS a développé son propre maillage de services appelé App Mesh. Enfin, Google a publié sa propre intégration avec Istio (bien qu'encore en version bêta) que les clients peuvent ajouter directement lors de la création du cluster.

Meilleur pari : GKE

Évolutivité et performances

En ce qui concerne les performances et l'évolutivité de GKE par rapport à AKS par rapport à EKS, GKE semble être en avance. En effet, il prend en charge le plus grand nombre de nœuds (5 000) et propose une documentation complète sur la manière de dimensionner correctement un cluster. Toutes les fonctionnalités de haute disponibilité sont disponibles et faciles à ajuster. De plus, GKE a récemment publié Anthos, un projet visant à créer un écosystème autour de GKE et de ses fonctionnalités ; avec Anthos, vous pouvez déployer GKE On-Prem.

AWS a cependant un avantage clé : c'est le seul à autoriser les nœuds bare-metal à exécuter votre cluster Kubernetes.

Depuis juin 2020, AKS manque de haute disponibilité pour le maître, ce qui est un aspect important à prendre en compte. Mais, comme toujours, cela pourrait bientôt changer.

Meilleur pari : GKE

Sécurité et Surveillance

En termes de conformité, les trois fournisseurs de cloud sont équivalents. Cependant, en termes de sécurité, EKS et GKE offrent une autre couche de sécurité avec leurs services de gestion de clés intégrés.

En ce qui concerne la surveillance, Azure et Google Cloud fournissent leur propre écosystème de surveillance autour de Kubernetes. Il convient de noter que celui de Google a été récemment mis à jour pour utiliser Kubernetes Engine Monitoring, qui est spécialement conçu pour Kubernetes.

Azure fournit son propre système de surveillance des conteneurs, conçu à l'origine pour un écosystème de conteneurs de base non Kubernetes. Ils ont ajouté la surveillance de certaines métriques et ressources spécifiques à Kubernetes (santé du cluster, déploiements) - en mode aperçu, à partir de juin 2020.

AWS propose une surveillance légère pour le plan de contrôle directement dans Cloudwatch. Pour surveiller les travailleurs, vous pouvez utiliser les métriques Kubernetes Container Insights fournies via un agent CloudWatch spécifique que vous pouvez installer dans le cluster.

Meilleur pari : GKE

Écosystème

En termes d'écosystèmes, les trois fournisseurs ont des forces et des atouts différents. AKS dispose désormais d'une documentation très complète autour de sa plateforme et est le deuxième en termes de publications sur Stack Overflow. EKS a le moins de publications sur Stack Overflow, mais bénéficie de la force d'AWS Marketplace. GKE, en tant que plate-forme la plus ancienne, a le plus de messages sur Stack Overflow et un nombre décent d'applications sur son marché, mais aussi la documentation la plus complète.

Meilleurs paris : GKE et EKS

Tarification

En ce qui concerne le prix global, même avec la décision de GKE d'implémenter le prix de 0,10 $/heure pour n'importe quel cluster, il reste de loin le cloud le moins cher. C'est grâce à quelque chose de spécifique à Google - les remises d'utilisation soutenue, qui sont appliquées chaque fois que l'utilisation mensuelle des ressources à la demande atteint un certain minimum.

Il est important de noter que l'exemple de ligne de prix ne tient pas compte du trafic vers le cluster Kubernetes que le fournisseur de cloud peut facturer.

La raison pour laquelle AWS n'autorise pas l'utilisation de son niveau gratuit pour tester un cluster EKS est qu'EKS nécessite des machines plus grandes que le niveau tX.micro et que la tarification horaire d'EKS ne figure pas dans le niveau gratuit.

Néanmoins, il peut toujours être économique de tester l'une de ces options Kubernetes gérées avec une charge décente en utilisant les nœuds ponctuels/préemptifs de chaque fournisseur de cloud. Cette tactique permettra facilement d'économiser 80 à 90 % sur le prix final. (Bien sûr, il n'est pas recommandé d'exécuter des charges de production avec état sur de telles machines !)

Fonctionnalités annoncées et avantage de Google

Lorsque l'on examine les différentes fonctionnalités annoncées en ligne, il semble qu'il existe une corrélation entre la durée de commercialisation de la version gérée de Kubernetes et le nombre de fonctionnalités. Comme mentionné, Google ayant été l'initiateur du projet Kubernetes semble être un avantage indéniable, résultant en une intégration meilleure et plus forte avec sa propre plateforme cloud.

Mais AKS et EKS ne doivent pas être sous-estimés à mesure qu'ils mûrissent; les deux peuvent profiter de leurs caractéristiques uniques. Par exemple, AWS est le seul à avoir une intégration de nœuds bare-metal et possède également le plus grand nombre d'applications sur son marché.

Maintenant que les fonctionnalités annoncées pour chaque offre Kubernetes sont claires, approfondissons avec quelques tests pratiques.

Kubernetes : AWS contre GCP contre Azure en pratique

La publicité est une chose, mais comment les différentes plates-formes se comparent-elles lorsqu'il s'agit de servir des charges de production ? En tant qu'ingénieur cloud, je connais l'importance du temps qu'il faut pour générer et supprimer un cluster lors de l'application de l'infrastructure en tant que code. Mais je voulais également explorer les possibilités de chaque CLI et commenter la facilité (ou non) avec laquelle chaque fournisseur de cloud permet de générer un cluster.

Expérience utilisateur de création de cluster

AK

Sur AKS, la génération d'un cluster est similaire à la création d'une instance dans AWS. Il suffit de trouver le menu AKS et de parcourir une succession de menus différents. Une fois la configuration validée, le cluster peut être créé, un processus en deux étapes. C'est très simple et les ingénieurs peuvent facilement et rapidement lancer un cluster avec les paramètres par défaut.

EKS

La création de cluster est nettement plus complexe sur EKS que sur AKS. Tout d'abord, et par défaut, AWS nécessite d'abord un voyage vers IAM pour créer un nouveau rôle pour le plan de contrôle Kubernetes et lui affecter l'ingénieur. Il est important de noter également que cette création de cluster n'inclut pas la création des nœuds, donc quand j'ai mesuré 11 minutes en moyenne, c'est uniquement pour la création du maître. La création du groupe de nœuds est une autre étape pour l'administrateur, nécessitant à nouveau un rôle pour les travailleurs avec trois politiques nécessaires à définir via le panneau de configuration IAM.

GKE

Pour moi, l'expérience de création manuelle d'un cluster est plus agréable sur GKE. Après avoir trouvé le moteur Kubernetes dans Google Cloud Console, cliquez sur pour créer un cluster. Différentes catégories de paramètres apparaissent dans un menu sur la gauche. Google préremplira le nouveau cluster avec un pool de nœuds par défaut facilement modifiable. Enfin et surtout, GKE a le temps de génération de cluster le plus rapide, ce qui nous amène au tableau suivant.

Il est temps de générer un cluster

J'ai effectué ces tests dans la même région (Francfort et Europe de l'Ouest pour l'AKS) pour supprimer l'impact possible de cette différence sur le temps de ponte. J'ai également essayé de sélectionner la même taille pour les nœuds du cluster : trois nœuds, chacun ayant deux vCPU et sept ou huit Go de mémoire, une taille standard pour exécuter une petite charge sur Kubernetes et commencer à expérimenter. J'ai créé chaque cluster trois fois pour calculer une moyenne.

Dans ces tests, GKE est resté loin devant avec un temps de frai toujours inférieur à trois minutes.

Kubernetes : aperçu d'AWS, de GCP et d'Azure CLI

Toutes les CLI ne sont pas créées égales, mais dans ce cas, les trois CLI sont en fait des modules d'une CLI plus grande. Qu'est-ce que ça fait d'être opérationnel avec la chaîne d'outils CLI de chaque fournisseur de cloud ?

AKS CLI (via az )

Après avoir installé az tooling, puis le module AKS (via az aks install-cli ), les ingénieurs doivent autoriser la CLI à communiquer avec le compte Azure du projet. Il s'agit d'obtenir les informations d'identification pour mettre à jour le fichier kubeconfig local via un simple az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

De même, pour créer un cluster : az aks create --resource-group myResourceGroup --name myAKSCluster

CLI EKS (via aws ou eksctl )

Sur AWS, nous trouvons une approche différente : il existe deux outils CLI officiels différents pour gérer les clusters EKS. Comme toujours, aws peut se connecter aux ressources AWS, en particulier aux clusters. L'obtention des informations d'identification dans un kubeconfig local peut être effectuée via : aws eks update-kubeconfig --name cluster-test .

Cependant, les ingénieurs peuvent également utiliser eksctl , développé par Weaveworks et écrit en Go, pour créer et gérer facilement un cluster EKS. Un avantage majeur qu'EKS offre aux ingénieurs cloud est qu'ils peuvent le combiner avec des fichiers de configuration YAML pour créer une infrastructure en tant que code (IaC) puisqu'il fonctionne avec CloudFormation. C'est certainement un atout à prendre en compte lors de l'intégration d'un cluster EKS dans une infrastructure plus large sur AWS.

La création d'un cluster via eksctl est aussi simple que eksctl create cluster , aucun autre paramètre n'est requis.

CLI GKE (via gcloud )

Pour GKE, les étapes sont très similaires : installez gcloud , puis authentifiez-vous via gcloud init . Les possibilités à partir de là : les ingénieurs peuvent créer, supprimer, décrire, obtenir des informations d'identification, redimensionner, mettre à jour ou mettre à niveau un cluster, ou répertorier les clusters.

La syntaxe pour créer un cluster avec gcloud est simple : gcloud container clusters create myGCloudCluster --num-nodes=1

AKS contre EKS contre GKE : résultats du test

En pratique, nous pouvons voir que GKE est certainement le plus rapide pour lancer un cluster de base, à la fois en termes de simplicité de la console et de temps d'apparition du cluster. Du point de vue UX, avec le bouton de connexion à côté du cluster, ce qui en fait également le moyen le plus simple de se connecter à un cluster.

En termes d'outils CLI, les trois fournisseurs de cloud ont implémenté des fonctionnalités similaires ; cependant, nous pouvons mettre l'accent sur l'outil supplémentaire fourni par Weaveworks pour EKS. eksctl est l'outil idéal pour mettre en œuvre l'infrastructure en tant que code au-dessus de votre infrastructure AWS préexistante, en combinant d'autres services avec EKS.

Les offres Kubernetes gérées vont de l'avant : AWS contre GCP contre Azure

Pour ceux qui débutent dans le monde de Kubernetes, l'implémentation de référence pour moi est GKE, car c'est la plus simple. Il est facile à configurer, il dispose d'une UX simple et rapide pour le spawn, et il est bien intégré à l'écosystème Google Cloud Platform.

Même si AWS a été le dernier à rejoindre la course, il présente quelques avantages indéniables, tels que des nœuds en métal nu et le simple fait qu'il soit intégré au fournisseur ayant la plus grande part d'esprit.

Enfin, AKS a fait de grands progrès depuis sa création. La parité des outils et des fonctionnalités ne prendra probablement pas longtemps, tout en laissant de la place dans le processus pour innover. Et comme pour toute offre Kubernetes gérée, pour ceux qui utilisent déjà la plate-forme mère, l'intégration sera un argument de vente.

Une fois qu'une équipe a choisi un fournisseur de cloud Kubernetes, il peut être intéressant de se pencher sur les expériences des autres équipes, en particulier les échecs. Ces post-mortem sont le reflet de cas réels, toujours un bon point de départ pour développer ses propres meilleures pratiques de pointe. J'attends vos commentaires ci-dessous avec impatience!