쿠버네티스, 물리장비에 올릴까? 가상장비에 올릴까? 머신별 장단점 알아보기.

Kubernetes

Micro Service Architecture(이하 MSA) 개발방식이 유행을 타면서 이와 동시에 docker와 같은 container application들을 orchestration하는 도구인 Kuberntes(이하 k8s)의 관심도도 엄청나게 높아지고 있다.

google trend 파랑 : kubernetes, 빨강 : docker swarm (in 대한민국)

k8s에 대한 관심이 지속적으로 늘어남과 동시에 개발자들은 효율적인 machine(host)의 resource(cpu, ram등)의 사용을 위해 아래와 같은 질문이 자연스럽게 나눠지곤한다.

k8s를 물리장비에 올릴까? 가상장비에 올릴까?
어디에 올렸을때 효과적일까?

상기와 같은 질문을 하기 전에 k8s의 목적에 대해 명확히 알아야 한다. k8s는 container orchestration도구일 뿐이다. container application들은 가상장비 혹은 물리장비에 올라갈 것이고 결국 container application의 역할과 종류, 요구사항에 따라 올라가는 위치가 달라진다고 볼 수 있다.

 

그러므로 아래와 같이 질문하는 편이 나아보인다.

 

k8s를 물리장비에 올릴까? 가상장비에 올릴까?
↓
현재 운영하고자 하는 containerized application을 물리장비에 올릴까? 가상장비에 올릴까?

요구사항에 따른 machine 종류 선택

	물리장비	가상장비
요구사항	- 게임, 10,000tps 이상의 트래픽 처리 등 - 가상장비를 운영할 환경이 되지 않을 경우    (소규모 회사에서의 on-promise 운영과 같은 경우)	- 10,000tps 이하의 웹서비스 - 이미 virtual machine 사용이 용이한 회사    (vm환경이 갖추어진 회사) - k8s node의 확장이 필요할 경우

간단히 위와 같이 정리가능하다. 성능이 필요하거나 가상화환경을 구축할 여건이 되지 않는다면 물리장비를 써야할 것이고, 가상화환경이 구축이 되어 잘 운영되어 있고 성능에 큰 이슈가 없다면 가상장비에서 운영하는 편이 좋은건 당연하다.

 

추가적으로 k8s의 document에도 나와 있지만 node설치시 physical에 할지 virtual에 할지에 대한 여부에 대한 이야기는 깊게 나와 있지 않다. 다만, 아래와 같이 cluster에 따라 선택한다고 적혀있다.

kubernetes node 설명

결론

k8s는 orchestration 도구. application의 요구사항에 맞는 machine을 취사선택하여 사용하자.