쿠버네티스의 개념, 역할, 컨테이너 오케스트레이션이 왜 필요한지, 장점

1. 쿠버네티스가 무엇인가요?

쿠버네티스란 리눅스 컨테이너 작업을 자동화하는 플랫폼이다. 이전까지 도커 컨테이너 기술이 무엇이고 왜 필요한지 알아보았지만, 현실에서는 웹 애플리케이션에서 수십, 수백 개로 세분화된 컨테이너와 컨테이너화 된 앱이 점점 더 많아지고 복잡성이 증가하게 되면 이 컨테이너들을 어떻게 관리할지 고민이 시작이 된다. 쿠버네티스는 이 컨테이너화 된 개별 애플리케이션들을 배포하고 확장하는 데 도움을 주기 위해, 자동으로 컨테이너를 그룹으로 묶고 적절한 서버에 배포되도록 한다. 여러 컨테이너를 묶은 것을 포드(Pod)라고 하고, 여러 대의 서버에 각 컨테이너를 적절히 배치하고 관리하는 것을 오케스트레이션(Orchestration)이라고 한다.

쿠버네티스는 수많은 컨테이너를 적절한 서버에 배포해주고 스케줄링 해준다.

컨테이너를 관리하는 플랫폼은 이전에도 여러 개가 존재했다. 도커에서 자체적으로 지원하는 Docker Swarm나, ECS, Nomad 등의 툴이 있었다. 하지만 구글이 시작한 프로젝트를 기반으로 하는 쿠버네티스가 등장하면서부터 지금까지 쿠버네티스는 거의 업계 표준이나 마찬가지의 위치를 갖게 됐다.

2. 컨테이너 오케스트레이션이 필요한 경우

컨테이너 자체는 원래 프로세스나 애플리케이션을 개별적으로 분리하고, 기반 시스템으로부터 격리하여 개발 및 운영을 편리하게 하도록 만들어졌다. 하지만 애플리케이션 규모가 커지고, 데이터베이스와 백엔드, 프론트엔드 등 여러 컨테이너를 모아서 단위로 관리하고자 하는 경우 각각의 컨테이너를 관리하기 힘들어진다. 쿠버네티스는 여러 컨테이너 애플리케이션을 여러 대의 호스트에 배포, 확장, 연결하는 작업을 자동화함으로써 이 문제를 해결한다.

로드밸런싱, 스케줄링, 자원 관리 효율화를 담당하는 쿠버네티스

사용자가 소수인 비교적 작은 애플리케이션을 개발하고 운영하는 데는 굳이 오케스트레이션이 필요가 없다. 컨테이너가 한 두 대의 서버에 몇 개만 운영되는 상황에서는 수동으로 하드웨어에 배포하는 방식으로 컨테이너를 관리해도 문제가 없다. 하지만 만약 앱의 기능과 사용자 수가 엔터프라이즈 급이라면 상황이 알라진다. 오케스트레이션이 필요한 경우를 정리해보자면 다음과 같다.

2-1. 복잡한 앱

두 개 이상의 컨테이너가 관련되는 앱이라면 오케스트레이션이 필요할 수 있다. 대신, 보통 사이즈의 서비스라면 도커 스웜(Docker Swarm)과 같이 좀 더 최소화된 툴을 사용하는 것이 적절할 수 있다.

2-2. 확장성과 복구성이 중요한 앱

쿠버네티스를 포함한 오케스트레이션 툴은 조건이 바뀔 때마다 코드를 직접 쳐서 대응하는 것이 아니라, 원하는 시스템 상태를 서술하는 방식으로 워크로드와 컨테이너 간의 균형을 맞출 수 있다.

2-3. 현대적인 CI/CD 기법을 적용할 때

오케스트레이션 시스템은 블루/그린 배치나 롤링 업그레이드를 사용하는 앱을 위한 배치 패턴을 지원한다.

3. 쿠버네티스의 장점

3-1. 무중단 (Fault tolerance-FT) 제공

기업의 서비스를 이용하면서 종종 '임시점검' 안내 문구를 본 적이 있을 것이다. 기업에서는 서버 업데이트를 위해서 사용률이 적은 새벽 시간을 활용하거나, 긴급 점검의 형태로 서비스를 일시 중단해 왔다. 하지만 쿠버네티스는 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 애플리케이션을 업데이트할 수 있다. 또 쿠버네티스는 자가 회복(Self Healing) 기능이 있기 때문에 실패한 컨테이너를 다시 시작하고, 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 삭제하고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.

3-2. Vendor Lock In 해결

쿠버네티스가 운영하는 컨테이너들은 독립적인 특성이 있기 때문에 특정한 클라우드 환경에 구애받지 않는다. 예를 들어 고객이 A사의 클라우드를 사용하다가, B사의 클라우드로 환경을 이전하고 싶을 때, 서로 다른 업체의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 Vendor Lock In이라고 한다. 쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경을 이전할 수 있다.

3-3. 효율적인 자원 사용

쿠버네티스는 Pod가 사용할 자원들(CPU, Memory 등)의 사용량을 사전에 지정함으로써, 필요한 만큼의 자원만 파드에 할당한다. 가상 머신이 게스트 OS의 일부 자원만을 사용하여 메모리 오버헤드가 발생하는 반면, 쿠버네티스의 컨테이너는 호스트 운영체제를 공유하면서 각 컨테이너가 필요한 만큼의 자원들을 사용하기 때문에 자원을 더 효율적으로 사용할 수 있다.

3-4. 유연한 확장성

쿠버네티스를 사용하면 각 컨테이너에 필요한 CPU 및 메모리 (RAM)의 양을 지정할 수 있다. 쿠버네티스는 자원 사용률에 따라 자동으로 파드의 수를 관리한다. 예를 들어 CPU 사용률이 300%로 증가하게 되면, 쿠버네티스의 Horizontal Pod Autoscaler가 파드를 1개에서 7개까지 증가시킨다. CPU 사용률이 다시 감소하게 되면 파드의 개수도 점차 줄어들게 된다.

출처: https://bcho.tistory.com/1255?category=731548