쿠버네티스가 뭔가요?
쿠버네티스에 대해 공부하기 전에, 먼저 쿠버네티스가 무엇인지 공식 문서를 보자. 사실 여러 번 보려고 시도 했지만 추상화가 너무 많고 설명이 복잡해 크게 와닿지 않았다. 그래서 나의 언어로 공식 문서를 요약 및 보충 정리해 보자면, 쿠버네티스는 컨테이너들의 작업 과정 및 서비스를 관리하기 위한 시스템이다. 컨테이너가 뭔지도 모른다면 이전 ft_server 시리즈를 참조하자. 쿠버네티스는 이미 만들어 놓은 애플리케이션 개발, 배포 및 관리 환경을 다른 곳에 쉽게 옮겨 심을 수 있고, 작업 구성 및 자동화를 용이하게 해준다.
전통적인 개발 방식에서, 하나의 애플리케이션을 하나의 물리적 서버 (하나의 컴퓨터)에서 실행하는 것은 많은 부분에서 비효율적이었다. 이후 가상화를 통해 (VM, Virtual Machine) 단일 물리 CPU에서 여러 가상 환경들을 만드는 방식으로 애플리케이션 배포를 했다. 여기에서 더욱 효율적인 방식으로 나아간 것이 도커가 제공하는 컨테이너 개념이다. 컨테이너는 VM이 각각의 운영체제를 가져야 하는 격리 속성을 완화하고, 애플리케이션의 베이스가 되는 운영체제는 컨테이너끼리 공유한다. 그래서 컨테이너는 VM보다 가볍고 효율적이다. 그러면서도 VM과 마찬가지로 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등을 갖기 때문에 종속성이 없고, 그래서 이식성이 좋다.
이외에도 많은 편리성이 있는데, 더 궁금하면 공식 문서를 참조해서 보자.
쿠버네티스가 할 수 있는 일
서비스 디스커버리와 로드 밸런싱
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션
쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백
쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
자동화된 빈 패킹(bin packing)
컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
자동화된 복구(self-healing)
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
한마디로, 애플리케이션 배포 환경을 구성하고, 애플리케이션에 문제가 생겼을 때 점검하고, 다운됐을 때 미리 만들어 둔 조건에 따라 애플리케이션을 복구하고, 트래픽이 몰릴 때 분산시켜 주고, 할당된 도구들(CPU, 메모리 등)을 사용 환경에 맞게 최적화해서 사용할 수 있게 해주는 등, 애플리케이션 개발 및 배포 후 관리에 있어서 번거로운 작업들을 대신해 주는 아주 좋은 놈이라고 할 수 있겠다.
쿠버네티스가 아닌 것
어렵게 느껴지는 어떤 것에 대해 제대로 알려면 그 자체에 대해 설명하려는 것보다, 그 자체가 '아닌 것'을 떠올려 보면 더 명확한 경우가 많다. 공식 문서에서도 이를 인식했는지, 쿠버네티스가 '아닌 것'에 대해 정리하고 있다. 그 전에, 아래 이미지를 보자.
위 이미지는 클라우드 컴퓨팅의 종류에 대해 설명하고 있다. PaaS, SaaS, IaaS에 대한 더 자세한 설명은 여기를 참조하자. 그리고, 쿠버네티스가 무엇인지 정확히 알기 위해 꼭 필요하므로 혹시 이 글이 누군가에게 도움이 될 상황을 생각하며 조금 자세히 써 보겠다.
이미지에서 가장 왼쪽 Packaged Software의 경우, 사용자가 직접 소프트웨어를 만드는 것을 의미한다. 어플리케이션(응용 프로그램 자체), 데이터, 런타임(실행 환경), 미들웨어, 운영체제(O/S), 가상화, 서버, 스토리지, 네트워킹 등을 다 직접 만들어야 한다.
예를들어 내가 자주 사용하는 구글 드라이브에 대해 생각해 보자. 나는 구글에 접속해서 구글 드라이브 아이콘을 더블클릭하기만 하면 바로 이 서비스를 사용할 수 있다. 그치만 만약, 이 애플리케이션을 내가 직접 만들어서 쓰려면 위에 나열한 모든 것들을 직접 만들어야 한다. 거기에다, 물리적인 환경인 CPU, RAM, Storage, Network device 등의 하드웨어들도 또한 모두 직접 만들어야 한다. 이것은 내가 지금부터 전자공학, 전기공학, 컴퓨터공학 등을 공부해도 어려운 일일지 모른다.
그래서 보통 일반 사용자들에게 친숙한 환경은 SaaS일 것이다. 이미지에서 맨 오른 쪽. 구글 드라이브, 지메일, 네이버 클라우드박스(구 엔드라이브), 드롭박스, MS 오피스365 등의 서비스가 이러한 SaaS에 해당한다. 소프트웨어는 이미 다 만들어진 상태로 유저들이 사용하기만 하면 되는 형태로 제공되며, 모든 필요 조건들이 이미 다 구성되어 벤더(공급자)에 의해 관리된다.
예를들어 SaaS가 지메일이라고 생각해 보면, PaaS와 IaaS에 대한 개념은 이해하기 쉬울 것이다. 단순히 '사용하기만 하면 되는'게 아니라, 이제 조금씩 직접 관리하고 개발하는 영역이 넓어진다. PaaS는 소프트웨어를 만들기 위해 필요한 데이터, 그리고 애플리케이션을 직접 관리 및 개발한다. 어떤 응용 프로그램을 만들기 위해 필요한 기반 환경들을 벤더들이 제공하고, 개발자들은 그 위에서 개발 실력을 발휘해 프로그램을 만들면 된다.
Heroku, Google App Engine, IBM Bluemix, OpenShift, SalesForce 등의 서비스들이 PaaS의 예시이다. 웹 개발자들에게 친숙한 Heroku를 예시로 설명해 보자면, 웹 애플리케이션을 만들어 서버위에서 구동할 수 있도록 쉬운 배포를 도와주는 플랫폼이다.
이 서비스는 웹 프론트엔드 개발자들 사이에서 많이 사용하는데, 나처럼 웹사이트를 실제로 유저들에게 접근 가능하도록 서버에 올리는 과정에서의 백엔드 지식 및 기술적 한계를 느끼는 사람들에게, 프론트엔드 웹 개발만 가지고도 웹 애플리케이션을 배포할 수 있도록 배포 환경을 제공해 준다. 따라서, 이미 만들어진 환경에서 요구하는 사양에 맞게 설정을 하고 코드를 올리면 웹사이트가 구동되는 것이다.
IaaS의 경우, 아마존 AWS를 생각하면 쉽다. IaaS 정도까지 오면 개념 및 사용법이 상당히 어렵게 다가온다. 웹개발자를 희망하는 나조차 AWS 사용에 있어서는 이름만 떠올려도 머리가 아플 정도다. 이에 관련하여, 좋은 아티클이 있다. 여기를 참조해 보자.
이제 쿠버네티스가 '아닌 것'에 대해 알아보자. '쿠버네티스는 (헤로쿠와 같은) PaaS가 아니다.'라고 공식 문서에서 말하고 있다. 쿠버네티스는 PaaS가 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하고, 사용자가 로깅, 모니터링, 알림 솔루션 등을 이용할 수 있지만 이 모든 것을 필수적으로 사용해야 하는 것이 아니며 레고 혹은 모듈처럼 추가하거나 제거하기 쉽다.
그렇담 쿠버네티스는 iaas인가? 나처럼 생각하는 사람들이 많았는지, 구글링을 하니 아래 처럼 자동완성이 되었다.
이 기사에 따르면, 쿠버네티스는 PaaS이다. 정리해 보면, PaaS의 표준으로 자리잡을 만큼 강력한 서비스 플랫폼이긴 하지만 기존의 PaaS보다 훨씬 효율적인 플랫폼이라고 말할 수 있겠다. (다만 효율적인 만큼 설정해 주어야 하는 부분도, 알아야 하는 개념도 많다.) 클라우드 컴퓨팅에 대해 조금의 이론적 배경이 있다면, 해당 기사를 읽으면 쿠버네티스 이해에 큰 도움이 될 것이다.
쿠버네티스 클러스터의 아키텍쳐
공식 문서 및 구글링을 참조해서 Key:Value 형식으로 정리해 보겠다.
클러스터
쿠버네티스를 배포하면 얻는 결과물. 우리가 ft_services에서 제출해야 할 것. '노드'의 집합이다. 모든 클러스터는 최소 한 개의 노드를 가진다. 클러스터의 아키텍쳐를 구성하는 요소들에 대해 잘 알고 있어야 우리가 원하는 결과물을 얻을 수 있다.
쿠버네티스의 기술적 구성. 클러스터링이라는 말은 여러 개의 서버를 묶어 하나의 서버처럼 사용할 수 있도록 지원하거나, 가상 네트워크를 이용해 산재된 서버를 연결하는 것.
워커 노드(또는 노드)
애플리케이션의 구성 요소인 파드(또는 팟)을 호스트.
노드 컴포넌트
동작 중인 파드를 유지시키고, 런타임 환경을 제공하고, 모든 노드에서 동작한다.
kubler, kube-proxy, 컨테이너 런타임 등이 있다.
컨트롤 플레인
워커 노드, 파드를 관리하는 관리자.
컨트롤 플레인 컴포넌트
클러스터에 관한 전반적인 결정을 수행하고, 클러스터 이벤트를 감지하고 반응한다. kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager 등이 존재한다.
애드온
쿠버네티스 리소스를 이용하여 클러스터 기능을 구현하는 역할을 한다. DNS, 웹 UI(대시보드), 컨테이너 리소스 모니터링, 클러스터-레벨 로깅 등이 존재한다.
노드, 컨테이너, 워크로드, 서비스/로드밸런싱/네트워킹, 스토리지, 구성, 보안, 스케줄링 및 축출, 정책, 클러스터 관리, 쿠버네티스 확장 등에 대한 더 자세한 개념은 공식 문서를 참조해 보자.
이제 이쯤 했으면...
더 잘 정리된, 더 고급 지식을 가진 많은 분의 문서를 참조하자. 시작부터 잘 정리된 문서를 보는 것보다 공식 문서를 보고 이해하려고 노력한 다음 보는 게 훨씬 도움이 많이 된다. 아래 링크에 접속해 왼쪽 인덱스를 보고 천천히 개념을 파악한 다음, 우리 프로젝트가 요구하는 기능들에 관한 내용을 다시 정리해 보자.
여기서 가장 중요하다고 생각되는 문장을 인용하면, "쿠버네티스는 복잡하고 다양한 작업을 하지만 자세히 들여다보면 현재 상태current state를 모니터링하면서 관리자가 설정한 원하는 상태를 유지하려고 내부적으로 이런저런 작업을 하는 단순한(?) 로직을 가지고 있습니다. (...) 쿠버네티스의 핵심은 상태이며 쿠버네티스를 사용하려면 어떤 상태가 있고 어떻게 상태를 선언하는지를 알아야 합니다." 일 것이다.
위의 정리를 읽고 나서, 쿠버네티스 안내서를 보면서 실습을 해 보자. 실습을 마친 뒤, 다음 포스트에서는 본격적으로 YAML 파일을 이용해 프로젝트가 요구하는 쿠버네티스 컨테이너의 명세를 지정해 보겠다.
