관리형 쿠버네티스 3종 비교 ‘AWS vs. 애저 vs. 구글 클라우드’

2018년 11월 05일      

ⓒ CIO Korea, Eric Johanson | InfoWorld

어떤 쿠버네티스 서비스를 선택해야 할까? 여기 아마존 EKS, 마이크로소프트 애저 쿠버네티스 서비스, 구글 쿠버네티스 엔진을 비교해 살펴본다.

분명 쿠버네티스는 오늘날 뜨거운 주제다. 구글이 수립했고 현재 CNCF(Cloud Native Computing Foundation)가 주도하고 있는 이 오픈소스 프로젝트는 콘테이너 오케스트레이션 전쟁에서 승리했다. 메소스피어(Mesosphere)와 도커(Docker Inc.) 등의 경쟁사 지망생들도 쿠버네티스를 채택했으며, 오픈시프트(OpenShift)와 클라우드 파운드리(Cloud Foundry) 등과 같은 선도 PaaS 스택들 또한 이를 포함시키기고 있다. 그리고 현재 모든 주요 클라우드 벤더가 쿠버네티스를 지원하고 있다.

하지만 그렇다고 해서 모든 쿠버네티스 제품이 같거나 동등한 것은 아니다. 본 기사에서는 관리형 쿠버네티스의 핵심 구성 요소를 분석하고 AECSK(Amazon Elastic Container Service for Kubernetes), AKS(Azure Kubernetes Service), 구글 KE(Google Kubernetes Engine) 등 3대 클라우드 제공자의 플랫폼 지원이 어떻게 다른지 살펴본다.

쿠버네티스 클러스터(Cluster) 설정하기
필자가 진행한 시험에서 3사의 서비스 모두 클러스터 구성에 문제가 없었지만 필요한 단계의 수에서 차이가 나타났다. 예를 들어, 아마존 EKS는 클러스터 생성을 위해 추가적인 단계가 필요하다. 하지만 마이크로소프트의 AKS와 구글 KE 등의 경우 몇 개의 간단한 명령으로 해결되며 수 분 안에 클러스터가 구성되어 운영된다. 또 AWS에서는 AWS IAM(Identity and Access Management)를 이용한 연합 인증을 가능하게 하는 헵티오(Heptio) 인증기 등 별도의 패키지를 설치해야 한다.

다양한 쿠버네티스 배치를 관리하는 경우 항상 kubectl 명령줄 툴이 구성되어 있어야 한다. 예를 들어, 필자는 쿠버네티스와 직접적으로, 그리고 거의 모든 관리형 쿠버네티스 제공자와 협력하고 있다. 많은 서비스들이 기본적으로 기존 파일에 kubeconfig 컨텍스트를 추가하는 명령을 제공하기 때문에 여러 제공자들의 클러스터 사이에서 훨씬 쉽게 전환할 수 있다. 아마존 EKS의 경우 수동 작업이다. 상황에 따라 신속하게 클러스터를 생성하고 삭제해야 하는 경우 시간 측면에서 비생산적일 수 있다.

즉 설정 관점에서 구글 KE와 AKS는 흡사하지만 아마존 EKS는 훨씬 많은 단계가 필요하다. 단 아마존은 이미 클러스 생성 속도를 높이기 위해 조치를 취하고 있다.

쿠버네티스 대시보드 비교
네이티브 쿠버네티스 대시보드는 모든 쿠버네티스 서비스를 위한 단순한 웹 기반 UI이다. 배치, 팟(pods), 서비스에 대한 간단한 지표를 제공하며 클러스터를 관리할 수 있게 해준다. 있으면 좋긴 하지만 쿠버네티스 대시보드가 반드시 필요한 것은 아니다. 쿠버네티스 대시보드에서 하는 모든 것을 명령줄에서도 쉽게 할 수 있다.

아마존 EKS 및 AKS를 사용할 때 대시보드는 사용 방법이 매우 간단하다. 필자는 클러스터를 로컬로 호스팅하고 필자의 기기에서 프록시를 시작하며 대시보드의 로컬호스트 버전을 탐색할 수 있었다.

하지만 단연 최고는 구글 KE의 대시보드였다. 솔직히 필자는 구글의 UI가 너무 마음에 들어 놀랐다. 그리고 구글이 쿠버네티스를 개발했기 때문에 어찌 보면 당연한 일일 것이다.

