쿠버네티스와 컨테이너 오케스트레이션
쿠버네티스(Kubernetes, k8s)란
- 오픈소스로 만들어진 컨테이너 오케스트레이션 도구
- 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공
- 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능

먼저 컨테이너부터 살펴보면 컨테이너란, 우리가 구동하려는 애플리케이션을 실행할 수 있는 환경까지 감싸서, 어디서든 쉽게 실행할 수 있도록 해 주는 기술이다.
PC에 프로그램을 설치할 때 특정 경로에 맞춰 설치를 해야 하거나, 내 컴퓨터에 필요한 옵션을 일일이 맞춰주느라 설치 과정에서 힘들었던 경험이 있을 것이다. 컨테이너는 이러한 환경까지 모두 포함하여 독립적으로 프로그램을 실행할 수 있도록 도와주는 기술이다. 컨테이너 환경을 묶어서 배포한 컨테이너 이미지라는 프로그램을 내려받아 구동하면 실행되기 때문에, 각종 설정 과정이 줄어 들어서 좀 더 편하게 사용할 수 있다.
컨테이너 런타임은 컨테이너를 사용할 때 필요하며 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구이다. 종류도 여러 가지가 있다. 그중 가장 유명한 것이 도커이다. 물론 도커가 사용하는 컨테이너 규격은 표준화되어 있기 때문에 도커가 아닌 다른 컨테이너 런타임들도 도커로 만든 컨테이너를 사용할 수 있다.
쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 다루는 도구를 말한다. 쿠버네티스가 해 주는 일은 여러 서버(노드)에 컨테이너를 분산해서 배치하거나, 문제가 생긴 컨테이너를 교체하거나, 컨테이너가 사용할 비밀번호나 환경 설정을 관리하고 주입해 주는 일 등을 한다.
이것을 컨테이너 오케스트레이션이라고 한다.
Q. 쿠버네티스가 컨테이너를 다루는 도구라면 도커를 다루는 도구는 아닌가?
A. 앞에서 언급했듯이, 쿠버네티스의 역할은 컨테이너를 분산 배치, 상태 관리 및 컨테이너의 구동 환경까지 관리해 주는 도구이고, 도커는 컨테이너를 다루는 도구(컨테이너 런타임) 중 하나일뿐이다.
쿠버네티스는 컨테이너를 다루기 위해 도커 이외에도 다양한 컨테이너 런타임 소프트웨어를 사용할 수 있다.

이 그림을 이해하는 데 있어서 가장 어려웠던 것은 첫 번째로는 하이퍼바이저(Hypervisor)와 컨테이너 런타임(Container Runtime)과 같은 용어가 익숙하지 않았기 때문일테다. 두 번째는 VM, Bin/Library, App이 어떤 의미인지 와닿지 않아서 어려웠을 것이다.
좀 더 예시를 들어서 설명해 보겠습니다.
맨 왼쪽 Traditional Deployment(전통적 배포)는 가상화 이전, 그러니까 오래전부터 쓰이던 방식이다. 물리적인 컴퓨터 한 대에 하나의 OS를 깔고 여러 가지 프로그램을 설치하는 방식이다. 예를 들어 우리는 PC 한 대에 윈도우를 하나 설치하고, 여러 가지 게임이나 워드프로세서 등을 깔아서 사용하는데 이와 비슷한 방식이라고 생각하면 된다. 가장 오래되고 단순한 방식이며 단일 목적 시스템이라면 이것으로도 별 무리가 없다.
그렇다면, 이 방식이 가진 문제점이 있다. 인터넷 뱅킹을 위해 보안 프로그램을 많이 설치했더니 게임이나 웹 브라우저 성능이 떨어지는 걸 경험, 누구나 한 번쯤 해봤을것이다. 한 대의 컴퓨터에서 모든 것을 처리하려고 하면 어떤 프로그램 동작이 다른 프로그램의 동작을 간섭하거나, 특정 프로그램이 성능을 독점할 경우 또 다른 프로그램의 성능이 떨어지는 단점이 있다. 성능이 떨어지는 정도에 그치지 않고 프로그램의 중단까지도 유발할 수도 있을 것이다. 그렇다면 이 문제를 해결하기 위해서는 어떻게 해야 할까요? “인터넷 뱅킹 전용 컴퓨터를 구입해 두 대를 쓰면 되지 않을까? 그럼 게임도 쾌적하게 하고 인터넷 뱅킹은 필요할 때만 할 수 있을 테니!” 이렇게 생각해 볼 수도 있겠지만, 그러기엔 비용이 너무 많이 든다.

