[Ops] Kubernetes란

 

쿠버네티스 (Kubernetes)란?

쿠버네티스는 컨테이너 오케스트레이션 도구의 일종이다

컨테이너 오케스트레이션이란 시스템 전체를 통괄하고 여러 개의 컨테이너를 관리하는 일을 말한다.

그 이르 그대로 오케스트라를 떠올리면 이해하기 쉽다. 지휘자가 전체 악단을 지휘하듯, 여러 개의 컨테이너를 지위하는 도구가 바로 쿠버네티스다

 

쿠버네티스를 k8s라고 줄여쓰디고 한다. k와 s사이에 8개의 글자가 있다는 의미의 약칭으로, 쿠버네티스와 관련된 검색어로 유용하다.

 

최근 쿠버네티스가 유행을 타고 있지만 그 본실상 일반적인 프로그래머가 쿠버네시스를 활발하게 사용할 일은 많지 않다. 왜냐하면 쿠버네티스는 앞서 설명했듯이 '여러 개의 컨테이너(=서버)'를 관리하는 도구이기 때문이다. 여기서 말하는 여러개란 동일한 구성의 컨테이너의 여러 세트를 말한다. 즉 많은 수의 서버로 구성되는 대규모 시스템을 관리할 일이 많은가, 라는 얘기가 된다.

 

이점을 감안하면 아무리 대규모 시스템을 개발하는 프로그래머라도 대규모 서버군을 프로그래머가 직접 관리할 일이 드물 듯이 쿠버네티스를 사용할 일도 드물 것이다.

 

다만 쿠버네티스로 어떤 일을 할 수 있는 가에 대한 지식은 시스템을 개발할 때 유용할 수 있다. 쿠버네스로 관리되는 시스템은 이를 전제로 개발해야 한다. 그렇지 않다면 쿠버네티스의 이점을 제대로 살릴 수 없다.

 

마찬가지로 프로젝트 매너저나 시스템 엔지니어를 담당하는 사람도 쿠버네티스로 어떤 일을 할 수 있는가는 잘 이해해야 한다. 

 

쿠버네티스는 여러대의 컨테니어가 여러 대의 물리적 서버에 걸쳐 실행되는 것을 전체로 한다.

도커는 한 대의 물리적 서버에서 실해되는 경우가 많아지만 쿠버네티스는 여러 대의 물리적 서버가 존재하는 것을 전제로 한다. 또 이 물리적 서버 한대 한대마다 재각기 여러 대의 컨테이너를 실행한다.

 

이렇게 여러 대의 서버에서 일일이 컨테이너를 실행하고 관리하기 쉬운 일이 아니다. 쿠버네티스는 바로 이를 위한 도구 이다. 예를 들어 20개의 컨테이너를 만들려면 docker run 커멘드를 20번 실행해야 할 것이다. 

 

도커 컴포즈를 사용한다 해도 물리적 서버가 여러 대라면 반복 작업은 사라지지 않는다. 거기다 어떻게든 컨테이너를 생성해 실행했다 해도 물리적 서버를 일일이 모니터링하면 장애가 일어나면 컨테이너를 다시 실행해야 하는 것은 물론이고 컨테이너를 업데이트하려면 다시 한번 큰 수고가 따른다. 

 

쿠버네티스는 이렇게 번거로운 컨테이너 생성이나 관리의 수고를 덜어주는 도구다. 도커 컴포즈에서 사용되는 컴포즈 파일과 비슷한 정의 파일(매니페스트 파일)만 작성하면 이 정의에 따라 모든 물리적 서버에 컨테이너를 생성하고, 생성한 컨테이너를 관리해 준다.

 

마스터 노드와 워커 노드

쿠버네티스는 전체적인 제어를 담당하는 마스터 노드와 실제 동작을 담당하는 워커 노드 두가지 노드로 구성된다. 노드는 거의 물리적 서버와 일치하는 개념이라고 보면 된다.

 

마스터 노드와 워커 노드는 그 역할에 차이가 있다. 

