ECS ή EKS: τι να διαλέξει μια startup;

Για τις περισσότερες startups με μικρή ομάδα και λιγότερα από δέκα-δώδεκα services, το ECS είναι η καλύτερη προεπιλογή: κανένα fee για control plane, κανένα cluster upgrade, λιγότερα πράγματα να μάθετε. Το EKS γίνεται η σωστή επιλογή όταν χρειάζεστε το οικοσύστημα του Kubernetes, φορητότητα σε άλλο cloud ή on-premises, ή όταν έχετε ήδη ανθρώπους που τρέχουν Kubernetes καλά.

Καμία επιλογή δεν είναι μόνιμη. Η εφαρμογή σας βγαίνει ως container images σε κάθε περίπτωση, οπότε το κόστος μετάβασης αργότερα είναι κυρίως στα deployment manifests και στα εργαλεία της πλατφόρμας, όχι στον κώδικά σας.

Η σύγκριση με μια ματιά

Το ECS είναι orchestrator του ίδιου του AWS, με σχεδόν καθόλου πλατφόρμα να συντηρείτε. Το EKS είναι managed Kubernetes: το AWS τρέχει το control plane, εσείς όλα τα υπόλοιπα γύρω του.

Κόστος: το fee του control plane είναι το μικρότερο κομμάτι

Το EKS χρεώνει $0.10 ανά cluster την ώρα, δηλαδή περίπου $73 τον μήνα ανά cluster για μήνα 730 ωρών. Το ECS δεν χρεώνει τίποτα για orchestration. Το compute κοστίζει το ίδιο και στα δύο, γιατί τρέχουν στα ίδια EC2 instances ή στο ίδιο Fargate.

Το fee μετράει περισσότερο απ' όσο φαίνεται όταν πολλαπλασιαστεί. Production, staging και dev σημαίνει τρία fees. Κι αν ένα cluster μείνει πίσω στα upgrades, το extended support το ανεβάζει στα $0.60 ανά cluster την ώρα, έξι φορές πάνω. Το extended support είναι ενεργό από προεπιλογή, οπότε ένα παρατημένο cluster περνά στην ακριβότερη τιμή χωρίς να το αποφασίσει κανείς.

Το μεγαλύτερο κόστος είναι οι άνθρωποι. Στο EKS κάποιος πρέπει να έχει την ευθύνη για τον AWS Load Balancer Controller, το VPC CNI, το CoreDNS, έναν node autoscaler, upgrades κάθε λίγους μήνες και το μοντέλο ασφάλειας RBAC μαζί με IAM. Από την εμπειρία μας, αυτό τρώει ένα σημαντικό κομμάτι του χρόνου ενός μηχανικού ακόμα και σε μικρό cluster. Στο ECS η περισσότερη από αυτή τη δουλειά απλώς δεν υπάρχει.

Υπάρχουν και νεότερες managed επιλογές που αλλάζουν λίγο την εξίσωση. Το EKS Auto Mode διαχειρίζεται nodes και βασικά add-ons με επιπλέον χρέωση ανά instance πάνω από το EC2, και τα ECS Managed Instances κάνουν κάτι αντίστοιχο για ECS σε EC2, επίσης με management fee ανά instance. Και τα δύο ανταλλάσσουν χρήματα με λιγότερη συντήρηση nodes.

Λειτουργικό βάρος στην καθημερινότητα

Το ECS σας ζητά να καταλάβετε task definitions, services, capacity providers και έναν ALB. Το EKS σας ζητά να καταλάβετε Kubernetes, και μετά την κόλλα του AWS από πάνω.

Ορίστε το ίδιο μικρό web service και στα δύο. Στο ECS είναι κομμάτι ενός task definition· στο Kubernetes είναι ένα Deployment που χρειάζεται ακόμα Service, Ingress και τον AWS Load Balancer Controller για να δεχτεί κίνηση.

{
  "family": "api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "runtimePlatform": { "cpuArchitecture": "ARM64", "operatingSystemFamily": "LINUX" },
  "taskRoleArn": "arn:aws:iam::123456789012:role/api-task",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789012.dkr.ecr.eu-central-1.amazonaws.com/api:1.4.2",
      "portMappings": [{ "containerPort": 8080 }],
      "essential": true
    }
  ]
}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      serviceAccountName: api
      containers:
        - name: api
          image: 123456789012.dkr.ecr.eu-central-1.amazonaws.com/api:1.4.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 500m
              memory: 1Gi

Κανένα από τα δύο δεν είναι δύσκολο από μόνο του. Η διαφορά φαίνεται μέσα σε έναν χρόνο: στο EKS θα κάνετε upgrade το cluster αρκετές φορές, θα ενημερώσετε add-ons και θα ψάξετε τουλάχιστον ένα πρόβλημα που ζει στο κενό ανάμεσα στο Kubernetes και στο networking ή στο IAM του AWS. Και στα δύο, κάντε pin τα image tags· το :latest στο production είναι πρόβλημα σε κάθε orchestrator.

