4. Container(컨테이너), Kubernetes(쿠버네티스)

Container

VM (Virtual Machine)은 하드웨어 가상화를 통해서 기존의 Host OS 위에 새로운 Guest OS를 얹어 별개의 독립된 운영체제를 구동하는 데 사용된다.

 

반면, 컨테이너(Container)는 기존의 Host OS 위에 컨테이너를 관리하는 별도의 소프트웨어가 개별 컨테이너(앱 + 서비스 + 미들웨어 등)를 관리하기에 동일한 OS를 공유하게 된다.

하지만 동시에, 각 컨테이너는 개별 파일 시스템, CPU, 프로세스 공간(Memory) 등을 가지게 된다.

 

컨테이너는 기존에 리눅스 계열에서 사용하던

  1. chroot : 특정 디렉토리를 새로운 최상위 디렉토리(root directory)로 설정하게 하는 명령어

  2. Namespace : 프로세스별로 독립적인 공간을 할당하여 관리하는 기능 - 즉 프로세스별 독립된 실행공간을 가질 수 있게 함

    - 현재 리눅스에는 크게 별개의 파일시스템 마운트, 독립적인 프로세스 공간 할당, 네임스페이스간 네트워크 충돌 방지, 프로세스간 통신 할당, 프로세스별 독립적인 호스트네임 할당, 사용자 할당의 기능을 지원한다고 한다.

  3. cgroup : 프로세스에 할당된 시스템 자원(cpu, memory 등)을 관리하는 기능

    - 네임스페이스는 시스템 자원을 할당하지는 못하기 때문

세 기능을 활용하여? 발전시켜? 시작되었다.

 

즉, chroot를 이용하여 새로운 루트 디렉토리를 설정하고 Namespace와 cgroup을 이용하여 프로세스를 분리한 후 독립된 자원을 프로세스별로 관리하는 것.

  - 이 방식이 초창기 리눅스에서 프로세스를 격리하여 사용하는 방법이었다.(LXC - Linux Container)

  - 이러한 컨테이너에서 사용하는 '이미지'란 실행에 필요한 각종 파일과 설정값들을 포함하고 있다.

 

사용자는 하나의 서버에 여러개의 컨테이너를 생성하고, 이미지를 이용하여 컨테이너를 설정한 후 별개의 업무를 수행시킬 수 있다.

 

컨테이너를 사용한 장점?

  - 컨테이너를 사용하여 서비스, 앱을 관리하는 경우, 각 서비스와 앱의 라이프사이클을 관리하기 용이하다. (애초에 컨테이너의 목적이 이러한 것 이다.)

  - 또한, 버전업이 필요한 경우에도 기존의 컨테이너에 새로운 운영 환경을 포함한 이미지를 만들어 적용시키면 간단하게 버전업도 가능하다(운영 환경 관리가 용이하다.)

 

앞서 말한 라이프사이클 관리의 경우, 컨테이너 오케스트레이션을 의미한다.

  - 오케스트레이션(Orchestration)이란 여러개의 컨테이너를 보다 쉽게 관리하도록 도와주는 것으로, 자동화된 설정 및 조절을 담당함.

 

쿠버네티스(Kubernetes)

이러한 컨테이너 오케스트레이션 기능을 제공하는 플랫폼 중 하나가 바로 쿠버네티스.

쿠버네티스가 제공하는 서비스는 크게

  - 컨테이너 그룹 로드밸런싱(load-balancing) : 특정 컨테이너의 네트워크 트래픽 로드밸런싱 등

  - 컨테이너 장애 복구 : 컨테이너의 상태를 저장해두고 되돌리거나 기존 컨테이너를 제거하고 새로운 컨테이너에 그대로 옮기기도 함. 이 외에도 작동을 멈춘 컨테이너를 재시작하거나 교체하는 작업도 수행

      - 설명에 따르면, '사용자 정의 상태 검사' 라는 것에 컨테이너가 응답이 없는 경우 컨테이너를 죽이고 다시 만든다고 한다.

  - 컨테이너 추가 및 제거

  - 컨테이너간 연결 및 포트 오픈

  - 서비스 디스커버리 : DNS, IP 등을 이용하여 컨테이너를 외부에 노출시킴

  - 빈패킹 자동화 : bin-packing(n개의 아이템을 m개의 방에 저장). 컨테이너별 필요한 리소스를 적절히 분배하거나 컨테이너를 추가하는 등의 작업.

등의 기능을 제공한다.

 

앞서 말했던 컨테이너가 중요한 서비스를 포함한 채 다운된다면? 혹은 수백 수천개의 컨테이너를 동시에 관리해야한다면?

이에 대한 해답을 주는 것이 쿠버네티스이다.

 

쿠버네티스에서 중요한 개념 중 하나는 'desired state'로, 관리자가 설정한 '이상적인 상태'를 의미한다.

관리자는 이러한 상태를 정의해두고, 쿠버네티스는 이러한 상태를 달성하고 유지하고자 하는 것을 주된 목적으로 삼아 동작한다.

 

 

쿠버네티스의 구조는 크게 마스터(Master), 노드(Node), Kubectl(Kube Control)이며

노드 안에는 kublet과 pod가 탑재되어있다.

 

사용자는 마스터에 직접 설정을 적용하거나 명령을 내리는 것이 아니라! kubectl을 이용하여 명령을 마스터에게 전달하고 마스터가 해당 명령을 알아서 노드에게 전달하게 된다.

  - 마스터는 3개 정도를 구성하곤 하는데 이는 시스템의 안정성을 위한 것

  - 마스터는 다양한 모듈로 구성되어 있는데, 그 중 가장 중요한 것이 API server이다.

  - 해당 서버는 입력된 모든 요청을 처리하는 서버로, kubectl에 의해 입력된 요청 외에도 내부 모듈에서 필요한 모든 요청을 처리하는 일을 담당한다.

  - 이 외에도, Scheduler와 Controller도 마스터에 포함되어 있는데, 각각 pod를 필요에 따라 할당하는 역할과 쿠버네티스의 오브젝트 상태를 전반적으로 관리하는 역할을 담당한다.

  - 즉, 생성된 pod를 할당하는 것은 스케쥴러, 관리하는 것은 컨트롤러 이다.

 

노드는 쉽게 생각해서 하나의 개별 피시이며, pod는 최소 1개의 컨테이너를 포함하고 있는 오브젝트이다.

  - pod는 쿠버네티스에서 배포할 수 있는 가장 작은 단위

  - 한개의 pod에 속한 컨테이너는 스토리지와 네트워크를 공유하게 되며, 상호간 접근이 가능하다.

  - 컨테이너를 단 한개만 사용하더라도 이를 pod로 묶어두어야 한다.

  - 쿠블릿(kublet)은 생성되어있는 pod의 라이프사이클을 관리한다.

  - 즉, 쿠블릿이 pod에 이상이 있으면 이를 재생성하기도 하고, pod에 전달된 요청을 처리하거나 명령을 수행하기도 한다.

 

이러한 pod들이 다수 모인 것을 ReplicaSet이라고 칭하며, replicas=3과 같은 선언을 통해 3개의 pod를 생성할 수 있다.  

ReplicaSet은 단순히 pod의 수를 제외하고, 각 pod별 설정값등을 저장하고 있다.

 

* 앞서 이야기한 모든 설정값들은 쿠버네티스에서는 YAML파일의 형태로 정의된다.