마스터 노드는 이름 그대로 감독과 같은 존재다. 집으로 말하면 대들보와 같다. 마스터 노드에서 컨테이너를 실행하지는 않으며 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 따라서 도커 엔진 같은 컨테이너 엔진도 설치되지 않는다. 

워커 노드는 실제 서버에 해당하는 부분으로 컨테이너가 실제 동작하는 서버다. 컨테이너가 동작해야 하므로 컨테이너 엔진이 설치돼야 하는 것은 물론이다. 

 

이렇게 마스터 노드와 워커 노드로 구성된 일군의 쿠버네시스 시스템을 클러스터라고 한다. 클러스터는 사람이 개입하지 않아도 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다. 관리자는 마스터 노드의 초기 설정 후 가끔 조정만 하면 되며, 관리자가 직업 워커 노드를 관리하는 일도 없다 

 

쿠버네티스는 도커 엔진 등의 컨테이너 엔진과는 별개의 소프트웨어다. 그러므로 쿠버네티스 소프트웨어와 CNI(Container Networking Interface: 가상 네트워크 드라이버)를 설치해야 한다. 대표적인 CNI 소프트웨어로 플란넬(flannel), 칼라고(Calico), AWS VPC CNI 등이 있다. 

가상 네트워크도 도커의 가상 네트워크와 쿠버네티스의 가상 네트워크가 서로 다르다. 도커의 가상 네트워크는 같은 물리적 컴퓨터 안에서의 네트워크인 데 비해, 쿠버네티스에서는 오버레이 네트워크이므로 다른 물리적 컴퓨터를 같은 로컬 네트워크로 묶기 위해 사용한다. 

 

또 마스터 노드에는 컨테이너 등의 상태를 관리하기 위한 etcd(키-값 스토러 타입의 데이터베이스)라는 데이터베이스가 설치된다. 워커 노드에는 물론 도커 엔진 같은 컨테이너 엔진이 필요하다. 

 

또 마스터 노드를 설정하는 관리자는 관리자의 컴퓨터에 kubectl을 설치한다. kubectl을 설치해야 마스터 노드에 로그인해 초기 설정을 진행하거나 추후 조정이 가능하다. 

 

컨트롤 플레인(제어판)과 kube-let

마스터 노드는 컨트롤 플레인을 통해 워커 노드를 관리한다

 

마스터 노드측 컨트롤 플레인의 구성

항목	내용
kube-apiserver	외부와 통신하는 프로세스, kubectl로부터 명령을 전달받아 실행
kube-controller-manager	컨트롤러를 통합 관리, 실행
kube-scheduler	파드를 워커 노드에 할당
cloud-controller-manager	클라우드 서비스와 연동해 서비스를 생성
etcd	클러스터 관련 정보 전반들 관리하는 데이터 베이스

etcd외에는 쿠버네티스에 포함돼 있으므로 굳이 추가 설치할 필요는 없다. etcd와 쿠버네티스만 설치하면 모든 설치가 완료된다. 

 

워커 노드에는 kube-let과 kube-proxy가 동작한다.  kube-let은 마스터 노드의  kube-schuduler와 연동하며 워커 노드에 컨테이너 또는 볼륨을 배치하고 실행한다. 이들 역시 쿠버네티스에 기본적으로 포함돼 있어 따로 설칠할 필요는 없다 

 

항목	내용
kube-let	마스터 노드의  kube-schuduler와 연동하며 워커 노드에 파드를 배치하고 실행한다. 또 실행 중인 파드의 상태를 정지적으로 모니터링하며  kube-schuduler에 통지한다
kube-proxy	네트워크 통신의 라우팅 매커니즘

 

쿠버네티스는 항상 바람직한 상태를 유지한다

쿠버네티스도 컨테이너를 생성하거나 삭제할 수 있지만 일일이 명령어를 입력하는 방식을 사용하지는 않는다. 바람직한 상태 (컨테이너는 00개, 볼륨은 XX개 구성) 를 YAML 파일에 정의하고, 자동으로 컨테이너를 생성하거나 삭제하면서 이 상태를 만들고 유지하는 것이 쿠버네티스의 기본적이 아이디어이다. 

 

