Kubernetes에 대하여

"Kubernetes, open source container orchestration tool"

 

Kubernetes는 컨테이너를 orchestration을 하는 기술이다.

앞서 컨테이너에 대한 개념과 컨테이너 기술 중 하나인 도커를 살펴보며 컨테이너의 필요성에 대해 알아볼 수 있었다.

사람들이 점점 전통적인 monolithic architecture에서 micro service 로 옮겨가면서 컨테이너에 대한 사용도가 급증하였다. 이에 따라 여러 컨테이너를 관리하는 것에 대해 어려움이 생기기 시작했다.

출처 : https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

 

이에 따라서 여러 컨테이너들을 관리하고, 리소스를 관리하는 서비스가 생겨나게 되었다.

​

컨테이너 Orchestration 툴은 높은 확장성(Scalability)을 제공한다. 즉 쉽게 Scale-up/out 할 수 있다.

장애가 발생하더라도 기존에 구성된 replica를 통해 인프라적으로 쉽게 복구가 가능하다.

그 중 가장 대표적인 쿠버네티스의 공식 독스에도 위 개념을 아래와 같이 설명하고 있다.

"쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다."

​

오늘은 여러 기술 중 가장 유명한 k8s를 먼저 살펴보고자 한다.

쿠버네티스의 구성요소는 node와 pod, 이 두 가지를 들 수 있다.

​

1. k8s 구성요소

Pod란, k8s의 가장 작은 단위이며, 컨테이너를 추상화한 것이다.

K8s는 컨테이너 실행환경과 그 기술도 추상화하고자 하기 때문에, 도커 위 layer를 추상화한 개념이라고 생각하면 된다.

즉 사용자는 오로지 k8s layer과 interact하면 되는 것이다.

보통 pod는 단일 application이 실행되는 컨테이너 단위로 여겨진다. (보통 pod별 1 app)

각 pod는 각자의 IP address를 부여받는다. (재실행될 경우 신규 IP를 할당받는다)

* 참고 : 도커는 하나의 컨테이너를 실행단위로 하는 것과 다르게 쿠버네티스는 파드를 실행 단위로 두고 있다.

출처 : https://preiner.medium.com/kubernetes%EC%9D%98-%EC%9D%B4%ED%95%B4-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC-17245a0d5f4d

​

여기서 Service란 개념도 등장하는데, 이는 pod별로 IP를 할당받게 되면서,

app이 장애가 발생했을 경우 해당 컨테이너가 재실행될 때 마다 신규 IP를 배정받는 것에 대해 불편함이 생겼기 때문이다.

Service는 static IP를 받아 영구적으로 IP 주소를 사용할 수 있고, pod가 죽더라도 그에 연결된 service와 IP는 그대로 사용할 수 있게 된다.

production의 경우 장애가 발생했을 때를 대비하여 replica를 같은 service내에 연결해두는데, 이 경우 한쪽 컨테이너가 죽더라도 동일한 영구 IP를 지닌 다른 컨테이너가 downtime동안 서비스를 제공할 수 있다.

이러한 점에서 미루어볼 수 있듯, service는 load balancer의 역할도 하게 된다.

여기서 replica는 실제로 pod를 구성하는 것이 아니라 blueprint로 만들게 된다. (= Deployment라고 불림)

즉 pod는 컨테이너 위의 layer를 추상화한 것이고, deployment는 pod를 추상화한 것이다.

내가 얼마나 replica를 생성할 것인지를 정의하여 필요할 때 자유롭게 scale-up/down이 가능하다.

​

추가로 DB는 따로 deployment를 통한 replica 구성이 어렵다.

왜냐하면 원본과 replica 모두 동일한 스토리지를 바라보고 있기 때문이다.

DB는 consistency 유지를 위해 여러 곳에서 접근이 가능할 경우 read/write시에 제어가 필요하다.

따라서 k8s 는 state를 지닌 app들에 대해 StatefulSet이라는 기능을 제공한다.

보통 stateless한 app들끼리 cluster를 구성하고, StatefulSet은 그 외부에 구성하곤 한다.

​

(+ ingress : external service. 외부 자원에서 접촉할 수 있는 서비스)

​

K8s는 ConfigMap이라는 기능도 제공한다.

