컨테이너 서비스는 모든 클라우드 사업자가 주력으로 밀고 있는 상품 중 하나입니다. 모두 표준을 지향하는 가운데 빠르게 최신 버전의 쿠버네티스를 안정적으로 반영하는 데 역량을 집중하고 있습니다. 참고로 클라우드 업체는 클라우드 네이티브 컴퓨팅 페더레이션(Cloud Native Computing Federation, 이하 CNCF)의 ‘Certified Kubernetes’ 인증을 받습니다. 가이드라인에 따라 인증 규격을 준수하는 것은 같지만 각 클라우드 사업자의 컨테이너 서비스가 모두 같은 것은 아닙니다. 각각 기능, 옵션 등 차별점을 내세워 서비스를 제공합니다.
그렇다면 구체적으로 각 서비스는 무엇이 다를까요? 대표적인 관리형 서비스인 AWS의 EKS(Elastic Kubernetes Service), 마이크로소프트의 AKS(Azure Kubernetes Service), 구글의 GKE(Google Kubernetes Engine)의 차이를 간단히 알아보고 완전 관리형 서비스인 Azure Red Hat OpenShift(이하 ARO)는 무엇이 다른지 살펴보겠습니다.
다르지만 비슷한 관리형 컨테이너 서비스
EKS, AKS, GKE는 다르지만 비슷합니다. 기본 틀은 쿠버네티스입니다. 버전은 업체마다 약간 차이를 보입니다. 최신 버전의 쿠버네티스를 즉시 반영하는 곳은 없습니다. 내부 평가와 안정화 기간을 충분히 갖습니다. 2020년 2월 기준으로 EKS는 1.14를 기본값으로 1.13, 1.12를 제공합니다. AKS는 1.14가 기본값이면 상위 버전인 1.15와 하위 버전인 1.13 선택이 가능합니다. GKE는 1.13이 기본이며 1.14, 1.15를 선택할 수 있습니다. 참고로 모든 업체는 최신 버전을 미리 보기나 베타 형식으로 제공합니다. 세 서비스 모두 CNCF 인증 버전은 1.14입니다.
마스터와 노드 업그레이드는 EKS와 AKS는 사용자가 하는 방식이고 GKE는 자동 업그레이드를 기본으로 하며 사용자가 직접 하는 옵션도 지원합니다. 컨테이너 런타임의 경우 EKS는 도커, AKS는 모비(Moby) 도커, GKE는 도커를 사용합니다. 많은 분이 궁금해하는 SLA는 EKS가 99.9%, AKS가 99.9%(가용성 영역을 사용하지 않는 경우)와 99.95%(가용성 영역을 사용하는 경우), GKE는 존 클러스터는 99.5%, 리전 클러스터는 99.95%를 보장합니다. SLA를 못 맞추었을 때 EKS와 AKS는 서비스 크레딧으로 보상을 한다는 항목을 SLA에 명시하고 있습니다. 컨테이너 성능 모니터링은 EKS는 AWS CloudWatch Container Insight, AKS는 Azure Monitor, GKE는 Cloud Monitoring(구 Stackdriver)으로 합니다.
한 계정에 허용하는 최대 클러스터는 EKS는 100/리전, AKS는 100, GKR는 50/존, 50/리전 클러스터입니다. 클러스터 당 최대 노드 수는 EKS는 1,000(매니지드 노드 그룹), AKS는 1,000, GKE는 5,000(만약 GKE ingress controller 사용 시 1,000)입니다. 네트워킹과 보안은 세 서비스 모두 기본적으로 Kubernetes RBAC를 바탕으로 높은 보안성을 제공합니다.
컨테이너 이미지 저장소로 EKS는 ECR, AKS는 ACR, GKE는 GCR을 지원합니다. 지원하는 형식은 세 서비스 모두 도커 이미지 매니페스트 V2, 스키마 1 & 2, OCI 스펙으로 동일합니다. 이미지 접근 제한은 ESK는 AWS IAM, AKS는 Azure RBAC, GKE는 GCP IAM을 통해 관리할 수 있습니다. 이미지 서명을 지원하는 서비스는 AKS가 유일합니다. 이미지 저장소 SLA는 EKS, AKS는 99.9%를 보장하고 GKE는 따로 명시하고 있지 않습니다.
ARO는 무엇이 다른가?
EKS, AKS, GKE는 모두 관리형 PaaS입니다. 클러스터 구축과 운영에 있어 인프라 관리의 부담을 쏙 뺀 서비스입니다. 반면에 ARO는 완전 관리형 서비스입니다. ‘완전’이란 수식어가 붙는 이유는 컨테이너 환경 관리 항목 중 상당 부분을 마이크로소프트와 레드햇이 수행합니다. 또한, 엔터프라이즈 쿠버네티스 서비스이다 보니 레드햇 기술 지원을 직접 받을 수도 있습니다. 클라우드 서비스이지만 온프레미스 솔루션처럼 누군가 기술 지원을 책임지고 해주는 특징이 있습니다.
참고로 ARO는 마이크로소프트와 레드햇의 공동 엔지니어링을 토대로 서비스가 개발되었고, 운영 및 지원도 양사 협력 체계 아래 이루어집니다. 양사는 통합 케이스 시스템을 운영하여 고객 문의에 응대하며, 보안 역시 협력 체제 아래 강화하고 있습니다.
다음으로 하이브리드 클라우드 환경 구축이 수월한 것도 차별점입니다. 레드햇 오픈시프트를 기반으로 온프레미스에서 컨테이너 환경을 구축해 운영하는 경험은 새로운 기술, 도구를 배울 필요 없이 익숙한 도구, 명령어, 절차, 정책을 공용 클라우드까지 이어갈 수 있습니다. 위치가 어디이건 오픈시프트 환경은 동일합니다. 운영과 관리 방식도 다를 바 없습니다. 앞서 언급한 바와 같이 기술 지원도 똑같이 받을 수 있습니다. 차이가 있다만 온프레미스 환경은 인프라 관리를 사용자가 직접 해야 한다는 것입니다.
다음으로 DevOps 체계 정립까지 원스톱으로 해결할 수 있다는 것이 일반적인 PaaS 기반 관리형 서비스와 차별점입니다. EKS, AKS, GKE는 컨테이너에 초점을 맞춘 서비스입니다. 반면에 ARO의 근간을 이루는 레드햇 오픈시프트는 컨테이너 기반 애플리케이션을 물리적 인프라, 가상 인프라, 공용 클라우드에 신속히 개발, 배포, 관리할 수 있도록 돕는 애플리케이션 플랫폼입니다. 개발부터 운영까지 포괄합니다. EKS, AKS, GKE를 이용할 경우 사용자가 일일이 여러 서비스를 조합해 구현해야 하는 복잡한 작업을 레드햇 오픈시프트 환경에서는 할 필요가 없습니다.
이상으로 EKS, AKS, GKE와 ARO의 차이를 간략히 알아보았습니다. 관리형 컨테이너 서비스와 ARO는 지향점이 다릅니다. 클라우드에서 컨테이너를 인프라 관리 부담 없이 편히 쓰고 싶다면 EKS, AKS, GKE 중 하나를 선택하면 됩니다. 하지만 기업의 하이브리드 클라우드 전략에 따라 컨테이너 환경을 구축하고자 할 때나 DevOps 체계 아래 애플리케이션 현대화를 고려 중이라면 ARO가 더 현명한 선택입니다. 따라서 조직의 필요와 전략에 따라 관리형 서비스를 쓸 것인지 완전 관리형 ARO를 선택할 것인지 고르는 것이 중요합니다.