minikube는 로컬 환경에서 실습과 테스트가 가능한 Kubernetes 클러스터를 손쉽게 만들 수 있는 툴이다.
이미 많은 사람들이 사용하고 있고, Aiden’s Lab의 실습 가이드 중에서도 minikube를 활용한 것들이 제법 많다.
Kubernetes를 공부하기 시작한 동료 개발자들에게 실습과 테스트할 때 사용하라고 minikube를 소개한 적이 있었는데, 그 중 한 명이 minikube를 설치하다가 이런 질문을 했다.
minikube를 설치해서 실행해보니 Docker가 필요하다는 오류가 나왔는데, 왜 minikube에 Docker가 필요한가요?
minikube뿐만 아니라 Kind와 같이 로컬 환경에 Kubernetes 클러스터를 구축해주는 툴들의 작동 원리와 깊은 연관이 있는 질문이어서 이번 아티클에서 다뤄보려 한다.
1. minikube가 클러스터를 구축할 때 Docker가 필요한 이유
minikube는 로컬 PC에 직접적으로 Kubernetes 클러스터를 설치하지 않는다.
가상 머신(VM)이나 컨테이너 런타임(예: Docker)을 이용해 가상 환경 위에 Kubernetes 클러스터 운영에 필요한 각 컴포넌트를 설치하는 것이다.
minikube가 Linux와 Windows, macOS 모두에서 사용될 수 있는 이유가 바로 이것이다. 각 운영체제에서 사용되는 다양한 VM과 컨테이너를 minikube가 지원하기 때문.
좀 더 자세히 살펴보자면, minikube가 로컬에 설치된 VM이나 컨테이너 런타임을 호출 및 상호작용할 수 있는 인터페이스 모듈을 가지고 있기 때문이다. 이 모듈을 minikube의 드라이버(Driver)라고 한다.
minikube 공식문서를 보면 Linux, Windows, macOS 환경 모두에서 선호되는(Preferred) 컨테이너 기반 드라이버는 Docker이다. 각 운영체제마다 선호되는 VM 기반 드라이버도 별도로 존재한다.
minikube start 명령어로 Kubernetes 클러스터를 생성할 때 --driver 옵션을 따로 명시하지 않으면 위에서 언급한 선호되는(Preferred) 드라이버로 자동 설정된다.
즉, 어떤 운영체제든 minikube start 명령어를 실행할 때 Docker 드라이버 또는 각 운영체제별 선호되는 VM 기반 드라이버가 설정되는데, 이때 Docker나 해당 VM 툴이 설치되어 있지 않는다면 오류가 발생하는 것이다.
2. Docker 환경 안에 Kubernetes를 구축한다는 건 어떤 의미일까?
이제 minikube가 Docker를 활용해 Kubernetes 클러스터를 어떻게 구축하는지 알아보겠다.
좀 더 쉽게 이해하기 위해 Kubernetes 클러스터의 구성을 단순화해보자.
클러스터는 노드(Node)의 집합이다. 그리고 각 노드는 컨테이너를 실행할 수 있는 환경이다.
노드라고 하면 복잡한 물리 서버가 연상될 수도 있는데, 사실 컨테이너 입장에서 보는 구성은 단순하다.
- IP
- kubelet (Kubernetes 관점에서의 컨테이너 상태 관리)
- 컨테이너 런타임 (예: containerd)
- CPU, RAM (컨테이너를 실행할 수 있는 자원)
그리고 이런 생각을 하는 사람들이 등장했다.
가상화 기술로 노드와 유사한 환경을 만들면 로컬에서도 쉽게 Kubernetes 클러스터를 구축할 수 있지 않을까?
minikube 같은 로컬 Kubernetes 툴의 기본 개념이 나온 것이다.
Docker 컨테이너는 리눅스 커널의 기능을 빌려 마치 독립된 서버처럼 내부 네트워크 스택과 프로세스 실행 공간을 가진다.
이런 Docker 컨테이너를 Kubernetes 클러스터의 노드처럼 구성해 띄운 것이 바로 minikube 클러스터라 할 수 있다.
minikube가 생성하는 노드 컨테이너에는 kubelet과 containerd라고 하는 컨테이너 런타임이 설치된다.
이 두 컴포넌트 덕분에 minikube 클러스터에서 kubectl로 Pod와 같은 Kubernetes 리소스를 생성 및 관리할 수 있다.
minikube 클러스터를 구축할 때엔 로컬의 Docker를 사용하고, 클러스터 내의 Kubernetes 리소스들을 배포할 땐 각 노드 컨테이너 안에 설치된 containerd를 사용하는 것이다.
3. minikube와 Kind
우리가 지금까지 알아본 minikube만큼이나 많은 사람들이 사용하는 로컬 Kubernetes 툴이 하나 더 있다. 바로 Kind(Kubernetes in Docker)이다.
minikube와 Kind는 모두 Docker 컨테이너 런타임으로 Kubernetes 노드를 생성하고 클러스터를 구축한다는 공통점을 가지고 있다.
하지만 이 둘은 디자인에서부터 큰 차이가 있다.
minikube는 어디서든 쉽게 로컬 Kubernetes 클러스터를 구축하는 것을 목표로 만들어졌다.
그래서 대부분의 OS 환경에서 작동될 수 있도록 Docker뿐만 아니라 운영체제별 VM까지 지원한다. 게다가 대시보드나 다양한 애드온도 미리 준비되어 있어 사용이 편리한 것도 큰 장점이다.
반면에 Kind는 태생부터 Docker 환경만을 고려해 개발되었다. 참고로 Kubernetes의 소스코드를 관리하는 커뮤니티 SIG(Special Interest Group) 중 Testing 그룹에서 로컬 Kubernetes 테스트를 위해 시작된 프로젝트이기도 하다.
그렇기 때문에 minikube보다 가볍고 성능적으로 유리하다는 장점이 있다. Kind가 Kubernetes 노드 생성에 사용하는 컨테이너 이미지 kindest/node는 꼭 필요한 바이너리들만 포함하고 있어 클러스터 구성을 2~30초 내로 끝낼 수 있다.
Kubernetes의 로컬 테스트에 대해 다루는 여러 공식 문서에서 minikube보다 kind를 먼저 언급하는 것도 위에서 살펴본 Kind의 장점 때문이다.
이렇게 minikube와 Kind는 설계 목적부터 다르기 때문에 어느 것이 더 좋다기보다는 상황에 따라 권장되는 툴이 달라진다고 봐야 한다.
만약 이제 막 Kubernetes를 학습하기 시작했다면 minikube를 사용하는 것이 좋다. 자체 대시보드뿐만 아니라 Ingress와 같은 다양한 애드온을 쉽게 사용할 수 있어 큰 도움이 될 것이다.
Kubernetes에 대해 어느 정도 지식이 있고, 가벼운 테스트 환경이 필요하다면 Kind를 고려해보자. 클러스터 생성 속도가 더 빠르다는 Kind의 장점을 충분히 활용할 수 있을 것이다.
마무리
본 아티클에서 ‘왜 minikube를 실행하는데 Docker가 필요한가’라는 질문으로 시작해서 minikube가 로컬 환경에서 Kubernetes 클러스터를 생성하는 원리를 살펴보고, minikube와 Kind를 비교해봤다.
앞으로 학습이나 테스트 목적으로 로컬 Kubernetes 툴을 사용할 때 조금 더 자신감을 가질 수 있을 것이다.
혹시 로컬 Kubernetes 툴에 대해 궁금한 점이나 다뤘으면 하는 주제가 있다면 언제든 피드백 페이지로 알려주길 바란다.