컨테이너 탐험가를 위한 ‘쿠버네티스’ 안내서

컨테이너는 2013년 도커(Docker) 컨테이너화 프로젝트가 런칭된 이후 인기가 높아졌다. 그러나 크고 분산된 컨테이너화 애플리케이션들은 조율이 점차 어려워질 수 있는 문제를 갖고 있다. 컨테이너화 된 애플리케이션을 대규모로 용이하게 관리할 수 있는 쿠버네티스가 컨테이너 혁신의 핵심으로 부상한 이유다.

컨테이너 오케스트레이션이란?
컨테이너는 VM과 유사한 분리 기능을 제공하면서도 비용이 훨씬 낮고, 유연성은 훨씬 더 크다. 그 결과, 컨테이너는 사람들이 소프트웨어 개발, 배포, 유지관리에 대한 사고방식을 바꿔 놓았다.

컨테이너화된 아키텍처의 경우, 하나의 애플리케이션을 구성하는 여러 서비스가 별개의 컨테이너로 묶여, 물리적 장치나 가상 머신의 클러스터에 배포된다. 그러나 이로 인해 컨테이너 오케스트레이션이 요구된다. 즉 컨테이너 기반 애플리케이션의 배포, 관리, 축소 및 확장, 네트워크 연결, 가용성을 자동화하는 도구가 필요해졌다.

쿠버네티스란?
쿠버네티스는 컨테이너 오케스트레이션 도구들 중 특히 인기를 끄는 오픈소스 프로젝트다. 다중 컨테이너 애플리케이션을 대규모로 배포해 관리할 수 있도록 도와준다. 쿠버네티스는 인기있는 컨테이너화 플랫폼인 도커와 함께 이용되는 경우가 많지만, 컨테이너 이미지 형식과 런타임에 대한 OCI 표준을 준수하는 다른 모든 컨테이너화 시스템도 지원한다. 

쿠버네티스는 활용 방식에 대한 제한이 적은 오픈소스이기 때문에 컨테이너를 운영하기 원하는 사람은 누구나 자유롭게, 그리고 온프레미스, 퍼블릭 클라우드, 두 곳 모두 등 장소에 구애 받지 않고 사용할 수 있다.
 

-> 칼럼 | 쏘리! 리눅스, 이제 주인공은 ‘쿠버네티스’다

구글과 쿠버네티스
쿠버네티스는 구글 내부의 프로젝트로 시작됐다. 구글이 내부에서 이용한 초기 컨테이너 관리 도구인 구글 보그(Borg)의 후계자(직접적이지는 않지만)이다. 2014년에 구글이 쿠버네스를 오픈소스로 공개했다. 

공개 이유 중 하나는 쿠버네티스가 도움을 주는 분산형 마이크로서비스 아키텍처가 클라우드에서 애플리케이션을 쉽게 실행할 수 있도록 해주기 때문이었다. 구글은 컨테이너, 마이크로서비스, 쿠버네티스 도입이 고객들을 클라우드 서비스로 유도할 잠재력을 갖고 있다고 판단했다(그렇지만 쿠버네티스는 애저와 AWS도 지원한다). 

쿠버네티스는 현재 리눅스재단 산하인 클라우드 네이티브 컴퓨팅 재단이 관리하고 있다.

쿠버네티스와 다른 프로젝트
쿠버네티스가 가장 많이 사용되고, 광범위하게 지원되는 도구가 되었지만, 유일한 대규모 컨테이너 관리 도구는 아니다. 고려할 가치가 있는 다른 선택지들도 존재한다.

– 쿠버네티스 Vs. 도커 및 도커 스웜 모드
쿠버네티스는 도커를 대체하지 않는다. 이를 보완한다. 그러나 도커와 관련된 고수준 기술들 가운데 일부를 대체한다.

이런 기술 중 하나가 ‘스웜(Swarm)’으로 불리는 도커 엔진(Docker Engine) 클러스터를 관리하는 시스템인 도커 스웜 모드(Docker swarm mode)이다. 이는 본질적으로 작은 오케스트레이션 시스템이다. 쿠버네티스 대신 도커 스웜 모드를 사용할 수 있지만, 도커(Docker Inc.)는 향후 도커를 핵심 요소로 지원하기로 결정했다.

