쿠버네티스가 뭔가?

해당 글은 쿠버네티스 공식 문서를 참고하여 작성하였다.

쿠버네티스 문서

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

위 설명은 쿠버네티스 공식 문서의 쿠버네티스에 대한 간단한 설명이다. 위 말이 무슨말일까?

→ 이식성이 있다는 것은 쿠버네티스는 컨테이너화 하여 동작하기 때문에 특정 OS 혹은 특정 환경에 국한된것이 아닌, 자체 시스템 환경을 컨테이너화 하여 내포하고 있기 때문에 타 플랫폼으로의 이동이 용이하다는 뜻이다. 마찬가지로 확장가능하다는 것도 기존의 모놀리스 기법이 아닌 각각의 어플리케이션을 컨테이너화 하여 배포하기 때문에 어플리케이션간의 의존성을 최대한 배제하고 독립적이라는 의미를 내포한다.

 

선언적 구성과 자동화를 용이하게 해준다는 말은 쿠버네티스는 컨테이너들 즉 각 어플리케이션들의 배포와 롤백, 서비스 점검 등과 같은 기능을 제공하여 개발자와 운영간의 간격을 좁혀주고 보다 서비스 관리를 자동화 시켜 주는 의미를 갖고 있다.

 

그렇다면 왜 최근에 쿠버네티스가 관심을 받게 되었을까?

→ 쿠버네티스의 등장 이유와 이점에 대해서 알기 위해 기존의 역사에 대해서 살펴볼 필요가 있다.

 

기존의 서비스 제작은 대부분 모놀리스 형식으로 제작되었다. 모놀리스란 하나의 서비스가 구축되기 위해 그 안에 어플리케이션들인 DB, 서버, 콘솔 등등이 하나로 묶인 형태로 구성되어있는 상태를 의미한다. 이런 형식은 서비스 배포나 확장 또는 라이브러리 업데이트 등에서의 아주 귀찮은 문제들이 발생했다. 하나의 어플리케이션만 수정해도 매번 전체 서비스를 배포해야 했고, 라이브러리 업데이트에 따른 종속성 문제도 매번 확인해야 했다. 또한, 만약 DB 가 사이즈가 증가하게 되면 scale-up 방식으로 내부 용량을 증설하는 등의 한계점에 다르게 되었다.

 

그래서 최근의 방식은 마이크로서비스 방식이다. 이는 모놀리스와 다르게 하나의 서비스 안에 독립적인 어플리케이션들이 존재한다. 서로 묶여 있기 보다 HTTP 등과 같은 네트워크 통신으로 대화하기 때문에 각각의 라이브러리 버전 의존도 또한 낮아지게 되며, 확장을 위해 scale-out 방식을 이용함으로써 더 용이하게 할 수 있게 되었다. 최근의 서비스들은 대부분 이러한 마이크로서비스 방식을 지향하고 있다.

 

이러한 마이크로서비스들은 독립적인 어플리케이션들이므로 각각이 같은 라이브러리에 서로 다른 버전을 내포할 수 있다. 하지만 이런 어플리케이션들을 무조건 서로 다른 서버, 물리 자원에 이식을 하게 되면 남는 자원이 생기고, 해당 자원들을 비효율적으로 사용하게 된다. 그렇다고 하나의 서버에 설치하면 같은 라이브러리 버전 충돌이 일어나게된다. 이런 문제를 해결하는 것이 바로 컨테이너 방식이다. 컨테이너는 리눅스의 네임스페이스 원리를 이용하여 각각의 프로세스가 서로 독립되어서 동작하고, 네트워크 또한 각각의 영역에서 분리되어 동작한다.

이런 관점에서 컨테이너 방식의 도커가 엄청난 관심을 받으며 부상하였다. 하지만 도커는 컨테이너화 하는 방식을 제공하는 것이지.. 수많은 컨테이너를 배포하고 운영하고 관리하는 툴을 제공하지는 않았다. 하지만 쿠버네티스는 이러한 독립된 컨테이너 들의 자원을 관리하고, 어플리케이션들이 자원을 효율적으로 사용하는 것에 대한 기능을 제공하기 때문에 최근 관심이 증가하고 있다. 

 

 

그럼 쿠버네티스 말고 컨테이너를 관리 운영하는 타 플랫폼이 없었나?

→ 있었지만 쿠버네티스가 구글에서 발표하여 수많은 기업들과의 협업으로 공개한것에 의해 보다 전문적이고 기능이 고도화되었기 때문에 쿠버네티스가 독보적인 관심을 받게 되었다.