예를 들어 내부 DB의 버전을 업그레이드하며 접속 URL이 변경되었다 하였을 때,

일반적으로 우리는 Docker file을 업데이트하여, repo에 push한 뒤, 컨테이너에 다시 pull하여 다시 빌드하게 된다.

이 과정은 구성된 개발 환경에 작은 변화가 생길 경우 굉장히 귀찮을 수 있다.

따라서 k8s는 ConfigMap을 통해 내 서비스의 external configuration(end point 등) 관한 정보를 담게 된다.

Secret이라는 기능을 통해서 user name, password와 같은 credentials 파일들을 base64로 인코딩하여 보관할 수도 있다.

​

Volume은 하드웨어에 존재하는 물리적인 스토리지에 pod를 붙인다(attach).

로컬일 수도 있고, 서버일수도 있고, k8s 클러스터 외부에 존재하는 on-premise storage가 될 수도 있다.

K8s는 데이터를 영구적으로 관리하지 않기 때문에, 장애가 발생했을 경우 내부적으로 저장하던 데이터를 복구할 수 없다.

따라서 replication 등의 방법을 통해 DB를 백업할 필요가 있다.

---

2. k8s 아키텍처

k8s에서 node는 여러 pod를 묶는 단위이다.

k8s 클러스터는 각각 master node와(여러개 가능) 그에 연결된 여러 worker/slave node 로 구성되어 있다.

​

여기서 모든 node에는 최소한 아래 세 가지의 process가 설치되어 있어야한다.

: container runtime, kubelet, kube proxy

1) Container runtime : 컨테이너 실행환경. 대표적인 예로는 도커가 있음

2) Kubelet : container runtime과 node를 연결하는 k8s 자체 프로세스. 컨테이너 내부의 pod를 실행하는 역할도 함

3) Kube proxy : request를 포워딩해주는 역할

​

Master node는 일반 node와는 다르게 4개의 process를 더 필요로 한다.

1) API server : 내 클라이언트 서버와 특정 k8s 클러스터를 연결하기 위해 사용됨. 클러스터 gateway.

gatekeeper로서의 역할로 authentication 과정을 거침.

API server로 들어오는 request를 validate하여 클러스터 내부로 request를 전송하는 역할

2) Scheduler : API server로부터 들어온 validated request를 받아 pod를 어느 worker node에 배정할지 결정. 결정한 이후 신규로 배정받은 pod를 통해 request를 실행하도록 만드는 것은 kubelet의 몫.

3) Controller Manager : 클러스터 state를 지속적으로 트래킹함. 예를 들어 pod가 다운되었을 때 controller manager가 파악하여 scheduler로 다시 넘김.(controller manager -> scheduler -> kubelet -> pod다시 배정)

4) etcd : 클러스터의 state를 저장하는 key value 스토어. API server, Scheduler, Controller Manager 이 세 가지가 기반으로 동작하는 데이터가 저장된 곳. (ex. 클러스터 현재 상태, 어떤 리소스가 사용가능한 상태인지? 등)

​

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

​

---

3. k8s sample cluster

master node는 CPU, RAM, stroage 의 자원을 적게 배정받는 편이다.

실제 job이 수행되는 곳은 worker node이기 때문이다.

​

새로 master 또는 node 서버를 추가할때의 프로세스는 아래 세 단계로 구성되어 있다.

1) bare 서버를 새로 배정받음

2) 1에서 받은 서버에 master/worker node 에서 필요로 하는 필수 프로세스들을 설치

3) 클러스터에 2를 추가

​

위 세 가지 과정을 통해 무한하게 클러스터의 power과 resource를 늘릴 수 있다.

---

이상 쿠버네티스의 구성 요소와 아키텍쳐에 대해 알아보았다.

다음 편에서는 이번에 알아본 kubernetes 지식을 바탕으로 kubeflow에 대해 정리해보고자 한다.

​

<요약 노트>

* Pod : 컨테이너의 추상화

* Service : 컨테이너 간의 communication

* Ingress : 클러스터로의 트래픽을 라우팅

* ConfigMap, secrets : external configuration

* Volume : data consistency

* Deployment, StatefulSet

---

참고자료

- Kubernetes official docs : https://kubernetes.io/ko/docs/concepts/overview/