유연한 컨테이너 관리 방안 제공하며 사실상 업계 표준 등극

‘쿠버네티스’ 등장

컨테이너는 이처럼 다양한 강점들로 인해 클라우드 환경에서 쓰임새가 점차 늘어나고 있다. 기업에서도 운영하는 클라우드가 늘어나면서, 매번 장비별로 컨테이너를 설정해주는 것이 어려운 일이 됐다. 가령 10개의 컨테이너만 있을 경우 담당자가 일일이 서비스를 올리고 내리고 하는 것이 가능하지만, 그 수가 100개, 200개로 늘어날 경우 사람의 통제 수준을 벗어나게 된다.

이에 중앙에서 여러 노드에 위치한 컨테이너들을 관리해주는 솔루션이 등장했다. 컨테이너 간 호출 등을 담당하는 오케스트레이션 기술이 적용된 것으로, 쿠버네티스가 대표적이다. 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해주며, 크고 빠르게 성장하는 생태계를 가지고 있다.

쿠버네티스는 구글이 컨테이너 관리를 위해 개발한 시작한 프로젝트였으며, 지난 2014년에 오픈소스화시킴으로써 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있게 됐다. 쿠버네티스는 구글이 15년여에 걸친 대규모 운영 워크로드 운영 경험을 기반으로 만들어졌으며 커뮤니티의 중요한 아이디어와 적용 사례가 결합된 것이 특징이다.

쿠버네티스는 모든 것이 포함된 서비스형 플랫폼(PaaS)이 아니며, 컨테이너 수준에서 운영되기 때문에 PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 모놀리식(monolithic)한 구조가 아니며, 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

