ECS vs EKS: Welke AWS-containerservice past bij jou?

Wat is ECS?

ECS is Amazons proprietaire beheerde containerorkestratieservice. Het biedt een eenvoudige en veilige manier om gecontaineriseerde applicaties te draaien. ECS is ontworpen voor eenvoud en vermindert het aantal keuzes dat klanten moeten maken rond compute-, netwerk- en beveiligingsconfiguraties, zonder in te leveren op schaal of features.

Er zijn een paar termen en componenten waarmee je voor ECS vertrouwd moet raken.

1. Cluster
2. Capacity provider
3. Taakdefinitie (task definition)
4. Taak (task)
5. Service

Cluster

Een ECS-cluster bestaat uit services, taken en capacity providers. Het bevat ook het ECS-control plane, dat door AWS wordt beheerd en voor ons niet zichtbaar is.

Capacity provider

Containers hebben een server nodig om op te draaien, of dat nu een virtuele machine in de cloud is of je lokale computer. In de context van ECS kun je het “Launch Type” kiezen om je containers op Elastic Compute Cloud (EC2) of Fargate te draaien.

Tabblad Infrastructure van de AWS ECS-console.

Taak

Een taak is een set draaiende container(s) die is geconfigureerd volgens een taakdefinitie. Het is in wezen een instantie van een taakdefinitie, vergelijkbaar met hoe een container een instantie van een image is.

Taakdefinitie

We hebben een Dockerfile voor onze applicatie en daar een image van gemaakt. We hebben de image naar een containerregistry gepusht, zoals DockerHub of AWS ECR. En nu? We gaan een taakdefinitie maken, een configuratie of blauwdruk voor onze containers (die op een ECS-cluster worden gedeployed) met de volgende informatie:

• Image(s). Een taak kan meer dan één image bevatten.
• Het poortnummer dat wordt gebruikt om met onze applicatie te communiceren.
• Volumes.
• Resources (CPU en geheugen) die we voor onze applicaties reserveren.

Taakdefinitie in de AWS ECS-console.

Service

Wat gebeurt er als we een losse container draaien en die crasht? Niets. Hij blijft in de crashstatus. Dit gedrag is hetzelfde als we een losse taak op ECS maken. We gebruiken de ECS-service om ervoor te zorgen dat onze applicaties altijd beschikbaar zijn. Een service zorgt ervoor dat er te allen tijde een gewenst aantal taken actief is.

Als een taak crasht of de onderliggende server waarop hij draait (en dus de container) uitvalt, maakt de service een nieuwe taak aan in een beschikbare capacity provider.

Implementatie van ECS

Nu we de basis van ECS hebben behandeld, gaan we een eenvoudige Nginx-image draaien en benaderen. Met gebruik van het bovenstaande ECS-cluster en de taakdefinitie maak ik een service die naar de taakdefinitie verwijst:

Services in de AWS ECS-console.

Deze service maakt op zijn beurt een taak aan.

Een taak in de AWS ECS-console.

De publieke IP-adres van de taak benaderen:

Applicatie op ECS succesvol benaderd.

Wat is EKS?

Voordat we in Elastic Kubernetes Service (EKS) duiken, is het belangrijk om te begrijpen wat Kubernetes is. Kubernetes is een open-source engine voor containerorkestratie die de deployment, schaalbaarheid en het beheer van gecontaineriseerde applicaties automatiseert. 

Wil je meer leren, bekijk dan de Introduction to Kubernetes-cursus. 

Het vanaf nul opzetten en beheren van een Kubernetes-cluster kan echter complex en tijdrovend zijn. Veel componenten en configuraties die nodig zijn om Kubernetes op te zetten, lijken bij organisaties en teams op elkaar. Om dit niet-onderscheidende zware werk te abstraheren en Kubernetes-adoptie te vereenvoudigen, heeft AWS EKS ontwikkeld.

EKS is een beheerde Kubernetes-service van AWS die veel operationele overhead voor zijn rekening neemt. Het vereenvoudigt Kubernetes-implementatie, -schaalbaarheid en -beheer door het control plane voor gebruikers te beheren. Door het beheer van deze componenten te abstraheren, stelt Amazon EKS gebruikers in staat zich te richten op het draaien van hun gecontaineriseerde workloads en het beheren van workernodes, of op serverless computing met AWS Fargate.

