2019.07.24

AWS·애저·구글 클라우드의 '관리형' 쿠버네티스 서비스 비교

Serdar Yegulalp | InfoWorld
첫 번째는 컨테이너, 그 다음이 쿠버네티스였다. 세상은 컨테이너화된 애플리케이션을 배포, 관리, 스케일링(축소 및 확장)하는 지겹고 복잡한 작업을 도와줄 구원 투수를 원했다. 그리고 마침내 쿠버네티스가 도움의 손길을 내밀었다.



쿠버네티스의 성장 이유 중 하나는 온프레미스, 클라우드 모두에서 쿠버네티스 클라우드를 실행할 수 있다는 점이다. 나아가 둘 모두를 오갈 수 있다. 즉 환경 간 컨테이너 앱을 이식할 수 있다. 이런 장점 때문에 주요 유명 퍼블릭 클라우드 업체가 모두 관리형 쿠버네티스 서비스를 제공한다. 회사 컨테이너를 클라우드로 옮기기만 하면 클라우드 업체가 나머지를 알아서 처리한다.

그러나 각 클라우드에 고유의 특징이 존재하듯, 쿠버네티스 서비스에도 이런 고유의 특징이 있다. 여기서는 쿠버네티스 플러그인 생태계를 통해 클라우드 스토리지 및 기타 서비스를 지원하는 방식을 중심으로, 아마존과 구글, 마이크로소프트의 호스팅 쿠버네티스 서비스의 특징을 비교, 분석해보자.

아마존 EKS(Elastic Kubernetes Service)
AWS는 2014년 말 아마존 일래스틱 컨테이너 서비스(ECS)로 컨테이너를 지원하기 시작했다. 이후 AWS EC2 인스턴스에서 도커를 실행할 수 있게 됐다. 지금은 ECS를 통해 EC2나 서버리스 상품인 AWS 파게이트(AWS Fargate) 중 하나에 도커를 배포할 수 있다.

그리고 몇 년 뒤(일반에 공식 배포된 시기는 2018년 6월) EKS로 쿠버네티스를 지원하기 시작했다. EKS 도입 이전에 AWS에서 쿠버네티스를 실행하는 유일한 방법은 많은 EC2 인스턴스를 스핀업해 수동으로 클러스터를 구성하는 것이었다. 그러나 EKS 도입 이후 쿠버네티스 클러스터를 더 쉽게 실행할 수 있게 됐다. 이제 EC2에 워커 노드를 배포한 후 관리 노드로 연결하면 된다.

아마존은 사용자가 여러 다양한 EC2 인스턴스에서 작업 노드를 실행할 수 있도록 지원한다. 예를 들어, 비용을 절약하기 위해 수요가 낮은 백그라운드 작업은 EC2 스폿 인스턴스에 예약할 수 있다. 대조적으로 장시간 지속해서 노드를 사용할 수 있게 만들어야 하는 작업은 EC2 예약 인스턴스에 예약할 수 있다.

아마존 EKS는 새 쿠버네티스 버전에 대한 업그레이드 메커니즘을 제공한다. 업그레이드 프로세스를 시작하면, 새 버전을 사용해 클러스터를 다시 시작하려 시도한다. 여기에 실패할 경우, 문제가 없었던 마지막 구성이 적용된다. 애드온은 수동으로 업그레이드해야 하며, 4보다 오래된 버전의 쿠버네티스는 지원하지 않는다. 아마존 키 관리 서비스를 사용해 쿠버네티스 시크릿을 저장하는 기능은 지원하지 않지만, 대략 처리할 수 있다.

쿠버네티스는 아마존 인프라에 사용할 수 있는 여러 공식 플러그인과 애드온을 제공한다. 데이터 암호화용 키 관리 서비스, AWS iAM 인증자, 일래스틱블록 스토리지용 컨테이너 스토리지 인터페이스 드라이버, 일래스틱 파일 시스템, Lustre아마존 FSx 등이다. CIS 드라이버는 아직 완성되지 않아 기업이 실제 환경에서 사용할 준비가 돼 있지 않다. 아마존은 또 AWS와 통합할 수 있도록 독자적인 쿠버네티스 컨트롤러를 제공한다. 그러나 완성되지 않은 상태이므로 실제 업무용으로는 권장하지 않는다.

