전체메뉴

클라우드가 발달할수록 그 기능과 품질을 좌우하는 핵심으로 떠오르는 것은 컨테이너를 배열하고 관리하는 쿠버네티스다. 특히 중앙의 온프레미스나 멀티․하이브리드 클라우드 모두에서 이런 기능의 쿠버네티스 클라우드를 실행할 수 있다는 점에서 클라우드의 ‘꽃’으로 비유된다. 아마존은 지난 2018년 첨단 버전의 쿠버네티스 EKS로 이 분야에서도 구글이나 MS에 앞서 기선을 제압한 바 있다. 이에 맞서 MS는 지난 2017년말 종전의 에저 컨테이너 관리를 대체한 쿠버네티스 AKS로 이에 맞섰고, 구글도 더욱 업그레이된 구글 쿠버네티스 엔진 GKE로 경쟁 대열에 합류했다.

쿠버네티스 기능은 ‘클라우드의 꽃’
쿠버네티스는 클라우드상의 각기 다른 환경 사이를 컨테이너로 된 앱을 오갈 수 있게 하고, 이식할 수도 있다. 이런 장점 때문에 웬만한 퍼블릭 클라우드 업체들은 모두 관리형 쿠버네티스 서비스를 제공하고 있다. 소비자 기업으로선 자사의 컨테이너를 클라우드로 옮기기만 하면 클라우드 업체가 알아서 처리해준다. 특히 세계 클라우드 시장을 장악하고 있는 AWS와 MS, 구글 등 ‘빅3’는 쿠버네티스의 성능과 고유의 장점을 통해 클라우드 시장의 패권을 다투고 있다. 그 중에서도 쿠버네티스를 통해 클라우드 스토리지의 성능을 높이고, 이에 따른 편의성과 효율성을 얼마나 높여가는가가 경쟁의 핵심이다.

복잡하고 사용자 많은 앱, 쿠버네티스 필수
컨테이너화된 앱을 사용하는 소비자가 많지 않을때엔 굳이 클라우드상의 다양한 배치와 조합을 위해선 오케스트레이션이 필요없다. 다시 말해 쿠버네티스 기능이 그다지 필요치 않다. 그러나 앱의 기능이 복잡해지고, 사용자도 증가할 경우는 문제가 달라진다. 즉, 오케스트레이션을 위한 쿠버네티스가 절실히 필요해진다. 또 워크로드상의 조건이 바뀌면서 그때마다 재코딩을 해야 한다거나 할 경우도 쿠버네티스가 요긴하게 적용된다. 이때 쿠버네티스는 코딩보단, 변한 조건에 맞는 시스템을 읽어드리는 방식으로 문제를 해결한다. 이런 과정에서 얼마나 적절하게 쿠버네티스가 작동하는냐에 클라우드 경쟁력이 좌우되는 것이다.

AWS의 EKS, 더 쉽게 쿠버네티스 클러스터 실행
AWS는 2014년경 수동으로 컨테이너 인스턴스(생성된 객체) 클러스터를 구성하는 방식으로 쿠버네티스(ECS)를 구성했다. 그러나 2018년에 EC2에 워커 노드를 배포한 후 관리 노드로 연결함으로써 쿠버네티스 클러스터를 더 쉽게 실행할 수 있게 하는 EKS가 나오면서 상황이 달라졌다. 즉 사용자가 종전의 여러 EC2 인스턴스에서 작업 노드를 실행할 수 있도록 한다. 만약 사용자 수요가 적은 백그라운드 작업은 EC2 스폿 인스턴스에 예약할 수 있고, 장시간 지속해서 노드를 사용할 수 있게 할 경우엔 EC2 예약 인스턴스에 예약할 수 있도록 한다. EKS는 또한 새로운 쿠버네티스 버전에 대한 업그레이드 메커니즘을 제공하고 있다.

또한 EKS에 의한 쿠버네티스는 아마존 인프라에 사용할 수 있는 부가기능이나 애드리브 기능, 즉 여러 공식 플러그인과 애드온을 제공한다. 예를 들어 데이터 암호화용 키 관리 서비스나, AWS iAM 인증자, 일래스틱 블록 스토리지용 ‘컨테이너 스토리지 인터페이스 드라이버’, 일래스틱 파일 시스템, 러스터용 아마존 FSx 등이다. 일종의 보너스인 셈이다.

MS AKS, 애저 명령줄로 쿠버네티스 버전 업그레이드
MS는 2015년 컨테이너 지원 시스템인 ACS를 처음 선보였다. 2년 후엔 그 보다 업그레이된 쿠버네티스 AKS(Azure Kubernetes Services)를 출시했다. AKS를 이용하면 리눅스와 윈도우 컨테이너를 실행할 수 있다. 그러나 앞서 아마존의 EKS와는 달리, 윈도우 서버 컨테이너에 대한 AKS 쿠버네티스 기능은 아직 안정적이지 못하다는 평가를 받고 있다. 

