이 글은 K8s 시리즈의 다섯 번째 글이다. Kubernetes 기초 개념(Pod, Deployment, Service 등)은 이전 글을 참고하자.

• 01: Kubernetes란? 컨테이너부터 클러스터까지
• 02: Pod, Deployment, Job, CronJob — K8s 워크로드 총정리
• 03: Service, Ingress — 트래픽 라우팅과 외부 접근
• 04: ConfigMap, Secret, Storage — 설정과 데이터 관리
• 05: Amazon EKS — 아키텍처와 Worker Node ← 현재 글
• 06: EKS 네트워킹·보안·비용·운영

직접 Kubernetes를 구축하면 Control Plane 설치, etcd 백업, 인증서 갱신, 버전 업그레이드 등 클러스터 관리에만 상당한 운영 부담이 생긴다. AWS EKS(Elastic Kubernetes Service)는 Control Plane 관리를 AWS에 위임하고, Rancher 같은 GUI 관리 도구를 함께 사용하면 kubectl 명령어를 몰라도 Pod 배포, 로그 확인, 스케일링 등 대부분의 작업을 웹 브라우저에서 수행할 수 있다. 즉 EKS가 인프라 운영을, Rancher가 일상 운영을 덜어주는 조합이다.

이 글에서는 EKS의 아키텍처부터 네트워킹, 보안, 최신 기능(Auto Mode, Pod Identity), 비용, 업그레이드 전략까지 실무에서 필요한 핵심을 정리한다.

1. EKS vs 직접 구축

핵심은 Control Plane 관리를 AWS에 맡긴다는 것이다. API Server, etcd, Scheduler를 직접 운영할 때 발생하는 장애 대응, 인증서 관리, 버전 호환성 문제를 신경 쓰지 않아도 된다.

2. EKS 아키텍처

EKS 클러스터는 AWS 관리 영역(Control Plane)과 사용자 관리 영역(Data Plane)으로 나뉜다.

2.1 Control Plane 상세

Control Plane은 클러스터별로 완전히 격리되어 있다. 다른 클러스터나 AWS 계정과 공유하지 않는다. AWS 관리 VPC에 위치하며, ENI(Elastic Network Interface)를 통해 사용자 VPC와 연결된다.

2.2 API Server 엔드포인트

프로덕션에서는 Private 엔드포인트 또는 Public + CIDR 제한을 사용하는 것이 권장된다.

3. Worker Node 옵션

EKS는 6가지 Worker Node 옵션을 제공한다. 관리 수준에 따라 선택하면 된다.

3.1 Managed Node Group

가장 보편적인 선택이다. AWS가 EC2 인스턴스의 프로비저닝, 패칭, 업데이트를 관리한다.

• Auto Scaling Group 기반으로 노드 수를 자동 조절
• Launch Template으로 인스턴스 타입, AMI, userdata 등 커스터마이징 가능
• 업데이트 시 자동 드레인: 노드 업데이트 시 기존 Pod을 다른 노드로 이동 후 교체

# Managed Node Group 예시 (eksctl)
managedNodeGroups:
  - name: general
    instanceType: m5.xlarge
    desiredCapacity: 3
    minSize: 2
    maxSize: 10
    labels:
      role: general

3.2 Fargate

Pod 단위의 서버리스 실행이다. 노드를 관리할 필요가 전혀 없다.

Fargate Profile로 어떤 Pod이 Fargate에서 실행될지 지정한다 (Namespace + Label 조합).

3.3 EKS Auto Mode (2024.12 GA)

2024년 re:Invent에서 발표된 가장 큰 변화다. 컴퓨팅, 스토리지, 네트워킹을 포함한 클러스터 인프라 관리를 자동화한다.

내부적으로 Karpenter가 EKS Control Plane에 통합된 것이다. 사용자가 Karpenter를 직접 설치·관리할 필요 없이 동일한 기능을 사용할 수 있다.

2025년 추가된 기능:

• EC2 On-Demand Capacity Reservations (ODCR) 및 Capacity Blocks for ML 지원
• 별도 Pod 서브넷 지원으로 인프라/앱 트래픽 분리
• AWS KMS 암호화 (ephemeral + root 볼륨)
• Forward Proxy 지원

Auto Mode vs Managed Node Group

선택 기준: 운영 간소화를 원하면 Auto Mode, 세밀한 제어가 필요하면 Managed Node Group.

3.4 Karpenter — 지능형 노드 오토스케일링

