2장에서는 베이그런트를 통해 테스트 환경을 코드로 자동 구현해 봤습니다. 3장에서는 본격적으로 우리가 배운 코드를 응용해 컨테이너 인프라 테스트 환경을 자동으로 구축해 보겠습니다. 그런데 컨테이너 인프라 환경이란 무엇일까요? 컨테이너 인프라 환경을 배우려면 정의를 정확하게 아는 것이 중요합니다.

컨테이너 인프라 환경이란 리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경을 말합니다. 여기서 컨테이너는 하나 이상의 목적을 위해 독립적으로 작동하는 프로세스입니다. 좀 더 간단하게 말하면 친구와 대화를 주고받는 메신저 프로그램이나 음악 감상 프로그램을 컨테이너로 구현할 수 있습니다.

개인 환경에서는 1명의 관리자(사용자)가 다양한 응용프로그램을 사용하므로 각각의 프로그램을 컨테이너로 구현할 필요가 거의 없습니다. 하지만 기업 환경에서는 다수의 관리자가 수백 또는 수천 대의 서버를 함께 관리하기 때문에 일관성을 유지하는 것이 매우 중요합니다.

이런 경우 컨테이너 인프라 환경을 구성하면 눈송이 서버(여러 사람이 만져서 설정의 일관성이 떨어진 서버)를 방지하는 데 효과적입니다.

▲ 그림 3-1 다양한 형태의 설정이 추가된 눈송이 서버

또한 가상화 환경에서는 각각의 가상 머신이 모두 독립적인 운영 체제 커널을 가지고 있어야 하기 때문에 그만큼 자원을 더 소모해야 하고 성능이 떨어질 수밖에 없습니다. 하지만 컨테이너 인프라 환경은 운영 체제 커널 하나에 컨테이너 여러 개가 격리된 형태로 실행되기 때문에 자원을 효율적으로 사용할 수 있고 거치는 단계가 적어서 속도도 훨씬 빠릅니다.

▲ 그림 3-2 가상화 환경과 컨테이너 인프라 환경 비교

컨테이너 인프라 환경이 처음부터 주목받았던 것은 아닙니다. 이미 가상화 환경에서 상용 솔루션(VMware)을 이용해 안정적으로 시스템을 운용하고 있었고, 기술 성숙도가 높아 문제없이 관리되고 있었습니다. 그러다 시간이 지나 커널을 공유해 더 많은 애플리케이션을 올릴 수 있는 컨테이너가 도입되기 시작하면서 늘어난 컨테이너를 관리해야 했습니다. 하지만 기존의 컨테이너 관리 솔루션(Docker Swarm, Mesos, Nomad 등)들은 현업의 요구 사항을 충족시키기에는 부족한 점이 있었습니다. 그래서 컨테이너 인프라 환경이 주는 장점이 많이 있음에도 컨테이너 관리 문제 때문에 보편화되기가 어려웠습니다.

하지만 그 이후 컨테이너 인프라 환경이 성장하게 된 결정적인 계기가 된 사건이 일어납니다. 구글이 쿠버네티스(Kubernetes)를 오픈 소스로 공개한 것입니다. 구글은 2014년 자사에서 컨테이너 운영 플랫폼으로 운영하던 보그(Borg)를 기반으로 하는 쿠버네티스를 오픈 소스화하고 2015년 7월 21일 쿠버네티스 버전 1.0을 출시했습니다. 구글은 리눅스 재단(Linux Foundation)과 파트너십을 맺고 클라우드 네이티브 컴퓨팅 재단(CNCF, Cloud Native Computing Foundation)을 설립했으며 쿠버네티스를 기초 기술(seed technology)로 제공했습니다.

이를 통해 안정적인 쿠버네티스를 누구나 자유롭게 이용하게 되면서 컨테이너 인프라 환경을 좀 더 효율적으로 관리할 수 있게 됐습니다. 이후 여러 기능이 계속 추가되면서 쿠버네티스의 생태계가 풍부해졌고, 사실상 쿠버네티스는 컨테이너 인프라 관리 솔루션의 표준으로 자리 잡게 됐습니다.

이제부터 쿠버네티스로 직접 실습해 보면서 컨테이너 인프라 환경을 전반적으로 이해하고 쿠버네티스가 어떤 강점이 있기에 컨테이너 인프라 환경에서 표준이 될 수 있었는지 알아봅시다.

▲ 그림 3-3 컨테이너 인프라 환경 중 3장에서 다룰 쿠버네티스 부분