쿠버네티스는 도커 스웜 모드보다 훨씬 더 복잡하고, 배포 과정에 많은 작업이 필요하다. 그러나 이런 작업은 장기적으로 큰 보상을 준다. 관리가 더 용이하고 탄력적인 애플리케이션 인프라일 수 있기 때문이다. 단 개발 작업과 더 작은 컨테이너 클러스트 환경에서는 도커 스웜 모드가 더 단순한 선택지일 수 있다.

– 쿠버네티스 Vs. 메소스
쿠버네티스와 경쟁하는 또 다른 프로젝트는 메소스(Mesos)이다. 메소스는 아파치 프로젝트로 트위터 개발자들이 최초 개발했다. 구글 보그 프로젝트의 ‘대항마’였었다.

메소스는 컨테이너 오케스트레이션 서비스를 제공하지만, 그 이상을 추구한다. 컨테이너화 요소와 그렇지 않은 요소를 모두 조율할 수 있는 클라우드 운영 체제를 지향한다는 의미이다. 따라서 여러 다양한 플랫폼을 메소스 내부에서 실행할 수 있으며, 여기에 쿠버네티스도 포함된다.

쿠버네티스 아키텍처: 작동 방식
쿠버네티스 아키텍처는 다양한 개념과 추상화를 이용한다. 기존의 친숙한 개념에서 변형된 것들도 있지만, 쿠버네티스에만 특정적인 것들도 있다.

– 클러스터
가장 높은 수준의 쿠버네티스 추상화인 클러스터는 쿠버네티스와 쿠버네티스가 관리하는 컨테이너를 실행하는 머신 그룹을 일컫는다. 쿠버네티스 클러스터에는 클러스터의 다른 모든 쿠버네티스 머신을 명령 및 제어하는 시스템인 마스터를 갖고 있어야 한다. 가용성 높은 쿠버네티스 클러스터는 여러 머신에서 마스터의 기능을 복제한다. 그러나 한 번에 한 개의 마스터만 작업 스케줄러와 컨트롤러 관리자를 실행한다.

– 노드와 팟
각 클러스터에는 쿠버네티스 노드(Nodes)들이 있다. 노드는 물리적 장치일 수도, VM일 수도 있다. 다시 강조하지만, 추상화 개념이 중요하다. 어떤 애플리케이션이 실행되든 쿠버네티스는 해당 기판(Substrate)에서 배포를 처리한다. 심지어 쿠버네티스를 이용, 특정 컨테이너가 VM이나 베어 메탈에서만 실행되도록 만들 수 있다.

노드는 생성하거나 관리할 수 있는 가장 기본적인 쿠버네티스 개체는 팟(Pod)이다. 각 팟은 쿠버네티스의 애플리케이션의 단일 인스턴스나 실행 프로세스이며, 하나 이상의 컨테이너로 구성된다. 쿠버네티스는 팟의 모든 컨테이너를 그룹으로 시작, 중지, 복제한다. 팟은 사용자가 컨테이너 자체가 아닌 애플리케이션에 집중할 수 있도록 해준다. 팟 상태부터 쿠버네티스를 구성하는 방법에 대한 자세한 정보는 분산 키 값 저장소인 Etcd에 저장된다.

팟은 사용자가 팟 정의로 명시한 상태에 부합하도록 필요에 따라 노드에서 생성되고 파괴된다. 쿠버네티스는 팟 스핀업, 배치, 스핀다운 방법을 다루는 컨트롤러라는 추상화를 제공한다. 컨트롤러는 관리될 애플리케이션의 종류에 따라 달라진다. 예를 들어, 스테이트풀세트(StatefulSet) 컨트롤러는 영구적 상태가 필요한 애플리케이션 처리에 이용된다. 디플로이먼트 컨트롤러는 앱의 축소나 확장, 새 버전으로 업데이터, 문제가 있을 때 알려진 정상 버전으로 롤백에 이용된다.

– 쿠버네티스 서비스
팟은 필요에 따라 만들어지고 없어지기 때문에 애플리케이션 생애주기를 다룰 또 다른 추상화가 필요하다. 애플리케이션을 구성하는 컨테이너를 실행하는 팟이 영구적이지 않은 경우에도 애플리케이션은 영구적이어야 한다. 이에 쿠버네티스는 서비스라는 추상화를 제공한다.

