준호의 블로그

EKS → 다른 클라우드 Kubernetes로 마이그레이션 — 비교 포인트

4 min read

EKS → 다른 클라우드 Kubernetes로 마이그레이션

Kubernetes 자체는 표준이지만, 매니지드 서비스가 되는 순간 클라우드마다 다른 사람의 작품처럼 느껴져요. 마이그레이션을 검토할 때는 단순한 manifest 이전이 아니라, 인프라 어댑터 자체를 갈아끼우는 작업이라고 봐야 해요.

핵심 비교 포인트

영역AWS EKS다른 매니지드 K8s주의할 점
노드 풀Managed Node GroupNode Pool자동 스케일 정책의 동작 방식이 다름
스토리지EBS / EFS클라우드별 블록·파일 스토리지StorageClass 매핑 표 작성 필수
네트워크 CNIaws-vpc-cni클라우드별 자체 CNI / Global RouterPod IP 할당 방식이 달라서 Network Policy 영향
LBALB / NLBCLB (L4/L7)Ingress Controller 차이 → 어노테이션 전부 재검토
보안 그룹SG다른 모델룰 변환 매핑 표 작성 필수
모니터링CloudWatch클라우드별 모니터링 + Prometheus알람 정책 재구성

진행 전 체크리스트

  1. 현재 워크로드 인벤토리 — 모든 manifest와 values.yaml을 한 곳에 모으기. 이게 시작점
  2. 외부 의존성 식별 — IAM 역할, S3 버킷, RDS, ALB 인증서 등 K8s 바깥의 모든 연결고리
  3. 상태 저장(stateful) 워크로드 우선순위 — 무상태 서비스는 쉽지만, DB·Redis·캐시 같은 건 다운타임 전략 필요
  4. 네트워크 정책 의존도 — CNI가 바뀌면 NetworkPolicy 동작이 달라질 수 있음
  5. CI/CD 파이프라인 — 빌드 환경, 이미지 레지스트리, 배포 도구가 새 클라우드와 호환되는지

단계적 접근

처음부터 전체를 옮기려고 하면 무조건 실패해요. 권장하는 순서는:

  1. PoC — 가장 단순한 무상태 서비스 1개를 새 K8s 클러스터에 띄워보기
  2. 측정 — 성능, 비용, 운영 편의성을 기존 환경과 비교
  3. 점진적 이전 — 트래픽 분할 → 하나씩 옮기기
  4. 롤백 플랜 — 어느 시점에든 원래 환경으로 돌아갈 수 있도록 DNS·DB 동기화 보장

가장 잘못 보는 함정

“manifest만 옮기면 된다”고 생각하는 것이 가장 큰 함정이에요. 실제로는 인프라 의존성 70% + manifest 30% 정도의 작업이고, 그 70%가 일정과 비용을 결정해요.

마무리

매니지드 K8s 마이그레이션은 단순한 “다른 클라우드 적응”이 아니라, 우리 시스템이 어떤 클라우드 추상화 위에 서 있었는지를 재발견하는 과정이에요. 그래서 항상 비교 매트릭스를 먼저 그리고 시작합니다.

그래프 뷰