쿠버네티스(Kubernetes)

Kubernetes란?

컨테이너 관리자로 컨테이너 운영을 자동화하기 위한 도구이다. 쿠버네티스와 동일한 기능을 하는 도구에는 메소스(Mesos), 도커 스웜(Docker Swarm) 등이 있다.

이런 도구를 컨테이너 오케스트레이션 도구라 하며, 많은 수의 컨테이너를 협조적으로 연동시키기 위한 통합 시스템이며 이 컨테이너를 다루기 위한 API 및 명령행 도구 등이 함께 제공된다.

또한 컨테이너를 이용한 애플리케이션 배포 외에도 다양한 운영 관리 업무를 자동화할 수 있다.

도커 호스트 관리, 서버 리소스의 여유를 고려한 컨테이너 배치, 스케일링, 여러 개의 컨테이너 그룹에 대한 로드 밸런싱, 헬스 체크 등의 기능을 갖추고 있다.

쿠버네티스로 실행하는 애플리케이션은 애플리케이션을 구성하는 다양한 리소스가 함께 연동해 동작하는데 , 여기서 말하는 쿠버네티스의 리소스란 애플리케이션을 구성하는 부품과 같은 것으로 노드, 네임스페이스, 파드 등을 의미한다.

k8s 라고 표현하기도 한다.
이유는 kubernetes가 k로 시작해서 s로 끝나는데, 그 사이 문자열 'ubernete'이 8글자이기 때문이라고 한다.

Kubernetes Cluster

Kubernetes 클러스터(cluster)는 Kubernetes의 여러 리소스를 관리하기 위한 집합체를 의미한다.
Kubernetes 리소스 중에서 가장 큰 개념은 노드(node)다. 그렇다면 Kubernetes 클러스터(cluster)는 쉽게 말하자면, 컴퓨터 내의 노드들을 하나로 묶은 집합체를 의미한다.

노드(node)는 클러스터(cluster)의 관리 대상으로 등록된 도커 호스트로, 도커 컨테이너가 배치되는 대상이다.

노드(node) 내부에 파드(pod)가 존재

파드(pod)는 또 도커(docker)를 포함한다.

Kubernetes 클러스터(cluster) 전체를 관리하는 서버인 마스터가 적어도 하나 이상 있어야 한다.

하나 이상이라는 의미는 클러스터가 작동하기 위한 최소 조건이지만 실제 프러덕 환경에서는 절대 하나로 클러스터(cluster)를 구성하지 않으며, 최소 3개 이상의 마스터 노드를 갖고 있다.

Master Node

Kubernetes Cluster 전체를 컨트롤하는 역할로 API 서버, 스케줄러, 컨트롤러 매니저, etcd 로 구성된다.

• API서버(명령, 통신 관련):  모든 명령과 통신을 API를 통해처리한다. 모든 기능은 REST API로 제공하고 그에 따른 명령을 처리한다.

• Etec (정보 저장): Cluster의 데이터베이스 역할로 서버로 설정값이나 클러스터의 상태를 저장한다. 따라서 분산형 Key/Value 형식이고 오픈소스이며, 빠른 응답과 신뢰성등의 장점이 있다.

• 스케줄러(리소스들을 할당할지 선정): pod나 서비스들을 적절한 노드에 저장하게 정리해주는 역할을 한다.

• 컨트롤러 매니져(RC,SC,VC,NC 관리): Replica controller, Service controller, Volume Controller, Node controller를 생성하고 각 노드에 배포하여 관리한다.

Node

Master Node에 의해 주어진 명령어를 받고 실제 워크로드에 생성하여 서비스하는 컴포넌트다. Kubelet, kube-proxy, cAdvisor와  컨테이너 런타임으로 구성되어 있다.

• Kubelet(통신):노드에 배포되는 에이전트로, 마스터의 API서버와 통신하면서 노드가 수행해야 할 명령을 받아 수행하고, 반대로 노드의 상태등을 마스터로 전달하는 역할을 한다.

