쿠버네티스와 컨테이너 오케스트레이션
쿠버네티스(Kubernetes,k8s)란
- 오픈 소스로 만들어진 컨테이너 오케스트레이션 도구
- 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공
- 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능
무엇을 오케스트레이션 한다는 것인가?
orchestrate는 사전적 의미를 살펴보면 다음과 같다.
to plan and organize something carefully and sometimes secretly in order to achieve a desired result (Cambridge Dictionary)
즉 컨테이너 오케스트레이션 도구는 수십~수백개의 컨테이너를 관리하고자 할 때 보다 더 잘 관리하기 위한 툴이다.
앞서 배운 컨테이너 조합은 기껏 해봐야 서너개에 불과한데, 어떻게 수십~수백개의 컨테이너가 생길 수 있다는 말일까?
- 이는 아키텍처의 트렌드가 모놀리식에서 마이크로서비스로 바뀌고
- 이로 인해서 컨테이너의 갯수가 증가하고
- 여기에 확장성을 고려해 스케일링까지 더할 경우에 발생할 수 있는 일이다.
다섯개 정도의 마이크로서비스를 운영하는 조직이 회사 내에 세 팀 정도가 존재하고, 최소한 두 개 이상의 레플리카를 만든다고 가정하면, 벌써 서른(5x3x2)개의 컨테이너가 존재할 것이다.
이럴 때는 쿠버네티스 도입을 고려해볼 수 있다.
쿠버네티스 공식 웹사이트에는 쿠버네티스를 만든 Google의 경험을 바탕으로 다음과 같이 안내하고 있다.
Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 원칙들에 따라 디자인되었기 때문에, 쿠버네티스는 운영팀의 규모를 늘리지 않고도 확장될 수 있습니다.
언제 사용하지 말아야 할까?
- 여러 Tier(단계)로 나뉘어지지 않은 모놀리식 아키텍처에서는 적합하지 않다.
- 모놀리식 아키텍처는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선이다.
- 고작 서너 개에 불과한 컨테이너만을 다루려면 적합하지 않다.
- 서너 개에 불과한 컨테이너는 docker-compose로도 충분하다.
- 비교적 단순한 아키텍처에 스케일링이 필요하지 않은 경우에는 적합하지 않다.
- 이후 트래픽이 증가하거나 스케일링이 필요한 경우 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공된다.
- 이후 트래픽이 증가하거나 스케일링이 필요한 경우 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공된다.
언제 사용해야 하는가? 어떤 기능이 있는가?
- 마이크로서비스를 컨테이너 방식으로 운영하는 조직이 확장성을 고려해야 할 때
- 무중단 서비스, 즉 고가용성을 제공해야 할 때
- 그 밖에 다양한 기능들: 자가 치유, 배치 실행, 구성 관리, 로드 밸런싱 등
보다시피 특징적인 기능은 AWS와 같은 퍼블릭 클라우드 공급자에서도 비슷하게 제공한다.
그러나 여기에는 비용의 문제에서 자유로울 수 없다.
이를 피하기 위해 쿠버네티스를 사용하기도 한다.
쿠버네티스를 사용하는 사람들은 다음과 같이 사용한다.
- 쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성하고
- 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성하기도 하며
- 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 한다.(이식성)
- 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원한다. 예) AWS EKS
- 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원한다. 예) AWS EKS
쿠버네티스 작동 원리
쿠버네티스 아키텍처는 위와 같이 생겼다.
클러스터는 최소 하나 이상의 제어판(Control Plane) 컴포넌트와 이것과 연결된 몇 개의 워커 노드로 구성되어 있다.
노드
워커 노드는 kubelet이라는 프로세스가 돌아가고 있는데 이 kubelet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 한다.
Pod
워커 안에는 한 개 이상의 컨테이너가 자리잡고 있으며 즉, 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳이라고 할 수 있다.
쿠버네티스에서는 이러한 컨테이너(정확히는 컨테이너 그룹)와 컨테이너가 사용하는 볼륨, 그리고 컨테이너의 작동 정보를 특별히 파드(Pod)라는 이름으로 부른다.
이에 대해서는 이후에 다시 다룬다.
제어판 (Control Plane)
관리를 위해 필요한 프로세스들은 전부 제어판 컴포넌트에 있다.
제어판 컴포넌트는 클러스터가 잘 작동할 수 있게 돕는다.
API 서버 (kube-apiserver)
제어판 컴포넌트에 있는 여러가지 프로세스 중 먼저 소개할 것은 바로 API 서버이다.
말 그대로 API 서버는 모든 클러스터 관리의 입구로서 명령을 내릴 수 있는 관문이다.
실제로 쿠버네티스에서 제공되는 UI나 CLI 등에서 클러스터 관리를 위해 뭔가 명령을 내리면 API가 호출된다.
당연히 직접 호출 할 수도 있다.
컨트롤러 매니저 (kube-controller-manager)
다른 하나는 Controller manager이다.
클러스터에서 무슨 일이 발생하는지를 추적하는 역할을 한다.
예를 들어 컨테이너가 죽거나 재시작되었을 경우, 컨트롤러 매니저는 이를 알 수 있다.
스케줄러 (kube-scheduler)
또 스케줄러가 있다.
스케줄러는 서버(노드) 리소스를 바탕으로 컨테이너(정확히는 pod)가 노드에 배치되게 만드는 역할을 담당한다.
새로 생성된 컨테이너를 찾아 노드에 할당한다.
키-값 저장소 etcd
마지막으로 ETCD 데이터베이스가 존재하는데, 이는 Key-value 저장소로 클러스터 관리에 필요한 모든 데이터를 저장하는 공간이다.
인프라를 원하는 상태로 만들기 위해서는 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터가 어딘가에 저장되어야 하는데 ETCD는 바로 이를 담당한다.
쿠버네티스 설치
쿠버네티스를 로컬 환경에서 실행하기 위해서는 minikube로 시작하는 것이 편리하다.
minikube는 쿠버네티스 로컬 클러스터 환경이다.
도커와 같은 컨테이너 런타임이 준비되어 있다면, 간단한 명령을 통해 해당 런타임에 적합한 쿠버네티스를 설치하고 즉시 사용할 수 있도록 만들어준다.
minikube 설치: 공식 문서
minikube 시작하기
도커와 같은 가상화 도구가 실행된 상태에서 minikube start 명령을 통해 쿠버네티스를 실행할 수 있다.
잘 작동되는지 확인하려면, kubectl get pods -A 명령을 실행해본다.
모든 네임스페이스(-A 옵션) 존재하는 모든 파드를 조회하는 명령어다.
다음 결과를 통해 앞서 배운 쿠버네티스 작동 원리에서 다뤘던 제어판(Control Plane)의 구성요소가 파드로 존재함을 확인할 수 있다.
Action Items
다음 Hands On을 따라서 해보자.
- minikube를 이용해서 클러스터를 생성한다.
minikube start- cozserver라는 이미지를 사용해 배포 가능한 리소스(deployment)를 생성한다.
kubectl create deployment hello-minikube --image=sebcontents/cozserver:1.0- 서비스(service)로 노출한다.
kubectl expose deployment hello-minikube --type=NodePort --port=8080- 로컬 클러스터를 호스트 컴퓨터에서 접속할 수 있도록 포트 포워딩을 한다.
kubectl port-forward service/hello-minikube 3333:8080- 브라우저를 열어서 http://localhost:3333으로 접속한다.
