쿠버네티스는 컨테이너 오케스트레이션을 위한 여러 도구 중 하나로 시작됐다. 10년이 지난 지금은 클라우드 네이티브 애플리케이션을 위한 선도적인 플랫폼이 됐다.
6월 6일은 쿠버네티스가 공식적으로 출시된 지 10주년이 되는 날이다. 쿠버네티스는 마이크로서비스 애플리케이션 내의 모든 소프트웨어 컨테이너를 더 쉽게 관리할 수 있는 컨테이너 관리 및 오케스트레이션 플랫폼으로 구축됐다. 수천 개의 인스턴스를 처리한 구글의 내부 컨테이너 관리 서비스인 Borg를 기반으로 하며, 구글은 다른 사람들이 컨테이너를 실행하는 데 활용할 수 있도록 오픈소스로 공개했다.
쿠버네티스가 출시되던 2014년에 대해 생각해 볼 필요가 있다. 당시에는 컨테이너를 관리하는 다양한 접근법이 있었다. 아피치 메소스(Apache Mesos)와 같은 대규모 오픈소스 프로젝트가 이미 있었고, 컨테이너화의 시발점이 된 도커는 도커 스웜을 통해 훌륭한 옵션을 제공했다. 이외에도 기업은 AWS ECS 관리 도구와 같은 방식과 이를 특정 컨테이너 관리에 어떻게 사용할 수 있는지 살펴보고 있었다.
그렇다면 쿠버네티스가 승리한 이유는 무엇일까? 클라우드 네이티브 애플리케이션을 위한 플랫폼으로 결국 쿠버네티스가 최종 채택될 가능성이 높았던 것일까? 아니면 장애물이 있었을까?
스테이트리스 워크로드에서 스테이트풀 워크로드까지
먼저 쿠버네티스는 소규모로 시작했다는 점이 중요하다. 구글이 엄청난 수의 워크로드와 프로세스를 관리하는 데 사용하는 도구를 기반으로 했지만, 처음부터 다른 조직에서 그 역할을 맡을 준비가 되어 있지 않았다. 쿠버네티스는 스테이트리스 애플리케이션 컨테이너를 관리하고, 이런 컨테이너가 생성, 사용, 폐기되는 방식을 오케스트레이션하는 데는 훌륭했다. 하지만 처음에는 애플리케이션 구성 요소에만 초점을 맞추었다.
이는 애플리케이션의 인프라를 구성하는 다른 모든 요소와 맞지 않았다. 애플리케이션은 클라우드에서 실행되어 처리를 수행할 수 있지만, 시간이 지나면서 저장해야 하는 데이터도 생성한다. 애플리케이션은 존재하는 데이터 소스와 상호 작용해야 한다. 또한 정보가 유출되거나 공격자가 이런 구성 요소에 액세스할 수 없도록 안전하게 작동해야 한다. 이런 요소는 쿠버네티스의 초기 릴리즈에서는 지원되지 않았다. 실제로 이런 워크로드를 고려할 수 있게 되기까지 StatefulSets 지원과 쿠버네티스 오퍼레이터 출시까지 2년이 더 걸렸다.
StatefulSets은 안정적이고 고유한 네트워크 식별자와 영구적인 스토리지를 지원했다. 또한 보다 질서정연하고 우아한 배포와 확장, 그리고 보다 질서정연하고 자동화된 롤링 업데이트를 수행할 수 있다. 이와 함께, 쿠버네티스 오퍼레이터의 출시로 개발자는 쿠버네티스 기본 요소를 다른 애플리케이션과 함께 사용하는 데 따르는 복잡성을 숨길 수 있게 됐다. 이 두 가지가 추가되지 않았다면, 쿠버네티스에서 스테이트풀 워크로드를 실행하려면 심각한 코어 해킹이 필요했다.
이와 함께, 쿠버네티스에서 스테이트풀 워크로드를 효과적으로 작동시키기 위한 커뮤니티의 노력이 있었다. MySQL 및 포스트그레SQL과 같은 데이터베이스 실행에 대한 논의는 레딧이나 스택 오버플로우 같은 곳에서 시작됐지만, 좋은 아이디어를 실제적이고 지속 가능한 프로젝트로 전환하기 위해서는 보다 공식적인 협업이 필요했다. 데이터 온 쿠버네티스(Data on Kubernetes) 커뮤니티와 같은 조직이 모여 이런 협업에 적합한 프레임워크를 제공함으로써 기업과 개인이 더 쉽게 기여할 수 있게 됐다.
처음에 쿠버네티스에서 데이터베이스를 실행하는 것에 대해 많은 반발이 있었기 때문에 이 작업은 필수적이었다. 애플리케이션 설계에 대한 12요소 접근 방식에 익숙한 사람들에게는 백엔드 서비스가 연결된 리소스로 취급되어야 한다. 당시에는 컨테이너에서 실행하고 싶지만 다른 환경에서 호스팅되는 데이터베이스나 스토리지 시스템과의 상호 작용을 관리해야 하는 개발자에게는 문제가 됐다. 이상적인 접근 방식은 데이터베이스가 애플리케이션 구성 요소와 똑같은 방식으로 클러스터에서 실행되어야 하며, 이렇게 하면 전체 서비스에서 인프라를 한 곳에서 쉽게 제어하고 관리할 수 있기 때문에 현재와 같은 접근 방식을 채택하고 있다.
오픈소스의 역할
쿠버네티스가 성공할 수 있었던 주요 이유 중 하나는 오픈소스였기 때문이다. 쿠버네티스는 클라우드 네이티브 컴퓨팅 재단에 기부되어 단일 솔루션 업체가 아니라 폭넓은 조직에서 지원할 수 있었다. 이는 기여 측면에서 부하를 분산하고 수용성을 높이는 데 도움이 됐다. 클라우드 컴퓨팅을 위한 플랫폼에 투자하는 방법을 고려할 때, 특정 클라우드 서비스 업체에 종속되지 않고 모든 플랫폼에서 독립적으로 컨테이너를 실행할 수 있는 플랫폼을 선택하는 것이 더 현명한 선택으로 여겨졌다.
이를 위해서는 쿠버네티스를 프로젝트로서 기꺼이 지원할 커뮤니티가 필요했고, 그 커뮤니티는 쿠버네티스의 성공을 위해 투자해야 했다. 이런 커뮤니티를 구축하기 위해서는 쿠버네티스가 오픈소스여야 한다고 쿠버네티스의 공동 개발자인 브렌든 번즈가 설명한 바 있다. 오픈소스가 아니었다면 개발자들이 쿠버네티스를 컨테이너 관리 도구로 선택하고 기여할 유인이 훨씬 적었을 것이다.
시간이 지나면서 쿠버네티스는 컨테이너 오케스트레이션을 위한 여러 도구 중 하나에서 클라우드 네이티브 애플리케이션을 위한 플랫폼이 됐다. 이를 통해 개발자는 모든 클라우드 플랫폼 또는 자체 데이터센터 환경에서 애플리케이션을 빌드하고 실행한 다음 향후에 원하는 플랫폼으로 해당 워크로드를 이동할 수 있다. 그 일환으로 쿠버네티스는 애플리케이션 구성 요소에 초점을 맞추던 것에서 클라우드의 모든 것을 지원하는 것으로 발전해 왔다.
쿠버네티스는 완벽하지 않다. 예를 들어, 쿠버네티스는 기업이 비용을 보다 효과적으로 제어할 수 있도록 데이터 및 스토리지와 같은 리소스를 자동 확장하고 관리하는 데 여전히 더 많은 작업이 필요하다. 하지만 여러 기업과 커뮤니티의 지원으로 이런 작업이 진행 중이므로 앞으로 모두가 혜택을 누릴 수 있다.
*Sergey Pronin은 오픈소스 데이터베이스 소프트웨어 지원 및 서비스 전문 업체 Percona의 그룹 제품 책임자이다.
editor@itworld.co.kr
