[GCP] Google Cloud Plaform - Container, Kubernetes, Kubernetes Engine

이 포스팅은 Coursera의 Google Cloud Platform Fundamentals:Core Infrastructure 강의를 요약 정리 한 것입니다.

---

Container, Kubernetes, Kubernetes Engine

 

이전 포스팅에서 GCP의 IaaS인 컴퓨팅 엔진에 대해 알아보았다. 컴퓨팅 엔진은 클라우드에서 가상 머신을 구동할 수 있게 하고 영속 저장소와 네트워크를 제공해준다. 그리고 GCP의 PaaS인 앱 엔진에 대해 알아보았다. 이번에는 쿠버네티스(kubernetes) 엔진에 대해 알아보자. 쿠버네티스 엔진은 인프라 스트럭처를 절약한다는 점에서 IaaS와 같지만 개발자의 요구를 염두해두고 구축된 PaaS와 같은 특징이 있다.

 

이에 앞서 컨테이너라고 불리는 소프트웨어 패키지 방식에 대해 알아보자. 컨테이너가 유용한 이유는 무엇이고 쿠버네티스 엔진에서 어떻게 이 컨테이너들을 관리할까? 먼적 기억해야 할 것은 IaaS가 하드웨어 가상화를 통해 컴퓨팅 자원을 다른 사람들과 공유한다는 점이다. 각각의 가상 머신은 개별적으로 OS 인스턴스를 가지고 있으며 이 환경에서 어플리케이션을 빌드하고 구동할 수 있고 실제 컴퓨터처럼 메모리, 파일 시스템, 네트워크 인터페이스와 같은 어트리뷰트에 접근할 수 있다. 그러나 유연성은 비용을 동반한다. 이런 환경에서 컴퓨터의 가장 작은 단위는 어플리케이션이 배포된 가상 머신이다. 가상 머신에 Guest OS를 설치하기 위해서 수 기가바이트의 용량이 필요하고 부팅에도 상당한 시간이 소요된다. 물론 이것은 가치가 있다. 가상 머신은 설정이 용이하고 원하는 툴을 설치하고 실행할 수 있다. 그래서 가상 머신이 디스크, 네트워크와 같은 하부 시스템의 리소스를 사용하게 설정하고 가상 머신 위에 웹서버, 데이터베이스, 미들웨어 등을 설치할 수 있다. 그러나 서비스의 성공으로 어플리케이션이 확장된 경우를 가정한다면 수요가 늘어날수록 개별적으로 Guest OS가 설치된 가상머신 전체를 스케일 아웃해야한다. 이것은 자원의 고갈이 가속화된다는 것을 의미한다.

 

대조적으로 App Engine과 같은 PaaS 환경인 경우를 생각해보자. App Engine에 배포하는 사람의 관점에서 본다면 위의 경우와는 매우 다르다. 빈 가상 머신을 얻는 대신 어플리케이션에 필요한 서비스 제품군에 액세스 할 수 있다. 따라서 이런 서비스를 사용하고 의존 라이브러리를 포함하는 코드 및 Self-contained한 워크로드를 작성하기만 하면 된다. 어플리케이션의 수요가 증가할수록 플랫폼은 워크로드 및 인프라별로 어플리케이션을 원활하고 독립적으로 확장한다. 이런 확장은 매우 빠르지만 기본 서버 아키텍처에 대한 제어는 포기하게 된다.

 

이것이 컨테이너가 필요한 이유이다. 컨테이너 컨셉은 PaaS환경처럼 워크로드의 독립적인 확장성과 IaaS환경에서 얻을 수 있는 운영체제 및 하드웨어의 추상화 계층을 제공한다. 파일 시스템과 하드웨어의 자체 파티션에 제한적으로 액세스하여 코드와 의존성을 감싸고있는 보이지않는 박스가 어떤 이점을 가질까? 윈도우, 리눅스 및 다른 운영 체제에서 프로세스는 프로그램이 동작하는 인스턴스라는 것을 기억해야한다. 컨테이너는 프로세스만큼 빠르게 실행된다. 운영체제의 새 인스턴스가 완전히 부팅되는 시간과 비교하였을 때 이는 아주 짧다. 각 호스트에서 필요한 것은 컨테이너 및 컨테이너 런타임을 지원하는 운영체제이다. 컨테이너는 본질적으로 하드웨어가 아닌 운영체제를 가상화 하고 있다. 이 환경은 PaaS처럼 확장되지만 IaaS와 같은 유연성을 갖는다. 컨테이너 추상화는 코드 이식성을 높이고 운영체제와 하드웨어를 블랙박스처럼 다룰 수 있다. 그렇기 때문에 코드를 개발환경, 스테이징, 프로덕션 또는 개인 컴퓨터로 부터 클라우드로 어떤 변화나 재빌드 없이 이식할 수 있다. 예를들어 웹 서버로 확장한 경우 단 몇 초 만에 확장할 수 있으며 단일 호스트의 워크로드 크기에 따라 수십 또는 수백 대를 배포할 수 있다.

 

이것은 간단한 예에 불과하고 조금 더 복잡한 경우를 생각해보자. 만약 마이크로 서비스 패턴등을 활용하여 독립적인 기능을 수행하는 많은 컨테이너를 사용하여 응용 프로그램을 구축하고 있다고 한다고 가정해보자. 이 컨테이너에서 실행되는 코드 단위는 네트워크 패브릭을 통해 서로 통신할 수 있다. 이런 방식으로 구축한다면 어플리케이션 모듈식으로 만들 수 있다. 이것들은 쉽게 배포가능하고 호스트 그룹 전체에 독립적으로 확장할 수 있다. 호스트는 어플리케이션에 대한 요구가 변경되거나 호스팅에 실패하고 교체될 때 컨테이너를 확장(scale up)과 축소(scale down)이 가능하고 컨테이너를 가동, 정지할 수 있다. 이것을 도와주는 도구가 바로 '쿠버네티스(kubernetes)'이다. 쿠버네티스는 여러 호스트의 많은 컨테이너를 간편하게 오케스트레이션하도록 해준다. 또한 이것들을 스케일하고 새로운 버전으로 롤 아웃하고 심지어 문제가 생길경우 이전 버전으로 롤백시킨다.

 

컨테이너를 어떻게 빌드하고 가동하는지 살펴보자. 컨테이너 이미지를 위한 가장 일반적인 포맷은 오픈소스 도구인 도커(docker)에 정의되어 있다. 도커를 통해 어플리케이션과 의존성을 번들할 수 있다. 또 다른 도구로는 Google Cloud에서 제공하는 컨테이너 빌드를 돕는 서비스인 Cloud Build를 활용할 수 있다. 도커를 이용해 실행 가능한 컨테이너 이미지를 생성하고 도커의 실행 명령어를 통해 이미지를 실행시킬 수 있다. 또한 컨테이너 이미지를 Google Container Registry와 같은 컨테이너 레지스트리 서비스에 업로드하여 공유하고 다운로드 받을 수 있다.