- AWS Service Operator를 이용하면 kubectl과 쿠버네티스 CRD(사용자 지정 리소스 정의)을 사용하는 AWS 리소스를 생성할 수 있다.
- Kubernetes Custom Metrics Adapter를 사용하면 쿠버네티스 축소 및 확장에 AWS 클라우드워치를 사용할 수 있다.
- Kubernetes Ingress 컨트롤러를 사용해 아마존 API 게이트웨이를 관리할 수 있다.
- 여러 아마존 계정에서 EKS 클러스터를 관리할 수 있는 플러그인을 제공한다.
- 쿠버네티스 CRD과 AWS VPN을 함께 사용할 수 있는 플러그인을 제공한다.
- 쿠버네티스 노드가 옵션인 2차 서브넷에 자동으로 포드를 위치시키는 플러그인을 제공한다.
- AWS 네트워크 로드 밸런서를 생성해 쿠버네티스 사용자 지정 리소스로 관리할 수 있는 플러그인을 제공한다.

마이크로소프트 애저 쿠버네티스 서비스
애저는 2015년 도입된 ACS(Azure Container Service)로 컨테이너를 지원하기 시작했다. ACS는 기본 도커 컨테이너, 쿠버네티스, 메소스피어 DC/OS를 지원했다. 마이크로소프트는 2017년 말 ACS를 대체하는 AKS(Azure Kubernetes Services)를 출시했다. ACS는 현재 축소되고 있으며, 2020년에 서비스가 종료된다. 쿠버네티스 사용자가 AKS에서 더 우수한 옵션을 사용할 수 있지만, 쿠버네티스 없이 도커를 사용하려면 도커가 제공하는 커뮤니티, 또는 엔터프라이즈 버전의 ‘에저용 도커(Docker on Azure)’를 사용하면 된다.

AKS를 이용하면 리눅스와 윈도우 컨테이너를 실행할 수 있다. 그러나 윈도우 서버 컨테이너에 대한 AKS 지원은 여전히 안정적이지 못하다. 기반이 되는 윈도우 컨테이너가 미완성 상태이기 때문이다. 예를 들어, AKS를 이용해 애저 컨테이너 인스턴스(하이퍼바이저 수준의 격리된 컨테이너)에 작업을 예약할 수는 있지만, 리눅스를 실행하는 경우에만 가능하다. 윈도우 컨테이너에는 Virtual Kubelet 프로바이더를 사용해야 한다. 마이크로소프트가 '실험적인 오픈 소스 프로젝트이며, 이를 고려해 사용해야 한다'고 설명하는 프로바이더이다.

애저 명령줄을 사용해 새 쿠버네티스 버전으로 업그레이드할 수 있다. 또 덜 방해가 되는 방식으로 업그레이드를 하고 싶다면 개별 노드 풀에 대해 업그레이드를 예약할 수도 있다. 노드 풀을 사용해 CPU나 메모리 요구가 더 많거나, 더 적은 VM 그룹을 정의할 수 있다. 기본값이 특정 클러스터의 모든 노드의 머신 종류가 동일한 것으로 설정돼 있기 때문이다. 애저의 쿠버네티스 지원 기능에는 GPU에서 노드 풀을 실행하는 기능이 포함됐지만, 리눅스 노드로 한정된다. 또 엔비디아 플러그인 설치 등 해당 노드에서 수행해야 할 복잡한 수동 작업이 있다. 그러나 텐서플로우 머신 러닝 등 대부분의 GPU 기반 쿠버네티스 작업을 애저에 설정해 예약할 수 있다.

쿠버네티스 플러그인은 애저 파일애저 디스크 스토리지에 대해 컨테이너 스토리지 인터페이스를 지원한다. 유감스럽게도 두 플러그인 모두 미완성(알파 개발 단계) 상태다. 따라서 프로덕션 작업에 사용하는 것은 현명하지 못하다. 쿠버네티스는 마이크로소프트 애저의 클러스터 API를 지원하는 공식 플러그인을 제공한다. 또 플러그인을 사용해 애저 키 볼트에서 쿠버네티스 시크릿을 관리할 수 있다. 단, 자동 키 순환은 지원하지 않는다.

구글 쿠버네티스 엔진
GKE(Google Kubernetes Engine)는 많은 구글 클라우드 기능과 연결된다. 액세스 관리와 ID는 기존 구글 계정 및 승인 인프라를 통해 처리된다. 구글 클라우드 다른 곳의 앱에 사용되는 스택드라이버 로깅 및 모니터링은 쿠버네티스 클러스터에 위치한 앱에 대한 정보도 제공한다. 구글 클라우드 콘솔이나 명령줄로 모든 쿠버네티스 기능을 제어할 수 있다.