Deze sectie bespreekt EKS kort. Voor meer, zie het artikel Fundamentals of Container Orchestration With AWS Elastic Kubernetes Service (EKS).

Er zijn een paar termen en componenten waarmee je voor EKS vertrouwd moet raken:

1. Cluster (master- en workernodes)
2. Manifestbestanden
3. Pods
4. ReplicaSet
5. kubectl-commandline-tool

Cluster

Een Kubernetes-cluster is een groep servers of virtuele machines waarop de Kubernetes-workloads draaien. Het bestaat uit de masternode (ook wel het control plane) en workernodes. 

In EKS wordt de masternode door AWS beheerd in een eigen VPC; dit is voor ons geabstraheerd. Ondertussen kunnen we de workernodes beheren via EC2-instances of serverless gaan met Fargate.

Netwerkconnectiviteit van het EKS-control plane. Beeldbron: AWS

Pods

Een pod is een Kubernetes API-resource. Het zijn de kleinste deploybare eenheden in Kubernetes. Het is een groep van één of meer containers en bevat specificaties over de te gebruiken image, poort, commando’s, enz.

Tab Resources in de AWS EKS-console.

ReplicaSet

Net als een pod is een ReplicaSet ook een Kubernetes API-resource. Het zorgt ervoor dat het gewenste aantal pods altijd draait.

Manifestbestanden

Kubernetes-manifestbestanden zijn configuratiebestanden waarmee je de gewenste staat van Kubernetes-resources declaratief definieert. Deze bestanden beschrijven welke resources in een Kubernetes-cluster moeten bestaan, hun configuraties en hoe ze met elkaar samenwerken.

Manifestbestanden zijn doorgaans geschreven in 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

Commandlinetool om met het Kubernetes-cluster te communiceren. We kunnen het kubectl-commando gebruiken om Kubernetes-resources imperatief te maken, beheren en verwijderen, of het samen met de manifestbestanden declaratief gebruiken.

# 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

Implementatie van EKS

Laten we nu laten zien hoe EKS werkt door dezelfde Nginx-image te draaien en te benaderen. 

Om het eenvoudig te houden maak ik een EC2-instance/workernode in een publieke subnet, deploy ik daar de applicatie, stel ik die bloot via een Kubernetes-serviceresource van het type NodePort en benader ik hem via het publieke IP van de instance. 

Ik gebruik de bovenstaande pod- en servicemanifesten en het kubectl-commando om de pod te maken:

# 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

Het EKS-cluster heeft één EC2-instance:

EC2-instance/workernode.

Zoek het publieke IPv4-adres van de instance op.

Het publieke IP-adres van EC2-instance/workernode.

Het publieke IP-adres van de instance benaderen op poort 31000:

Applicatie op EKS succesvol benaderd.

ECS vs. EKS: Overeenkomsten

Nu we de basis van ECS en EKS hebben behandeld, zien we enkele overeenkomsten. Dat is niet verrassend, want het zijn allebei tools voor containerorkestratie.

Compute-capaciteit

Beide services laten applicaties draaien op EC2, waarbij gebruikers verantwoordelijk zijn voor het onderhouden, patchen en upgraden van de EC2-instances, of op AWS Fargate, de serverless compute-optie waarbij AWS de onderliggende servers beheert en infrastructuurbeheer overbodig maakt.

Model voor workloadbeheer

Beide services hebben vergelijkbare structuren en benaderingen voor het beheren en onderhouden van applicatieresources.

In AWS ECS heet de configuratie die definieert hoe containers moeten draaien een taakdefinitie (task definition), terwijl dit in AWS EKS gebeurt met een podmanifest. Zodra gedeployed, draait de gecontaineriseerde applicatie in ECS binnen een taak, terwijl die in EKS binnen een pod draait. Om te zorgen dat er altijd een bepaald aantal taken of pods actief is, gebruikt ECS een service, terwijl EKS hiervoor op een ReplicaSet vertrouwt.

