Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

50장. EKS는 언제 고려하는가 — 개념 한 줄 이해

이 장에서 말하고자 하는 것

지금까지 ECS를 중심으로 컨테이너를 다뤘다.

AWS의 컨테이너 오케스트레이션은 ECS만 있는 게 아니다.

EKS (Elastic Kubernetes Service)

도 있다.

이 장은 EKS가 무엇이고 언제 고를지를 초보자 시점에서 간단히 정리한다.


1. EKS는 무엇인가

EKS는 AWS가 관리해주는 Kubernetes 클러스터다.

EKS = "AWS가 운영해주는 Kubernetes"

Kubernetes는 오픈소스의 컨테이너 오케스트레이션 표준이다.
EKS는 그 컨트롤 플레인을 AWS가 책임지고 운영한다.


2. ECS와 EKS의 차이

항목ECSEKS
만든 곳AWS 자체오픈소스 Kubernetes
학습 곡선낮음높음
AWS 의존성강함약함 (이식성 높음)
멀티 클라우드어려움쉬움
생태계AWS 중심광대한 K8s 생태계
인력 시장작음
비용Task 단위컨트롤 플레인 시간당 + 노드

3. ECS가 더 어울리는 경우

  • AWS 안에서만 동작하는 서비스
  • 운영 인력이 적다
  • Kubernetes 학습 비용이 부담된다
  • 빠르게 시작해야 한다

이 책의 척추 구조도 ECS 기준이다.


4. EKS가 더 어울리는 경우

  • 멀티 클라우드를 고려한다
  • Helm · Argo · Istio 같은 K8s 표준 도구를 이미 쓴다
  • K8s 경험자가 채용 시장에서 풍부하다
  • 사내 표준이 K8s 기반이다

5. Fargate는 ECS와 EKS 양쪽에서 쓸 수 있다

  • ECS on Fargate
  • EKS on Fargate

“노드 관리에서 해방되는 것” 은 ECS / EKS 선택과 별개의 축이다


6. 우리 서비스에서

이 책의 구조는 ECS on Fargate 다.

이유:

  • 초보자 학습 곡선이 가장 낮다
  • AWS 다른 서비스와의 연동이 자연스럽다
  • 운영 인력이 적어도 무리 없이 굴러간다

EKS는 회사 사정에 따라 나중에 고려할 수 있는 옵션으로 둔다.


7. EKS의 기본 용어 한 번만 보기

검토할 때 마주칠 핵심 용어다.

Pod         : 하나 이상의 컨테이너 묶음 (ECS의 Task와 유사)
Deployment  : Pod의 원하는 수와 버전 관리 (ECS의 Service와 유사)
Service     : 내부 트래픽 노출 (Service Discovery와 유사)
Ingress     : 외부 트래픽 진입점 (ALB와 비슷한 자리)
Namespace   : 논리적 분리 (ECS Cluster와 비슷한 자리)

ECS의 사고방식이 익으면 EKS로 옮기는 것도 어렵지 않다.


8. 직접 확인해보기 — CLI

# 클러스터 만들기 (eksctl 사용이 일반적)
eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-2 \
  --fargate

# kubectl 로 노드 보기
kubectl get nodes

kubectl 은 Kubernetes의 표준 CLI다.
EKS 운영의 90%는 이 명령으로 한다.


9. 코드로는 이렇게 생겼다 — Terraform

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "my-cluster"
  cluster_version = "1.30"

  vpc_id     = aws_vpc.main.id
  subnet_ids = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
  ]

  fargate_profiles = {
    default = {
      selectors = [
        { namespace = "default" }
      ]
    }
  }
}

ECS와 비교하면 부속이 더 많다.
처음 켤 때 학습 비용이 크다는 점이 코드에서도 보인다.


10. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. “K8s가 멋지니까” EKS 부터 시작한다

운영 인력 부족한데 EKS를 깔면 운영 자체가 부담.

ECS로 시작 → 필요해지면 EKS

안티패턴 2. EKS 컨트롤 플레인 비용을 무시한다

EKS는 클러스터당 시간 단위 비용이 있다.
개발용 클러스터를 여럿 띄우면 청구서가 쌓인다.

안티패턴 3. K8s YAML을 IaC 없이 직접 apply 한다

손으로 적용한 리소스는 추적이 안 된다.

Helm / Argo CD / Terraform 같은 도구와 함께 쓴다


11. 한 줄로 정리

EKS는 K8s를 AWS가 대신 운영해주는 옵션이며,
이식성과 K8s 생태계가 필요할 때 ECS의 대안으로 등장한다


12. 이 장의 핵심 정리

  1. EKS는 AWS의 관리형 Kubernetes다.
  2. AWS 종속 + 단순함 → ECS, 이식성 + 표준 → EKS.
  3. Fargate는 ECS · EKS 양쪽에서 사용할 수 있다.
  4. 이 책은 ECS on Fargate를 기본으로 한다.
  5. EKS는 인력 · 표준 · 멀티 클라우드 요건이 생길 때 고려한다.