[컨테이너] 02. 쿠버네티스 개념

1. 마스터 / 노드

  - 마스터 : 컨테이너 클러스터를 관리하는 중앙 집중식 컨트롤러

  - 노드 : 컨테이너가 배포되고 실행되는 머신

 

2. 오브젝트

  - 기본 오브젝트 : 가장 기본적인 구성단위

  - 컨트롤러 : 기본 오브젝트를 생성 / 관리 등 추가 기능 수행

  - 오브젝트 스펙 : 오브젝트는 오브젝트의 특성 (설정정보) 로 구성되며 이는 CLI 인자로 정의되거나, Yaml , Json 파일로 스펙을 정의한다.

 

2-1. 기본 오브젝트

  : 컨테이너 어플리케이션의 워크로드를 기술하는 오브젝트 종류로 Pod, Service, Volume, Namespace 4가지가 있다.

 

  1) Pod

    : 쿠버네티스의 기본 컨테이너 배포 단위로, 하나 이상의 컨테이너들을 포함하는 단위

    - 하나의 Pod 내의 컨테이너는 IP 와 Port 를 공유한다. ( 한 Pod 안에서 컨테이너 간 통신 시 localhost 를 통해 통신 가능 )

    - 하나의 Pod 내의 컨테이너간 디스크 볼륨을 공유할 수 있다.

  2) Volume

    : Pod 가동 시 기본적으로 컨테이너마다 로컬 디스크를 생성하여 연결한다. 하지만 이는 컨테이너가 재기동 혹은 다시 배포될 때 Pod 설정에 따라 다시 정의되어 데이터가 유실될 수 있다.

    - 위의 이유로 여러가지 타입으로 외부 스토리지에 연결하여 데이터를 보호할 수 있으며 이를 Volume 을 통해 연결한다.

  3) Service

    : Pod 는 동적으로 IP 가 바뀌기 때문에, 라벨 과 라벨 셀렉터를 이용하여 로드밸런싱 해준다.

    - 라벨은 Pod 에 지정해주고, 라벨 셀렉터를 Service 에서 지정하여 특정 라벨을 가진 Pod 들을 특정 포트로 로드밸런싱 해줄 수 있다.

  4) Name space

    : 쿠버네티스 클러스터 내에서 논리적인 분리단위이다.

    - 사용자 별 네임 스페이스 권한을 다르게 설정 가능

    - 네임 스페이스 별 리소스의 할당량을 다르게 지정 가능 ( CPU 수량 등 )

    - 네임 스페이스 별 리소스를 나눠서 관리 가능 ( Pod , Service 등 )

    + 네임 스페이스는 논리 단위라서 실제로 네임 스페이스간 분리되는것이 아니므로 서로 간의 통신을 안되게 분리하고자 한다면 클러스터를 분리하는 것을 권장한다.

 

2-2. 라벨

  : 메타데이터 섹션에 키/값 쌍으로 정의하며, 하나의 리소스에 여러 라벨을 동시에 적용할 수 있다.

  : 라벨 셀렉터는 쿠버네티스에서 2가지 방식으로 제공한다.

    1) Equality based selector : '=' or '!=' 으로 특정 키에 특정 값이 같냐 다르냐로 필터링한다. ( 밑에 RC 가 사용하는 방식)

      ex, floor = 10F

      ex, station != gangnam

    2) Set based selector : ''in' or 'notin' 으로 특정 키에 특정 값들 중 속하냐 안속하냐로 필터링한다. ( 밑에 Relica Set 이 사용하는 방식)

      ex, floor in (10F,11F)

      ex, station notint (gangnam,seocho)

 

2-3 컨트롤러

  : 앞서 4개의 오브젝트로 배포한 어플리케이션을 편하게 관리하기 위해 컨트롤러 개념이 사용된다.

  - 종류 : Replication Controller (RC) , DaemonSet, Job, StatefulSet, Deployment 등이 있다.

 

  1) Replication Controller (RC)

    : Pod 를 지정된 숫자로 가동시키며 이를 유지해준다. 파트는 아래 3가지로 구분된다.

    - Replica 수 : RC 에 의해 관리되는 Pod 의 수로, 해당 Pod 수를 유지시킨다. 적다면 새로운 Pod 를 띄우고, 많다면 남는 Pod 를 제거한다.

    - Selector : Pod Selector 는 라벨을 기반으로 RC 가 관리한 Pod 를 가지고 오는데 사용한다.

    - Pod Template : Pod 를 추가 기동 시 사용할 Pod 정보 (도커 이미지, 포트, 라벨 등) 를 정의한다.

    ** 만약 Pod 가 기동중일 때 새로 생성된 RC 의 라벨 셀렉터에 기존 Pod 라벨이 일치한다면 이 Pod 는 새로 생성한 RC 에 제어를 받게 된다. 즉, Replica 수 보다 많다면 RC 에 의해 제거될 수 있고, 적다면 RC 에 의해 Pod 가 추가되는데 템플릿에 기재된 패키지가 기존과 다르다면 다른 패키지를 사용하는 Pod 들이 생성될 수 있다.

 

  2) Replica Set

    : 기존 RC와 비슷하나 Pod 를 선정할 때 RC는 Equality 기반 Selector 이지만, Replica Set 은 Set 기반의 Selector 을 이용한다.

 

  3) Deployment

    : 먼저 서비스에 새로운 버전이 나왔을 경우 업데이트하는 방법을 살펴봐야 한다.

    1. Blue/Green 배포

      : 새로운 버전의 어플리케이션이 적용된 Pods 를 기존과 같은 수량으로 만들고 RC 도 신규에 맞게 새로 생성한다. 그리고 Load balancing 을 위해 사용하던 Service 오브젝트의 트래픽을 한번에 새로 생성한 Pod 들로 일괄적으로 이동시킨다.

    2. Rolling Upgrade

     : 기존 RC 의 수를 하나 줄이고 새로운 RC 에 새로운 버전의 Template 으로 하나 늘리며 배포하는 방식이다. 새로 배포되는 Pod 를 기존과 동일한 라벨을 주어 Service 오브젝트에서 로드밸런싱을 기존과 신규를 섞어서 동작하게 하여 서비스 단절이 없도록 진행하며 하나씩 바꾸어 나간다.

    - 하지만 이러한 방식들은 수동으로 작업이 필요하며, 각 과정마다 모니터링도 해야하며 문제 발생 시 롤백도 수동으로 해주어야 한다.

    - 때문에 이러한 과정을 자동화한 개념이 Deployment 이다.

 

    - Deployment 는 Pod 배포를 위해 RC 를 생성하고 관리하며, 롤백을 위한 기존 버전의 RC 관리 등의 기능이 포함되어 있다.

 

  4) DaemonSet (DS)

    : Pod 가 특정 노드들에서 하나씩만 동작하도록 하는 형태로 Pod 를 관리하는 컨트롤러이다.

    - "node selector" 기능을 이용하여 특정 노드에서 Pod 가 동작하도록 관리하는 식으로 사용할 수 있다.

 

  5) Job

    : 배치 작업같이 일회성 동작이 필요한 경우 사용한다.

    - Job 작업이 끝나면 Pod 도 같이 종료되어 사라진다.

 

  6) Cron jobs

    : 유닉스의 cron 과 유사하며 일회성 작업인 job 을 스케줄링하여 특정 시점마다 반복하게 한다.

    - 사용방법도 cron 과 유사하다.

 

  7) StatefulSet

    : Data Base 등과 같이 상태를 지니는 Pod 를 지원하기 위해 사용