쿠버네티스의 서비스는 특정 팟 그룹(또는 다른 쿠버네티스 개체)를 네트워크를 통해 액세스 할 수 있는 방법을 설명한다. 쿠버네티스 자료에 따르면, 애플리케이션의 백엔드를 구성하는 팟이 변경될 수 있지만, 프론트엔드는 이를 알거나 추적해서는 안 된다. 서비스가 이를 가능하게 만든다.

쿠버네티스 내부에는 중요한 요소들이 몇개 더 있다. 스케줄러는 리소스 간 균형이 유지되고, 배포가 애플리케이션 정의의 요건을 충족하도록 워크로드를 노드에 분산시킨다. 컨트롤러 관리자는 애플리케이션, 워크로드 등 시스템 상태가 Etcd의 구성 설정에서 정의한 상태와 일치하도록 만든다.

도커 자체와 같이 컨테이너가 이용하는 저수준 메커니즘이 쿠버네티스로 대체되지는 않는다는 점을 기억하는 것이 중요하다. 쿠버네티스는 앱을 대규모로 계속 실행하기 위해 이런 메커니즘을 사용할 수 있도록 도움을 주는 추상화 기능들을 제공할 뿐이다.

– 정책
쿠버네티스의 정책은 팟이 특정 동작 기준을 준수하는지 확인한다. 예를 들어, 정책을 통해 팟이 CPU와 메모리, 프로세스 ID, 디스크 공간을 과도하게 사용하지 못하도록 막는다. 이런 ‘제한 범위’는 CPU는 상대적(예, 하드웨어 스레드의 50%), 메모리는 절대적(예, 200MB)이다. 이런 제한과 함께  리소스 할당 방법을 이용, (애플리케이션이 아닌)여러 쿠버네티스 사용자 팀이 동등하게 리소스에 액세스를 할 수 있도록 만든다.

– 인그레스
쿠버네티스 서비스는 클러스터 내부에서 실행된다. 그러나 외부에서 이런 서비스에 액세스 하기 원할 수도 있다. 쿠버네티스는 각기 다른 단순성과 견고성으로 이러한 니즈를 채워주는 몇몇 구성 요소들을 갖고 있다. 노드포트(NodePort)와 로드밸런서(LoadBalance)를 예로 들 수 있다. 그러나 가장 유연한 구성 요소는 인그레스(Ingress)이다. 인그레스는 통상 HTTP를 통한 클러스터 서비스에 대한 외부 액세스를 관리하는 API이다.

인그레스를 제대로 설정하려면 약간의 구성이 요구된다. 쿠버네티스 개발과 관련된 책을 쓴 매튜 파머는 자신의 웹사이트에 단계적 과정들을 소개하고 있다.

– 대시보드
이들 구성 요소를 모두 파악하는 데 도움을 주는 쿠버네티스의 구성 요소는 앱 배포 및 문제해결, 클러스터 리소스 관리에 이용할 수 있는 웹 기반 UI인 대시보드이다. 대시보드는 기본으로 설치되어 있지 않지만, 추가해도 큰 문제는 없다.

쿠버네티스의 강점
쿠버네티스에는 새로운 추상화와 개념들이 도입되어 있고, 학습 곡선이 가파르기 때문에 이를 사용했을 때 장기적인 이점을 묻는 것은 당연한 일이다. 다음은 쿠버네티스 내부에서 앱을 더욱 쉽게 실행하도록 해주는 구체적인 몇몇 방법이다.

– 쿠버네티스는 사용자를 위해 앱 상태, 복제, 로드 밸런싱, 하드웨어 리소스를 관리한다
쿠버네티스가 사용자의 수고를 덜어주기 위해 기본적으로 처리해주는 작업 중 하나는 애플리케이션을 구현, 실행하고, 사용자 요구에 대응하는 일이다. ‘건강하지 않은’ 앱, 정의된 상태에 부합하지 않는 앱을 자동으로 치료할 수 있다.

쿠버네티스가 제공하는 또 다른 이점은 메모리, 스토리지, I/O, 네트워크 대역폭 등 하드웨어 리소스 사용을 극대화하는 것이다. 애플리케이션 리소스 사용량을 약하게, 그리고 강하게 제한할 수 있다. 아주 적은 리소스를 사용하는 많은 앱을 동일한 하드웨어에 묶을 수 있다. 확장할 필요가 있는 앱은 확장 공간이 있는 시스템에 배치할 수 있다. 또 여러 클러스터를 대상으로 한 업데이트 배포, 업데이트에 문제가 있을 때 롤백을 자동화해 처리할 수 있다.