이는 윈도우 컨테이너 자체가 미완성 상태이기 때문이란 지적이다. 즉 AKS를 이용해 애저 컨테이너 인스턴스에 작업을 예약하려면 리눅스를 실행해야만 가능하다. 윈도우 컨테이너로 쿠버네티스를 구성하려면 MS의 실험적 오픈 소스 프로그램인 가상의 쿠버네티스 프로바이더를 별도로 활용해야 하는게 단점이다. 매우 번거로운 과정인 셈이다.

물론 MS 역시 장점도 많다. 애저 명령줄을 사용해 새 쿠버네티스 버전으로 업그레이드할 수 있고, 안전한 업그레이드를 위해 개별 노드 풀에 대해 업그레이드를 예약할 수도 있다. 노드 풀을 사용해 메모리 용량을 조절할 수 있는 VM그룹을 규정할 수도 있다. 다만 이 경우도 애저의 쿠버네티스 지원 기능은 리눅스 노드로 한정된다. 또 엔비디아 플러그인 설치 등 해당 노드에서 수행해야 할 복잡한 수동 작업이 있다. 

쿠버네티스 플러그인으론 애저 파일과 애저 디스크 스토리지에 대해 컨테이너 스토리지 인터페이스 지원 기능이 있다. 그러나 여전히 이들 플러그인 모두 완벽하지 않다는 평가가 많다. 전반적으로 아마존에 비해선 아직 따라잡아야 할 보완점이 많은 편이다.

구글, 여러 개인 앱을 여러 호스트에 자동으로 배치․관리
구글 쿠버네티스 엔진(GKE, Google Kubernetes Engine)는 수 많은 구글 클라우드와 연결된다. 구글 클라우드 콘솔이나 명령줄로 모든 쿠버네티스 기능을 제어할 수 있다. 구글은 대체로 컨테이너 관리를 위한 무난한 쿠버네티스 기술을 보유하고 있다. 

예를 들어 새로운 쿠버네티스 클러스터는 그 직전 가장 안정적인 마지막 쿠버네티스 버전을 실행하도록 설정돼 있다. 그리곤 자동으로 최신 쿠버네티스로 업그레이드되게 하며, 수동으로 업그레이드를 할 수도 있다. 또한 구글 쿠버네티스는 컨테이너가 여러 개인 애플리케이션을 여러 개의 호스트에 배치하고 관리하는 작업을 자동화해 준다. 각각의 컨테이너를 직접 관리할 필요가 없다. 다만 특정 클러스터의 모든 노드는 동일한 구글 컴퓨트 엔진(GCE) 머신을 실행해야 한다. 

구글의 쿠버네티스 인스턴스는 또 자체 컨테이너 최적화 OS를 실행한다. 컨테이너 최적화 OS에는 스토리지와 메모리 공간, 최적의 방식으로 컨테이너를 실행, 관리하는 데 필요한 구성 요소가 들어있다. 구글 역시 AWS와 애저처럼 독자 개발한 컨테이너 레지스트리를 제공하고 있다. 또 맞춤형 컨테이너를 쿠버네티스로 배포할 수 있도록 클라우드 컨테이너 빌드 기능도 제공한다. 보안을 위한 쿠버네티스 시크릿 기능도 있다. 이는 구글 클라우드 키 관리 서비스에 보관된 키를 사용해 데이터를 암호화할 수 있는 기능이다. 그럼에도 GPU 기반 노드에 대해 수동으로 장치 드라이버를 프로비저닝 해야하는 등 개선점도 아직 적지 않다는게 전문가들의 평가다.

AWS가 앞서고, 구글․MS 맹추격 양상
애초 클라우드 업계는 컨테이너 기술 향상에 주력했고, 시간이 지나면서 쿠버네티스 기능이 경쟁력을 좌우하기 시작했다. 컨테이너화된 애플리케이션을 배포하고, 관리하며, 앱을 축소하거나 확장하는 등의 복잡한 작업을 해내는 이들 기술은 곧 사용자를 설득하는 가장 중요한 클라우드의 무기가 될 수 밖에 없다. 전문가마다 평가가 다소 다르긴 하지만, 현재로선 이 분야에서도 대체로 아마존의 우위를 인정하는 의견이 많다. 그럼에도 불구하고, 구글이 빠른 속도로 업그레이드에 성공하고 있으며, MS역시 클라우드의 기반이 되는 윈도우 컨테이너의 성능 향상에 박차를 가하는 등 맹렬한 추격에 나서고 있어 귀추가 주목된다.