기본값으로 새 쿠버네티스 클러스터는 가장 안정적인 마지막 쿠버네티스 버전을 실행하도록 설정돼 있다. 또 클러스터 마스터가 자동으로 최신 쿠버네티스로 업그레이드되도록 설정돼 있다. 그러나 이런 업그레이드를 끄고, 수동으로 업그레이드를 할 수도 있다. 특정 클러스터의 모든 노드는 동일한 구글 컴퓨트 엔진(GCE) 머신 종류를 실행해야 한다. 기본 머신 종류는 1개의 가상 CPU와 3.75GB의 메모리를 제공하지만, 클러스터를 생성할 때 변경할 수 있다.

쿠버네티스 인스턴스는 구글의 컨테이너 최적화 OS를 실행한다. 크로미움 OS 프로젝트에서 파생된 OS다. 랜처와코어OS 등 다른 컨테이너 중심 OS처럼, 컨테이너 최적화 OS에는 스토리지와 메모리 공간, 복잡성, 공격 표면을 최소화하면서 컨테이너를 실행, 관리하는 데 필요한 구성 요소만 포함돼 있다.

구글은 AWS와 애저처럼 독자 개발한 컨테이너 레지스트리를 제공하고 있다. 또 맞춤 생성한 컨테이너를 쿠버네티스 배포하려는 사람들을 위해 독자 개발한 클라우드 컨테이너 빌드 서비스도 제공한다. 쿠버네티스 시크릿은 구글 클라우드 키 관리 서비스에 보관된 키를 사용해 암호화할 수 있다. 구글 쿠버네티스는 오래전부터 GPU 기반 노드를 지원했다. 그러나 각 노드에 대해 수동으로 엔비디아 GPU 장치 드라이버를 프로비저닝 해야 한다.

두 플러그인이 GKE에 대해 컨테이너 스토리지 인터페이스 기능을 제공한다. 구글 컴퓨터 엔진 퍼시스턴트 디스크구글 클라우드 파일스토어가 여기에 해당한다. 둘 다 구글이 공식 지원하는 플러그인이 아니다. 또 아직은 프로덕션 용도로 사용해서는 안 된다. 기타 구글 클라우드 플랫폼용 쿠버네티스 프로젝트로는 GCE에 쿠버네티스 클러스터를 생성하는 테라폼 모듈, 구글 클라우드 키 관리 서비스용 쿠버네티스 키 관리 서비스 플러그인을 예로 들 수 있다. 유용하지만 아직 초기 단계다. ciokr@idg.co.kr


2019.07.24

AWS·애저·구글 클라우드의 '관리형' 쿠버네티스 서비스 비교

Serdar Yegulalp | InfoWorld
첫 번째는 컨테이너, 그 다음이 쿠버네티스였다. 세상은 컨테이너화된 애플리케이션을 배포, 관리, 스케일링(축소 및 확장)하는 지겹고 복잡한 작업을 도와줄 구원 투수를 원했다. 그리고 마침내 쿠버네티스가 도움의 손길을 내밀었다.



쿠버네티스의 성장 이유 중 하나는 온프레미스, 클라우드 모두에서 쿠버네티스 클라우드를 실행할 수 있다는 점이다. 나아가 둘 모두를 오갈 수 있다. 즉 환경 간 컨테이너 앱을 이식할 수 있다. 이런 장점 때문에 주요 유명 퍼블릭 클라우드 업체가 모두 관리형 쿠버네티스 서비스를 제공한다. 회사 컨테이너를 클라우드로 옮기기만 하면 클라우드 업체가 나머지를 알아서 처리한다.

그러나 각 클라우드에 고유의 특징이 존재하듯, 쿠버네티스 서비스에도 이런 고유의 특징이 있다. 여기서는 쿠버네티스 플러그인 생태계를 통해 클라우드 스토리지 및 기타 서비스를 지원하는 방식을 중심으로, 아마존과 구글, 마이크로소프트의 호스팅 쿠버네티스 서비스의 특징을 비교, 분석해보자.

아마존 EKS(Elastic Kubernetes Service)
AWS는 2014년 말 아마존 일래스틱 컨테이너 서비스(ECS)로 컨테이너를 지원하기 시작했다. 이후 AWS EC2 인스턴스에서 도커를 실행할 수 있게 됐다. 지금은 ECS를 통해 EC2나 서버리스 상품인 AWS 파게이트(AWS Fargate) 중 하나에 도커를 배포할 수 있다.

그리고 몇 년 뒤(일반에 공식 배포된 시기는 2018년 6월) EKS로 쿠버네티스를 지원하기 시작했다. EKS 도입 이전에 AWS에서 쿠버네티스를 실행하는 유일한 방법은 많은 EC2 인스턴스를 스핀업해 수동으로 클러스터를 구성하는 것이었다. 그러나 EKS 도입 이후 쿠버네티스 클러스터를 더 쉽게 실행할 수 있게 됐다. 이제 EC2에 워커 노드를 배포한 후 관리 노드로 연결하면 된다.