이 문제를 해결하기 위해 등장한 해법이 위 그림의 Virtualized Deployment(가상화 배포)이다. 가상머신(Virtual Machine)을 기반으로 배포를 하는 방법이다. 중간에 위치한 하이퍼바이저는 하나의 시스템 상에서 가상 컴퓨터를 여러 개 구동할 수 있도록 해 주는 중간 계층을 의미한다는 정도로만 알면 되고 App은 실행하고자 하는 프로그램, Bin/Library는 프로그램이 실행하는데 필요한 환경과 관련된 파일이라고 생각하면 된다.
가상머신은 말 그대로 가상 컴퓨터이다. 컴퓨터이기 때문에 우리가 컴퓨터를 조립할 때 CPU, 메모리 및 SSD를 장착하듯, 가상머신에도 CPU, 메모리, 저장 장치 등을 개별적으로 할당할 수 있다. 앞에서 말한 게임 프로그램과 인터넷 뱅킹 보안 프로그램이 간섭을 일으켜 문제가 된다면 두 프로그램을 각각의 가상머신에서 실행시켜면 하나의 컴퓨터 안에서 두 개의 가상화된 컴퓨터가 동작하기 때문에 서로 간섭을 일으키지 않게 된다. 가상머신 성능을 조절해 게임 컴퓨터에는 좀 더 많은 CPU와 메모리를, 인터넷 뱅킹용 컴퓨터에는 적은 CPU와 메모리를 할당하여 사용할 수 있다. 한 서버와 같이 다중화와 분산 처리가 중요한 시스템이라면 시스템 자원 상황에 따라 가상머신 개수를 늘리고 줄이는 것도 좀 더 유연하게 처리할 수 있다.
다만 이 방식이 전통적 배포 방식보다는 분명 효율적이지만, 가상머신은 완전한 컴퓨터이고 가상머신에 일일이 운영체제를 설치해야 하기 때문에 컨테이너 중심의 배포(Container Deployment)보다는 무거운 편이다.
Container Deployment(컨테이너 중심의 배포)에 대해 살펴보겠다. 하이퍼바이저라는 부분이 Container Runtime으로 대체되었고, Virtual Machine이라고 된 부분은 Container로 대체가 되었다. 컨테이너는 가상머신과 달리 프로그램 구동을 위해서 OS를 매번 설치할 필요가 없고 그림에서 보는 것과 같이 OS는 하나만 사용한다.
컨테이너 기반 배포는 전통적 배포 위에 Container Runtime이 올라가 있는 것 같은데 물리적인 컴퓨터 상에서만 유효한가?
꼭 그렇지는 않다. 컨테이너 런타임 위에 OS와 하드웨어가 층으로 쌓여 있는 그림을 보고 전통적인 배포 위에서 컨테이너 런타임을 올렸다고 오해를 하곤 하는데, 컨테이너는 OS 하단이 어떻게 동작하는지 직접 관심을 두지 않는다. 그래서 가상머신 위에 올라간 OS에서 컨테이너 기반 배포를 하는 것이 가능하다.
앞에서 게임과 인터넷 뱅킹 프로그램이 한 컴퓨터에 설치된다면, 서로 간섭을 일으켜 성능 저하나 오류를 발생시킬 수 있다. 지금부터 이 문제를 컨테이너 중심의 배포 방식에서는 어떻게 해결하는지 알아보기 위해 게임과 인터넷 뱅킹 소프트웨어가 각각 컨테이너로 배포된다고 가정해보겠다.(물론 이럴 일은 없겠지만, 동작 방식의 예시일뿐이다.)
이때 게임과 인터넷 뱅킹은 하나의 OS 상에서 구동된다. 이것만 보면 전통적 배포에서 하나의 OS 위에 프로그램을 여러 개 구동시킨 것과 별 차이가 없어 보일수도 있다. 그렇지만 컨테이너 중심의 배포는 여기서 중요한 기술적인 차이점은 게임과 인터넷 뱅킹이 각각 실행되면서 ‘이 컴퓨터에서 나만 구동되고 있다’라고 판단할 수 있도록, 실제로 두 프로그램 간에 간섭을 일으킬 수 없는 장벽을 치며 이러한 장벽을 치는 것과 동시에 OS는 게임과 인터넷 뱅킹이 사용할 수 있는 CPU, 메모리 등의 자원 또한 독립적으로 사용할 수 있도록 할당하고 관리한다. 이러한 과정을 통해 게임과 인터넷 프로그램은 스스로를 ‘서로 다른 컴퓨터에서 깔려 있다’고 생각하게 된다. 물론 OS의 관점에서 보자면 둘 다 OS 상에서 구동되는 프로그램이긴하다. 이와 같은 컨테이너 동작 방식을 OS 커널을 공유하는 가상화라고 표현하기도 한다.
이때 주의할 점이 하나 있습니다. 컨테이너는 OS를 공유하는 방식이기 때문에, 어떤 프로그램의 문제가 다른 프로그램을 간섭할 수는 없다. 그러나 내 프로그램의 문제가 OS에 문제를 일으킬 경우에는 OS에서 구동 중인 전체 컨테이너의 문제가 될 가능성이 있기때문에 이 점에 신경을 써야 한다

'TIL' 카테고리의 다른 글
| 54~55일차 컨테이너 오케스트레이션 실습 (0) | 2022.07.04 |
|---|---|
| 53일차 컨테이너 오케스트레이션 (0) | 2022.07.01 |
| Terraform 더 알아보기 (0) | 2022.06.29 |
| 50~51일차 Infrastructure as Code 실습 (0) | 2022.06.28 |
| 49일차 Infrastructure as Code (0) | 2022.06.24 |