Karpenter는 AWS가 만든 오픈소스 노드 오토스케일러로, Cluster Autoscaler를 대체한다. Pod이 Pending 상태가 되면 워크로드에 맞는 최적의 인스턴스를 직접 선택하여 수 초 내에 노드를 프로비저닝한다.

Cluster Autoscaler vs Karpenter

Karpenter가 LLM 워크로드에 좋은 이유

1. GPU 인스턴스 자동 선택: Pod이 nvidia.com/gpu: 4를 요청하면, Karpenter가 p4d.24xlarge, g5.12xlarge 등 사용 가능한 GPU 인스턴스 중 가장 저렴한 것을 자동으로 선택한다
2. Spot + On-Demand 혼합: 학습 Job에는 Spot, 서빙 서버에는 On-Demand를 하나의 NodePool에서 자동 적용
3. Consolidation: 벤치마크 Job이 끝나면 빈 GPU 노드를 수 초 내에 종료 → 비용 절감
4. 빠른 스케일링: Pending Pod 감지 후 수 초 내 노드 프로비저닝 → 대기 시간 최소화

Karpenter 핵심 리소스

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-workloads
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["p", "g"] # p(학습용), g(추론용) 인스턴스 패밀리
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100" # NodePool 전체 CPU 상한
    nvidia.com/gpu: "16" # GPU 총 16장까지
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s # 빈 노드는 30초 후 종료

Auto Mode와의 관계

EKS Auto Mode는 Karpenter가 Control Plane에 내장된 것이다. 직접 Karpenter를 설치·관리할 필요 없이 동일한 기능을 쓸 수 있다. 다만 Auto Mode는 커스터마이징이 제한적이므로, NodePool을 세밀하게 제어하고 싶다면 Karpenter를 직접 설치하는 것이 낫다.

3.5 Hybrid Nodes (2024.12 GA)

온프레미스 서버를 EKS 클러스터의 Worker Node로 등록할 수 있다.

• Control Plane은 AWS, Worker Node는 온프레미스
• AWS Site-to-Site VPN, Direct Connect, 또는 자체 VPN으로 연결
• nodeadm CLI로 각 호스트를 클러스터에 조인
• CNI는 Cilium 또는 Calico 사용 (VPC CNI가 아님)
• 네트워크 요구사항: 최소 100Mbps, RTT 200ms 이하 권장
• 연결이 불안정한 DDIL 환경에는 적합하지 않음 → EKS Anywhere 고려

4. EKS 네트워킹

4.1 VPC CNI

EKS의 기본 CNI(Container Network Interface)로, Pod에 VPC의 실제 IP 주소를 할당한다. 오버레이 네트워크 없이 VPC 내에서 직접 통신하므로 성능 오버헤드가 거의 없다.

노드당 최대 Pod 수

인스턴스 타입에 따라 ENI 수와 ENI당 IP 수가 다르다.

t3.medium에서 17개밖에 못 띄우는 점을 간과하면, Pod이 Pending 상태에 빠지는 문제가 발생한다. 실제 워크로드에 맞는 인스턴스 타입을 선택하는 것이 중요하다.

4.2 IP 고갈 해결

VPC CNI는 Pod마다 실제 VPC IP를 사용하므로, 서브넷 IP가 부족해질 수 있다. 해결 방법:

Prefix Delegation이 가장 간단하고 효과적이다. ENABLE_PREFIX_DELEGATION=true 설정만으로 노드당 Pod 밀도를 크게 높일 수 있다.

4.3 Warm Pool 튜닝

VPC CNI의 ipamd는 미리 IP를 확보해두는 Warm Pool을 유지한다.

Pod 생성이 빈번한 환경에서는 WARM_IP_TARGET을 적절히 설정하면 Pod 시작 지연을 줄일 수 있다. 반대로 IP를 아끼려면 WARM_ENI_TARGET=0 + MINIMUM_IP_TARGET을 낮게 설정한다.

4.4 Network Policy

VPC CNI v1.14+에서 Kubernetes NetworkPolicy API를 네이티브로 지원한다. 별도의 Calico 설치 없이 Pod 간 네트워크 격리가 가능하다.

5. 보안

5.1 Pod에서 AWS 서비스 접근: IRSA vs Pod Identity

Pod이 S3, ECR 등 AWS 서비스에 접근해야 할 때, EC2 인스턴스 전체에 권한을 주면 그 노드의 모든 Pod이 같은 권한을 갖게 된다. 이를 해결하기 위해 Pod(ServiceAccount) 단위로 최소 권한을 부여한다.

IRSA (IAM Roles for Service Accounts)

기존 방식이며 여전히 널리 사용된다.