쿠버네티스가 지원하는 애플리케이션의 유형에는 제약이 없다. 쿠버네티스는 상태 유지가 필요 없는(Stateless) 워크로드, 상태 유지가 필요한(Stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작한다.

또한 소스코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합, 지속적인 배포(CI/CD) 워크플로우는 기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다.

쿠버네티스 아키텍처
쿠버네티스 아키텍처

사실상 업계 표준으로 등극

쿠버네티스는 단순한 오케스트레이션 솔루션이 아니며, 오히려 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다.

반면 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성돼 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

불과 4~5년 전만 해도 다양한 컨테이너 오케스트레이션 기술이 시장에 존재했다. 그러나 현재는 대부분 쿠버네티스 기반으로 바뀌었으며, 경쟁사들도 쿠버네티스 기반 컨테이너 오케스트레이션 기술을 활용하기에 이르렀다. 최근 들어 많은 인기를 구사하면서 오픈스택보다 더 많은 관심을 받고 있기도 하다.

실제로 레드햇은 독자적인 컨테이너 기술을 보유하고 있었으나 도커 컨테이너와 쿠버네티스 기술을 빠르게 받아들여 이를 제품에 녹여낸 ‘오픈시프트’를 출시했으며, 이후 아마존웹서비스(AWS), 마이크로소프트(MS), IBM 등 주요 클라우드 업체들도 하나둘씩 쿠버네티스를 공식 지원하기에 이르렀다.

이처럼 쿠버네티스는 구글의 클라우드 오케스트레이션 운영·관리 노하우가 그대로 반영돼 있었기에 기능이 뛰어났으며, 빠른 시간 내 업계에서 주목을 받았다.
 

유연한 컨테이너 관리 방안 제공

쿠버네티스의 컨테이너 관리 방식은 소위 디스크립터(Descriptor)와 같아서 사용자가 컨테이너 배포에 필요한 자원이 얼마인지 입력하면, 그 이후는 쿠버네티스가 스스로 자원을 할당하고 컨테이너 서비스를 실행시킨다. 만약 컨테이너에 문제가 생겼다 해도 사용자 개입 없이 자동으로 재시작하기도 한다.

쿠버네티스의 또 다른 특징은 복제 개념을 갖고 있다는 것이다. 가령 단일 컨테이너가 정지하면 해당 컨테이너가 제공하는 서비스가 중단되는데, 이를 방지하고자 여러 복제본을 만들고 로드밸런서를 통해 자동 복제 기능을 제공하며, 일반 클라우드에서 VM이 하는 방식처럼 서비스가 무중단으로 업그레이드되게끔 롤링 업데이트도 제공한다.

이 같은 기능들로 인해 쿠버네티스는 알려진 도커 스웜과 아파치 메소스를 밀어내고 사실상의 표준(de facto) 클라우드 컨테이너 오케스트레이션 툴로 등극하게 됐다.

쿠버네티스는 설치 구성이 자유롭다. 구글의 사상이 오픈소스로 결합돼 있는 만큼 어느 클라우드 인프라에서건 동작하지 않는 곳이 없다.

처음 쿠버네티스가 등장했을 때 베어메탈 환경에서 사용하다가 점차 클라우드에 설치해 사용하는 방안들이 늘어났다. 만약 클라우드에 설치해 클러스터를 구성해 사용하던 중 자원이 꽉 찼을 경우에는 어떻게 해야 할까? 베어메탈에서는 별도로 네트워크를 연결하고 쿠버네티스를 설치해야 해서 불편하다. 하지만 클라우드는 VM을 API로 생성할 수 있으며 쿠버네티스도 주요 퍼블릭 클라우드 프로바이더를 지원하기에 자원 확장을 클라우드 API를 사용해 쿠버네티스 안에서 자동으로 실시한다. 외부 로드밸런서로 서비스를 노출하는 것도 자동으로 가능하다. 이를 통해 쿠버네티스가 클라우드 영역으로 완전히 올라오게 됐다.

초기 쿠버네티스는 구글 클라우드 플랫폼(GCP)을 비롯해 아마존웹서비스(AWS), 마이크로소프트 애저(MS Azure) 클라우드를 지원했으며, 이후 오픈스택과 프라이빗 클라우드도 지원하기에 이르렀다. 현재는 알리바바 클라우드에서도 쿠버네티스가 지원된다.

재미있는 사실은 이러한 클라우드 지원을 쿠버네티스가 자체적으로 했다기보다 클라우드 사업자들이 쿠버네티스를 지원하는 방향으로 이뤄졌다는 것이다. 이를 통해 사용자로서는 선택의 폭이 넓어졌고, 클라우드 상에서 쿠버네티스를 운영하기에 한층 용이해졌다.
 

쿠버네티스 기반 클라우드 사용 확대

클라우드 자체가 유연하게 인프라를 확장할 수 있고, API로 온디맨드 설계가 가능하지만 이를 관리하는 것 자체는 쉽지 않았다. 하지만 컨테이너 자체가 다이내믹하게 관리된다는 것은 클라우드를 좀 더 클라우드스럽게 만들어주는 역할을 했고, 이에 따라 클라우드 사용자 역시 늘어나며 클라우드 생태계가 점차 확대되기 시작했다.

2018년 기준 포춘 100대 기업의 75%가 이미 쿠버네티스를 도입하고 있으며, 현재는 클라우드 네이티브 컴퓨팅 파운데이션(CNCF)에서 쿠버네티스 프로젝트를 관리하고 있다.

초기에는 클라우드로 인해 쿠버네티스가 확장됐지만, 점차 쿠버네티스로 인해 클라우드 사용이 확대되는 경향이 늘어났다. 베어메탈을 운영하는 것은 전문적인 기술이 필요하고 복잡하다. 서버를 구매해서 사용하는 것이 비용적인 문제 외에도 하드웨어 네트워크 구성이 쉽지 않기 때문이다. 그러나 쿠버네티스가 베어메탈 환경을 지원하면서 사용자가 설정 몇 개만 건드리면 클러스터를 생성할 수 있게 되면서 베어메탈 도입에 대한 허들도 다소 줄어들었다.

그러나 쿠버네티스는 서비스형 플랫폼(PaaS)일까? 물론 PaaS 구성에 필요한 것들이 대부분 들어가 있는 것은 맞지만, PaaS라 단정 짓기에는 부족한 점들이 있다. 쿠버네티스는 말 그대로 가장 저변이 되는 플랫폼만 제공하며, 그 위에 소프트웨어들이 탑재되면서 PaaS를 구성하게 된다. 대표적으로 레드햇 오픈시프트, VM웨어 클라우드 파운드리(VCF), 나무기술의 칵테일 등이 이에 해당한다.

저작권자 © 테크데일리(TechDaily) 무단전재 및 재배포 금지