쿠버네티스 개념 총정리!!! 그림과 실습으로 배우는 도커 & 쿠버네티스

본 포스팅은 그림과 실습으로 배우는 도커 & 쿠버네티스를 바탕으로 작성되었습니다.

 

쿠버네티스란?

쿠버네티스는 여러 개의 컨테이너(=서버)를 관리하는 도구이다.

 

컨테이너 오케스트레이션 도구의 일종이다. 컨테이너 오케스트레이션이란 시스템 전체를 통괄하고 여러 개의 컨테이너를 관리하는 일을 말한다. 그 이름 그대로 오케스트라를 떠올리면 이해하기 쉽다. 지취자가 전체 악단을 지휘하듯, 여러 개의 컨테이너를 지휘하는 도구가 바로 쿠버네티스다.

 

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

 

또한 여러 개의 애플리케이션 서비스를 돌릴 때 worker node 중에 하나가 없어져도 끊기지 않고 서비스에 이상이 없게(no downtime)하는 개념을 내포한다.

 

도커와의 차이점

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

도커에서는 docker run 커맨드를 20번 실행해야 일일이 만들 수 있는데, 쿠버네티스는 이런 번거로운 컨테이너 생성이나 관리의 수고를 덜어주는 도구다. 정의 파일(매니페스트 파일)만 작성하면 이 정의에 따라 모든 물리적 서버에 컨테이너를 생성하고, 생성한 컨테이너를 관리해 준다. 

 

클러스터의 구성 - 마스터 노드와 워커 노드

쿠버네티스는 전체적인 제어를 담당하는 마스터 노드와 실제 동작을 담당하는 워커 노드라는 두 가지 유형의 노드로 구성된다. 

 

마스터 노드: 이름 그대로 감독과 같은 존재다. 집으로 말하면 대들보 같은 것으로, 마스터 노드에서 컨테이너를 실행하지는 않으며 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 따라서 도커 엔진 같은 컨테이너 엔진도 설치되지 않는다. 마스터는 컨테이너를 관리하는 업무로도 여력이 없기 때문이다. 관리직이 바쁜 것은 비단 사람에게만 해당되는 얘기는 아닌 것 같다.

마스터 노드에는 컨테이너 등의 상태를 관리하기 위해 etcd라는 데이터베이스가 설치된다. 

 

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

 

클러스터: 이렇게 마스터 노드와 워커 노드로 구성된 일군의 쿠버네티스 시스템을 클러스터라고 한다.

 

클러스터는 사람이 개입하지 않아도 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다.

관리자는 마스터 노드의 초기 설정 후 가끔 조정만 하면 되며, 관리자(나)가 직접 워커 노드를 관리하는 일도 없다.

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

 

마스터 노드 - 컨트롤 플레인

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

 

1. kube-apiserver: 외부와 통신하는 프로세스, kubectl로부터 명령을 전달받아 실행한다.

2. kube-controller-manager: 컨트롤러를 통합 관리, 실행한다.

3. kube-scheduler: 파드를 워커 노드에 할당한다.

4. cloud-controller-manager: 클라우드 서비스와 연동해 서비스를 생성한다.

5. etcd: 클러스터 관련 정보 전반을 관리하는 데이터베이스

 

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

 

워커 노드 - kube-let과 kube proxy

kubelet: 마스터 노드에 있는 kube-scheduler와 연동하며 워커 노드에 파드를 배치하고 실행한다. 또 실행 중인 파드의 상태를 정기적으로 모니터링하며 kube-scheduler에 통지한다.

kube-proxy: 네트워크 통신의 라우팅 매커니즘

 

출처: https://sungwookkang.com/1483

 

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

쿠버네티스도 컨테이너를 생성하거나 삭제할 수 있지만 일일이 명령어를 입력하는 방식을 사용하지는 않는다.

"컨테이너는 ㅇㅇ개, 볼륨은 xx 개로 구성하라" 와 같이 어떤 바람직한 상태를 YAML 파일에 정의하고, 자동으로 컨테이너를 생성하거나 삭제하면서 이 상태를 만들고 유지하는 것이 쿠버네티스의 기본적인 아이디어다. 

 

도커 컴포즈와는 다르게 이 상태를 유지하는 기능이 있다. 도커 컴포즈는 모니터링 기능이 없어서 컨테이너의 수를 바꾸는 등 컨테이너를 만들 때 외에는 관여하지 않는다.

 

그러므로 어떤 이유로 컨테이너가 망가졌다면 쿠버네티스가 알아서 망가진 컨테이너를 삭제하고 새 컨테이너로 대체하며,정의에서 '컨테이너 5개'를 '컨테이너 4개'로 수정하면 컨테이너를 한 개 삭제한다.

 

쿠버네티스의 기능은 어디까지나 자동으로 상태를 유지하는 것으로, 컨테이너를 삭제하고 싶다면 삭제 명령어를 입력하는 것이 아니라 파일에서 바람직한 상태를 수정해야 한다. 사람이 개입해서 지워봤자 마스터 노드의 명령으로 좀비같이 다시 생긴다 ㅎㅎ

 

쿠버네티스의 구성과 관련된 용어(파드, 서비스, 디플로이먼트, 레플리카세트)

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

출처ㅣ https://akasai.space/kubernetes/about_pod/

그림에서의 노드가 워커 노드.

 

 

서비스: 이들 파드를 이끄는 것이 서비스다. 서비스가 관리하는 파드는 모두 기본적으로 동일한 구성을 갖는다. 구성이 다른 파드는 별도의 서비스로 관리한다. 서비스는 여러 개의 파드를 이끄는 반장이므로 파드가 여러 개의 워커 노드(물리적 서버)에 걸쳐 동작하더라도 이들을 모두 관리한다.

 

