쿠버네티스 설치·실습 환경 만들기 2026 — minikube·kind·도커 데스크톱 중 뭘 쓸까

설치 방법부터 궁금하시겠지만, 솔직한 판단을 먼저 드리는 게 맞다고 봅니다. 결론부터 말하면, 혼자 사이트 몇 개를 운영하는 수준이라면 실무 운영에서 쿠버네티스가 꼭 필요하지는 않습니다. 저는 사이트 12개를 운영하지만 모두 버셀에 배포하고 데이터는 슈퍼베이스에 맡깁니다. 컨테이너를 직접 오케스트레이션할 일이 거의 없습니다. 작은 서비스 하나를 운영하려고 쿠버네티스를 도입하면, 얻는 것보다 관리해야 할 것이 더 많아지는 경우가 흔합니다.

그렇다면 누가 배워야 하는지 정리하면 다음과 같습니다.

제 솔직한 권유는 이렇습니다. 당장 운영에 필요해서가 아니라 학습과 커리어 차원에서 배우는 거라면 로컬 실습으로 충분합니다. 굳이 클라우드에 유료 클러스터를 띄워 돈을 쓸 필요는 없습니다. 한국 클라우드 환경에서 관리형 쿠버네티스를 띄우면 노드 비용이 원화로 매달 쌓이는데, 학습 단계에서는 그 비용이 아깝습니다. 로컬 도구로 같은 개념을 거의 다 익힐 수 있습니다.

로컬 쿠버네티스 학습 도구는 크게 세 가지가 자주 쓰입니다. 이름은 비슷하게 들리지만 성격이 꽤 다릅니다. 핵심만 먼저 비교하면 다음과 같습니다.

한 줄로 추리면 이렇게 정리됩니다. 가장 손쉽게 시작하려면 도커 데스크톱의 쿠버네티스 켜기 옵션을 쓰면 되고, 학습 자료가 많고 무난한 표준을 원하면 minikube, 클러스터를 자주 만들었다 지우는 실험이나 CI 환경 흉내를 내고 싶으면 kind가 맞습니다. 세 도구 모두 같은 kubectl 명령으로 다루기 때문에, 한번 하나에 익숙해지면 다른 도구로 옮겨 가는 것도 어렵지 않습니다.

제 추천 순서는 이렇습니다. 도커를 이미 쓰고 있다면 도커 데스크톱 체크박스로 가장 먼저 켜 보고, 본격적으로 애드온과 드라이버를 만지며 공부할 거라면 minikube로 옮기고, 클러스터를 일회용으로 빠르게 다루는 단계가 되면 kind를 더하는 흐름입니다. 처음부터 세 개를 다 깔 필요는 없습니다.

한국 개발자 상당수가 맥북, 그중에서도 애플 실리콘 맥을 씁니다. 다행히 위 세 도구는 모두 애플 실리콘(arm64)을 정식 지원합니다. 다만 몇 가지 알아 둘 점이 있습니다.

• 컨테이너 이미지 아키텍처를 확인합니다. 애플 실리콘은 arm64라서, arm64 이미지가 없는 일부 옛 이미지는 에뮬레이션으로 느리게 돌거나 에러가 날 수 있습니다.
• 도커 데스크톱이 가장 무난합니다. 애플 실리콘용 도커 데스크톱이 잘 다듬어져 있어, 쿠버네티스 켜기 옵션도 arm64에서 안정적으로 동작합니다.
• minikube는 docker 드라이버를 권합니다. 애플 실리콘에서는 별도 가상화 도구 없이 docker 드라이버로 돌리는 게 가장 단순합니다.
• kind도 arm64 도커 위에서 그대로 동작합니다. 컨테이너 기반이라 별도 가상머신이 필요 없습니다.

제가 애플 실리콘 맥에서 겪은 흔한 함정은 이미지 아키텍처 문제였습니다. 어떤 예제 이미지를 받아 실행했더니 컨테이너가 자꾸 재시작되거나 느렸는데, 알고 보니 그 이미지가 arm64를 지원하지 않아 x86 에뮬레이션으로 돌고 있던 경우였습니다. 학습용 이미지를 고를 때 멀티 아키텍처를 지원하는 공식 이미지를 쓰면 이 문제는 대부분 피할 수 있습니다.

어떤 도구를 고르든 클러스터를 다루는 명령줄 도구 kubectl은 공통으로 필요합니다. 맥에서는 홈브루(Homebrew)로 설치하는 게 가장 간단합니다. 홈브루가 없다면 먼저 홈브루부터 설치한 뒤 진행하시면 됩니다.

설치가 끝나면 kubectl version --client 명령으로 버전이 출력되는지 확인합니다. 아직 클러스터를 띄우지 않았으니, kubectl get nodes 같은 명령은 연결할 클러스터가 없다고 에러가 날 수 있는데 정상입니다. 클러스터를 만들면 그 도구가 자동으로 kubectl이 바라볼 컨텍스트를 등록해 줍니다.

여기서 컨텍스트라는 개념을 한 번 짚고 가면 뒤가 편합니다. kubectl은 여러 클러스터를 다룰 수 있고, 지금 어떤 클러스터를 바라보는지를 컨텍스트로 구분합니다. 도커 데스크톱, minikube, kind를 함께 쓰면 컨텍스트가 여러 개 생기는데, kubectl config get-contexts로 목록을 보고 kubectl config use-context 명령으로 전환합니다. 이걸 모르면 minikube를 켜 놓고 도커 데스크톱 클러스터에 명령을 날리는 식의 혼선이 생깁니다.

