쿠버네티스

1. 등장배경

도커로 배포한 앱 서버가 3 ~ 5개 있다고 하자. 서비스가 커지면서 대용량 트래픽을 감당하기 위해, 빠른 시간 내 컨테이너를 몇 십 개로 늘려야하는 상황이 왔다. 이때 기존 서버를 다운 시키는 일 없이 컨테이너를 늘리기 위해 어떻게 할 것인가?

컨테이너가 어마어마하게 증가한다면, 도커만으로는 관리가 어려워지기 때문에 이를 운영, 모니터링할 툴이 필요하다.

2. 하는 일

도커와 쿠버네티스의 가장 큰 특징을 말하면, 도커는 애플리케이션을 컨네이너화하고 쿠버네티스는 오케스트레이션을 쉽게 해주는 자동화된 파이프라인에 가깝다.

3. 특징

• 오케스트레이션에 들어가는 리소스를 줄여준다.

공식문서에서는 쿠버네티스가 오케스트레이션의 필요성을 없애준다고 표현했다. 오케스트레이션이 ‘A를 하고, A를 하면 B를 하고, B를 하면 C를 하는 것’과 같이 정의된 워크플로우를 수행하는 것이라면, 쿠버네티스는 자동화된 프로세스 처리를 통해 운영자가 오케스트레이션에 들이는 리소스를 줄일 수 있도록 한다.

• 다양한 앱과 기능을 지원한다.

꼭 도커가 아니라도, 여러 컨테이너를 지원한다. 또한, 다음에 소개할 기능들처럼 다양한 기능을 지원하기 때문에 관리자의 선택권이 많아진다.

다양한 앱과 기능을 지원하기 때문에 monolithic(단단하게 하나로 잘 짜여진)하지는 않고, 융통성 있고 유연한 오케스트레이션 툴이다.

쿠버네티스의 기능

1. 서비스 디스커버리

내가 어디에 서비스를 올렸는지 알려준다.

2. 스토리지 오케스트레이션

사용자가 올리는 파일, 개발자가 관리하는 파일 등을 어디에 저장할 것인가. 또한, 그렇게 정한 storage(저장소)를 컨테이너에 마운트할 수도 있다.

3. 자동화된 롤백, 롤아웃

버전만 알려주면 다운타임 없이(서버를 다운시키는 일 없이) 버전 배포가 가능하다.

4. 자동화된 빈 패킹

각 컨테이너에 필요한 CPU, 메모리(RAM) 용량을 지정할 수 있다.

5. 자동화된 복구

문제가 생기면 스스로 어떻게 해결한다. 서버가 언제든지 죽을 수 있고, 늘어날 수 있는 ‘가축’처럼 변하면서 일부 서버가 죽어도 사용자에게 서비스를 할 수 있는 시대가 되었다. 하지만 서버의 대다수가 죽으면 운영이 위험하기 때문에, 서비스하던 노드가 죽으면 다른 노드에 컨테이너를 띄워서 서비스하는 등 셀프 힐링을 한다.

쿠버네티스 구성

1. 마스터 노드

마스터 노드 역시 클러스터의 일부이며, 컨테이너를 배포할 수 있는 다른 서버들을 인지하고 있다.

2. 워커 노드(미니언 노드)

워커 노드에서는 로컬처럼 컨테이너 실행을 위해 도커 엔진이 돌아간다.

3. 컨트롤러

컨트롤러는 서버의 가장 바람직한 상태를 기억하고 있으며, API 서버의 상태를 항상 감시한다. API서버의 상태를 확인하여, 만약 상태가 그 바람직한 상태에 어긋난다면, 바람직한 상태로 만들기 위한 태스크를 API 서버에 할당한다.

4. API 서버

API 서버는 마스터 내에 존재한다. key-value store에 원하는 상태를 저장하고, 저장된 상태를 조회해 모든 요청을 처리한다.

5. kubelet

마스터의 명령을 듣고 워커에게 그 명령을 전달시키는 역할을 한다.

6. Pod 컨테이너의 집합을 말한다. 네트워크의 네임스페이스와 로컬 볼륨을 공유한다.

쿠버네티스의 매니지먼트 유닛이며, 요청이 들어왔을 때 실제 어떤 컨테이너에 요청을 전달할 것인가 정해준다.