아마존은 사용자가 여러 다양한 EC2 인스턴스에서 작업 노드를 실행할 수 있도록 지원한다. 예를 들어, 비용을 절약하기 위해 수요가 낮은 백그라운드 작업은 EC2 스폿 인스턴스에 예약할 수 있다. 대조적으로 장시간 지속해서 노드를 사용할 수 있게 만들어야 하는 작업은 EC2 예약 인스턴스에 예약할 수 있다.

아마존 EKS는 새 쿠버네티스 버전에 대한 업그레이드 메커니즘을 제공한다. 업그레이드 프로세스를 시작하면, 새 버전을 사용해 클러스터를 다시 시작하려 시도한다. 여기에 실패할 경우, 문제가 없었던 마지막 구성이 적용된다. 애드온은 수동으로 업그레이드해야 하며, 4보다 오래된 버전의 쿠버네티스는 지원하지 않는다. 아마존 키 관리 서비스를 사용해 쿠버네티스 시크릿을 저장하는 기능은 지원하지 않지만, 대략 처리할 수 있다.

쿠버네티스는 아마존 인프라에 사용할 수 있는 여러 공식 플러그인과 애드온을 제공한다. 데이터 암호화용 키 관리 서비스, AWS iAM 인증자, 일래스틱블록 스토리지용 컨테이너 스토리지 인터페이스 드라이버, 일래스틱 파일 시스템, Lustre아마존 FSx 등이다. CIS 드라이버는 아직 완성되지 않아 기업이 실제 환경에서 사용할 준비가 돼 있지 않다. 아마존은 또 AWS와 통합할 수 있도록 독자적인 쿠버네티스 컨트롤러를 제공한다. 그러나 완성되지 않은 상태이므로 실제 업무용으로는 권장하지 않는다.

- AWS Service Operator를 이용하면 kubectl과 쿠버네티스 CRD(사용자 지정 리소스 정의)을 사용하는 AWS 리소스를 생성할 수 있다.
- Kubernetes Custom Metrics Adapter를 사용하면 쿠버네티스 축소 및 확장에 AWS 클라우드워치를 사용할 수 있다.
- Kubernetes Ingress 컨트롤러를 사용해 아마존 API 게이트웨이를 관리할 수 있다.
- 여러 아마존 계정에서 EKS 클러스터를 관리할 수 있는 플러그인을 제공한다.
- 쿠버네티스 CRD과 AWS VPN을 함께 사용할 수 있는 플러그인을 제공한다.
- 쿠버네티스 노드가 옵션인 2차 서브넷에 자동으로 포드를 위치시키는 플러그인을 제공한다.
- AWS 네트워크 로드 밸런서를 생성해 쿠버네티스 사용자 지정 리소스로 관리할 수 있는 플러그인을 제공한다.

마이크로소프트 애저 쿠버네티스 서비스
애저는 2015년 도입된 ACS(Azure Container Service)로 컨테이너를 지원하기 시작했다. ACS는 기본 도커 컨테이너, 쿠버네티스, 메소스피어 DC/OS를 지원했다. 마이크로소프트는 2017년 말 ACS를 대체하는 AKS(Azure Kubernetes Services)를 출시했다. ACS는 현재 축소되고 있으며, 2020년에 서비스가 종료된다. 쿠버네티스 사용자가 AKS에서 더 우수한 옵션을 사용할 수 있지만, 쿠버네티스 없이 도커를 사용하려면 도커가 제공하는 커뮤니티, 또는 엔터프라이즈 버전의 ‘에저용 도커(Docker on Azure)’를 사용하면 된다.

AKS를 이용하면 리눅스와 윈도우 컨테이너를 실행할 수 있다. 그러나 윈도우 서버 컨테이너에 대한 AKS 지원은 여전히 안정적이지 못하다. 기반이 되는 윈도우 컨테이너가 미완성 상태이기 때문이다. 예를 들어, AKS를 이용해 애저 컨테이너 인스턴스(하이퍼바이저 수준의 격리된 컨테이너)에 작업을 예약할 수는 있지만, 리눅스를 실행하는 경우에만 가능하다. 윈도우 컨테이너에는 Virtual Kubelet 프로바이더를 사용해야 한다. 마이크로소프트가 '실험적인 오픈 소스 프로젝트이며, 이를 고려해 사용해야 한다'고 설명하는 프로바이더이다.