Diepe integratie met andere AWS-services

Als containerservice op AWS heeft Amazon veel moeite gedaan om te zorgen dat ECS en EKS goed integreren met andere AWS-services. 

Voor networking is er Amazon VPC, waarmee containers in geïsoleerde omgevingen kunnen draaien met volledige controle over netwerkconfiguraties, security groups en subnets. Load balancers voor het routeren van verkeer naar containers. 

Oplossingen zoals EBS, EFS en S3 zijn beschikbaar om te voorzien in de behoefte aan persistente opslag voor gecontaineriseerde applicaties.

Beide services gebruiken AWS IAM om toegang en permissies fijnmazig te regelen. Dit bepaalt tot welke AWS-resources de gecontaineriseerde applicatie toegang heeft, zoals S3, DynamoDB of RDS.

Samenvatting van de belangrijkste overeenkomsten

ECS vs. EKS: Verschillen

Het is belangrijk om de verschillen tussen Amazon ECS en Amazon EKS te begrijpen wanneer je tussen beide kiest. 

In deze sectie splitsen we hun kernverschillen op in gebruiksgemak, schaalbaarheid, maatwerk en kosten, zodat je kunt bepalen welke service het beste aansluit bij je technische vereisten en zakelijke doelen.

Gebruiksgemak en leercurve

EKS is gebouwd op Kubernetes, dus vertrouwdheid met Kubernetes-concepten en -tools is vereist. De leercurve voor EKS is daardoor steiler dan voor ECS. Dit houdt onder meer in dat je begrijpt hoe het kubectl-commando werkt en enkele andere essentiële Kubernetes API-resources, zoals services (niet te verwarren met de term “services” in de context van ECS), config maps, ingress, enz. De sectie “Wat is EKS” hierboven raakt slechts het topje van de ijsberg van wat EKS biedt.

ECS en EKS vereisen kennis van AWS-services zoals CloudWatch, IAM, ASG, enz. Gelukkig is dat alles wat nodig is voor ECS, maar niet voor EKS. Dus wint ECS op het gebied van gebruiksgemak.

Schaalbaarheid

Beide services kunnen even goed schalen als ze correct zijn geconfigureerd. De manier waarop ze schalen verschilt echter. ECS ondersteunt autoscaling via ECS Service Auto Scaling voor taken en ECS Cluster Auto Scaling voor instances. Het gebruikt alleen AWS-native services zoals CloudWatch-metrics en ASG-schaalbeleid.

EKS gebruikt daarentegen Kubernetes-native schaalfuncties, zoals Horizontal Pod Autoscaler (HPA) voor pods en Cluster Autoscaler voor instances. Cluster Autoscaler is niet standaard op het EKS-cluster geïnstalleerd en moet dus door de gebruiker zelf worden geïnstalleerd. Dit voegt complexiteit toe omdat de juiste configuratie vereist is op zowel de AWS-resources (bijv. IAM-rollen) als de Kubernetes API-resources (bijv. serviceaccounts) voor de Cluster Autoscaler om te functioneren, wat AWS API-calls vereist om in en uit te schalen.

Een recent geïntroduceerde nieuwe functie voor EKS, EKS AutoMode, kan deze extra complexiteit aanpakken. Het draagt het beheer en de schaalbaarheid van EKS-workernodes over aan AWS, maar brengt extra kosten met zich mee.

Flexibiliteit en maatwerk

Zoals vermeld is ECS Amazons propriëtaire beheerde containerorkestratieservice, ontworpen voor eenvoud. AWS verzorgt het meeste clustermanagement en biedt vooraf gedefinieerde configuraties die passen bij gangbare containerworkloads, maar mogelijk niet aan niche-eisen voldoen. Hoewel dit de complexiteit vermindert, beperkt het de maatwerkmogelijkheden vergeleken met Kubernetes.

EKS biedt de volledige kracht van Kubernetes, waarmee gebruikers deployments, podscheduling, storage classes en netwerkpolicies kunnen aanpassen aan hun behoeften. Geavanceerde orkestratiefuncties, zoals Custom Resource Definitions (CRD’s) en operators, maken ongeëvenaarde flexibiliteit in applicatieontwerp mogelijk. 