• Kube-proxy(노드 안에 트래픽 정리) : 노드로 들어오는 네트워크 트래픽을  적절한 컨테이너로 라우팅하고, 로드밸런싱등을 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고 , 노드와 마스터간의 네티워크 통신을 관리한다.

• container runtime: pod를 통해 배포된 컨데이너를 실행하는 역할.
  대표적으로 도커 컨테이너가 있고, 이외에 rkt,hyper container도 있다.

• cAdvisor(모니터링): 각 노드에서  기동되는 모니터링 에이전트로, 노드내에서 가동되는 컨테이너들의 상태와 성능등의 정보를 수집하여, 마스터에게 전달한다.

Namespace

Kubernetes는 클러스터(cluster) 안에 가상 클러스터(cluster)를 또 다시 만들 수 있다.

클러스터 안의 만들어진 가상 클러스터를 네임스페이스(namespace)라고 한다.

클러스터(cluster)를 처음 구축하면 default, docker, kube-public, kube-system의 네임스페이스 4개가 이미 만들어져 있다.

$kubectl get namespac 명령으로 현재 클러스터 안에 존재하는 네임스페이스의 목록을 확인할 수 있다.

네임스페이스(namespace)를 클러스터(cluster) 안의 가상 클러스터(cluster)라는 개념이 어려웠는데, 전체 클러스터에서 리소스의 구분 용도 즉, 전체 클러스터에서 특정 이름으로 클러스터의 영역을 구분하는 정도라고 생각하고 넘어가자!

Pod

파드(pod)는 컨테이너가 모인 집합체의 단위로, 적어도 하나 이상의 컨테이너로 이루어져 있다.

앞서 언급한 컨테이너는 도커 컨테이너를 의미하는데 쿠버네티스를 도커와 함께 사용한다면 파드는 컨테이너 하나 혹은 컨테이너의 집합체가 된다.

쿠버네티스(Kubernetes)에서는 결합이 강한 컨테이너를 파드로 묶어 일괄 배포하는데 아래의 그림을 보고 이해해 보자!

한 pod 안의 컨테이너는 모두 같은 노드에 배치된다. 즉, pod 하나가 여러 노드에 걸쳐 배치될 수는 없다는 것을 의미한다.

kubernetes를 이용한 운영중인 서비스 배포 방법

1. 블루 그린 배포 (Blue Green Deployment)

Blue 컴퓨터를 통해 기존 버전을 가진 서버를 현재 운영하고 있다고 가정하자

유저들은 모두 Blue 컴퓨터에 연결되어 있는 상황에서 새로운 버전을 배포해야할 때,

새로운 버전을 가진 서버를 Green 컴퓨터에 켠다.

그리고, Blue에 있던 유저 트래픽을 Green 으로 한번에 옮긴다.

Blue는 계속 대기하고 있다가, 혹시 Green에 문제가 생기면 다시 Blue로 트래픽을 옮긴다.

이 방식의 대표적인 단점은 현재 운영중인 서버의 2배 가량의 자원이 필요하다는 점이다.

2. 카나리 배포 (Canary Deployment)

카나리 배포는 일부 유저 트래픽만 새로운 버전을 배포한 서버로 보내서, 문제가 없는지 체크한 뒤

괜찮다면 더 많은 유저 트래픽을 새로운 배포한 서버로 보내고, 이를 반복한다.

3. 롤링 배포 (Rolling Deployment)

롤링 배포는 카나리 배포와 유사하다.

1. 현재 운영중인 서버 중에서 하나의 컴퓨터를 끈다.
   

2. 껐던 컴퓨터에 새로운 버전을 담아 배포하고. 두번째 컴퓨터를 꺼줍니다.
   

이런식으로 기존버전에서 새로운 버전으로 트래픽을 점진적으로 전환하는 것을 롤링 배포라고 한다.

참고자료
: 코드캠프 강의자료