애저 명령줄을 사용해 새 쿠버네티스 버전으로 업그레이드할 수 있다. 또 덜 방해가 되는 방식으로 업그레이드를 하고 싶다면 개별 노드 풀에 대해 업그레이드를 예약할 수도 있다. 노드 풀을 사용해 CPU나 메모리 요구가 더 많거나, 더 적은 VM 그룹을 정의할 수 있다. 기본값이 특정 클러스터의 모든 노드의 머신 종류가 동일한 것으로 설정돼 있기 때문이다. 애저의 쿠버네티스 지원 기능에는 GPU에서 노드 풀을 실행하는 기능이 포함됐지만, 리눅스 노드로 한정된다. 또 엔비디아 플러그인 설치 등 해당 노드에서 수행해야 할 복잡한 수동 작업이 있다. 그러나 텐서플로우 머신 러닝 등 대부분의 GPU 기반 쿠버네티스 작업을 애저에 설정해 예약할 수 있다.

쿠버네티스 플러그인은 애저 파일애저 디스크 스토리지에 대해 컨테이너 스토리지 인터페이스를 지원한다. 유감스럽게도 두 플러그인 모두 미완성(알파 개발 단계) 상태다. 따라서 프로덕션 작업에 사용하는 것은 현명하지 못하다. 쿠버네티스는 마이크로소프트 애저의 클러스터 API를 지원하는 공식 플러그인을 제공한다. 또 플러그인을 사용해 애저 키 볼트에서 쿠버네티스 시크릿을 관리할 수 있다. 단, 자동 키 순환은 지원하지 않는다.

구글 쿠버네티스 엔진
GKE(Google Kubernetes Engine)는 많은 구글 클라우드 기능과 연결된다. 액세스 관리와 ID는 기존 구글 계정 및 승인 인프라를 통해 처리된다. 구글 클라우드 다른 곳의 앱에 사용되는 스택드라이버 로깅 및 모니터링은 쿠버네티스 클러스터에 위치한 앱에 대한 정보도 제공한다. 구글 클라우드 콘솔이나 명령줄로 모든 쿠버네티스 기능을 제어할 수 있다.

기본값으로 새 쿠버네티스 클러스터는 가장 안정적인 마지막 쿠버네티스 버전을 실행하도록 설정돼 있다. 또 클러스터 마스터가 자동으로 최신 쿠버네티스로 업그레이드되도록 설정돼 있다. 그러나 이런 업그레이드를 끄고, 수동으로 업그레이드를 할 수도 있다. 특정 클러스터의 모든 노드는 동일한 구글 컴퓨트 엔진(GCE) 머신 종류를 실행해야 한다. 기본 머신 종류는 1개의 가상 CPU와 3.75GB의 메모리를 제공하지만, 클러스터를 생성할 때 변경할 수 있다.

쿠버네티스 인스턴스는 구글의 컨테이너 최적화 OS를 실행한다. 크로미움 OS 프로젝트에서 파생된 OS다. 랜처와코어OS 등 다른 컨테이너 중심 OS처럼, 컨테이너 최적화 OS에는 스토리지와 메모리 공간, 복잡성, 공격 표면을 최소화하면서 컨테이너를 실행, 관리하는 데 필요한 구성 요소만 포함돼 있다.

구글은 AWS와 애저처럼 독자 개발한 컨테이너 레지스트리를 제공하고 있다. 또 맞춤 생성한 컨테이너를 쿠버네티스 배포하려는 사람들을 위해 독자 개발한 클라우드 컨테이너 빌드 서비스도 제공한다. 쿠버네티스 시크릿은 구글 클라우드 키 관리 서비스에 보관된 키를 사용해 암호화할 수 있다. 구글 쿠버네티스는 오래전부터 GPU 기반 노드를 지원했다. 그러나 각 노드에 대해 수동으로 엔비디아 GPU 장치 드라이버를 프로비저닝 해야 한다.

두 플러그인이 GKE에 대해 컨테이너 스토리지 인터페이스 기능을 제공한다. 구글 컴퓨터 엔진 퍼시스턴트 디스크구글 클라우드 파일스토어가 여기에 해당한다. 둘 다 구글이 공식 지원하는 플러그인이 아니다. 또 아직은 프로덕션 용도로 사용해서는 안 된다. 기타 구글 클라우드 플랫폼용 쿠버네티스 프로젝트로는 GCE에 쿠버네티스 클러스터를 생성하는 테라폼 모듈, 구글 클라우드 키 관리 서비스용 쿠버네티스 키 관리 서비스 플러그인을 예로 들 수 있다. 유용하지만 아직 초기 단계다. ciokr@idg.co.kr


X