Οικοσύστημα και φορητότητα

Εδώ το EKS κερδίζει καθαρά. Αν θέλετε Helm charts για software τρίτων, GitOps με Argo CD ή Flux, Karpenter για scaling των nodes, operators για βάσεις ή queues, ή ένα ενιαίο μοντέλο deployment σε AWS, άλλο cloud και on-premises, το Kubernetes σας τα δίνει και το ECS όχι.

Να είστε ειλικρινείς με τον εαυτό σας για το αν το χρειάζεστε τώρα. Η φορητότητα έχει αξία όταν ένα συμβόλαιο ζητά on-premises ή multi-cloud, ή όταν πουλάτε software που οι πελάτες εγκαθιστούν στα δικά τους clusters. Το «μπορεί κάποια μέρα να φύγουμε από το AWS» σπάνια αρκεί για να φορτωθεί μια ομάδα πέντε μηχανικών το Kubernetes· στη σύγκριση AWS, GCP και Azure για ελληνικές startups εξηγούμε γιατί οι περισσότερες ομάδες μένουν σε ένα cloud.

Fargate και στα δύο: όχι ακριβώς το ίδιο προϊόν

Το Fargate τρέχει και σε ECS και σε EKS, αλλά στο ECS κάνει περισσότερα. Για το EKS, η τεκμηρίωση αναφέρει ξεκάθαρους περιορισμούς: χωρίς Fargate Spot, DaemonSets, privileged containers, GPUs, EBS volumes και Arm. Και η σελίδα τιμών του Fargate σημειώνει ότι Arm και Windows είναι προς το παρόν διαθέσιμα μόνο για ECS.

Αυτό έχει σημασία για το κόστος. Στο ECS μπορείτε να τρέχετε Fargate tasks σε Graviton και να βάζετε Fargate Spot για workers και μη-production. Στο EKS, οι περισσότερες ομάδες που νοιάζονται για το κόστος καταλήγουν σε EC2 nodes με Karpenter ή Auto Mode αντί για Fargate.

Δεξιότητες της ομάδας και προσλήψεις

Ο καλύτερος orchestrator είναι αυτός που η ομάδα σας μπορεί να χειριστεί στις 3 τα ξημερώματα. Αν κανείς στην ομάδα δεν έχει τρέξει Kubernetes σε production, το EKS φέρνει μια καμπύλη εκμάθησης ακριβώς τη στιγμή που πρέπει να βγάλετε προϊόν.

Στην Ελλάδα οι μηχανικοί με πραγματική εμπειρία Kubernetes σε production είναι λίγοι και ακριβοί, κάτι που συζητάμε στο άρθρο για την πρόσληψη senior DevOps στην Ελλάδα. Το ECS παραδίδεται πιο εύκολα, βρίσκετε πιο εύκολα ανθρώπους γι' αυτό, και είναι πιο δύσκολο να το στήσετε πολύ λάθος.

Τι μένει ίδιο ό,τι κι αν διαλέξετε

Μεγάλο μέρος της δουλειάς που κάνει μια container πλατφόρμα καλή είναι ίδιο σε ECS και EKS, οπότε μην την καθυστερείτε περιμένοντας την απόφαση για τον orchestrator.

• Ένα IAM role ανά workload, ποτέ κοινά credentials στο node: task roles στο ECS, Pod Identity ή IRSA στο EKS.
• Images στο ECR, με scanning, immutable tags και build μία φορά στο CI.
• Ξεχωριστοί AWS λογαριασμοί ανά περιβάλλον, με το cluster ή τα ECS services ορισμένα σε Terraform.
• Logs, metrics και alerts στημένα πριν το πρώτο deploy στο production, με ορισμένο retention.
• Private subnets και σχέδιο για το egress, γιατί τα image pulls μέσα από NAT gateway μαζεύουν γρήγορα κόστος.

Αν αυτά είναι σωστά, η αλλαγή orchestrator αργότερα είναι ένα οριοθετημένο project. Αν είναι λάθος, ούτε το ECS ούτε το EKS θα σας σώσει.

Οδηγός απόφασης

Χρησιμοποιήστε το μέγεθος της ομάδας και τον αριθμό των services ως πρώτο φίλτρο και μετά ελέγξτε τις εξαιρέσεις.

Οι εξαιρέσεις που δικαιολογούν EKS νωρίς: προϊόν που βασίζεται σε Kubernetes operators ή σε software πακεταρισμένο σε Helm, συμβατική υποχρέωση φορητότητας, ML ή GPU workloads όπου τα εργαλεία του Kubernetes είναι πολύ μπροστά, ή ομάδα με εμπειρία κυρίως σε Kubernetes.

Μετάβαση από ECS σε EKS αργότερα