– 쿠버네티스는 헴(Helm) 차트를 이용해 사전 구성된 애플리케이션을 쉽게 배포한다
데비안 리눅스 APT와 파이썬 PIP 같은 패키지 관리자를 이용하면 사용자가 수동으로 애플리케이션을 설치해 구성하는 번거로움을 피할 수 있다. 애플리케이션에 여러 외부 종속성이 있을 때 특히 유용한 부분이다.

쿠버네티스의 패키지 관리자는 헴(Helm)이다. 대중적인 많은 소프트웨어 애플리케이션이 상호 의존적인 컨테이너 그룹으로 쿠버네티스에서 실행된다. 헴은 정의 메커니즘을 제공한다. 애플리케이션이나 서비스를 쿠버네티스 내부에서 컨테이너 그룹으로 실행할 수 있는 방법을 설명하는 ‘차트’가 여기에 해당된다.

처음부터 자신만의 헴 차트를 생성할 수 있다. 내부에 배포할 사용자 지정 앱을 구축한다면 이렇게 해야 할 수 있다. 그러나 공통된 배포 패턴을 갖고 있는 대중적인 애플리케이션을 이용하고 있다면, 누군가 이미 헴 차트를 만들어 아티팩트 허브(Artifact Hub) 게시했을 확률이 높다. 공식 헴 차트를 찾아볼 수 있는 또 다른 장소는 <Kubeapps.com> 디렉터리이다.

– 쿠버네티스는 스토리지, 시크릿, 기타 애플리케이션 관련 리소스를 쉽게 관리할 수 있도록 해준다
컨테이너는 불변이다. 여기에 집어넣는 코드와 데이터도 변경되면 안 된다. 그러나 애플리케이션은 상태가 필요하다. 외부 스토리지 볼륨을 처리할 수 있는 확실한 방법이 필요하다는 의미이다. 컨테이너는 앱 생애주기 동안 생성되고, 없어지고, 다시 생성되기 때문에 더욱 복잡해진다.

쿠버네티스는 컨테이너와 앱이 다른 리소스와 동일한 분리된 방식으로 스토리지를 처리하도록 추상화를 제공한다. 아마존 EBS 볼륨부터 구형 NFS까지 많은 대중적인 스토리지에 쿠버네티스 스토리지 드라이버를 통해 액세스 할 수 있다. 이를 볼륨이라고 부른다. 통상 볼륨은 특정 팟에 바운딩 되지만, ‘영구 볼륨(Persistent Volume)’이라고 불리는 볼륨 하위유형은 팟에 독립적이어야 하는 데이터에 이용할 수 있다.

컨테이너가 ‘시크릿’과 함께 작동해야 하는 때가 많다. 컨테이너에 하드코딩 되면 안 되며, 디스크 볼륨에 공개된 채 위치해서는 안 되는 API 키나 서비스 암호 같은 크리덴셜이 시크릿이다. 도커 시크릿(Docker secrets)과 해시콥 볼트(HashiCorp Vault) 같은 서드파티 솔루션도 있지만, 쿠버네티스에도 시크릿을 처리할 수 있는 자체적인 메커니즘이 있다. 단, 주의를 기울여 구성해야 한다.

– 쿠버네티스 애플리케이션은 하이브리드 클라우드와 멀티클라우드 환경에서 실행할 수 있다
클라우드 컴퓨팅 분야의 오랜 ‘꿈’ 중 하나는 모든 클라우드, 퍼블릭과 프라이빗을 혼합한 클라우드에서 모든 앱을 실행하는 것이다. 그러면 벤더 ‘록인’ 문제를 방지할 수 있다. 또 특정 클라우드에 특정적인 기능들을 이용할 수 있다.

쿠버네티스 SIG 프로젝트인 쿠버페드(KubeFed ; Kubernetes Cluster Federation)을 이용, 여러 지역과 클라우드에서 여러 클러스터를 서로 계속 동기화할 수 있다. 예를 들어, 여러 클러스터 간 특정 앱 배포를 일관되게 처리할 수 있고, 서로 다른 클러스터들이 백엔드 리소스를 어떤 클러스터이든 액세스할 수 있도록 서비스 디스커버리를 공유할 수 있다. 또 페더레이션을 이용해 가용성이 높거나, 장애에 강한 쿠버네티스 배포판을 생성할 수 있다. 여러 클라우드 환경에 배포해도 상관이 없다.