구글의 UI는 정말로 네이티브 쿠버네티스 대시보드의 업그레이드된 버전처럼 보인다. 동작이 일정하고 매끄럽게 작동하며 유용한 정보를 제공하고 탐색이 쉽다. 또한 즉시 사용이 가능하기 때문에 수동 대시보드 설정이 필요없다. AKS도 대시보드를 내장하고 있지만 탐색이 덜 직관적이고 학습이 좀 필요하다.

아마존 EKS는 3사의 서비스 중 유일하게 기능 대시보드를 기본 제공하지 않는다. 로컬 대신에 사람들이 클러스터에 도달하기 위해 인스턴스에 연결하는 외부 인스턴스(아마존 EC2, 구글 클라우드 엔진, 애저 컴퓨트)에서 클러스터를 운영할 계획이라면 생각해 보아야 할 부분이다.

필자의 경우가 한 예일 수 있다. 과거 쿠버네티스를 아마존 EC2 우분투(Ubuntu) 인스턴스에서 구동했다가 아마존 EKS를 설정하기 위해 삭제했다. 구성 및 가동을 마친 애플리케이션(그리고 나머지)은 매우 원활하게 작동했다. 단, 대시보드는 없었다.

아마존 EKS 대시보드를 생성하려면 API 서버가 노출되거나 기기 호스팅 쿠버네티스에 프록시에 대한 외부 액세스가 필요했다. 하지만 둘 다 불가능했으며 우리는 인스턴스에 대한 PEM 키 액세스가 있었기 때문에 로컬 프록시를 추가 구성 없이 노출시킬 수 없었다. 결국 필자는 모든 것을 명령줄에서 수행할 수 있었기 때문에 UI를 설정하느라 더 많은 시간을 지체할 이유가 없어 기본적으로 대시보드 구축을 포기했다.

자신이 선택한 쿠버네티스 대시보드는 결국 개인적인 필요에 의한 것이다. 단순히 소프트웨어를 평가하거나 관리형 쿠버네티스로 전환할 때 모든 서비스가 원활하게 작동하도록 하고 싶다면 내장형 대시보드와 사용 편의성 때문에 구글 KE를 선택할 것이다.

하지만 생각해 보면 목적은 대부분의 워크플로를 자동화하는 것이기 때문에 쿠버네티스 배치가 생산에 적용될 즈음에는 대부분이 스크립트화되고 자동화되어 대시보드가 전혀 필요 없게 될 것이다.

예를 들어, 유럽 물리학 조직 CERN은 약 210개의 쿠버네티스 클러스터를 구성했다. 그들이 자체 생산 워크플로를 위해 대시보드를 사용하고 있지는 않을 것이다.

쿠버네티스 클러스터 스케일링
쿠버네티스의 장점인 확대 및 축소 기능성, 즉 스케일링은 명령줄, 대시보드를 이용해 쉽게 수행될 수 있다. 단 필자가 시험한 3개의 쿠버네티스 제품 중 구글 KE만이 클러스터 자동 스케일링을 자동으로 설정했다.

이 기능의 돋보이는 이점은 팟에 리소스가 고갈되었을 때 쿠버네티스가 팟을 확대할 수 있고 노드가 충분히 활용되지 못할 때 노드를 축소하고 팟을 다른 노드로 이동하는 기능이다. 즉 자동 스케일링은 짧은 프로세스 운영 시 특히 좋다.

아마존 EKS와 AKS는 모두 워커 노드가 자동 확대/축소 그룹으로써 구동한다고 밝혔지만 쿠버네티스가 정책을 인식하지 못하기 때문에 자동 확대/축소를 수동으로 설정해야 한다. 이 구성이 많이 개입된 것은 아니지만 여전히 설정과 유지보수가 필요하다. 결국 마스터 노드에 대한 배치로써 자동 확대/축소를 배치한 후 정책을 구성하게 된다.

모니터 시험에서는 아무런 문제가 없었지만 개인적인 경험상 제3자 서비스 유지보수는 위험하다. 깃허브에서 아마존에서의 자동 확대/축소 및 애저에서의 클러스터 자동 확대/축소에 관한 수동 설정 문서를 확인할 수 있다.

쿠버네티스 클러스터를 위한 고가용성
가용성이 중요하긴 하지만 쿠버네티스에서 가장 중요한 구성 요소는 아니다. 쿠버네티스는 안정성 및 장애 허용범위와 관련해, 일반 인스턴스 가용성과 같은 장점을 갖고 있다. HA(High Availability)의 핵심은 클러스터에서 단일 장애 지점을 없애는 것이다. HA 클러스터가 있다면 일부 마스터 노드를 잃을 수 있다. 이것이 HA 쿠버네티스의 기본적인 정의이다.