Το να ξεκινήσετε με ECS δεν σας δεσμεύει. Images, registry, VPC, βάσεις και CI μένουν ίδια· ξαναγράφετε τα deployment definitions και αντικαθιστάτε μερικά integrations του AWS με τα αντίστοιχα του Kubernetes.

1. Κρατήστε τα θεμέλια φορητά από την πρώτη μέρα. Config μέσω environment variables, health endpoints, stateless services, images που χτίζονται μία φορά και προωθούνται με tag. Infrastructure σε Terraform, ώστε το EKS cluster να είναι απλώς ένα ακόμα module.
2. Στήστε το cluster δίπλα στο ECS, όχι στη θέση του. Ίδιο VPC, ίδιες βάσεις. Εγκαταστήστε τον AWS Load Balancer Controller, έναν node autoscaler και τη λύση σας για secrets (External Secrets ή Secrets Store CSI driver).
3. Μεταφράστε ένα service. Task definition σε Deployment και Service, task IAM role σε EKS Pod Identity, autoscaling του ECS service σε HorizontalPodAutoscaler.
4. Μεταφέρετε την κίνηση σταδιακά. Με weighted ALB target groups ή weighted Route 53 records στέλνετε 5%, μετά 50%, μετά 100% στην έκδοση του EKS, με άμεσο rollback στο ECS.
5. Μεταφέρετε τα υπόλοιπα σε παρτίδες, μετά σβήστε τα ECS services και ενημερώστε runbooks και on-call οδηγίες.

Αλλάζει και το CI pipeline: τα deploy steps περνούν από το update ενός ECS service σε apply manifests ή commit σε GitOps repo. Εκμεταλλευτείτε τη μετάβαση για να διορθώσετε τα CI/CD anti-patterns που έχουν μαζευτεί, και κρατήστε την πρόσβαση στο AWS χωρίς keys με GitHub Actions OIDC.

Η δική μας προεπιλογή

Για startup σε αρχικό στάδιο στο AWS, ξεκινάμε με ECS σε Fargate, Graviton και Fargate Spot για τα μη-production, όλα σε Terraform. Περνάμε σε EKS όταν η ομάδα, ο αριθμός των services ή μια απαίτηση πελάτη κάνει το Kubernetes να αξίζει το βάρος του, και σχεδιάζουμε τη μετάβαση ώστε να είναι ένα Σαββατοκύριακο μεταφοράς κίνησης και όχι project ενός τριμήνου.

Αν ζυγίζετε αυτή την απόφαση, ή έχετε ήδη ένα EKS cluster που σας τρώει περισσότερο χρόνο απ' όσο θα έπρεπε, το Kubernetes consulting μας καλύπτει και τις δύο κατευθύνσεις, και μια οργανωμένη μετάβαση ανάμεσα σε πλατφόρμες είναι μέρος της δουλειάς μας στο cloud migration.

Συχνές ερωτήσεις

Είναι το ECS φθηνότερο από το EKS;

Το ECS δεν έχει χρέωση για orchestration, ενώ το EKS χρεώνει $0.10 ανά cluster την ώρα σε standard support και $0.60 σε extended support. Το compute κοστίζει το ίδιο και στα δύο. Η μεγαλύτερη διαφορά είναι ο χρόνος των μηχανικών: το EKS θέλει τακτικά upgrades και συντήρηση add-ons, που για μικρή ομάδα συνήθως κοστίζουν περισσότερο από το ίδιο το fee.

Kubernetes ή ECS για μια startup;

Οι περισσότερες startups στο AWS με λιγότερους από δέκα περίπου μηχανικούς και δέκα services εξυπηρετούνται καλύτερα από ECS σε Fargate. Διαλέξτε Kubernetes νωρίς αν οι πελάτες ζητούν on-premises ή multi-cloud, αν το προϊόν σας βασίζεται σε operators ή Helm, ή αν η ομάδα σας ήδη τρέχει Kubernetes με σιγουριά.

Μπορώ να περάσω από ECS σε EKS αργότερα;

Ναι. Images, registry, VPC, βάσεις και CI μένουν ίδια. Μεταφράζετε τα task definitions σε Kubernetes Deployments και Services, περνάτε τα task IAM roles σε EKS Pod Identity και μεταφέρετε την κίνηση σταδιακά με weighted ALB target groups ή Route 53 records, κρατώντας το ECS για άμεσο rollback.

Λειτουργεί το Fargate το ίδιο σε ECS και EKS;

Όχι. Σύμφωνα με την τεκμηρίωση του AWS, το Fargate στο EKS δεν υποστηρίζει Fargate Spot, DaemonSets, privileged containers, GPUs, EBS volumes ή Arm. Στο ECS μπορείτε να χρησιμοποιήσετε Fargate Spot και Arm tasks σε Graviton, κάτι που το κάνει εκεί πιο δυνατή και φθηνότερη επιλογή.