들어가며
이 글은 제가 쿠버네티스의 기본을 배우고 나아가 Certified Kubernetes Administrator 자격을 취득하기 위해 공부한 내용을 정리한 것입니다.
컨테이너와 VM의 공통점과 차이
VM과 컨테이너에는 공통점이 많습니다. 둘 다 가상화 기술을 기반으로 하고 있으며, 이로 인한 이점을 그대로 누리고 있습니다. 즉, 어플리케이션을 개발하는 환경을 특정 하드웨어 환경과 분리하고, 격리한다는 점에 있어서는 동일합니다. 하나의 하드웨어에서 VM이든, 컨테이너든 여러 개의 환경을 동시에 이용할 수 있다는 점도 그렇죠. 말하자면, 개발 환경에 대한 의존을 줄이고, 리소스를 효율적으로 사용할 수 있다는 것입니다. 배포의 속도도 아주 빨라서, 몇 분 정도면 개발자가 요청하는 환경이 준비됩니다. 그러나 당연하게도, 이 둘은 같지 않습니다.
먼저, VM과 컨테이너의 가장 큰 차이는 추상화의 레벨입니다. VM의 경우 베어메탈 서버에 하이퍼바이저가 올라가고, 그 위에 게스트 OS가 올라가는 형태입니다. 하나의 하드웨어를 추상화하여 여러 개의 OS를 올리는 VM은, 즉 하드웨어 레벨의 가상화라고 말할 수 있습니다.
출처: Docker Blog (https://www.docker.com/blog/containers-replacing-virtual-machines/)
한편, 컨테이너의 경우 OS 위에 컨테이너 엔진 (Docker)가 올라가고, 그 위에 컨테이너가 올라가죠. 그 안에 개발에 필요한 리소스들 - 이를테면 바이너리나 라이브러리들 - 이 들어 있고 물론 개발하는 앱 또한 여기에 들어가게 됩니다. 이때, 컨테이너에는 하나의 앱 사용이 권장됩니다. 만일 여러 개의 서비스 혹은 어플리케이션을 개발하고 싶다면 어떻게 할까요? 컨테이너를 그만큼 더 만드시면 됩니다.
하나의 VM (혹은 게스트 OS) 위에 여러 개의 컨테이너를 올리는 이 아키텍쳐는, 말하자면 OS레벨의 가상화라고 볼 수 있습니다. VM이 하드웨어와 OS를 분리했듯, 컨테이너는 OS와 어플리케이션을 분리한다는 점에서 차이가 있습니다.
가상화 (그리고 VM) 은 기존의 서버 운영 방식을 혁명적으로 바꿔놓은 기술이었습니다. 앞서 언급했듯, 배치 시간이 크게 단축되고 제한된 하드웨어 리소스를 훨씬 효율적으로 사용할 수 있었습니다. 그러나 한편으로, VM을 통한 개발 환경에는 몇 가지 약점들이 있었습니다. VM은 OS와 하이퍼바이저에 의존하는 부분들이 있기 때문에, 완전히 portable 하지는 못했습니다. 또한 VM이 만들어지고, 배포되는 시간 때문에 현재의 어플리케이션이 요구하는 속도로 스케일링을 하지 못한다는 약점이 있었습니다.
VM이 아닌 컨테이너를 이용할 경우 얻을 수 있는 몇 가지 이점들이 있습니다.
- 플랫폼에 의존하지 않아서, 포터블합니다.
- OS를 통째로 포함하는 VM과 달리, 컨테이너는 가볍고 작습니다.
- 가볍고 작기 때문에, 더 빠르게 배포할 수 있고 빠른 속도로 스케일링할 수 있습니다.
- 컨테이너는 서로 격리되어 있기 때문에, 어느 한 컨테이너의 설정을 변경하거나 업그레이드, 교체할 경우에 다른 컨테이너가 그 영향을 받지 않습니다.
DevOps 의 관점에서 본 VM과 컨테이너
개발을 하는 입장에서 컨테이너로 인해 얻을 수 있는 이점은 이와 같이 명백해보입니다. 그런데 인프라 관리자는 VM이 아닌 컨테이너를 통한 개발 환경에서 무슨 이득을 볼 수 있을까요?
출처: HOL-2133-03-MAP - Containers, Docker and Kubernetes 101 (https://labs.hol.vmware.com/HOL/catalogs/catalog/1886)
가상화 기술이 시장화되기 전, DB나 웹 앱 등 각각의 애플리케이션은 단일 하드웨어 서버 위에서 (monolithic 하게) 개발되고, 운영됐습니다. 이는 즉, 새로운 어플리케이션을 개발하기 위해서는 개발자가 관련된 환경 - 서버 스펙 및 특정 OS 등 - 을 운영팀에게 요청하고, 운영팀은 이를 검토한 후 새로운 서버를 구입해서, 주문한 게 배달되면 여러 가지 선을 연결하고... 하는 작업을 일일이 거쳐 새로운 서버를 배포해야 했다는 것을 의미합니다. 또한 이 모든 일들은 각각의 분리된 (siloed) 부서들이 서로서로 담당해 왔었습니다. 이 모든 환경에서의 개발은, 당연히 시간이 많이 걸리고 비용도 엄청나게 듭니다. 서버를 구매하는 비용 뿐 아니라 관리를 위해 드는 시간과 노력, 부서간 커뮤니케이션의 어려움 등을 전부 포함해서요. 이게 위의 그림에서 보이는 1세대 플랫폼 당시 (대충 2001년 까지)의 상황입니다. 이러한 상황에서는 소프트웨어의 개발과 배포의 텀도 당연히 길어집니다.
가상화가 대중화되면서, 그리고 CPU와 램 뿐 아니라 스토리지와 네트워크가 가상화되는 SDDC (소프트웨어 정의 데이터 센터)가 대중화되며 이러한 문제들은 크게 개선될 수 있었습니다. 개발팀의 요구에 따라 알맞는 환경을 제공하는 일이 순식간에 이루어지게 되었고, 당연히 새로운 하드웨어를 구매하는 비용 또한 크게 절감되었습니다. 어플리케이션의 개발도 따라서 더욱 애자일하고 빠르게 이뤄질 수 있게 되었으며, 스케일링도 쉬워졌습니다. 그리고 동시에, 인프라 관리자 입장에서는 네트워킹, 스토리지 및 컴퓨팅 자원이 전부 소프트웨어적으로 정의되므로 (즉, 직접 하드웨어를 이리저리 움직이는 게 아니라 소프트웨어를 통해 그 모든 것들을 다루므로) 관리하는 게 대단히 편리해졌죠. 이게 2세대 플랫폼의 환경입니다.
출처: Pease, 2017. Devopedia에서 재인용. (https://devopedia.org/devops)
앞서 1세대 플랫폼의 경우 개발팀과 운영팀이 각각 격리 (siloed) 되어 있었다고 말씀드렸습니다. 개발팀의 경우 빠르게 소프트웨어를 개선하고 배포하고 싶어합니다. 반면 운영팀은 개발 및 배포 인프라의 안정성을 중시합니다. 둘이 원하는 것이 다르고, 이 간극은 쉽사리 좁혀지기 어려웠습니다. 웹 앱이 빠르게 업데이트된다고 해도, 그것이 실제로 소비자에게 보여지려면 이에 맞는 인프라가 확보될 때까지의 시간이 걸렸죠. 인프라가 소프트웨어적으로 정의되고, 관리가 자동화되면서 이 간극은 크게 좁혀졌습니다. 위의 도식에서 볼 수 있듯, 개발팀과 운영팀이 서로 협력하며 소프트웨어 개발과 배포의 일련의 사이클을 물 흐르듯 이어 받음을 통해 길었던 사이클을 성공적으로 짧게 만들 수 있었습니다. 쿠버네티스로 인해 컨테이너의 관리가 더 쉬워지면서 나타난 이른바 "3세대 플랫폼"은, 개발팀과 운영팀의 협업과 이를 통한 소프트웨어 개발 사이클의 가속화 - 즉, DevOps - 를 더욱 촉진합니다.
쿠버네티스를 통한 컨테이너의 관리
어플리케이션을 잘게 쪼개고, 각각 나눠진 컨테이너들을 통합적으로 관리한다는 것은 굉장히 복잡하고 어려운 일이지만, 이를 쉽게 할 수 있도록 도와주는 오케스트레이션 기술이 발달하며 이러한 일들이 대단히 쉬워졌습니다. 이를테면 컨테이너가 다운되었을 때 자동적으로 이를 복구해주고, 필요에 따라서 로드밸런싱을 해주는 등의 일이죠.
쿠버네티스가 할 수 있는 대표적인 일들은 다음과 같습니다.
- 서비스 디스커버리와 로드 밸런싱: 쿠버네티스는 DNS 네임 혹은 자체 IP 주소를 사용하여 컨테이너를 공개할 수 있습니다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 분산하여 배포가 안정적으로 이루어질 수 있게 만듭니다.
- 스토리지 오케스트레이션 쿠버네티스는 당신이 선택한 스토리지 시스템 (이를테면 로컬 스토리지, 퍼블릭 클라우드 프로바이더 등) 을 자동적으로 마운트할 수 있게 해줍니다.
- 자동화된 롤아웃과 롤백 컨테이너가 어떠한 상태에 있어야 하는지를 정해놓으면, 정해진 빈도에 맞추어 컨테이너의 현재 상태를 정해놓은 상태로 바꿀 수 있습니다. 예를 들어, 디플로이먼트를 위한 새 컨테이너를 만들고, 기존의 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용시키는 일을 전부 자동적으로 하게 만들 수 있습니다.
- 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 클러스터 노드를 쿠버네티스 안에 만들어놓고, 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에게 지시해놓으면, 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해줍니다.
- 자동화된 복구(self-healing) 쿠버네티스는 작동하지 않는 컨테이너를 다시 시작하고, 컨테이너를 교체하며, 사용자가 정의한 건강 체크 (health check) 에 응답하지 않는 컨테이너를 없애고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않습니다.
- 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있습니다. 컨테이너 이미지를 재구성하거나, 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있습니다.
참조 링크
Are Containers Replacing Virtual Machines? - Docker Blog
HOL-2133-03-MAP - Containers, Docker and Kubernetes 101 - VMware Hands-on Labs
Introduction to Kubernetes for the Virtual Infrastructure Administrator - Kube.Academy
