Kubernetes sur AWS : quelle option choisir, managée ou pas

Le faire par soi-même ou pas : c’est le choix que devront faire les utilisateurs qui souhaitent exécuter Kubernetes sur AWS. EKS ou pas, tout dépend du cas d’usage.

Les utilisateurs  qui veulent déployer Kubernetes sur AWS doivent choisir entre deux propositions : aller seul ou laisser Amazon s'occuper de la migration. Chaque approche a ses avantages et ses inconvénients.

Kubernetes a pour objectif de simplifier l'automatisation, le déploiement, le dimensionnement et le fonctionnement opérationnel des applications en containers.  Cet orchestrateur open source permet de profiter des avantages de ces containers mais sans avoir à goûter à sa complexité.

AWS dispose de son propre service, Amazon Elastic Container Service, qui connaît un certain succès. Les utilisateurs peuvent ainsi utiliser leurs propres clusters Kubernetes sur EC2. Cependant, le géant du cloud, après ses deux archi-rivaux que sont Microsoft et Google,  n’a pas pu ignorer la demande d’un service managé. Depuis la fin 2017, AWS propose ainsi Elastic Container Service for Kubernetes (EKS).

Alors comment choisir ?

Avec EKS, AWS prend complétement en charge le control place - des composants comme etcd et le serveur d’API Kubernetes. L'ensemble de l'infrastructure fonctionne de façon « cachée », sur plusieurs zones de disponibilité, tandis qu'AWS remplace automatiquement tout nœud défaillant afin de maintenir une haute disponibilité.  Le groupe s'occupe également des mises à jour et des correctifs. Pour l'utilisateur, ce control place d'EKS s’apparente finalement à une boîte noire.

Toutefois, il est encore de la charge  des utilisateurs de déployer et de maintenir le data plane sur les nœuds de workers. On choisit le type et la taille des instances, leur nombre et tout ce qui concerne les nœuds qui exécuteront les workloads.

Un cluster EKS peut être déployé en utilisant eksctl. Cet outil provisionne une infrastructure Kubernetes, y compris le control plan managé et les nœuds non managés. Il peut également apporter des modifications ultérieures si nécessaire. On peut utiliser kubectl pour exécuter des commandes sur un cluster Kubernetes et gérer les ressources qui s’y trouvent. C'est un outil standard, quelle que soit la version de Kubernetes.

L’autre option consiste à exécuter soi-même un environnement Kubernetes sur une instance EC2. Le déploiement peut se faire avec des outils comme kops, qui aident à créer et à gérer le cluster Kubernetes. Dans ce cas, le control plan sera visible et disponible pour les utilisateurs avec les bons droits. Avec cette option, les administrateurs devront également tout réparer et tout entretenir à la main, ce qui peut s'avérer peu pratique dans de nombreux cas.

Kubernetes sur AWS : managé ou pas ?      

Les premières choses à considérer : les fonctionnalités et la disponibilité. C'est là que l'EKS n'est pas à la hauteur. Il n'est pas disponible sur toutes les régions AWS et sa vitesse de release est lente. A la date de publication de cet article, EKS ne fonctionne que jusqu'à la version 1.12 de Kubernetes, même si la version 1.14 est déjà sortie. De plus, EKS n'a pas toutes les fonctionnalités proposées avec la version hébergée et managée par l’utilisateur. Amazon comble l’écart, mais lentement. Par exemple, il n’a ajouté les endpoints privés que récemment.

Mais d’un autre côté, EKS efface les contraintes liées au déploiement et à la maintenance de Kubernetes. C'est l'un de ses principaux arguments de vente. De nombreuses entreprises n'ont pas les ressources ou la volonté de gérer leur propre cluster Kubernetes. L'intérêt pour Kubernetes dans le cloud a donc considérablement augmenté avec la sortie d'EKS.

Le coût est un autre facteur. EKS facture 150 $ par mois pour le control plane et on doit payer pour les nœuds workers en plus de cela. Étant donné que Kubernetes managé peut être déployé sur différents types d'instances, leur coût variera en fonction des cas d'utilisation. Les environnements de développement plus petits coûteront  moins de 150 $ par mois, alors que pour les workloads  plus importantes, on peut facilement dépasser ce chiffre.

Choisir la bonne option se résume donc au cas d'utilisation et aux exigences spécifiques de développement. Les coûts sont probablement semblables pour les deux options. La différence se fera donc sur les fonctions disponibles et la simplicité - ou l'absence de simplicité.

Pour approfondir sur Architectures logicielles et SOA

Close