[k8s] 쿠버네티스(kubernates, k8s)란?

아마 이름은 많이 들어보셨을거같아요. 제가 처음에 들었을 때는 굉장히 세련되보이면서 엄청나게 어려울것같은 이름이라는 생각이 들었습니다. 저도 궁금해서 여러번 찾아보았지만, 아직도 정확히 내부에서 무슨일이 일어나는지 소스코드까지는 감히 이해하지 못했습니다 ㅠㅡㅜ

 

오늘은 그래서 엄청 깊은 코드레벨의 지식보다는, 쿠버네티스가 무엇이고 왜 탄생하게되었는지 얕고 넓은 개념으로 알아보도록 하겠습니다.

 

쿠버네티스에 대해 설명하려면, 반드시 먼저 알아야하는 개념이 있습니다. 바로 컨테이너 오케스트레이션 인데요. 왜냐면 쿠버네티스는 컨테이너 오케스트레이션의 한 종류이자 가장 표준같은 존재이기 때문입니다. 자 바로 알아볼까요?

---

컨테이너 오케스트레이션

오케스트라 지휘자

지난시간에 이 글에서 도커를 이용한 컨테이너 가상화에 대해서 알아보았었습니다. 이미지로 여러개의 컨테이너를 생성할 수 있다고 했었죠. 자 근데... 계속해서 필요한 컨테이너를 생성하다보니 컨테이너를 1억개를 생성해버렸다고 가정해봅시다. 심지어 컨테이너 1억개가 하나의 서버에 들어갈 수 없으니 서버는 몇만대가 넘는다면.. 이걸 어떻게 관리할 수 있을까요?

 

중간에 어떠한 이유로 중단된 컨테이너가 있어서다시 켜줘야하고, 만약 새로운 버전으로 배포를 하게된다면요? 끔찍하지 않나요? 이처럼 기존의 서버관리방식에는 한계가 존재합니다.

이 많은 컨테이너를 linux 명령어를 하나씩 입력하면서 관리할 수 없으니, 얘네들을 한번에 묶어서 관리할 수는 없을까..? 하고 나온 개념이 바로 컨테이너 오케스트레이션입니다! 오케스트라를 보면 지휘자 한명이 몇십명의 연주자를 컨트롤하면서 연주를 리드하죠. 바로 그런 역할을 해주는게 컨테이너 오케스트레이션의 핵심입니다.

 

따라서 컨테이너 오케스트레이션은 이런 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 기술의 개념입니다. 컨테이너 오케스트레이션이라고 불리기 위해서는 다음이 가능해야합니다.

 

1. 클러스터 관리

**여기서 노드는 하나의 물리적인 서버와 동일하다고 보시면 됩니다.

마스터서버 하나가 존재하고 다른 모든 서버가 클러스터형태로 묶여있어서, 마스터서버가 클러스터 전체에 명령을 내릴 수 있는 구조로 이루어져있어야합니다. 이러한 구조로 인해 우리는 직접 모든 서버에 접근할 필요없이 마스터서버에만 명령을 내려주면, 마스터서버는 알아서 다른 모든 서버에게 명령을 내려줄 수 있습니다.

---

2. 상태 관리

특정 컨테이너가 반드시 몇개가 띄워져있어야한다는 상태가 유지될 수 있어야합니다. 만약 어떠한 오류가 생겨서 컨테이너가 4개 띄워져있어야하는데 하나가 죽었다면, 알아서 하나를 띄워서 항상 4개를 유지시켜줄 수 있는 자동화시스템이 갖춰져야합니다!

---

3. 배포관리

컨테이너 배포시 알아서 리소스가 남는 서버를 찾아서 컨테이너를 배포시켜줄 수 있어야합니다. 만약 모든 서버에서 남는 리소스가 없다면 새로운 서버를 열어서라도 배포를 해주는 자동화시스템이 갖춰져야합니다.

---

4. 버전관리

원하는 모든 컨테이너의 버전관리 및 롤백이 자동으로 관리될 수 있어야합니다. 예를들어 새로운 버전 배포시 명령어를 하나하나 입력해서 배포하는 것이 아니라 자동으로 모든 컨테이너의 버전을 업그레이드 해서 배포할 수 있어야합니다. 롤백도 포합입니다.

---

5. 서비스 검색

컨테이너가 어느서버에 띄워졌는지 추적할 수 있어야합니다. 아까 배포관리 부분에서 사람이 직접 특정 서버에 컨테이너를 배포하는 것이 아니라, 알아서 남는 리소스가 있는 서버에 배포가 된다고 했죠? 따라서 어떤 서버에 접근해야 해당 컨테이너에 접속할 수 있는지가 기록되어 남겨져서 후에 서비스 검색이 이루어질 수 있어야합니다.

---

6. 스토리지 관리

여러 종류의 디스크 또는 클라우드 스토리지가 서버별로 다르게 존재한다고 하더라도, 이들이 모두 추상적으로 묶어서 관리되어야합니다. 따라서 저장소 접근시 개별적으로 접근하는게 아니라 하나의 저장소에 접근하는 것처럼 되어야합니다.

---

아직 쿠버네티스는 들어가지도 않았는데 너무 길죠.. ㅠㅡㅜ 하지만 여기까지만 해도 쿠버네티스 개념의 절반은 이해하셨다고 보면 됩니다. 왜냐하면 위에서 말한대로 결국 쿠버네티스도 컨테이너 오케스트레이션을 실현시켜주는 하나의 플랫폼이니까요! 자 그럼 이제 드디어 쿠버네티스로 넘어가보겠습니다.

---

쿠버네티스(kubernates, k8s)