하지만 쿠버네티스는 거대하며, 망가질 수 있는 여러 구성 요소가 있다. 쿠버네티스의 CNCF 자원 홍보 대사이자 KC+CNCNA 2017(KubeCon + CloudNativeCon North America 2017)에서 인터뷰한 루카스 칼드스트롬(Lucas Käldström)은 이렇게 설명했다.

“kube-dns를 예로 들어보자. 일반 클러스터가 있고 여기에 여러 마스터가 있으며 여러 Etcd 복제품이 있지만 여전히 1개의 kube-dns만 구동한다고 가정해본다. kube-dns를 구동하는 마스터가 고장 나면 갑자기 모든 서비스 발견 쿼리가 해결되지 않을 수 있기 때문에 클러스터에 일종의 고장 정지가 발생한다. 그래서 이를 더욱 깊이 연구하고 클러스터의 핵심 구성 요소 위치를 분석한 후 단일 장애 지점을 없애려 노력해야 한다.”

HA 관점에서 관리형 쿠버네티스 제공자는 어떻게 발전하고 있을까?

구글 KE는 멀티존과 지역 등 2개 모드로 사용할 수 있다. 지역 및 멀티존 클러스터 사이의 주된 차이점은 지역 클러스터가 3개의 마스터를 생성하지만 멀티존 클러스터는 1개만 생성한다는 점이다. 예를 들어, US-East에서 지역 클러스터를 운영하고 있다면 US-East-1, 2, 3에서 마스터를 생성한다. 지역 클러스터는 지역 내의 단일 구역보다는 한 지역 전체에서 사용할 수 있기 때문에 단일 구역이 다운되면 쿠버네티스 제어영역과 리소스가 영향을 받지 않는다.

루카스 칼드스트롬은 다음과 같은 말도 남겼다.

“HA와 멀티 마스터 사이에는 차이가 있다. 예를 들어, 마스터가 3개이고 이런 마스터에 대한 부하 균형 앞에 1개의 Nginx 인스턴스만 있다면 멀티 마스터 클러스터이지만 HA는 아니다. 왜냐하면 Nginx는 언제든지 다운될 수 있기 때문이다.”

아마존 EKS는 구글 KE와 유사한 접근방식을 취한다. 다양한 구역에서 1개의 HA 마스터와 워커 노드를 제공한다.

AKS는 지금까지 HA가 없는 유일한 제공자이다. 워커 노드를 사용해 특정 구역에 HA를 제공할 수 있지만 더 많은 노력이 필요하며 HA 마스터 노드와 같은 수준의 민첩성을 제공하지 못한다.

선택 기준은 조직의 니즈
결국 어떤 쿠버네티스 벤더를 선택할 지는 조직 및 제품 타협에 달렸다. 쿠버네티스 전용 기능은 여러 벤더가 제공하고 있으며 현재 대부분 버전 v1.10 상태이다. 조직의 필요에 따라 선택해야 한다.

예를 들어, 필자의 팀은 거의 모든 서비스에서 AWS에 맞추어 표준화한다. 도커 이미지는 아마존 ECR에서 호스팅되고 인스턴스는 아마존 EC2에 있으며 소스 코드는 AWS 코드커밋에 있고 호스팅 파일은 아마존 S3에 있는 식이다. 필자의 경우 표준화와 자동화가 소프트웨어를 구축하고 구동하는 이유이기 때문에 아마존 EKS를 쓰는 것이 맞다.

반면 소프트웨어를 위해 여러 벤더에 의존하고 있지만 이를 중요하게 여기지 않을 수 있다. 그리고 평가 및 실험 또는 자동 확대/축소 및 수동 확대/축소 관리 문제 해결의 중요성에 초점을 맞춘다면 구글 KE를 사용할 것이다. 마이크로소프트를 주로 이용하고 클라이언트가 클라이언트에서 구동하는 애플리케이션을 위해 애저 서비스를 요청할 수 있는 애저의 서비스 카탈로그의 이점을 원한다면 AKS를 선택할 것이다.

각종 복잡성이 존재하기 때문에 해결하고자 하는 비즈니스 사용례에 맞추어 선택해야 한다. 일체식 앱 또는 대형 도커 컴포즈 파일 관리가 어렵다고 생각했는가? 배치, 팟, 서비스, 대몬 세트를 위해 수 백 개의 YAML 파일을 관리해 보라.

* Eric Johanson은 앱다이나믹스 소프트웨어 엔지니어다. ciokr@idg.co.kr 
 

※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지

[원문출처 : http://www.ciokorea.com/news/40080]