1. 클러스터별 OIDC Provider 설정 필요
2. IAM Role에 OIDC Provider를 Trust Relationship으로 설정
3. ServiceAccount에 IAM Role ARN을 annotation으로 지정
4. Pod에서 sts:AssumeRoleWithWebIdentity로 임시 자격증명 교환

Pod Identity (2023.12~, 권장)

IRSA의 후속으로, 더 간단하고 보안이 강화된 방식이다.

새로 구성한다면 Pod Identity를 사용하는 것이 권장된다. OIDC Provider 설정이 불필요하고, ABAC 세션 태그를 통해 kubernetes-namespace, kubernetes-service-account 등으로 세밀한 접근 제어가 가능하다.

5.2 Cluster Access 관리

기존에는 aws-auth ConfigMap으로 IAM ↔ K8s RBAC을 매핑했다. 이 방식은 ConfigMap을 직접 편집해야 해서 실수로 잠김(lockout) 위험이 있었다.

EKS Access Entry (v1.23+)는 이를 대체하는 API 기반 접근 관리 방식이다.

5.3 보안 모범 사례

• API Server 엔드포인트를 Private으로 설정하거나 CIDR 제한
• 클러스터 생성자의 cluster-admin 권한 제거 (bootstrapClusterCreatorAdminPermissions=false)
• IMDSv2만 허용, hop limit=1 → Pod가 노드 IAM Role 상속 방지
• 비root 사용자로 컨테이너 실행 (runAsNonRoot: true)
• K8s API 접근 불필요한 Pod은 automountServiceAccountToken: false

6. 비용 구조

6.1 기본 비용

Control Plane

Extended Support에 진입하면 비용이 6배로 뛴다. 버전 업그레이드를 미루면 비용으로 돌아온다.

Provisioned Control Plane (대규모 워크로드용)

2025년 11월에 추가된 옵션으로, Control Plane 용량을 사전 할당할 수 있다.

대규모 AI 학습/추론, 고빈도 배포, Spark 잡 같은 대량 Pod 배치에 유용하다. 티어 간 전환은 API 한 번 호출로 가능하며 다운타임이 없다.

Worker Node

인스턴스 비용은 일반 EC2와 동일하다.

Fargate 비용 예시

6.2 숨은 비용

EKS 청구서에는 나타나지 않지만, 실제로 상당한 비용을 차지하는 항목들이 있다.

특히 NAT Gateway가 의외로 크다. 100개 Pod이 각각 매일 1GB씩 외부 통신하면 NAT만으로 월 ~$230이 나온다.

6.3 EKS vs GKE vs AKS

EKS를 선택하는 이유: 이미 AWS 생태계(ECR, IAM, VPC, EFS, S3 등)를 사용하고 있다면, 다른 서비스와의 네이티브 통합이 가장 큰 장점이다.

7. 버전 관리와 업그레이드

7.1 EKS 버전 라이프사이클

EKS는 Kubernetes 버전을 Standard Support 14개월 + Extended Support 12개월 = 총 26개월 지원한다.

Extended Support에 진입하면 비용이 6배이므로, Standard 기간 내에 업그레이드하는 것이 중요하다.

7.2 업그레이드 순서

EKS는 한 번에 1 마이너 버전만 업그레이드할 수 있다 (예: 1.29 → 1.30 → 1.31).

7.3 버전 스큐 정책

7.4 업그레이드 모범 사례

• 연 1-2회 업그레이드 주기 유지: Extended Support 진입 전에 실행
• Staging 먼저: 프로덕션 적용 전 반드시 검증
• PodDisruptionBudget 설정: 업그레이드 시 서비스 가용성 보장
• 서브넷 IP 여유: Control Plane 업그레이드 시 최소 5개 IP 필요
• EKS 애드온은 자동 업그레이드 안 됨: 수동으로 호환성 확인 후 업데이트
• VPC CNI도 1 마이너 버전씩 업그레이드

8. EKS와 연동되는 AWS 서비스

9. 전체 배포 흐름 한눈에 보기

참고 문헌

• Amazon EKS 공식 문서
• Amazon EKS Architecture
• Amazon EKS Pricing
• EKS Auto Mode 발표 블로그
• EKS Auto Mode and NodePools Explained
• EKS Hybrid Nodes Deep Dive
• EKS Pod Identity 공식 문서
• IRSA vs Pod Identity 비교
• VPC CNI Best Practices
• EKS IAM Best Practices
• EKS Upgrade Best Practices
• EKS Version Lifecycle
• EKS Provisioned Control Plane
• EKS vs GKE vs AKS 2026 비교
• AWS Fargate Pricing