서비스가 관리하는 파드는 모두 기본적으로 동일한 구성을 갖는다. 구성이 다른 파드는 별도의 서비스로 관리한다.

https://github.com/sungsu9022/study-kubernetes-in-action/issues/5

서비스는 클라이언트가 파드를 검색하고 통신을 가능하게 한다.

서비스는 각 파드에 요청을 배분한다.

 

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

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

 

예를 들어, 워드프레스 파드를 관리하는 반장은 워드프레스로 들어오는 요청이 한 파드에 몰리지 않게끔 적절히 분배한다.

 

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

 

 

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

 

파드는 파드에 요청을 배분하는 서비스라는 반장과 파드의 수를 관리하는 레플리카세트라는 반장에 의해 관리된다.

 

 

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

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

파드가 아이돌 그룹이고 컨테이너는 개인 멤버라면 디플로이먼트는 소속사에 비유할 수 있다. 

 

리소스: 파드, 서비스, 디플로이먼트, 레플리카세트 등을 리소스라고 한다. 

 

파드: 컨테이너 묶음

서비스: 파드에 대한 요청을 관리하는 반장 - 요청 관련

클러스터 IP: 각 서비스에 부여되는 대표 IP - 요청 관련 

레플리카세트: 파드의 수를 관리하는 반장 - 수와 관련

디플로이먼트: 레플리카세트의 상사 같은 개념으로, 파드의 배포에 관한 정보를 관리 - 수와 관련

 

매니페스트 파일이란?

파드나 서비스에 대한 설정을 매니페스트라고 하고, 이를 적은 파일을 매니페스트 파일(정의 파일)이라고 한다. 매니페스트 파일은 YAML 또는 JSON 형식으로 기재한다.

 

쿠버네티스는 매니페스트파일(정의 파일)에 기재된 내용에 따라 파드를 생성한다.

매니페스트 파일의 내용을 쿠버네티스에 업로드하면 그 내용이 데이터베이스(etcd)에 바람직한 상태로 등록되며, 서버 환경을 이 바람직한 상태로 유지한다.

 

매니페스트 작성

리소스 단위로 작성한다.

예를 들어 디플로이먼트나 서비스 단위로 작성.

예를 들어 아파치 파드를 만들려면 아파치 디플로이먼트와 아파치 서비스 이렇게 두 개의 리소스를 작성하면 된다.

 

파드는 단독으로 매니페스트 파일이 기재되는 경우가 드물며, 대부분 디플로이먼트에 포함되는 형태로 기재된다. 

파드 항목은 정말로 파드만을 만들 때 사용하는 항목이다.

디플로이먼트 항목에 레플리카 세트와 파드가 포함되어 있는 계층적 구조다.

 

 

apiVersion: API 그룹 및 버전

kind: 리소스 유형

metadata: 메타데이터

spec: 리소스 내용

 

메타데이터와 스펙

매니페스트 파일에는 메타데이터와 스펙을 기재한다.

메타데이터에는 리소스의 이름이나 레이블을 기재한다. 

스펙은 리소스의 내용을 정의한다. 요약하자면 어떤 리소스를 만들 것인가에 해당하는 부분이다.

 

metadata(리소스의 이름, 레이블)

스펙(아파치 컨테이너, 개수는 3개..)

 

레이블과 셀렉터

파드나 서비스 같은 리소스에 원하는 레이블을 붙일 수 있다.

레이블은 키-값 쌍의 형태로 메타데이터로 설정한다. 레이블을 부여하면 셀렉터 기능을 사용해 특정 레이블이 부여된 파드만을 배포하는 등 특정 파드를 선택해 설정할 수 있다.

 

예를 들어 펭귄 시스템, 바다코끼리 시스템이라는 서비스를 운영하는 회사가 골드 회원, 실버회원, 알루니늄 회원의 등급별로 파드를 나눴다고 생각해보자. 이를 레이블로 관리한다면 펭귄 시스템과 관련된 파드, 골드 회원과 관련된 파드를 지정해 액션을 취할 수 있다.

 

system: 펭귄

rank: 골드

 

system: 바다코끼리

rank: 실버

 

등이 있을 때 [rank: 골드]인 리소스만을 대상으로 선택해 액션을 취할 수 있다.

 

유형

유형은 서비스의 종류를 말한다. 다시 말해 외부로부터 서비스에 어떤 유형의 IP 주소 (또는 DNS)로 접근할지를 설정한다.

1. cluster IP: 클러스터 Ip를 통해 서비스에 접근하도록 함

2. nodePort: 워커 노드의 IP를 통해 서비스에 접근하도록 함

3. LoadBalancer: 로드밸런서의 IP를 통해 서비스에 접근하도록 함

4. ExternalName: 파드에서 서비스를 통해 외부로 나가기 위한 설정

 

쿠버네티스 명령어

kubectl

create 생성

apply 리소스의 변경 사항을 반영

describe 상세 정보를 확인

scale 레플리카 수를 변경

rollout 롤아웃을 수행

exec 컨테이너에서 명령을 수행

run 컨테이너에서 명령을 한 번 실행

attach 컨테이너에 접속

logs 컨테이너의 로그를 화면에 출력 

get pods 파드의 목록을 화면에 출력

 

매니페스트 파일 수정

메니페스트 파일로 파드의 개수를 늘리려면 replicas를 수정하면 된다. 

매니페스트 파일로 아파치를 nginx로 바꾸려면 image 이름을 apache에서 nginx로 바꾸면 된다.

 

 

본 포스팅은 그림과 실습으로 배우는 도커 & 쿠버네티스를 바탕으로 작성되었습니다.

책을 정말 추천합니다.

설명이 잘 나와 있습니다.