이렇게 설명하면 도커 컴퓨터와 구별이 잘 가지 않을 수도 있겠지만 도커 컴포즈는 옵션을 지정해 수동으로 컨테이너의 수를 바꿀 수는 있어도 모니터링 기능이 없어서 컨테이너를 만들 때 외에는 관려하지 않는다. 이에 비해 쿠버네티스에는 상태를 유지하는 기능이 있다. 

그러므로 어떤 이유로 컨테니어가 망가졌다면 쿠버네티스가 알아서 망기진 컨테이너를 삭제하고 새 컨테이너로 대체하며, 정의한 내용으로 수정하면 컨테이너를 생성하거나 삭제한다. 

 

쿠버네티스의 구성과 관련 용어 

- 파드, 서비스, 디플로이먼트, 레플리카세트

 

파드는 컨테이너와 볼륨을 함께 묵은 것이다 

쿠버네티스에서 컨테이너는 파드(Pod)라는 단위로 관리된다. 파드는 컨테이너와 불륨을 함께 묶은 것으로, 기본적으로 파드하나가 컨테이너 하나이지만 컨테이너가 여러 개의 파드도 있을 수 있다. 

대규모 시스템이 여러 대의 서버로 구성되듯이 컨테이너도 여러 개로 구성하는 것이 기본이다. 

다만 파드에 포함되는 불륨은 기본적으로 함께 파드에 포함되는 컨테이너가 정보를 공유하기 위해 사용하는 것으로, 파드에 불륜이 없는 경우도 많다. 

 

파드가 모여 구성하는 서비스 

파드를 모은 것이 서비스(service)다. 서비스라는 용어는 여러 의미로 쓰이지만 여기서 말하는 서비스는 여러 개의 파드를 이끄는 반장이라고 생각하면 된다. 서비스가 관리하는 파든느 모든 기본적으로 동일한 구성을 갖으며, 구성이 다른 파드는 별도의 서비스로 관리한다. 서비스는 여러 개의 파드를 이끄는 반장이므로 파드가 여러 개의 워커 노드(물리적 서버)에 걸쳐 동작하더라도 이들을 모두 관리한다.

서비스 역할은 쉽게 말해 로드 밸런서 (부하 분산장치)다. 각 서비스는 자동적으로 고정된 IP 주소를 부여받으며 (cluster IP), 이 주소로 들오는 통신을 처리한다 

내부적으로는 여러 개으이 파드가 있어도 밖에서는 하나의 IP주소(cluster IP)만 볼 수 있으며, 이 주로 접근하면 서비스가 통신을 적절히 분배해주는 구조다. 

하지만 서비스가 분해나는 통신은 한 워커 노드 안으로 국한된다. 여러 워커 노드 간의 분배는 실제 로드 밸런서 또는 인그레스(ingress)가 담당한다. 이들은 마스터 노드도 워커 노드도 아닌 별도의 노드에서 동작하거나 물리적 전용 하드웨어다. 

 

디플로이먼스와 레플리카세트 

서비스가 요청을 배분하는 것이라면 레플리카세트(ReplicaSet)는 파드의 수를 관리하는 것이다. 장애등의 이유로 파드가 종료됐을 때, 모자라는 파드를 보충하거나 정의 파일에 정의된 파드 수가 감소하면 그 만큰 파드의 수를 실제로 감소시킨다. 

레플리카세트가 관리하는 동일한 구성의 파드를 레플리가 (Replica)라고도 부른다. 이 레플리카는 우리가 흔히 복제품으로 이해하는 것과 같다. 파드의 수를 조정하는 것을 '레플리카의 수를 조정'한다고 하거나 파드의 수를 결정하는 것도 '레플리카의 수를 결정'한다고 표현하기도 한다.

레플리카 세트를 단독으로 쓰이는 경우가 드물다. 왜냐하면 원하는대로 다루기가 어렵기 떄문이다. 따라서 레플리카세트는 디플로이먼트(deployment)와 함께 쓰일 때가 많다.

디플로이먼트란 파드의 디플로이(배포)를 관리하는 요소로, 파드가 사용하는 이미지 등 파드에 대한 정보를 갖고 있다.