ECS vs EKS : Quel service de conteneurs AWS vous convient le mieux ?

Qu'est-ce que le SCE ?

ECS est le service d'orchestration de conteneurs géré propre à Amazon. Il offre un moyen simple et sécurisé d'exécuter des applications conteneurisées. Conçu pour être simple, ECS réduit les décisions des clients concernant les configurations informatiques, de réseau et de sécurité sans sacrifier l'échelle ou les fonctionnalités.

Il existe quelques terminologies et composants avec lesquels vous devez vous familiariser pour le SCE.

1. Groupement d'entreprises
2. Fournisseur de capacité
3. Définition des tâches
4. Tâche
5. Service

Groupement d'entreprises

Un cluster ECS comprend des services, des tâches et des fournisseurs de capacité. Il contient également le plan de contrôle ECS, qui est géré par AWS et n'est pas visible pour nous.

Fournisseur de capacité

Les conteneurs ont besoin d'un serveur sur lequel s'exécuter, qu'il s'agisse d'une machine virtuelle dans le cloud ou de votre ordinateur local. Dans le contexte de l'ECS, vous pouvez sélectionner le "Type de lancement" pour exécuter vos conteneurs sur Elastic Compute Cloud (EC2) ou Fargate.

Onglet Infrastructure de la console AWS ECS.

Tâche

Une tâche est un ensemble de conteneurs en cours d'exécution configurés selon une définition de tâche. Essentiellement, il représente une instance d'une définition de tâche, de la même manière qu'un conteneur sert d'instance à une image.

Définition des tâches

Nous avons un fichier Docker pour notre application et nous avons créé une image à partir de ce fichier. Nous avons poussé l'image vers un registre de conteneurs tel que DockerHub ou AWS ECR. Et maintenant ? Nous procédons à la création d'une définition de tâche, qui est une configuration ou un plan pour nos conteneurs (à déployer sur un cluster ECS) qui comprend les informations suivantes :

• Image(s). Une tâche peut contenir plus d'une image.
• Le numéro de port qui sera utilisé pour communiquer avec notre application.
• Volumes.
• Ressources (CPU et mémoire) à réserver pour nos applications.

Définition de la tâche dans la console AWS ECS.

Service

Que se passe-t-il lorsque nous exécutons un conteneur autonome et qu'il se bloque ? Rien ne se passe. Il reste en état de panne. Ce comportement est identique si nous créons une tâche autonome sur ECS. Nous utilisons le service ECS pour nous assurer que nos applications sont toujours opérationnelles. Un service permet de s'assurer qu'un certain nombre de tâches sont en cours d'exécution à tout moment.

Si une tâche tombe en panne ou si le serveur sous-jacent qui l'héberge (et donc le conteneur) tombe en panne, le service créera une nouvelle tâche dans un fournisseur de capacité disponible.

Mise en œuvre du SCE

Maintenant que nous avons couvert les bases de l'ECS, lançons une image Nginx simple et accédons-y. En utilisant le cluster ECS et la définition de tâche ci-dessus, je vais créer un service qui fait référence à la définition de tâche :

Services dans la console AWS ECS.

Ce service créera à son tour une tâche.

Une tâche dans la console AWS ECS.

Accéder à l'adresse IP publique de la tâche :

Accès réussi à l'application fonctionnant sur ECS.

Qu'est-ce que l'EKS ?

Avant de plonger dans Elastic Kubernetes Service(EKS), il est essentiel de comprendre ce qu'est Kubernetes. Kubernetes est un moteur d'orchestration de conteneurs open-source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. 

Pour en savoir plus, je vous recommande de consulter le cours Introduction à Kubernetes. 

Cependant, le démarrage et la gestion d'un cluster Kubernetes à partir de zéro peuvent s'avérer complexes et chronophages. De nombreux composants et configurations nécessaires à la mise en place de Kubernetes sont similaires d'une organisation à l'autre et d'une équipe à l'autre. Pour abstraire cette lourdeur indifférenciée et simplifier l'adoption de Kubernetes, AWS a développé EKS.

EKS est un service Kubernetes géré fourni par AWS qui prend en charge une grande partie des frais généraux opérationnels. Il simplifie le déploiement, la mise à l'échelle et la gestion de Kubernetes en gérant le plan de contrôle pour le compte des utilisateurs. En faisant abstraction de la nécessité de gérer ces composants, Amazon EKS permet aux utilisateurs de se concentrer sur l'exécution de leurs charges de travail conteneurisées et sur la gestion des nœuds de travail ou des tâches Fargate.

