쿠버네티스란 무엇인가

여러 개의 컨테이너화된 애플리케이션을 여러 서버(쿠버네티스 클러스터)에 자동으로 배포, 스케일링 및 관리해주는 오픈소스 플랫폼

쿠버네티스의 역사

쿠버네티스는 구글이 내부적으로 사용하던 컨테이너 클러스터 관리 도구 Borg에서 아이디어를 얻어 만들어진 오픈 소스 소프트웨어다. 2014년 6월에 공개되어, 2015년 7월에 클라우드 네이티브 컴퓨팅 파운데이션(CNCF)으로 이관되었다.

CNCF는 쿠버네티스 외에도 많은 프로젝트를 호스트하고 있으며, 프로젝트별로 성숙도가 정의되어있다. 성숙도는 높은 순으로 Graduated, Incubating, Sandbox 중 하나로 분류된다. 쿠버네티스는 Graduated로 분류되어 성숙도를 인정받았다.

쿠버네티스는 구글의 GCP 에서 GKE 라는 서비스로, AWS에서 EKS 라는 서비스로 쿠버네티스를 제공한다.

쿠버네티스 등장 배경

도커의 등장과 함께 컨테이너 기술이 개발자들에게 널리 이용되었다
동시에 서비스의 규모가 점차 커지게 되면서, 모놀리틱 아키텍처가 아닌 마이크로 서비스 아키텍처가 각광을 받았다
클라우드 컴퓨팅, 분산 시스템의 등장으로 여러 서버를 클러스터로 구성하여 서비스를 운영하게 되었다
여러 컨테이너를 여러 서버에 배포하는데 이 때 컨테이너 크기와 서버의 리소스를 고려해 배포해주어야 한다
이 때 서비스에 요구되는 스케일 확장, 장애 대응, 버전 롤백과 같은 것들을 쉽게 해줄 도구가 필요했다
이를 해결해주기 위해 등장한 것이 쿠버네티스이다

쿠버네티스의 특징

쿠버네티스(Kubernetes)는 컨테이너로 향상된 리소스 활용의 이점을 누리면서도 복잡한 분산 시스템을 쉽게 배포하고 관리할 수 있도록 만들어준다.
쿠버네티스는 단순한 컨테이너 플랫폼을 넘어 마이크로서비스, 클라우드 플랫폼을 지향하고 컨테이너로 이루어진 것들을 손쉽게 담고 관리할 수 있는 그릇 역할을 한다. 또한 CI/CD, 머신러닝 등 다양한 기능이 쿠버네티스 플랫폼 위에서 동작한다.
쿠버네티스는 컨테이너 규모, 컨테이너의 상태, 네트워크, 스토리지, 버전과 같은 것들을 관리하며 이를 자동화한다.

쿠버네티스가 제공하는 것들

선언적 코드를 사용한 관리 (IaC)
- YAML 형식이나 JSON 형식으로 작성한 선언적 코드(매니페스트)를 통해 컨테이너 배포할 수 있다
(오토)-스케일링
- 부하에 따라서 레플리카 수를 자동으로 늘리거나 줄일 수 있다
스케줄링
- 컨테이너를 노드에 배포할 때, 노드의 성능을 기준으로 스케줄링할 수 있다
자동화된 복구
- 프로세스 모니터링, 헬스 체크 등을 이용해 컨테이너를 자동으로 재배포할 수 있다
서비스 디스커버리
- 마이크로서비스 아키텍처에서 서로의 마이크로서비스를 참조할 수 있는 서비스 디스커버리 기능을 제공한다
로드 밸런싱
- 로드 밸런서 주소를 엔드포인트로 할당하고, 트래픽을 여러 대의 서버로 분산시킬 수 있다
데이터 관리
- etcd를 사용해 데이터를 이중화된 상태로 관리할 수 있다

쿠버네티스 아키텍처

마스터 노드

Control Plane (클러스터 기능을 제어하고 전체 클러스터가 동작하게 만드는 역할)
전체 클러스터를 관리하는 서버

쿠버네티스에서 모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행합니다. 특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는 게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답합니다.

마스터의 API 서버는 할일이 굉장히 많기 때문에, 함께 도와줄 일꾼들이 필요합니다. 이들을 스케줄러와 컨트롤러라고 합니다. 보통 하나의 스케줄러와 역할별로 다양한 컨트롤러가 존재합니다.

API 서버: 클러스터 상태 조회, 변경을 위한 API 인터페이스 제공. 모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행
컨트롤러: 자신이 맡은 오브젝트의 상태를 계속 체크하고 Desired 상태를 유지, API서버 요청 처리
스케줄러: 배포할 Pod(컨테이너와 비슷)가 있는지 계속 체크, 필요한 경우 가장 최적의 노드를 선택
etcd: 클러스터에 배포된 애플리케이션 실행 정보를 저장. 고가용성을 제공하는 키-밸류(key-value) 저장소

워커 노드

컨테이너가 배포되고 실제로 실행되는 서버
kubelet: 클러스터내의 모든 노드에서 실행되는 에이전트. 파드내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할
kube-proxy: 쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리. kube-proxy는 이런 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스. 호스트의 네트워크 규칙을 관리하거나 커넥션 포워딩을 하기도함.
container runtime: 컨테이너 런타임은 실제로 컨테이너를 실행시키는 역할. 가장 많이 알려진 런타임으로는 도커(Docner)가 있고, 그외 rkt, runc같은 런타임도 지원. 그외에도 컨테이너에 관한 표준을 제정하는 역할을 하는 OCI의 런타임 규격을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용가능

Desired State

쿠버네티스에서 가장 중요한 것은 desired state(원하는 상태)라는 개념이다. 원하는 상태라 함은 관리자가 바라는 환경을 의미하고 좀 더 구체적으로는 얼마나 많은 웹서버가 떠 있으면 좋은지, 몇 번 포트로 서비스하기를 원하는지 등을 말한다.
쿠버네티스는 복잡하고 다양한 작업을 하지만 자세히 들여다보면 현재 상태current state를 모니터링하면서 관리자가 설정한 원하는 상태를 유지하려고 내부적으로 이런저런 작업을 하는 로직을 가지고 있다.

이렇게 상태가 바뀌게 되면 API서버는 차이점을 발견하고 컨트롤러에게 보내 desired state로 유지할 것을 요청한다. 그리고 컨트롤러가 변경한 후 결과를 다시 API서버에 보내고 API서버는 다시 이 결과를 etcd(상태를 저장하고 있는 곳)에 저장하게 된다.