쿠버네티스는 구글에 의해 설계되고 현재는 리눅스 재단에 의해 관리되고 있는 컨테이너 오케스트레이션의 표준같은 오픈소스 소프트웨어입니다. 도커 스웜 등 다른 기술들도 존재하지만 오픈소스(무료)이고, 가장 인기가 많으며, 전세계 150개가 넘는 모임이 있을 정도로 가장 많이 사용되는 컨테이너 오케스트레이션 기술입니다.

** 줄여서 k8s 로 부르기도 하는데 8은 k와s 사이의 글자수를 뜻합니다..

 

그럼 쿠버네티스는 위에서 다뤘던 1~6번을 어떻게 실현을 시켰을까요? 바로 알아봅시다.

대략적인 쿠버네티스 설계도

1번 - 클러스터 관리 실현: 우선 쿠버네티스는 크게 마스터(Master)노드와 워커(Worker)노드로 이루어져있습니다. 하나의 마스터 노드에 여러개의 워커노드가 존재하고 이 워커노드들은 클러스터형식으로 관리됩니다.

 

2번, 4번 - 상태관리, 버전관리 실현: 쿠버네티스의 마스터 노드는 API 서버라고도 불리게 됩니다. 이 API 서버는 컨트롤러(Controller)를 통해 현재상태를 파악하고 만약 목표상태와 다르다면 조치를 취하게 됩니다. 컨트롤러는 이러한 상태를 관리하는 무한루프입니다.

3번, 5번 - 배포관리, 서비스 검색 실현: 쿠버네티스에는 컨트롤러와 별개로 스케쥴러도 있습니다. 이 스케쥴러는 워커노드의 리소스 상태를 보면서 만약 새로운 컨테이너 배포가 필요하다면 비어있는 곳을 확인해서 배포해주고 기록해줍니다.

 

6번 - 스토리지 관리: 쿠버네티스는 etcd라는 곳에 모든 것이 저장되고 관리됩니다. 설정파일도 여기에 저장되고 읽어올때도 여기서 읽어오게됩니다.

---

쿠버네티스 배포 단위

쿠버네티스에는 배포 단위가 존재합니다.

 

포드(Pod)

포드(Pod)는 가장 작은 배포단위입니다. 이 Pod 안에는 보통 하나의 컨테이너가 존재하며 (두개이상도 가능), 고유 IP를 할당받아서 다른 Pod끼리 서로 통신이 가능합니다. 가장 작은 "배포단위"인 만큼 각각의 포드를 배포할 수 있습니다.

 

레플리카셋 (ReplicaSet)

Pod의 갯수와 상태를 묶어서 관리해주는 배포단위입니다. 위처럼 replica 갯수가 4로 설정된 상태로 레플리카셋을 배포하게된다면, 만약 나중에 저 Pod 중에 하나가 내려가게되더라도, 계속해서 4개를 유지하기위해 자동으로 새로운 Pod를 띄웁니다. 내부에 Pod를 포함한 배포단위기이기 때문에 replicaSet 설정에는 내부에 Pod 설정도 같이 해주어야합니다.

 

디플로이먼트(Deployment)

레플리카셋까지 포함하는 상위 배포단위로, 버전 정보를 포함하여 상태관리를 해줍니다. 예를들어서 현재 모든 Pod의 버전이 v1인데 v2로 바뀐 Deployment를 배포했다면, 내부에 있는 레플리카셋이 두개로 나누어지며 순차적으로 무중단 버전 업그레이드를 진행해줍니다. 컨테이너는 하나가 구동되는데 약 1초내외이므로 속도가 빨라서 다운타임이 거의 없습니다.

---

서비스 연결

그럼 이쯤에서 또 들수있는 의문이 있습니다. 마스터노드로 워커노드들을 클러스터로 관리하는건 알겠는데.. 만약 사용자가 노드에 컨테이너로 띄워진 서비스를 이용하려고 접근하면 어떻게 해야되는가? 마스터노드로 접근하나? 아니면 클러스터 묶음에 할당된 IP로 접근하나?

 

정답은 둘다 아닙니다. 외부 브라우저에서는 클러스터나 마스터노드에 직접 접근할수가 없기때문에 모든 노드들은 NodePort라는걸 가집니다. 그리고 외부브라우저는 각 노드의 NodePort를 통해 노드에 접근하게됩니다. 그리고 노드에 접근해서 컨테이너가 띄워진 Pod에 연결해서 그 내부의 컨테이너로 드디어 접근을 할 수가 있는 것이죠. 이를 그림으로 나타내면 아래와 같습니다

---

오늘은 쿠버네티스에 대해 아주아주아주 앝게 개념에 대해서만 알아보았는데요. 뭔가 되게 복잡한 느낌이죠? 그런데 직접 쿠버네티스를 사용해서 배포를 해봤을때는, 뭐야.. 이게 끝이야? 이렇게만하면 끝이야? 하는 생각이 들었습니다.

 

결국 제가한건 pod, replicaSet, Deployment에 대한 설정을 yml 파일로 작성하고, 쿠버네티스 명령어로 저 yml을 실행한게 전부였습니다. yml 파일도 되게 간단한 형식입니다. 근데 이 간단한 설정으로 저렇게 많고 복잡한 것이 모두 자동화가 된다는게 놀라웠던 기억이 납니다.

 

정말 기술이 어렵고 복잡할수록 사용자가 사용할때는 엄청 편리하고 쉬워지네요.

 

읽어주셔서 감사합니다! 제가 아직 지식이 많이 부족한 부분이라 틀린부분이나 수정이 필요한 부분이 있으면 댓글로 남겨주시면 감사하겠습니다!

 

 

출처:
- 컨테이너 오케스트레이션이란?)
- [초보를 위한 쿠버네티스 안내서] 컨테이너 오케스트레이션이란