쿠버페드는 아직 베타 프로젝트이지만, 알파 수준의 구성요소를 갖고 있다. 이는 고수준 페더레이션 솔루션보다 미래에 기능을 구현하기 위해 사용되는 저수준의 구성 요소들을 대상으로 하고 있다. 쿠버페드 자료에 따르면, 긴급 복구나 여러 지역에 분산된 애플리케이션을 예로 들 수 있다.

쿠버네티스를 입수할 수 있는 장소
쿠버네티스는 오픈소스부터, 상업 배포판, 퍼블릭 클라우드 서비스 등 여러 형태를 갖고 있다. 이를 입수할 장소는 유즈 케이스를 참조하는 것이 좋다.

• 직접 구현하기 원하는 경우: 많이 사용되는 플랫폼을 대상으로 미리 구축된 바이너리, 소스 코드는 깃허브 쿠버네티스 리포지토리에서 다운로드 할 수 있다. 자신의 시스템에 작은 쿠버네티스 인스턴스를 테스트하고 싶다면, 미니쿠버(Minikube)를 사용해 단일 머신에 로컬 클러스터를 셋업 할 수 있다.

• 도커 커뮤니티나 도커 엔터프라이즈를 이용하는 경우: 도커의 가장 최신 에디션은 쿠버네티스를 팩인(Pack-in)으로 지원한다. 컨테이너 전문가들이 가장 쉽게 쿠버네티스를 배우는 방법이다. 이미 잘 알고 있을 제품을 매개체로 하기 때문이다(도커 또한 배포에 미니쿠버를 이용).

• 온프레미스나 프라이빗 클라우드에 배포하는 경우: 프라이빗 클라우드에 선택한 인프라에 쿠버네티스가 기본 탑재되어 있을 확률이 높다. 표준에 부합하고, 인증되었으며, 지원된 쿠버네티스 배포판을 수십 벤더들이 공급하고 있다.

• 퍼블릭 클라우드에 배포하는 경우: 3대 퍼블릭 클라우드 벤더들은 모두 쿠버네티스를 ‘as a service’로 제공한다. 구글 클라우드 플랫폼은 구글 쿠버네티스 엔진을 지원한다. 마이크로소프트 애저는 애저 쿠버네티스 서비스를 제공한다. 아마존은 기존 일래스틱 컨테이너 서비스에 쿠버네티스를 추가했다. 또 여러 많은 벤더들이 관리형 쿠버네티스 서비스를 제공하고 있다. 

튜토리얼
기본적인 사항은 모두 알아봤다. 이제 쿠버네티스를 시작할 준비가 됐다. 쿠버네티스를 다루면서, 스스로 사용 방법을 터득할 수 있도록 도움을 주는 튜토리올들이 많다. 가장 간단한 튜토리올은 쿠버네티스 프로젝트 사이트이다. 고급 정보는 퀵 코드(Quick COde)가 선정한 10대 쿠버네티스 튜토리올을 참조한다.  

자격증
쿠버네티스 작동 방식을 잘 알고 있다는 판단이 들고, 자신의 전문성을 고용주에게 증명하고 싶다면 리눅스 파운데이션과 클라우드 네이티브 컴퓨팅 파운데이션이 제공하는 쿠버네티스 관련 자격증에 대해 알아본다.

• 인증 쿠버네티스 관리자(Certified Kubernetes Administrator): CKA 자격증 보유자는 애플리케이션 생애주기 관리, 설치, 구성, 검증, 클러스터 유지보수, 문제 해결 등 쿠버네티스 관리자로서의 책임을 수행할 스킬, 지식, 자격을 갖추고 있음을 보증하는 자격증이다.

• 인증 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer): 쿠버네티스용 클라우드 네이티브 애플리케이션을 고안, 구축, 구성, 노출할 수 있음을 증명하는 자격증이다.

자격증 시험은 각각 375달러이다. 교육 과정도 제공된다. 관심이 있는 사람들이 쿠버네티스에 대해 더 체계적으로 학습을 할 수 있는 과정이다. dl-ciokorea@foundryco.com