EKS kan ook worden geïntegreerd met diverse open-sourcetools en -plugins uit het Kubernetes-ecosysteem, zoals Prometheus, Grafana en Istio, waardoor ontwikkelaars zeer toegesneden oplossingen kunnen bouwen. Dus wint EKS de strijd om flexibiliteit en maatwerk.

Kosten

Naast de standaardkosten voor netwerkresources (bijv. publieke IPv4-adressen, NAT-gateways) en compute- en opslagresources (bijv. EC2-instances, Fargate en EBS-volumes) die zowel op ECS als EKS van toepassing zijn, heeft ECS lagere kosten en een veel eenvoudiger kostenstructuur.

Er zijn geen kosten voor het ECS-control plane. Met andere woorden: als je een ECS-cluster zou maken zonder draaiende taken, zou je geen kosten maken. Voor EKS zijn er daarentegen kosten voor het door AWS beheerde control plane, ongeacht of je applicaties in het Kubernetes-cluster draaien.

De kosten van het EKS-control plane variëren afhankelijk van de gebruikte Kubernetes-versie. Een Kubernetes-versie met standaardondersteuning kost $0,10 per cluster per uur, terwijl een versie met uitgebreide ondersteuning $0,60 per cluster per uur kost.

Samenvatting van de belangrijkste verschillen

Wanneer kies je voor ECS?

De keuze hangt af van de vereisten van je applicatie, zakelijke doelen, teamexpertise, operationeel budget en algehele prioriteiten.

ECS, dat eenvoudiger en kosteneffectiever is, is ideaal voor teams met krappe budgetten, een korte time-to-market en een voorkeur voor gestroomlijnde operaties. Het is vooral geschikt voor applicaties die geen portabiliteit over multi-cloud of hybride omgevingen vereisen en exclusief op AWS draaien. Als AWS-specifieke service sluit ECS naadloos aan bij workloads die in het AWS-ecosysteem blijven.

Hoewel zowel ECS als EKS Fargate ondersteunen voor serverless containerdeployments, biedt ECS een meer rechtstreekse integratie. Met ECS kun je direct kiezen om taken op Fargate te draaien zonder extra configuratie. Bij EKS met Fargate moet je labels op pods specificeren om te bepalen welke workloads op Fargate moeten draaien, wat een extra laag complexiteit toevoegt. Dit maakt ECS een aantrekkelijke keuze voor teams die een eenvoudigere serverless-ervaring zoeken.

Wanneer kies je voor EKS?

Kubernetes, het onderliggende platform voor EKS, is cloud-agnostisch en maakt het mogelijk workloads consistent te draaien op AWS, andere cloudproviders en on-premises omgevingen. Deze portabiliteit is vooral nuttig voor organisaties die opereren in multi-cloudopstellingen of hybride on-premises infrastructuur. Azure en Google Cloud bieden ook beheerde Kubernetes-services—respectievelijk Azure Kubernetes Service (AKS) en Google Kubernetes Engine (GKE)—wat de alomtegenwoordigheid van Kubernetes in moderne cloudomgevingen onderstreept.

EKS is ideaal als je applicatie of use-case geavanceerde maatwerk- en uitbreidingsmogelijkheden vereist. Zo ondersteunt Kubernetes het maken van Custom Resource Definitions (CRD’s), waarmee je aangepaste resources kunt definiëren om specifieke applicatieconfiguraties te beheren of te integreren met externe systemen. Deze flexibiliteit is een belangrijk onderscheidend vermogen van EKS.

Hoewel EKS het control plane abstraheert en op AWS vertrouwt voor het beheer ervan, vereist effectief werken in een EKS-omgeving nog steeds vertrouwdheid met Kubernetes API-resources en -concepten. De Kubernetes-expertise van het team is daarom cruciaal om het platform optimaal te benutten.

EKS biedt ook een breed scala aan aanpasbare add-ons die kunnen worden geïnstalleerd om de functionaliteit van het cluster uit te breiden. Deze add-ons maken het eenvoudiger om een cluster te voorzien van de nodige operationele tools, wat de setup vereenvoudigt en de productiviteit verhoogt.

