[kubernetes] 쿠버네티스란?

앞서 실습한 내용으로 도커를 이용하여 CD 구현하면 되지만 만약 배포 서버가 1000대라면..!

물론 구현할 수 있지만 편리하게 할 수 있는게 있다면!

그리고 운영 서버를 받고 사용해보니 많은 리소스가 필요 없어 놀고 있는 리소스가 있을때 다른 서비스에 활용하여 자원을 잘 사용하는 방법이 있다면 ...! 반대로 리소스가 부족할때 자동으로 스케일링 할 수 있는 방법이 있다면..!

또한 장애가 있을때 자동으로 복구(롤백/컨테이너다시시작/컨테이너교체)를 해준다면...!

바로 쿠버네티스를 사용하면 모두 가능하다!!

쿠버네티스는 여러개의 컨테이너 애플리케이션을 여러 서버에 자동으로 배포 및 스케일링 등 관리 해주는 오픈소스 시스템이다!

이제 쿠버네티스의 구조를 알아보자!
쿠버네티스 공식 홈페이지에 있는 구성도 이며 클러스터는 Master/Slave 구조로 동작한다.

크게 Master 역할을 하는 '컨트롤 플레인 컴포넌트' Slave 역할을 하는 '노드 컴포넌트'가 있으며 Master와 Slave 통신은 컨트롤 플레인 컴포넌트의 API Server를 통해 통신한다.

컴포넌트 안에 포함된 서비스 하나하나 알아보자!

우선 Master 역할을 하는 '컨트롤 플레인 컴포넌트'는 클러스터에 대한 관리를 수행하고 설정에 대한 조건이 맞도록 자동 감지하고 동작한다.

구성요소	설명
kube-apiserver	클러스터 상태 조회/변경을 위한 API
etcd	클러스터 상태가 key-value 형태로 저장되는 데이터 저장소 (워커노드의 kubelet에는 cAdvisor(모니터링서비스)가 있어서 노드의 상태정보를 마스터에 전달하여 etcd에 상태 정보를 저장한다.)
kube-scheduler	노드가 할당 되지 않은 파드 감지하고 실행할 적합한 노드를 선택
kube-controller-manager	노드, 잡, 엔드포인트, 서비스 어카운트/토큰 컨트롤러가 있으며 클러스터 관리 동작
cloud-controller-manager	클라우드별 클러스터 관리 담당

Slave 역할을 하는 '노드 컴포넌트'는 컨테이너 실행을 담당하며 파드를 유지 시킨다!

구성요소	설명
kubelet	파드에서 컨테이너가 설정한 스펙에 맞게 동작하도록 관리, 노드 상태 정보 마스터에 전달
kube-proxy	네트워크 프록시(중개)로 내부, 외부 파드 통신 가능하도록 관리하며 파드 통신 요청을 받으면 맞는 Pod의 IP로 라우팅 시켜준다.

API 서버를 통해 클러스터와 통신을 하며 클라이언트는 kubectl을 통해 클러스터에 Http 프로토콜로 통신하며 플로우는 아래와 같다!

번호	설명
①	사용자가 Kubectl을 통해 클러스터에 서비스 생성 요청을 한다.
②	Kubectl은 Http프로토콜로 마스터의 API 서버에 서비스 생성 요청을 전달한다.
③	API Server는 Contoroller Maneger에 서비스 생성 요청을 전달한다.
④	Controller Manager는 서비스 생성 요청에 해당하는 사양(etcd)과 현재 상태를 비교하여 필요한 리소스 생성 요청을 API Server에 전달한다. (이후에도 감시하며 사양과 상태가 다르면 API Server에 파드 생성 요청을 진행한다.)
⑤	API Server는 Scheduler에 필요한 리소스를 어느 노드에 요청 하면 될지 물어본다.
⑥	Scheduler는 해당 리소스에 할당할 노드를 전달하며 상태 정보를 업데이트 할것을 요청한다.
⑦	API Server는 리소스 상태 etcd에 저장 요청 한다.
⑧	etcd는 리소스 상태 변경 완료 이벤트를 API Server에 전달한다.
⑨	서비스 생성할 노드의 Kubelet에 파드 생성 이벤트를 전달한다.
⑩	Kubelet은 파드를 구성할 컨테이너 생성 요청을 Container Runtime을 통해 진행하며 예제에서는 도커(Container Runtime)를 이용한다.
⑪	Container Rumtime(도커)는 컨테이너를 생성한다.
⑫	Kubelet은 컨테이너를 감시한다. (헬스 체크)

# 알면 좋은 개념!  - 서비스 디스커버리란?

쿠버네티스에서는 서비스 디스커버리 개념을 사용하고 있다! 자동화된 컨테이너는 스케일인/아웃 되거나 장애 복구 작업으로 인해 예고없이 종료되거나 재시작 되니 서비스의 IP가 계속적으로 바뀌어 대상 IP를 찾기 어렵게 된다.

이를 해결하기 위해 서비스 디스커버리 개념을 사용한다.(L4,L7 스위치에서도 사용하는개념)

서비스 Registry 서버가 있고 마이크로 서비스의 IP를 저장하고 있어 클라이언트가 Registry 서버로부터 IP를 받아 클라이언트가 받은 IP로 호출한다.

마이크로서비스 인스턴스는 Registry 서버로 본인의 IP를 등록,삭제를 진행하며 주기적으로 하트비트를 보내며 살아 있다는것을 확인시켜준다.

서비스 Registry 서버는 하트비트가 오지 않는 서버는 목록에서 제외 시킨다.

이를 통해 클라이언트는 원하는 서비스와 쉽게 통신 할 수 있다.

# 참고 문서

https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 컴포넌트