Cette section présente brièvement l'EKS. Pour en savoir plus, consultez l'article Fundamentals of Container Orchestration With AWS Elastic Kubernetes Service (EKS).

Il existe quelques terminologies et composants avec lesquels vous devez vous familiariser pour l'EKS :

1. Cluster (nœuds maître et ouvrier)
2. Fichiers manifestes
3. Cosse
4. Ensemble de répliques
5. kubectl utilitaire de ligne de commande

Groupement d'entreprises

Un cluster Kubernetes est un groupe de serveurs ou de machines virtuelles sur lesquels s'exécutent les charges de travail Kubernetes. Il se compose d'un nœud principal (communément appelé plan de contrôle) et de nœuds de travail. 

Dans EKS, le nœud principal est géré par AWS dans son propre VPC ; il est indépendant de nous. Entre-temps, nous pouvons gérer les nœuds de travail via des instances EC2 ou aller sans serveur en utilisant Fargate.

Connectivité du réseau du plan de contrôle de l'EKS. Source de l'image : AWS

Cosse

Un pod est une ressource de l'API Kubernetes. Il s'agit des plus petites unités déployables dans Kubernetes. Il s'agit d'un groupe d'un ou plusieurs conteneurs contenant des spécifications sur l'image à utiliser, le port, les commandes, etc.

Onglet Ressources dans la console AWS EKS.

Ensemble de répliques

Identique à un pod, un ReplicaSet est également une ressource de l'API Kubernetes. Il permet de s'assurer que le nombre souhaité de pods est toujours en cours d'exécution.

Fichiers manifestes

Les fichiers manifestes Kubernetes sont des fichiers de configuration utilisés pour définir l'état souhaité des ressources Kubernetes de manière déclarative. Ces fichiers décrivent les ressources qui doivent exister dans un cluster Kubernetes, leurs configurations et la manière dont elles interagissent les unes avec les autres.

Les fichiers manifestes sont généralement écrits en YAML :

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Utilitaire de ligne de commande pour communiquer avec le cluster Kubernetes. Nous pouvons utiliser la commande kubectl pour créer, gérer et supprimer des ressources Kubernetes de manière impérative ou l'utiliser avec les fichiers manifestes de manière déclarative.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Mise en œuvre de l'EKS

Démontrons maintenant comment fonctionne EKS en exécutant et en accédant à la même image Nginx. 

Pour faire simple, je vais créer une instance EC2/nœud de travail dans un sous-réseau public, y déployer l'application, l'exposer via une ressource de service Kubernetes de type NodePort, et y accéder via l'IP publique de l'instance. 

Je vais utiliser le manifeste de pod et de service ci-dessus et la commande kubectl pour créer le pod :

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

Le cluster EKS possède une instance EC2 :

Instance EC2/nœud de travail.

Localisez l'adresse IPv4 publique de l'instance.

L'adresse IP publique de l'instance EC2/nœud de travail.

Accéder à l'adresse IP publique de l'instance avec le port 31000 :

Accès réussi à l'application fonctionnant sur l'EKS.

ECS vs. EKS : Similitudes

Maintenant que nous avons couvert les bases de l'ECS et de l'EKS, nous pouvons voir certaines similitudes entre eux. Ce n'est pas surprenant, car il s'agit de deux outils d'orchestration de conteneurs.

Capacité de calcul

Les deux services permettent aux applications de fonctionner sur EC2, où les utilisateurs sont responsables de la maintenance, des correctifs et de la mise à niveau des instances EC2, ou sur AWS Fargate, l'option d'informatique sans serveur où AWS gère les serveurs sous-jacents, ce qui supprime le besoin de gestion de l'infrastructure.

Modèle de gestion de la charge de travail

Les deux services ont des structures et des approches similaires pour gérer et maintenir les ressources d'application.

Dans AWS ECS, la configuration qui définit comment les conteneurs doivent s'exécuter est appelée définition de tâche, tandis que dans AWS EKS, elle est réalisée à l'aide d'un fichier manifeste de pod. Une fois déployée, l'application conteneurisée dans ECS s'exécute dans une tâche, tandis que dans EKS, elle s'exécute dans un pod. Pour garantir qu'un nombre spécifié de tâches ou de pods sont toujours en cours d'exécution, ECS utilise un service, tandis qu'EKS s'appuie sur un ensemble de répliques pour cette fonctionnalité.

