Kubernetes 등장 배경과 장점

🍳머리말

kubernetes in action이라는 책을 통해 공부한 내용을 정리했습니다.

---

📕 Software 개발 배포의 변화

📔 Monolithic Application

 과거 application은 단일 process로 실행되거나 소수의 server에 분산된 몇몇 process로 실행되는 거대한 program이었습니다. 이러한 legacy system은 release가 느리고 드물게 update됩니다.

하나의 release의 주기는 다음과 같습니다.

개발자가 전체 system package화 -> 운영자가 배포, monitoring하며 장애 발생시 사용 가능 server로 migration

 

 모든 것이 서로 강하게 결합해 구성되며, 전체가 단일 운영체제 processs로 실행되기 때문에 하나의 개체로 개발, 배포, 관리해야 합니다. app의 일부를 변경하는 경우 전체 app을 다시 배포해야 하므로 오래걸리며 개발, 배포, 관리의 경계가 시간이 지나면 모호해집니다.

 

또한 이 app을 실행하기 위해 소수의 강력한 server가 필요합니다. system상 증가하는 부하를 처리하려면 CPU, memory 등을 server에 추가해야하는데 이는 scale out(server 복제본 늘리기), scale up(server 사양 높이기) 두 가지 방식이 있습니다. 전자의 경우 app을 변경할 필요는 없지만 비용이 상대적으로 많이 들고 한계가 있습니다. 후자는 app을 대폭 변경해야하는 상황에 놓이기 쉬우나 비교적 비용이 저렴합니다. 이를 고려했는데도 monolithic app을 분리하지 못한다면 확장할 수 없기 때문에 문제가 됩니다.

 

📔 Microservices

 거대한 monolithic legacy app은 급변하는 요구사항을 충족시키기 위해, 커지는 app의 크기 등으로 생기는 여러 문제를 해결하기 위해 점차 더 작고 독립적으로 실행, 배포가 가능한 구성 요소로 쪼개지게 되었습니다. 서로 분리된 덕분에 각자 개발, batch, update, 확장할 수 있게 되었습니다. 하지만 구성 요소의 수가 증가함에 따라 system을 원활히 구성, 관리, 유지가 어려워 졌습니다. server의 구성 요소를 자동으로 sceduling하고 구성하며 감독하고 오류를 처리하는 것에 있어 자동화가 필요해졌으며 이는 kubernetes가 등장하게 된 배경입니다.

 

 각 microservice 끼리는 단순하고 잘 정의된 interface API를 통해 통신합니다. 일반적으로 RESTful API를 제공하기 위해 HTTP이 같은 동기 protocol을 이용해 통신하거나 AMQP같은 비동기 protocol을 이용해 통신합니다. 또한 각각의 구성 요소를 구현하기에 가장 적합한 언어를 선택해 작성할 수 있습니다.

 

 앞서 말했던것처럼 각 microservice은 개발, 배포를 할 수 있습니다. 상대적으로 정적인 외부 API가 있는 독립형 process이기 때문입니다. 이 중 하나만 변경되더라도 microservice가 제공하는 API가 이전 version과 호환되는 방식으로 변경되거나 변경 자체가 없다면 다른 service를 변경하거나 다시 배포하는 번거로움이 없습니다.

 

📔 Monolithic Application vs Microservices

	Monolithic Application	Microservices
확장	system 전체	service(구성요소)별
배포	일부만 변경해도 app 전체	변경된 구성요소만, but 상호 종속성 고려

---

📕 kubernetes

그리스어로 조타 장치, 조종사라고 합니다. k8s라고도 합니다. 8글자라서?

k8s는 단순한 ochestration system이 아닙니다. k8s는 ochestration의 필요성을 없애버렸습니다. ochestration이란 특정한 action을 지시하는 것입니다. 예를 들어 docker run [image name]으로 linux terminal 명령어를 실행했을 때 container를 해당 image를 base로 docker engine을 이용해 띄워준다는 의미입니다. 이런식으로 명령어를 단순히 실행하는 것에 그치기 때문에 어떤 원하는 상태(desired state)가 있다면 하나하나 이를 유지하기 위해 사용자가 workflow(컨테이너 간에 공유되는 볼륨, 수많은 도커 플래그들, 또는 컨테이너의 관리 및 제어 등등)을 지정해줘야 하는 번거로움이 있습니다. 

 

다시 본론으로 돌아가서, k8s는 어떤 action을 실행하는 것이 아닌 사용자가 desired state(manifest files : yaml, json 등)만 명시해서 넘겨주면 알아서 current state를 지속적으로 monitoring하고 차이가 발생할 경우 갱신하여 일치하도록 만듭니다. 사용자는 이를 유지하기 위한 명령어를 따로 입력하지 않아도 되며 몰라도 동작하게끔 되어 있습니다.

📔 내부 동작

k8s는 다양한 component로 이루어져있는데 각자는 최소의 책을 가지고 독립적인 일만 수행하며 이들이 모여 하나의 system을 이룹니다.

 

k8s가 desired state를 위해 동작하는 방식은 다음 flow diagram을 따릅니다.

flow diagram - [출처: platform9]

📔 장점

 

📑 개발자 입장

 운영팀의 도움 없이도 배포를 원하는 만큼 할 수 있습니다.

 

 📑 운영자 입장

 장애 발생 시 자동 monitoring, 자동 일정 조정이 가능합니다.

 

 📑 System 관리자 입장

기존 개별 app을 감독했던 것에서 kubenetes와 나머지 infra만 확인하면 됩니다.

 

이렇게 application을 감독, 관리해줌으로써 업무에 편리를 가져다 줍니다.

 

---

📕 참조

https://suhwan.dev/2019/04/22/understanding-kubernetes-design/

Kubernetes 좀 더 잘 이해하기