가장 자료가 풍부하고 무난한 minikube부터 실제로 띄워 보겠습니다. 전제는 도커 데스크톱(또는 도커 엔진)이 깔려 있고 실행 중이라는 점입니다. minikube를 docker 드라이버로 돌릴 것이기 때문입니다.

minikube start가 끝나면 단일 노드 클러스터가 생기고, kubectl 컨텍스트도 자동으로 minikube로 잡힙니다. kubectl get nodes를 쳤을 때 노드 하나가 Ready로 나오면 성공입니다. 여기서 간단한 애플리케이션을 하나 띄워 보면 학습 효과가 큽니다.

여기까지 따라 하면 디플로이먼트로 파드를 만들고, 서비스로 외부에 노출하고, minikube service로 브라우저에서 확인하는 흐름을 한 번에 경험합니다. 실습이 끝나면 minikube stop으로 멈추거나 minikube delete로 깔끔히 지웁니다. 학습용은 자주 지웠다 다시 만드는 게 오히려 좋습니다. 망가진 상태를 붙들고 고치는 것보다, 지우고 새로 띄우는 게 빠르고 개념도 더 잘 잡힙니다.

minikube에 익숙해졌다면 kind도 한번 써 보시길 권합니다. kind는 클러스터 전체를 도커 컨테이너 안에 띄우는 방식이라, 만들고 지우는 속도가 매우 빠릅니다. 멀티노드 클러스터를 흉내 내거나, 깃허브 액션(GitHub Actions) 같은 자동화 파이프라인에서 일회용 클러스터를 띄울 때 특히 잘 맞습니다.

도커 데스크톱은 설치가 가장 단순합니다. 별도 명령 없이, 도커 데스크톱 설정(Settings) 화면의 Kubernetes 탭에서 Enable Kubernetes 항목을 체크하고 적용하면 됩니다. 잠시 기다리면 단일 노드 클러스터가 켜지고, kubectl 컨텍스트가 docker-desktop으로 추가됩니다. GUI로 켜고 끄는 게 익숙한 분에게는 이 방식이 심리적 진입장벽이 가장 낮습니다.

다만 도커 데스크톱 방식은 쿠버네티스 버전이나 노드 구성을 세밀하게 고르기 어렵다는 한계가 있습니다. 특정 버전으로 실험하거나 여러 노드를 구성해 보고 싶다면 minikube나 kind가 더 유연합니다. 정리하면, 처음 한 번 켜 보는 용도로는 도커 데스크톱이 가장 쉽고, 본격적인 실습과 버전 실험은 minikube나 kind가 낫습니다.

지금까지 셋을 모두 깔아 봤다면, 이제 본인 상황에 맞게 주력 도구를 정하면 됩니다. 제가 권하는 선택 기준을 정리하면 다음과 같습니다.

제 개인적인 흐름을 공유하면, 개념을 처음 잡을 때는 자료가 많은 minikube로 시작했고, 클러스터를 일회용으로 다루는 단계가 되면서 kind를 더 자주 씁니다. 도커 데스크톱 쿠버네티스는 정말 빠르게 한 번 확인할 때만 켭니다. 세 도구가 모두 같은 kubectl 명령을 쓰기 때문에, 어느 것으로 배워도 다른 환경으로 옮겨 가는 비용은 거의 없습니다. 그러니 처음에는 도구 선택에 너무 오래 고민하지 말고, 가장 쉬운 것으로 일단 손을 대 보시길 권합니다.

로컬에서 파드와 서비스를 띄워 봤다면, 그다음으로 익혀 두면 좋은 개념을 순서대로 정리하겠습니다. 한꺼번에 다 하려 하지 말고 하나씩 손으로 만져 보는 게 핵심입니다.

1. 디플로이먼트와 레플리카 수 조절: kubectl scale로 파드 개수를 늘렸다 줄여 보며 자가 복구 동작을 관찰합니다.
2. 서비스 종류 비교: ClusterIP·NodePort·LoadBalancer가 어떻게 다른지 직접 노출해 봅니다.
3. 설정과 비밀값 분리: ConfigMap과 시크릿(Secret)으로 환경 변수를 주입해 봅니다.
4. 선언형 매니페스트: 명령어 대신 YAML 파일로 같은 리소스를 만들어, kubectl apply -f 흐름에 익숙해집니다.
5. 네임스페이스: 여러 실습을 네임스페이스로 격리해 정리하는 습관을 들입니다.

여기까지 로컬에서 충분히 다뤄 보면, 나중에 실무나 면접에서 쿠버네티스 이야기가 나와도 개념이 막연하지 않습니다. 다만 다시 강조하면, 1인 개발자가 실제 운영까지 쿠버네티스를 도입할지는 별개의 문제입니다. 저처럼 버셀과 슈퍼베이스로 운영이 충분한 규모라면, 쿠버네티스는 운영 도구라기보다 학습과 커리어용 지식으로 두는 선택도 합리적입니다. 도구를 배우는 것과, 그 도구를 실제 서비스에 도입하는 것은 다른 결정이라는 점만 분명히 해 두시면 됩니다.

참고 자료

• 쿠버네티스 공식 도구 설치 문서 (kubernetes.io/docs/tasks/tools) — kubectl·minikube·kind 설치 안내
• minikube 공식 시작 가이드 (minikube.sigs.k8s.io) — 드라이버 선택과 첫 클러스터
• kind 공식 빠른 시작 (kind.sigs.k8s.io) — 클러스터 생성·멀티노드 구성