어떤 쿠버네티스 서비스를 선택해야 할까? 여기 아마존 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자 서비스 유지보수는 위험하다. 깃허브에서 아마존에서의 자동 확대/축소 및 애저에서의 클러스터 자동 확대/축소에 관한 수동 설정 문서를 확인할 수 있다.