Intégration poussée avec d'autres services AWS

En tant que service de conteneurs sur AWS, Amazon a fait de gros efforts pour s'assurer que ECS et EKS s'intègrent bien aux autres services AWS. 

Pour le réseau, il y a Amazon VPC, qui permet aux conteneurs de fonctionner dans des environnements isolés avec un contrôle total sur les configurations de réseau, les groupes de sécurité et les sous-réseaux. Équilibreurs de charge pour acheminer le trafic vers les conteneurs. 

Des solutions, telles que EBS, EFS et S3, sont disponibles pour répondre aux besoins de stockage persistant des applications conteneurisées.

Les deux services utilisent AWS IAM pour contrôler l'accès et les autorisations de manière granulaire. Elle détermine les ressources AWS auxquelles l'application conteneurisée peut accéder, telles que S3, DynamoDB ou RDS.

Résumé des principales similitudes

ECS vs. EKS : Différences

Il est important de comprendre les différences entre Amazon ECS et Amazon EKS avant de choisir l'un ou l'autre. 

Dans cette section, nous analyserons leurs principales différences en termes de facilité d'utilisation, d'évolutivité, de personnalisation et de coût, afin de vous aider à déterminer le service qui correspond le mieux à vos exigences techniques et à vos objectifs commerciaux.

Facilité d'utilisation et courbe d'apprentissage