Selectie van EKS-add-ons.

Samengevat is EKS zeer geschikt voor microservices-architecturen of applicaties met talrijke onderling verbonden componenten die veel controle en granulariteit vereisen. Het is vooral gunstig voor teams die geavanceerde maatwerkopties nodig hebben of werken in omgevingen waar portabiliteit van workloads essentieel is.

Beslisflowchart ECS vs. EKS. Afbeelding door de auteur.

Tools en integraties

Of het nu om een gecontaineriseerde applicatie gaat of een applicatie die direct op een VM draait, monitoring en observability zijn cruciaal. Binnen het AWS-ecosysteem kunnen zowel ECS als EKS gebruikmaken van AWS-tools en services van derden om de volledige Software Development Lifecycle (SDLC) voor gecontaineriseerde applicaties te versterken.

Monitoring en logging

Monitoring en logging zijn essentieel voor zicht op je applicaties en infrastructuur. AWS biedt native tools en ondersteunt integraties van derden voor zowel ECS als EKS, zoals Amazon CloudWatch voor metrics, logs en alarms. 

AWS X-Ray voor tracing van requests door microservices maakt het eenvoudig om performanceproblemen in ECS-taken of EKS-pods te analyseren en debuggen. Tools van derden zoals Datadog, Prometheus, Grafana en New Relic bieden uitgebreide visualisatie- en meldingsmogelijkheden die zijn toegesneden op containers.

CI/CD-pijplijnen

CI/CD-pijplijnen helpen tests, scans en deployments te automatiseren, wat zorgt voor snellere iteraties en minder handmatig werk. Populaire CI/CD-tools, zoals GitLab-pipelines en GitHub Actions, integreren met ECS en EKS om containerbuilds, tests en deployments mogelijk te maken. Deze tools werken met Docker-containers voor ECS of Helm-charts voor EKS.

Infrastructure as Code (IaC)

IaC is cruciaal voor het creëren van consistente en herhaalbare infrastructuur, het minimaliseren van provisioningstijd en het verkleinen van het risico op menselijke fouten die gepaard gaan met handmatige configuraties via de AWS Management Console. 

Populaire IaC-tools zijn onder meer Terraform en AWS CloudFormation. Hoewel beide veel worden gebruikt, heeft Terraform vaak de voorkeur vanwege de cloud-agnostische mogelijkheden, waardoor teams infrastructuur bij meerdere cloudproviders met één tool kunnen beheren.

Netwerken en beveiliging

AWS biedt robuuste netwerk- en beveiligingsfuncties voor zowel ECS als EKS om veilige communicatie en toegangscontrole te waarborgen, zoals AWS VPC-networking om resources te isoleren binnen private subnets. AWS WAF en Shield: bescherm applicaties die op ECS en EKS worden gehost tegen veelvoorkomende webkwetsbaarheden en DDoS-aanvallen. AWS KMS om EBS-volumes en Kubernetes-secrets die in etcd zijn opgeslagen te versleutelen.

Conclusie

ECS en EKS zijn beide robuuste containerorkestratieservices van AWS, elk afgestemd op verschillende applicatiebehoeften en teamprioriteiten. 

ECS is makkelijker om mee te beginnen, eenvoudiger te provisionen, te deployen en te onderhouden, en heeft lagere operationele kosten. EKS daarentegen heeft een steilere leercurve en hogere initiële complexiteit, maar biedt ongeëvenaarde flexibiliteit en geavanceerde maatwerkmogelijkheden, wat het ideaal maakt voor teams met gespecialiseerde of complexe vereisten. 

De keuze tussen ECS en EKS hangt af van de behoeften van je applicatie, de expertise van je team en de gewenste balans tussen eenvoud en controle.

Wil je je AWS-kennis versterken, dan is de AWS Concepts-cursus een goed startpunt. Wil je dieper duiken in AWS-tools en -technologieën, bekijk dan de AWS Cloud Technology and Services-cursus. Daarnaast biedt de Containerization and Virtualization Track waardevolle inzichten om uit te blinken in het beheren en deployen van containers.