L'EKS est construit sur Kubernetes, une familiarité avec les concepts et les outils de Kubernetes est donc nécessaire. La courbe d'apprentissage de l'EKS sera donc plus raide que celle de l'ECS. Cela implique de comprendre le fonctionnement de la commande kubectl et d'autres ressources essentielles de l'API Kubernetes, telles que les services (à ne pas confondre avec le terme "services" utilisé dans le contexte de l'ECS), les cartes de configuration, l'ingress, etc. La section "Qu'est-ce qu'EKS" ci-dessus effleure à peine la surface de ce qu'offre EKS.

ECS et EKS nécessitent une connaissance des services AWS tels que CloudWatch, IAM, ASG, etc. Heureusement, cela suffit pour l'ECS, mais pas pour l'EKS. C'est donc le SCE qui l'emporte en termes de facilité d'utilisation.

Évolutivité

Les deux services peuvent s'adapter aussi bien l'un que l'autre s'ils sont configurés correctement.. Cependant, la façon dont ils sont mis à l'échelle diffère. ECS prend en charge la mise à l'échelle automatique via ECS Service Auto Scaling pour les tâches et ECS Cluster Auto Scaling pour les instances. Il n'utilise que les services natifs d'AWS, tels que les mesures CloudWatch et les politiques de mise à l'échelle ASG.

Cependant, EKS utilise des fonctionnalités de mise à l'échelle natives de Kubernetes, telles que Horizontal Pod Autoscaler (HPA) pour les pods et Cluster Autoscaler pour les instances. Cluster Autoscaler n'est pas installé par défaut sur le cluster EKS et l'utilisateur doit donc l'installer lui-même. Cela ajoute de la complexité car la configuration appropriée est requise à la fois sur les ressources AWS (par exemple, les rôles IAM) et les ressources API Kubernetes (par exemple, les comptes de service) pour que le Cluster Autoscaler fonctionne, ce qui nécessite de faire des appels API AWS pour la mise à l'échelle en entrée et en sortie.

Une nouvelle fonctionnalité récemment mise en place pour EKS, EKS AutoMode, peut remédier à cette complexité supplémentaire. Elle permet de décharger la gestion et la mise à l'échelle des nœuds de travail EKS sur AWS, mais elle s'accompagne de coûts supplémentaires.

Flexibilité et personnalisation

Comme nous l'avons mentionné, ECS est le service d'orchestration de conteneurs géré par Amazon, conçu pour la simplicité. AWS s'occupe de la plupart des tâches de gestion des clusters et propose des configurations prédéfinies qui conviennent aux charges de travail courantes des conteneurs, mais qui ne répondent pas forcément à des besoins spécifiques. Si elle réduit la complexité, elle limite les options de personnalisation par rapport à Kubernetes.

EKS offre toute la puissance de Kubernetes, permettant aux utilisateurs de personnaliser les déploiements, la planification des pods, les classes de stockage et les politiques de mise en réseau en fonction de leurs besoins. Les fonctions d'orchestration avancées, telles que les définitions de ressources personnalisées (CRD) et les opérateurs, offrent une souplesse inégalée dans la conception des applications. 

EKS peut également être intégré à divers outils et plugins open-source de l'écosystème Kubernetes, tels que Prometheus, Grafana et Istio, ce qui permet aux développeurs de construire des solutions hautement personnalisées. L'EKS remporte donc la compétition en termes de flexibilité et de personnalisation.

Coût

Outre les coûts standard des ressources réseau (par exemple, adresses IPv4 publiques, passerelles NAT) et des ressources de calcul et de stockage (par exemple, instances EC2, Fargate et volumes EBS) qui s'appliquent à la fois à l'ECS et à l'EKS, l'ECS a un coût inférieur et une structure de coûts beaucoup plus simple, L'ECS a un coût inférieur et une structure de coût beaucoup plus simple.

Il n'y a pas de frais pour le plan de contrôle ECS. En d'autres termes, si vous deviez créer un cluster ECS sans aucune tâche en cours d'exécution, vous n'auriez aucun coût à supporter. Parallèlement, pour l'EKS, le plan de contrôle géré par AWS entraîne des coûts, que vous ayez ou non des applications en cours d'exécution dans le cluster Kubernetes.

Le coût du plan de contrôle EKS varie en fonction de la version de Kubernetes utilisée. Une version de Kubernetes bénéficiant d'un support standard coûte 0,10 $ par cluster et par heure, tandis qu'une version bénéficiant d'un support étendu coûte 0,60 $ par cluster et par heure.

Résumé des principales différences

Quand choisir ECS ?

Le choix dépend des exigences de votre application, des objectifs de l'entreprise, de l'expertise de l'équipe, du budget opérationnel et des priorités générales.

L'ECS, plus simple et plus rentable, est idéal pour les équipes dont les budgets sont plus serrés, les délais de mise sur le marché plus courts et qui préfèrent des opérations rationalisées. Il est particulièrement bien adapté aux applications ne nécessitant pas de portabilité sur des environnements multi-cloud ou hybrides et est conçu pour fonctionner exclusivement sur AWS. En tant que service spécifique à AWS, ECS s'aligne parfaitement sur les charges de travail confinées à l'écosystème AWS.

Si ECS et EKS prennent tous deux en charge Fargate pour les déploiements de conteneurs sans serveur, ECS offre une intégration plus simple. Avec ECS, vous pouvez choisir directement les tâches à exécuter sur Fargate sans configuration supplémentaire. En revanche, Fargate avec EKS nécessite de spécifier des étiquettes de pods pour déterminer quelles charges de travail doivent être exécutées sur Fargate, ce qui ajoute une couche de complexité. Cela fait d'ECS un choix intéressant pour les équipes à la recherche d'une expérience serverless plus simple.

Quand choisir EKS ?

Kubernetes, la plateforme sous-jacente d'EKS, est agnostique au cloud, ce qui permet aux charges de travail de s'exécuter de manière cohérente sur AWS, chez d'autres fournisseurs de cloud et dans des environnements sur site. Cette portabilité est particulièrement bénéfique pour les organisations opérant dans des configurations multi-cloud ou des infrastructures hybrides sur site. Azure et Google Cloud proposent également des services Kubernetes gérés - respectivement Azure Kubernetes Service (AKS) et Google Kubernetes Engine (GKE) - soulignant l'omniprésence de Kubernetes dans les environnements cloud modernes.

EKS est idéal si votre application ou votre cas d'utilisation nécessite une personnalisation et une extensibilité avancées. Par exemple, Kubernetes prend en charge la création de définitions de ressources personnalisées (CRD), qui vous permettent de définir des ressources personnalisées pour gérer des configurations d'application spécifiques ou s'intégrer à des systèmes externes. Cette flexibilité est un élément clé de différenciation pour EKS.

Bien qu'EKS fasse abstraction du plan de contrôle et s'appuie sur AWS pour le gérer, fonctionner efficacement dans un environnement EKS exige toujours une certaine familiarité avec les ressources et les concepts de l'API Kubernetes. Par conséquent, l'expertise Kubernetes de l'équipe est cruciale pour exploiter efficacement la plateforme.

EKS offre également une large gamme de modules complémentaires personnalisables qui peuvent être installés pour étendre les fonctionnalités du cluster. Ces modules complémentaires facilitent l'approvisionnement d'un cluster avec les outils opérationnels nécessaires, ce qui simplifie l'installation et améliore la productivité.

Sélection des modules complémentaires de l'EKS.

En résumé, l'EKS est bien adapté aux architectures de microservices ou aux applications comportant de nombreux composants interconnectés nécessitant un contrôle et une granularité élevés. Il est particulièrement avantageux pour les équipes qui ont besoin d'options de personnalisation avancées ou qui travaillent dans des environnements où la portabilité de la charge de travail est essentielle.

ECS vs. Organigramme de décision de l'EKS. Image par l'auteur.

Outils et intégrations

Qu'il s'agisse d'une application conteneurisée ou d'une application fonctionnant directement sur une machine virtuelle, la surveillance et l'observabilité sont primordiales. Grâce à leur appartenance à l'écosystème AWS, ECS et EKS peuvent exploiter les outils AWS et les services tiers pour améliorer l'ensemble du cycle de développement logiciel (SDLC) des applications conteneurisées.

Surveillance et journalisation

La surveillance et la journalisation sont essentielles à la visibilité de vos applications et de votre infrastructure. AWS fournit des outils natifs et prend en charge des intégrations tierces pour ECS et EKS, comme Amazon CloudWatch pour les mesures, les journaux et les alarmes. 

AWS X-Ray pour le traçage des requêtes à travers les microservices facilite l'analyse et le débogage des problèmes de performance dans les tâches ECS ou les pods EKS. Des outils tiers tels que Datadog, Prometheus, Grafana et New Relic offrent des capacités de visualisation et d'alerte améliorées, adaptées aux conteneurs.

Pipelines CI/CD

Les pipelines CI/CD permettent d'automatiser les tests, les analyses et les déploiements, ce qui accélère les itérations et réduit les efforts manuels. Les outils CI/CD courants, tels que les pipelines GitLab et les actions GitHub, s'intègrent à ECS et EKS pour permettre la construction, les tests et les déploiements de conteneurs. Ces outils fonctionnent avec des conteneurs Docker pour ECS ou des cartes Helm pour EKS.

Infrastructure as Code (IaC)

L'IaC est essentiel pour créer une infrastructure cohérente et reproductible, minimiser le temps de provisionnement et réduire le risque d'erreur humaine associé aux configurations manuelles via la console de gestion AWS. 

Les outils IaC les plus populaires sont Terraform et AWS CloudFormation. Si les deux sont largement utilisés, Terraform est souvent préféré pour ses capacités agnostiques au cloud, permettant aux équipes de gérer l'infrastructure sur plusieurs fournisseurs de cloud à l'aide d'un seul outil.

Réseaux et sécurité

AWS fournit des fonctions de réseau et de sécurité robustes pour ECS et EKS afin de garantir une communication et un contrôle d'accès sécurisés, tels que le réseau AWS VPC pour isoler les ressources au sein de sous-réseaux privés. AWS WAF et Shield : Protégez les applications hébergées sur ECS et EKS contre les vulnérabilités web courantes et les attaques DDoS. AWS KMS pour chiffrer les volumes EBS et les secrets Kubernetes stockés dans etcd.

Conclusion

ECS et EKS sont tous deux des services d'orchestration de conteneurs robustes fournis par AWS, chacun étant adapté aux différents besoins des applications et aux priorités de l'équipe. 

L'ECS est plus facile à utiliser au départ, plus simple à approvisionner, à déployer et à maintenir, et ses coûts d'exploitation sont moins élevés. En revanche, EKS présente une courbe d'apprentissage plus raide et une complexité initiale plus élevée, mais offre une flexibilité inégalée et des options de personnalisation avancées, ce qui en fait la solution idéale pour les équipes ayant des besoins spécialisés ou complexes. 

Le choix entre ECS et EKS dépend des besoins de votre application, de l'expertise de l'équipe et de l'équilibre souhaité entre simplicité et contrôle.

Si vous souhaitez renforcer vos connaissances sur AWS, le cours Concepts AWS est un excellent point de départ. Pour approfondir les outils et technologies AWS, consultez le cours sur les technologies et services cloud AWS. En outre, pour ceux qui souhaitent maîtriser la conteneurisation, le cursus sur la conteneurisation et la virtualisation offre de précieuses indications pour vous aider à exceller dans la gestion et le déploiement de conteneurs.