홈랩에 가장 적합한 Kubernetes 배포판은 무엇인가요?

홈랩용 최고의 Kubernetes 배포물은 K3s 또는 MicroK8s입니다.

3노드 홈랩을 위한 Kubernetes 배포판 비교

자신의 홈 랩에 가장 적합한 Kubernetes 플레버 선택

Page content

저는 Ubuntu 기반 홈랩에 적합한 3개 노드(각각 16GB RAM, 4코어)를 갖춘 자체 호스팅 Kubernetes 변형을 비교하고 있으며, 설치 및 유지보수가 용이하고, Persistent Volumes(PV) 및 LoadBalancer(LB) 서비스를 지원하는 것을 중심으로 살펴보고 있습니다.

시나리오: 우리는 홈랩에 3개의 Ubuntu 노드(각각 16 GB RAM, 4 CPU 코어)를 가지고 있습니다. 고가용성(HA)이나 ARM 지원은 우선순위가 아닙니다. 우리는 설치가 간단하고 유지보수가 쉬운 Kubernetes 클러스터(단일 노드 또는 3노드)를 원하며, Persistent Volumes (PV) 및 LoadBalancer (LB) 서비스를 지원해야 합니다(이렇게 하면 저장소나 외부 IP가 필요한 클라우드 네이티브 앱이 부드럽게 작동할 수 있습니다). HA 또는 ARM CPU 호환성 요구사항이 없는 3노드 클러스터 옵션에 집중할 것입니다.

kubernetes homelab

아래에서는 인기 있는 가벼운 [Kubernetes(https://www.glukhov.org/ko/post/2024/10/kubernetes-cheatsheet/ “가장 흔하고 유용한 k8s 명령어 목록 및 설명 - k8s cheatsheet”) 분포 – K3s, MicroK8s, Minikube, 그리고 kubeadm (vanilla Kubernetes) –를 비교하고, 주요 기준(기능, 설치/유지보수, PV/LB 지원, 자원 요구사항, 클러스터 설정, 도구)에서 어떻게 비교되는지 살펴보겠습니다. 또한 홈랩 시나리오에 따라 어떤 것을 선택하는 것이 좋을지 몇 가지 추천도 포함하고 있습니다.

K3s (Rancher의 가벼운 Kubernetes)

주요 기능: K3s는 CNCF 인증된 Kubernetes 분포로, 최소한의 자원 사용을 위해 설계되었습니다(512MB RAM만으로도 작동할 수 있습니다). K3s는 전체 Kubernetes 컨트롤 플레인을 단일 이진 파일과 프로세스로 포장하고, 가벼운 구성 요소(예: 기본적으로 etcd 대신 SQLite 데이터 저장소, 네트워킹은 flannel 사용)를 사용합니다. 내장된 ingress 컨트롤러(Traefik)와 간단한 서비스 로드 밸런서를 포함한 합리적인 기본값을 제공합니다. K3s는 부loat를 줄이기 위해 오래된/알파 기능을 제거합니다.

설치 및 유지보수의 용이성: 매우 간단합니다. 우리는 한 줄의 스크립트(curl ... | sh) 또는 K3sup과 같은 도구를 통해 설치할 수 있습니다. 서버는 기본 구성 요소가 즉시 제공되는 상태로 부팅됩니다. 노드를 추가하는 것은 간단합니다(서버에서 토큰을 받아 K3s 에이전트를 실행하면 됩니다). 업그레이드도 간단합니다(이진 파일을 교체하거나 새 버전의 설치 스크립트를 사용하면 됩니다). 별도의 etcd 설정이 필요하지 않습니다(다중 마스터 HA 설정을 선택하지 않는 한). K3s는 설치 후 최소한의 조작이 필요하도록 설계되어 있어 IoT 및 홈랩에서 인기가 있습니다.
Persistent Volume 지원: 내장되어 있습니다. 기본적으로 K3s는 Rancher의 local-path StorageClass를 포함하고 있으며, 이는 각 PVC에 대해 호스트 파일 시스템에서 PV를 동적으로 할당합니다. 이는 PVC가 생성될 때 자동으로 노드의 hostPath 볼륨이 생성되도록 합니다. 이는 단일 노드 저장 솔루션(각 볼륨은 하나의 노드의 디스크에 위치)이지만, 상태가 있는 앱에 대해 즉시 작동합니다. 더 고급의 저장 솔루션을 원한다면 Rancher의 Longhorn(분산 블록 저장소)과 같은 것을 추가할 수 있으며, K3s는 이를 지원하지만 홈랩에서는 일반적으로 기본 local-path 프로비저너가 충분합니다.
LoadBalancer 지원: 내장되어 있습니다. K3s는 ServiceLB(이전 이름은 “Klipper LB”)라는 가벼운 컨트롤러를 포함하고 있으며, 이는 외부 클라우드 제공업체 없이도 호스트에서 IP/포트를 할당할 수 있도록 합니다. LoadBalancer 서비스를 생성하면 K3s는 각 노드에 작은 LB 파드(svc-...)의 DaemonSet을 배포하며, 이는 호스트 포트를 사용하여 서비스로 트래픽을 전달합니다. 기본적으로 K3s는 노드의 IP(내부 또는 외부)를 재사용하여 LB IP로 사용하고, LB 파드에서 iptables 라우팅을 사용하여 트래픽을 서비스의 ClusterIP로 전달합니다. 이는 제로 설정으로 작동하며, 서비스가 “대기” 상태에 머무르지 않습니다(예: 베어메탈에서의 vanilla K8s와 달리). 단점은 LB 외부 IP가 우리의 노드 중 하나(또는 모든 노드)의 IP가 될 것이며, 포트가 비어 있어야 한다는 점입니다. 대부분의 홈랩 사용 사례(예: HTTP/HTTPS 포트에서 몇 가지 서비스 노출)에 대해서는 완벽하게 작동합니다. 필요하다면 내장된 LB를 비활성화하고 MetalLB를 수동으로 설치할 수도 있지만, 대부분의 사용자는 편리한 기본값을 유지합니다.
자원 요구사항: 매우 낮습니다. K3s는 저사양 하드웨어에서도 작동할 수 있습니다. 공식적으로는 서버 노드에 512MB RAM과 몇백 MB의 디스크 공간만 충분합니다. 실제로는 작은 클러스터가 컨트롤 플레인에 몇백 MB의 메모리를 사용할 수 있습니다. 이진 파일은 100MB 미만입니다. CPU 오버헤드는 최소이며(이용 중인 상태에서 K3s는 MicroK8s보다 약간 더 많은 CPU를 사용하지만, 큰 차이가 아닙니다), 우리의 노드(각각 16GB)는 K3s를 편안하게 실행하는 데 충분합니다.
단일 노드 vs 다중 노드: 모두에 적합합니다. K3s는 단일 노드(모든 컨트롤 플레인 및 워크로드가 하나의 머신에) 또는 다중 노드로 실행할 수 있습니다. 3노드 설정에서는 1개의 서버(마스터)와 2개의 에이전트를 실행하거나, 심지어 모든 3개의 서버를 HA용으로 실행할 수도 있습니다(하지만 HA는 목표가 아니므로 여기서는 필요하지 않습니다). 에이전트를 추가하는 것은 토큰을 사용하는 것이 매우 간단합니다. K3s의 기본 SQLite 데이터 저장소는 단일 서버에 적합하며, 다중 서버 HA를 위해 내장 etcd로 전환할 수 있습니다(다중 서버 노드를 시작할 때 K3s는 자동으로 이 작업을 수행할 수 있습니다).
CLI 및 UI 도구: K3s는 일반적인 Kubernetes와 마찬가지로 kubectl을 통해 상호작용합니다. K3s는 자체 kubectl 빌드를 포함하고 있으며, k3s kubectl ...을 실행하거나 K3s의 kubeconfig를 가리키는 일반적인 kubectl을 사용할 수 있습니다. 설치 명령어 외에는 K3s에 특화된 CLI가 없습니다(의도적으로 최소한의 기능을 제공). 내장된 웹 UI는 포함되어 있지 않으며(기본적으로 upstream Dashboard는 설치되지 않음). 그러나 우리는 K3s에 Kubernetes Dashboard나 다른 도구를 수동으로 배포할 수 있습니다. Rancher(동일한 회사에서 제공하는 GUI 관리 도구)도 K3s 위에 설치할 수 있지만, 이는 K3s 자체에 포함되어 있지 않습니다. 본질적으로 K3s는 핵심 k8s API를 제공하며, 필요에 따라 추가 기능(ingress, 저장소 등)을 추가할 수 있습니다(일부는 이미 포함되어 있음).

MicroK8s (Canonical의 저유지비용 Kubernetes)

주요 기능: MicroK8s는 Canonical의 가벼운 Kubernetes 분포로, snap 패키지로 제공됩니다. 이는 단일 명령어로 완전히 표준에 부합하는 Kubernetes 클러스터(업스트림 이진 파일)를 설치할 수 있으며, 단일 머신 또는 작은 클러스터에서 사용이 용이하도록 설계되었습니다. “전체 포함” 접근 방식을 강조하며, 간단한 명령어로 많은 선택적 기능을 활성화할 수 있습니다. MicroK8s는 기본적으로 vanilla Kubernetes 경험(모든 표준 API)을 제공하지만, 일반적인 요구사항에 대한 편리한 추가 기능도 포함합니다. 단일 노드 및 다중 노드 배포를 모두 지원하며, 노드를 “조인"하여 클러스터를 형성할 수 있습니다. 또한, 3개의 마스터를 사용하는 경우 HA 모드(Dqlite – 분산 SQLite 사용)를 지원하는 컨트롤 플레인도 제공합니다.

설치 및 유지보수의 용이성: 매우 간단합니다. Ubuntu 머신에서 snap install microk8s --classic만 실행하면 Kubernetes 노드가 설정됩니다. 이는 모든 구성 요소를 포함한 단일 패키지입니다. MicroK8s는 Ubuntu의 snap 시스템을 통해 유지보수가 이루어지며, 이는 업데이트가 원자적이고 자동화될 수 있습니다(우리는 Kubernetes 버전을 위한 채널을 추적할 수 있습니다). 이 자동 업데이트 기능은 이 옵션 중 유일하며, 우리는 보안 패치 및 소규모 업그레이드를 snap refresh를 통해 선택적으로 받을 수 있습니다. MicroK8s 관리는 microk8s 명령어를 통해 수행되며, 이는 기능을 활성화/비활성화하는 하위 명령어를 포함합니다. 전체적으로 매우 낮은 마찰이 있으며, 컨테이너나 VM을 관리할 필요가 없고(호스트에서 네이티브로 실행), 외부 etcd를 구성할 필요도 없습니다(내부 데이터 저장소 사용). 유지보수는 필요 시 snap을 업데이트하고 microk8s.status를 사용하여 모니터링하는 것에 집중됩니다.
Persistent Volume 지원: 추가 기능을 통해 가능합니다. 기본적으로 MicroK8s는 “hostpath-storage” 추가 기능을 활성화하기 전에는 PV를 자동으로 할당하지 않습니다. 이 기능을 활성화하는 방법은 microk8s enable hostpath-storage입니다. 이는 호스트의 디렉토리에서 볼륨을 할당하는 기본 StorageClass를 생성합니다. 이는 K3s의 local-path와 개념적으로 유사한 동적 hostPath 프로비저너입니다. 활성화되면, 모든 PVC는 MicroK8s 노드의 hostpath PV에 바인딩됩니다. (다중 노드 MicroK8s 클러스터의 경우, hostpath PV는 하나의 노드에 위치하며, 테스트 또는 홈랩 사용에는 적합하지만 분산 저장소는 아닙니다). MicroK8s는 또한 Mayastor 및 기타 저장소 추가 기능을 제공하여, 노드 간 더 고급의 저장소를 원하는 경우 사용할 수 있습니다. 그러나 단순성을 위해 hostpath 저장소가 잘 작동합니다. 참고: 이 추가 기능은 기본적으로 비활성화되어 있습니다(가볍게 유지하기 위해), 따라서 PVC가 작동하도록 하려면 활성화해야 합니다. Canonical은 이 기능이 생산용 HA에 적합하지 않다고 지적하지만(복제되지 않음), 홈랩에서는 완벽합니다.
LoadBalancer 지원: 추가 기능을 통해 가능합니다. MicroK8s는 기본적으로 로드 밸런서를 포함하지 않지만, MetalLB를 쉽게 추가할 수 있습니다. microk8s enable metallb:<start-IP>-<end-IP>를 실행하면 MetalLB가 Layer 2 모드로 배포되고, LAN에서 사용할 IP 풀을 지정할 수 있습니다. 활성화되면, LoadBalancer 유형의 서비스는 해당 범위에서 IP를 자동으로 할당받고, MicroK8s는 LAN에서 ARP를 통해 이를 광고합니다. 이는 베어메탈에서 클라우드와 유사한 경험을 제공합니다. (MetalLB를 활성화하지 않으면, LoadBalancer 서비스는 대기 상태에 머무르며, MicroK8s 자체는 이를 구현하지 않기 때문입니다 – upstream Kubernetes와 동일). 홈랩에서는 MetalLB가 간단하며, 로컬 네트워크에서 서비스에 액세스할 수 있게 해줍니다. 우리는 네트워크에서 사용 가능한 무료 서브넷 또는 IP 범위를 선택해야 합니다. MicroK8s의 enable 명령어는 설정을 간편하게 하지만, 여전히 별도의 단계입니다. (반면, K3s는 LB에 대해 즉시 작동하지만, 노드 IP/포트를 사용하는 제한이 있습니다). 많은 MicroK8s 사용자는 초기 설정에서 MetalLB를 활성화하여 기능적인 LB를 사용합니다.
자원 요구사항: MicroK8s는 비교적 가볍지만, K3s보다 약간 더 많은 자원을 사용합니다. 이는 모든 핵심 서비스(API 서버, 컨트롤러, 스케줄러, kubelet, etcd 또는 Dqlite)를 네이티브로 실행합니다. 유휴 상태일 때는 일반적으로 컨트롤 플레인에 약 500–600 MB RAM이 필요하며, 활성화된 추가 기능에 따라 달라집니다. Canonical은 약 540 MB의 기본 메모리를 언급합니다. 유휴 상태일 때 CPU 사용량은 낮으며, 우리의 16 GB 노드는 충분한 여유 공간을 제공합니다. 디스크 공간 요구사항은 작으며(snap 약 200 MB + etcd 데이터). 요약하자면, MicroK8s는 보통 하드웨어에서도 실행될 수 있으며, 라즈베리 파이를 위한 것도 제공됩니다. 우리의 시나리오에서는 기계들이 MicroK8s를 쉽게 수용합니다. 여러 추가 기능(대시보드, 모니터링 등)이 활성화되면 자원 사용량이 증가합니다.
단일 노드 vs 다중 노드: MicroK8s는 모두에 적합합니다. 단일 노드 클러스터(예: 개발 머신 또는 하나의 서버)에 사용하거나, 노드를 “조인"하여 다중 노드 클러스터를 생성할 수 있습니다. MicroK8s 문서에는 노드를 추가하는 명령어가 제공되어 있으며, 우리는 첫 번째 노드에서 토큰을 가져와 다른 노드에서 사용합니다. HA가 없는 다중 노드 설정에서는 하나의 노드가 주요 컨트롤 플레인으로 작동합니다. 3개 노드의 경우, ha-cluster 모드를 활성화하여 3개 노드에서 Dqlite를 실행하여 컨트롤 플레인을 HA로 만들 수도 있지만, 우리의 경우 HA는 필요하지 않습니다. 단일 노드든 3개 노드든, Kubernetes API 경험은 동일합니다. 다중 노드 MicroK8s는 K3s보다는 조금 더 최근에 출시되었지만, 지금은 매우 안정적입니다. 우리가 몇 개의 Ubuntu 박스에서 최소한의 노력으로 k8s를 실행하는 “마이크로 클라우드"를 원한다면, 이는 좋은 선택입니다.
CLI 및 UI 도구: MicroK8s는 microk8s 명령줄 도구를 제공하며, 매우 편리합니다. 예를 들어, microk8s enable <addon>은 다양한 서비스(DNS, ingress, storage, metallb, dashboard 등)를 토글할 수 있고, microk8s status는 실행 중인 항목을 보여줍니다. 또한 내장된 kubectl도 포함되어 있으며, microk8s kubectl ... 또는 별칭을 사용하여 클러스터에 접근할 수 있습니다. 이는 kubeconfig 설정이 필요하지 않다는 점에서 매우 편리합니다. UI 도구로는 Kubernetes Dashboard가 추가 기능으로 제공됩니다(microk8s enable dashboard), 이는 표준 웹 UI를 배포합니다. 활성화되면, 우리는 10443 포트 또는 프록시를 통해 접근할 수 있습니다. MicroK8s는 자체 GUI가 없으며, Kubernetes Dashboard 또는 다른 도구에 의존하지만, 활성화가 간단하다는 점은 장점입니다. 요약하자면, MicroK8s는 일반적인 작업에 대해 한 명령어 경험을 강조하며, 많은 복잡성을 추상화하는 “그냥 작동” 철학을 따릅니다(이로 인해 일부 내부 기능이 숨겨지는 단점이 있습니다). 이는 매우 홈랩 친화적이며, 각 구성 요소의 수동 설정 없이 Kubernetes 클러스터를 원하는 사람들에게 적합합니다.

K3s vs MicroK8s 비교: 두 제품 모두 목표와 기능 면에서 매우 유사합니다 – 가볍고, 사용이 용이하며, 다중 노드 지원이 가능합니다. K3s는 추가 기능을 추가할 때 약간 더 “DIY” 성향이 있으며, 포함되지 않은 항목은 Helm 차트나 수동 매니페스트에 의존합니다. 반면, MicroK8s는 CLI를 통해 내장된 추가 기능을 제공합니다. 또한, MicroK8s는 내부적으로 더 “vanilla” Kubernetes(업스트림 구성 요소, snap으로 포장됨)이며, K3s는 일부 커스텀 이진 파일과 모든 것을 위한 단일 서비스를 사용합니다. 두 제품 모두 홈랩에 적합하며, 선택은 종종 선호도에 달려 있습니다: Ubuntu/snaps와 통합된 느낌을 원한다면 MicroK8s가 좋고, 최소한의 접근 방식과 약간 더 수동적인 제어를 원한다면 K3s가 훌륭합니다. (나중에 추천을 제공하겠습니다.)

Minikube (단일 노드 로컬 K8s)

주요 기능: Minikube는 일반적으로 개발자의 PC 또는 랩탑에서 로컬로 Kubernetes를 실행하는 도구로, 여러 대의 머신을 사용하는 전통적인 클러스터가 아닌 단일 노드 클러스터를 생성합니다. Minikube는 우리의 머신에서 가상 머신 또는 컨테이너에 단일 노드 Kubernetes 클러스터를 생성합니다. Minikube는 다양한 환경을 지원하며, Linux, macOS, Windows에서 실행되며, 여러 가상화 도구(VirtualBox, KVM, Hyper-V, Docker 드라이버 등)를 지원합니다. Kubernetes SIGs에 의해 유지되며, 테스트 및 학습에 자주 사용됩니다. Minikube는 다중 노드 구성으로도 사용할 수 있지만, 기본적으로 단일 노드 클러스터를 위한 도구입니다(“다중 노드” 모드는 사실 동일한 호스트에서 컨테이너 런타임을 사용하여 여러 노드를 시작하는 것으로, 클러스터를 시뮬레이션하는 데 유용하지만, 별도의 물리 머신에서 실행하는 것은 아닙니다).

설치 및 사용의 용이성: Minikube는 단일 머신에서 시작하는 것이 매우 쉽습니다. 우리는 minikube 이진 파일을 설치하고, VM 드라이버(또는 Docker)가 있는지 확인한 후 minikube start 명령을 실행하면 됩니다. 이는 로컬 VM/컨테이너를 설정하고 그 안에서 Kubernetes를 실행하게 됩니다. 이는 Kubernetes 클러스터를 처음 실행하는 데 가장 간단한 방법일 수 있습니다. CLI(minikube)는 VM과 상호작용할 수 있는 명령(시작, 중지, 삭제)과 애드온을 활성화하는 명령을 제공합니다. Minikube는 로컬 사용을 위해 설계되었기 때문에, 일반적으로 필요할 때 시작하고 작업이 끝나면 중지하는 것이 일반적이지만, 원한다면 홈랩 서버에서 지속적으로 실행할 수도 있습니다. 유지보수 및 업그레이드는 간단합니다: minikube 버전을 업데이트하고 클러스터를 재시작하면 됩니다(Minikube는 플래그를 사용하여 실행 중인 Kubernetes 버전을 업데이트할 수도 있습니다). 그러나 한 가지 제한점은 Minikube가 단일 노드로 설계되어 있다는 점입니다(더 많은 노드를 추가하려면 동일한 호스트에서 추가 VM 인스턴스를 시작해야 하며, 실제 별도의 호스트를 조인하는 것은 아닙니다). 따라서, 세 개의 별도 물리 노드에서 Minikube를 사용하는 것은 사실상 세 개의 독립적인 단일 노드 클러스터를 실행하는 것과 같으며, 이는 우리가 원하는 것이 아닐 수 있습니다. Minikube는 단일 머신에서 개발 및 테스트에 탁월하지만, 여러 물리 서버에 걸쳐 있는 클러스터를 관리하는 데는 적합하지 않습니다.
지속 가능한 볼륨 지원: 내장 지원 (hostPath). Minikube 클러스터는 기본적으로 hostPath 프로비저너를 사용하는 기본 StorageClass를 자동으로 포함합니다. 사실, Minikube는 PVC가 요청되면 VM 내부에서 hostPath PV를 동적으로 생성하는 작은 컨트롤러를 실행합니다. 이는 우리가 PersistentVolumeClaim을 생성하면 Minikube VM의 파일시스템(보통 /tmp/hostpath-provisioner 또는 유사한 경로)에서 저장 공간을 사용하여 이를 충족시켜 줍니다. 기본 PV 사용은 즉시 작동하며, 설정이 필요하지 않습니다. 예를 들어, Minikube의 기본 “standard” StorageClass는 노드의 hostPath 저장소에 매핑됩니다. 다만, 주의할 점은 Minikube VM을 재시작하거나 삭제하면 hostPath 볼륨이 손실될 수 있다는 점입니다(Minikube는 /data, /var/lib/minikube, /tmp/hostpath*와 같은 특정 디렉터리를 재시작 시에도 보존하려고 시도합니다). 그러나 일반적으로, 비생산 환경에서는 이는 문제가 되지 않습니다. 더 많은 시뮬레이션을 원한다면, Minikube에는 CSI hostpath 드라이버 애드온도 포함되어 있으며, 스냅샷 기능을 지원하고 다중 노드 모드에서도 작동할 수 있습니다. 그러나 이는 주로 실험용입니다. 결론적으로, Minikube는 기본적으로 hostPath를 통해 PV를 지원하며, 이는 상태가 있는 앱을 위한 홈랩 테스트에 충분합니다.
LoadBalancer 지원: 터널링을 통해 지원 (또는 MetalLB 애드온). 클라우드 환경에서는 LoadBalancer 서비스가 외부 IP를 가진 클라우드 LB를 제공합니다. Minikube에서는 당연히 클라우드 제공자가 없기 때문에, Minikube는 두 가지 메커니즘을 제공합니다:
- Minikube 터널: 우리는 별도의 프로세스에서 minikube tunnel을 실행하여 호스트에 네트워크 라우트를 생성하고 LoadBalancer 서비스에 IP를 할당할 수 있습니다. 기본적으로, 우리의 호스트가 “외부 LB” 역할을 하게 됩니다. LoadBalancer 서비스를 생성하면 Minikube는 “외부 IP”(보통 클러스터의 서브넷에서)를 표시하고 minikube tunnel 프로세스가 이 IP를 서비스에 라우팅합니다. 이는 터널 프로세스가 계속 실행되어야 하며(보통 루트 권한이 필요합니다), 이는 수동적인 단계이지만, LoadBalancer 서비스가 실행 중인 터널이 없을 경우 Minikube는 “External-IP pending” 메시지를 표시합니다.
- MetalLB 애드온: Minikube의 새 버전에는 MetalLB 애드온도 포함되어 있습니다. 우리는 minikube addons enable metallb 명령을 실행하고 IP 범위를 구성할 수 있습니다(Minikube는 우리에게 이를 요청합니다). 이는 MetalLB를 Minikube 클러스터 내부에 배포하여, 이는 일반적인 베어메탈 Kubernetes와 동일하게 LoadBalancer 서비스를 처리하게 됩니다. 이는 초기 설정 후 별도의 터널 프로세스가 필요하지 않은 더 “클러스터 내부” 솔루션입니다.
두 가지 방법 모두 작동하며, 사용할 방법은 우리가 선택하는 것입니다. 하나의 서비스를 빠르게 노출시키려면 minikube tunnel이 빠르고 일시적이며, 더 영구적인 설정을 원한다면 MetalLB 애드온을 활성화하여 LB가 실제 IP를 받을 수 있도록 할 수 있습니다(예를 들어, 브리지 네트워킹을 사용하는 Minikube에 10.0.0.240-250 범위를 할당할 수 있습니다). Minikube가 일반적으로 단일 노드이기 때문에, 사실 “로드 밸런서”는 여러 노드 사이에서 밸런싱을 하지 않고 단일 노드의 서비스에 외부 접근을 제공하는 것입니다. 이는 개발에 적합합니다. 홈랩에서 하나의 노드만 사용하고 그 노드에 Minikube를 실행한다면, 이들을 사용하여 앱에 접근할 수 있습니다. 그러나 세 개의 노드를 모두 활용하려면 Minikube의 LB 접근 방식은 해당 시나리오에 적합하지 않습니다.
자원 요구 사항: Minikube 자체는 가볍지만, 일반적으로 VM 내에서 전체 단일 노드 Kubernetes를 실행하기 때문에, 일반적인 작은 클러스터와 유사한 자원 사용량이 있습니다. VM에 대한 최소 권장 사양은 2GB RAM과 2개의 CPU입니다. 기본적으로 Minikube는 VM에 2GB RAM을 할당합니다. 우리의 경우, 각 머신당 16GB RAM이 있으므로 이는 매우 간단합니다. 유휴 상태의 Minikube(Kubernetes)는 약 600MB 메모리만 사용합니다. 고려해야 할 한 가지는 Minikube가 우리의 OS 위에서 실행되며, 가상화 도구를 통해 VM 또는 Docker 컨테이너로 실행되므로, 이는 추가 오버헤드를 발생시킬 수 있다는 점입니다. 홈랩 서버에서는 “none” 드라이버를 사용하여 Minikube를 실행할 수 있습니다(이 드라이버는 호스트에 직접 Kubernetes 구성 요소를 설치합니다). 그러나 “none”(또는 베어메탈) 드라이버는 사실상 kubeadm을 그 노드에 사용하는 것과 유사하며, 수동 정리가 필요하기 때문에 인기 있는 것은 아닙니다. 대부분은 VM 또는 Docker 드라이버를 사용합니다. 요약하자면, 우리의 홈랩 노드 중 하나라도 Minikube를 쉽게 실행할 수 있습니다. 유일한 제약은 Minikube가 모든 세 개의 노드의 자원을 사용하지 못한다는 점입니다. 즉, 단일 호스트에 제한되며(실험용 다중 노드 기능을 사용하지 않는 한) 모든 세 개의 노드를 사용할 수 없습니다.
단일 노드 vs 다중 노드: 주로 단일 노드. Minikube는 단일 머신에서 단일 노드 클러스터를 위한 이상적인 도구입니다. 다중 노드를 시뮬레이션하는 기능도 제공합니다(예: Docker 드라이버를 사용하여 minikube start --nodes 3 명령을 실행하면 하나의 호스트에서 3개의 Kubernetes 노드를 컨테이너로 시작합니다), 하지만 이는 테스트 용도로만 사용됩니다. Minikube를 사용하여 세 개의 별도 물리 서버에서 실제 다중 노드 클러스터를 생성할 수는 없습니다. 세 개의 머신이 있다면, 각 머신에 독립적인 Minikube 인스턴스를 실행해야 하며, 이는 하나의 클러스터가 아닙니다. 따라서, 우리의 목적이 세 개의 노드를 하나의 Kubernetes 클러스터에서 사용하는 것이라면, Minikube는 권장하지 않습니다. 단일 머신(우리의 PC 또는 하나의 서버)에서만 사용하고 K8s를 실행하려는 경우에 적합합니다. 또한, Kubernetes 기초 학습 및 로컬 개발에도 매우 좋습니다.
CLI 및 UI 도구: minikube CLI는 주요 인터페이스입니다. 우리는 이를 사용하여 클러스터를 시작하거나 중지할 수 있으며, minikube dashboard 명령은 Kubernetes 대시보드를 활성화하고 브라우저에서 자동으로 열어줍니다. minikube addons enable <addon> 명령은 여러 선택적 구성 요소(인그레스, metallb, metrics-server 등)를 활성화할 수 있습니다. Minikube는 자동으로 kubectl 액세스를 설정합니다(우리의 kubeconfig에 “minikube”라는 컨텍스트를 구성합니다). UI에 대해서는 앞서 언급했듯이, Kubernetes 대시보드는 dashboard 명령을 통해 쉽게 접근할 수 있습니다. Minikube는 자체적인 웹 UI를 가지고 있지 않으며, 표준 도구에 의존합니다. Minikube의 디버깅도 간단합니다. 필요하다면 minikube ssh 명령을 사용하여 노드 VM에 접속할 수 있습니다. 전체적으로, 단일 노드 시나리오에 대해 도구는 매우 사용자 친화적입니다.

Kubeadm (우리 노드에서의 Vanilla Kubernetes)

주요 기능: Kubeadm은 “분배판”이 아니라, Kubernetes 클러스터를 처음부터 생성하는 공식 도구입니다. Kubeadm을 사용하면 우리는 머신에 표준 업스트림 Kubernetes 구성 요소를 배포하게 됩니다. 이는 사실상 우리가 “자체 클러스터”를 생성하는 방법이며, 분배판이 포함하는 추가 기능 없이 최선의 실천 방식을 따릅니다. Kubeadm은 컨트롤 플레인 노드(예: etcd, API 서버, 컨트롤러 매니저, 스케줄러)를 설정하고, 워커 노드를 이에 조인하게 됩니다. 결과적으로, 클라우드 VM에서 얻는 것과 동일한 완전한 표준 Kubernetes 클러스터가 생성됩니다. 이 접근 방식은 우리에게 완전한 제어권과 유연성을 제공하지만, 초기 수동 작업과 지식이 가장 많이 요구됩니다. 이는 일반적으로 생산 환경이나 Kubernetes 내부 구조를 이해하려는 학습 환경에서 사용됩니다.

설치 및 유지보수의 용이성: 다른 것들에 비해, kubeadm은 가장 복잡합니다. 우리는 각 노드에 의존성(예: 컨테이너 런타임인 containerd, kubeadm, kubelet, kubectl)을 수동으로 설치해야 합니다. 그런 다음 마스터 노드에서 kubeadm init을 실행하고, 워커 노드에서 제공된 토큰을 사용하여 kubeadm join을 실행해야 합니다. 또한, 초기화 후 CNI(네트워크 플러그인)를 설정해야 합니다(예: Calico, Flannel 등) – kubeadm은 기본적으로 이를 설치하지 않습니다. 이 모든 과정에 대한 잘 문서화된 단계가 있으며(이 과정은 어려운 것이 아니지만 많은 단계가 필요합니다), 기본적으로 kubeadm은 우리가 시작하는 클러스터를 제공하지만, 애드온을 우리가 직접 처리해야 합니다. 유지보수 측면에서는, 우리는 업그레이드(예: kubeadm은 업그레이드 명령을 제공하지만, 노드를 드레인하고, 이진 파일을 업데이트하는 등의 작업을 수동으로 해야 함), etcd 건강 상태 모니터링, 인증서 갱신 등에 책임이 있습니다. 간단히 말해, kubeadm은 강력하지만 수동적인 도구입니다. 이는 종종 “어려운 방법”(소스에서 빌드하는 것만큼은 아니지만)으로 불리며, 홈랩 취미主义者가 학습을 즐기는 경우에 매우 적합합니다. 그러나 우리의 우선순위가 “쉬움과 유지보수가 적은 것”이라면, kubeadm은 K3s/MicroK8s보다 더 많은 작업이 필요합니다. 각 업그레이드나 변경에는 수동 작업이 필요합니다. 그러나 한 번 설정하면, 이는 진짜 것입니다: 표준 Kubernetes 클러스터이며, 숨은 추상화 없이 제공됩니다.
지속 가능한 볼륨 지원: 기본적으로 없음 (수동으로 추가해야 함). kubeadm으로 설치된 클러스터는 사실상 빈 Kubernetes입니다. 기본적으로 StorageClass나 동적 프로비저너가 포함되어 있지 않습니다. 클라우드 환경에서는 일반적으로 클라우드 제공자가 기본 StorageClass를 제공합니다(예: AWS EBS 등), 그러나 홈랩 베어메탈 환경에서는 우리가 자체 솔루션을 설치해야 합니다. 일반적인 접근 방법:
- HostPath 프로비저너: K3s/Minikube가 하는 것과 유사하게 Rancher Local Path Provisioner(작은 컨트롤러 + StorageClass로 hostPath PV를 생성하는 것)를 설치할 수 있습니다. 이는 간단한 애드온(단순한 YAML 매니페스트)이며, 로컬 동적 저장소를 제공합니다.
- NFS 또는 NAS: 일부 홈랩 사용자는 NFS 서버를 설정하거나 NAS를 사용하고, 정적 PV 또는 NFS CSI 드라이버를 사용하여 프로비저닝합니다.
- OpenEBS/Longhorn/Ceph: 분산 저장소를 위해 Longhorn 또는 Ceph RBD를 Rook를 통해 설치하는 복잡한 옵션도 있습니다. 이는 더 많은 자원과 복잡성을 요구합니다.
핵심 포인트는 kubeadm이 우리 대신 저장소를 “해결”하지 않는다는 점입니다. 우리는 결정하고 구성해야 합니다. 편의성이 우선순위라면, 가장 간단한 방법은 hostPath 프로비저너를 설치하거나 NFS를 사용하는 것입니다. 예를 들어, Rancher의 local-path 프로비저너는 몇 개의 kubectl apply 명령으로 설치할 수 있으며, K3s의 동작을 모방합니다(어떤 노드의 /var/lib/rancher/ 아래에 볼륨을 생성합니다). 그러나 이는 수동 단계입니다. 이를 수행하기 전에는 우리가 생성한 PVC가 항상 “Pending” 상태에 머무를 것입니다. 왜냐하면 Kubernetes에 기본적인 프로비저닝이 없기 때문입니다. 따라서, kubeadm은 분명히 Persistent Volumes을 지원하지만, 동적 PV 지원은 우리가 설정에 얼마나 많은 노력이 들어가는지에 따라 결정됩니다.
LoadBalancer 지원: 기본적으로 없음 (수동으로 추가해야 함). 여기서도 비슷한 이야기입니다: 전통적인 온프레미스 클러스터에서는 내장 LoadBalancer 구현이 없습니다. 우리가 plain kubeadm 클러스터에서 LoadBalancer 유형의 서비스를 생성하면, 이는 pending 상태에 머무르게 됩니다. 이 문제를 해결하기 위한 일반적인 방법은 MetalLB를 수동으로 설치하는 것입니다. MetalLB는 매니페스트 또는 Helm 차트를 통해 설치할 수 있으며, IP 범위를 구성한 후 LoadBalancer 서비스에 해당 IP를 할당합니다(이것은 MicroK8s와 동일합니다). kubeadm 클러스터에 MetalLB를 설치하는 방법에 대한 많은 가이드가 존재합니다. 일부 사용자는 kube-vip를 사용하여 컨트롤 플레인 VIP 및 서비스 LB를 설정하기도 하지만, 서비스에 대해 MetalLB는 더 간단합니다. 기본적으로, kubeadm은 우리가 필요로 하는 어떤 로드 밸런싱 메커니즘을 설정할 수 있는 자유(또는 부담)가 있습니다. 아무것도 설정하지 않으면 외부 접근에 대해 NodePort 서비스만 제한됩니다. 홈랩에서는 MetalLB를 설치하는 것이 매우 권장되며, 이는 간단하고 클라우드와 유사한 서비스 IP 기능을 제공합니다. 하지만 다시 말하지만, 이는 우리가 수행해야 하는 추가 단계입니다(예: K3s는 즉시 작동하거나 MicroK8s는 간단한 활성화로 작동합니다).
자원 요구 사항: 표준 Kubernetes는 잘라낸 버전보다 약간 더 무겁습니다. 각 노드는 kubelet과 kube-proxy를 실행하고, 마스터는 etcd와 컨트롤 플레인 구성 요소를 실행합니다. 단일 컨트롤 플레인 노드는 2GB RAM으로 실행할 수 있지만, 일반적으로 그 위에 포드를 실행하는 경우 더 많은 RAM이 필요할 수 있습니다. padok 가이드는 마스터에 2GB, 워커에 2GB를 권장합니다. 우리의 경우(노드당 16GB RAM), 이는 충분합니다. 유휴 상태의 etcd와 API 서버는 각각 몇백 MB 메모리만 사용합니다. kubeadm 클러스터와 MicroK8s 사이에는 실행 중에 큰 차이가 없습니다. 결국, MicroK8s는 동일한 구성 요소입니다. 차이점은 기본적으로 실행되는 것이며, MicroK8s는 DNS와 저장소를 기본적으로 활성화할 수 있지만, kubeadm에서는 이를 설치해야 합니다. 자원 측면에서, kubeadm은 우리가 구성하는 대로 가볍거나 무거울 수 있습니다. 아무것도 추가하지 않은 상태라면 매우 가볍게 실행될 수 있습니다. 일반적인 설정(예: CoreDNS, 대시보드 등을 추가하는 경우)에서는 시스템 오버헤드로 약 1GB 정도 사용할 수 있습니다. 우리는 충분한 RAM을 가지고 있으므로, 자원은 걱정할 필요가 없습니다. 이는 CPU/RAM보다 인간의 시간과 자원이 더 중요합니다.
단일 노드 vs 다중 노드: Kubeadm은 모두 가능하며, 완전한 유연성을 제공합니다. 우리는 단일 노드 클러스터를 초기화할 수 있고, 심지어 kubeadm에게 마스터 노드가 워크로드를 실행하도록 허용하도록 말할 수도 있습니다(마스터를 untaint). 또는 하나의 마스터와 두 개의 워커를 조인할 수 있습니다(일반적인 3노드 설정). 심지어 세 개의 마스터와 세 개의 워커를 설정할 수도 있습니다 – 어떤 토폴로지든 가능합니다. 우리의 경우, 아마도 1개의 컨트롤 플레인 노드와 2개의 워커가 있는 kubeadm 설정이 될 것입니다(고가용성은 필요하지 않으므로, 여러 마스터는 필요하지 않습니다). 이는 기능적인 3노드 클러스터를 제공합니다. 다중 노드 설정의 과정은 잘 문서화되어 있으며, 기본적으로 모든 노드에 Kubernetes를 설치하고 하나를 초기화하고 나머지를 조인하는 것입니다. 결과는 관리되는 클러스터나 다른 분배판이 제공하는 것과 동일합니다: 우리의 3노드는 kubectl get nodes 등에서 표시됩니다. 따라서, kubeadm은 “모든 3노드를 사용할 수 있다”는 요구 사항을 충족합니다.
CLI 및 UI 도구: kubeadm에서는 kubeadm 자체가 유일한 특별한 CLI이며, 설정 및 (나중에) 업그레이드 단계에 사용됩니다. 일상적인 사용에서는 kubectl을 사용하여 클러스터를 관리합니다. Kubernetes가 제공하는 것 이상의 통합 관리 CLI는 없습니다. UI에 대해서는 기본적으로 아무것도 포함되지 않으며, 우리는 수동으로 Kubernetes 대시보드나 다른 도구를 배포할 수 있습니다(일반적인 클러스터와 동일하게). 기본적으로, kubeadm은 우리에게 빈 Kubernetes 캔버스를 제공합니다. 우리가 그 위에 그림을 그릴 수 있는 것은 우리가 결정하는 것입니다 – 이는 대시보드, 인그레스 컨트롤러, 저장소 클래스 등을 설치하는 것 포함됩니다. Lens, Octant 등과 같은 많은 제3자 대시보드도 우리가 GUI 관리 경험을 원한다면 kubeadm 클러스터에 연결할 수 있지만, 이는 외부 도구입니다. 요약하자면, kubeadm은 순수한 Kubernetes 환경을 제공하며, 최대의 유연성을 제공하지만, 이는 생산 클러스터처럼 모든 것을 설정해야 하는 필요성을 동반합니다.
Kubespray Kubespray를 사용하여 Kubernetes를 설치하는 방법에 대한 자세한 내용은 Kubernetes with Kubespray을 참조하십시오.

병렬 비교 표

아래는 네 가지 옵션을 주요 포인트에 따라 비교한 요약입니다:

항목	K3s (가볍고 Rancher K8s)	MicroK8s (Canonical “Low-Ops” K8s)	Minikube (단일 노드 개발용 K8s)	Kubeadm (순수 Kubernetes)
설치	한 줄 설치 스크립트(단일 바이너리). 시스템 서비스로 실행. 매우 빠른 설정.	Ubuntu에서 snap을 통해 한 명령어로 설치. 모든 구성 요소 포함. `microk8s join`을 통해 클러스터링이 간단함.	minikube CLI를 설치한 후 `minikube start`을 실행하여 로컬 VM/컨테이너를 시작. 크로스 플랫폼이며 초보자 친화적.	각 노드에 kubeadm, kubelet 등을 수동으로 설치. `kubeadm init` + `kubeadm join`을 실행해야 하며, 사전 조건이 필요함. 여러 단계를 포함(런타임, 네트워킹 플러그인 등).
유지보수 및 업그레이드	수동 업그레이드(바이너리 교체 또는 새 버전 설치 스크립트 사용). 단일 바이너리이기 때문에 간단하며 관리할 것이 거의 없음. 자동 업데이트 없음.	snap refresh를 통해 업데이트(자동 업데이트 가능). `microk8s` CLI를 통해 추가 기능 및 클러스터 서비스 관리. 일반적으로 low-ops이며 자동 업그레이드 가능.	개발용으로 클러스터를 쉽게 삭제/재생성 가능. minikube 버전을 업데이트하고 클러스터를 재시작하여 업그레이드. 일시적인 사용에 적합(장기적인 in-place 업그레이드에 중점을 두지 않음).	사용자가 모든 업그레이드를 담당. `kubeadm upgrade` 사용 가능하지만, 노드 드레인, etcd 백업 등이 필요함. 전체 제어 가능하지만, 사용자가 직접 작업해야 함(자동 업데이트 없음).
K8s 버전	업스트림과 비교해 상당히 가까움(가끔 엣지 릴리스에 사용됨). CNCF 준수. 일부 기능은 기본적으로 비활성화됨(알파/레거시).	업스트림 릴리스를 따름(1.27, 1.28 등 snap 채널). CNCF 준수. 본질적으로 순수 K8s 바이너리.	시작 시 Kubernetes 버전을 선택할 수 있음(예: `minikube start --kubernetes-version=v1.27`). 기본값은 최신 안정 버전.	원하는 버전을 선택할 수 있음(특정 kubeadm/kubelet 버전 설치). 전체 업스트림 Kubernetes – 버전과 업그레이드 시점을 우리가 결정함.
기본 기능	포함된 기본값: Flannel CNI, CoreDNS, Traefik ingress, 서비스 LB, 로컬 스토리지 클래스, metrics-server 등. (필요하지 않으면 모두 비활성화 가능). 기능을 위해 필요한 최소한의 구성.	기본값 최소: DNS는 일반적으로 활성화됨, 나머지는 선택적. ingress(NGINX), MetalLB, hostpath 스토리지, 대시보드 등에 대한 간단한 명령어로 추가 기능 가능. 3개 이상의 노드에서 HA 모드 활성화 가능.	VM에 포함됨: 일반적으로 Docker/containerd 런타임, Kubernetes와 StorageProvisioner, DNS 등의 기본 추가 기능 포함. ingress, 대시보드 등은 CLI를 통해 선택적으로 토글 가능. 다노드는 기본적으로 제공되지 않음.	베어본: 코어 Kubernetes 이외의 아무것도 없음. ingress, 기본 스토리지 또는 LB, 대시보드 없음. CNI 플러그인을 선택해야 함(필요 시 설치). 본질적으로 DIY 클러스터.
지속 가능한 볼륨 지원	예 – 기본 제공. Rancher local-path 동적 프로비저너 포함, 이는 PVC에 대해 노드의 hostPath PV를 생성함. 기본 StorageClass “local-path”는 자동으로 로컬 디스크를 사용함.	예 – 간단한 추가 기능. `hostpath-storage`를 활성화하여 동적 PV를 위한 기본 StorageClass를 얻을 수 있음. 활성화 전에는 기본 PV 프로비저너 없음. 추가 기능은 다노드 생산 환경에는 적합하지 않지만, 홈랩에서는 충분함.	예 – 기본 제공. 기본 StorageClass는 minikube VM 내부의 hostPath 프로비저너를 사용함. PVC는 간단한 컨트롤러가 노드의 파일시스템에 hostPath PV를 생성하여 충족함. 특정 디렉토리의 경우 재시작 후에도 데이터가 유지됨.	아니요(수동). 기본 프로비저너 없음 – 클러스터는 초기에는 StorageClass가 없음. 사용자가 스토리지 솔루션(예: local path 프로비저너, NFS, Ceph 등)을 설치해야 함. 기본적인 접근법: hostPath 프로비저너 YAML을 적용하여 K3s/Minikube가 수행하는 것과 유사하게 만듦. 프로비저너가 설치되기 전에는 PVC가 대기 상태로 남음.
LoadBalancer 지원	예 – 내장 ServiceLB. K3s의 servicelb 컨트롤러(Klipper)는 LoadBalancer 서비스를 감시하고, 노드에 pod를 배포하여 노출함. 노드의 IP와 호스트 포트를 사용하여 트래픽을 전달함. 구성 없이 바로 작동함. 소규모 클러스터에 적합하며, 노드의 내부/외부 IP를 사용함.	예 – MetalLB 추가 기능을 통해. IP 범위를 지정하여 `metallb`를 활성화함. 베어메탈에서 실제 Layer-2 LoadBalancer 제공. 기본적으로 활성화되지 않음. 활성화 후, 각 LoadBalancer 서비스는 우리의 IP 풀에서 고유한 IP를 할당받음. 초기 설정(IP 범위)이 필요함.	예 – 터널 또는 MetalLB를 통해. 클라우드 LB 없음, 하지만 `minikube tunnel`을 실행하여 LoadBalancer 서비스에 외부 IP를 할당할 수 있음(호스트에 라우트 생성). 또는 minikube에서 MetalLB 추가 기능을 활성화하여 자동 LB IP 할당 가능. 기본적으로 LB 서비스는 우리가 이 방법 중 하나를 사용할 때까지 “대기” 상태로 남음.	아니요(수동). 내장 LoadBalancer 없음. 일반적으로 MetalLB를 수동으로 설치하여 베어메탈 LoadBalancer 기능을 제공함. MetalLB(또는 다른 LB 컨트롤러)가 설정되면 LoadBalancer 서비스가 작동함. 설정하지 않으면 LB 서비스는 영원히 대기 상태로 남음.
네트워킹 (CNI)	기본값 = Flannel (오버레이 네트워킹). 필요 시 CNI 교체 가능. CoreDNS가 클러스터 DNS로 배포됨. Traefik ingress는 기본적으로 포함됨(비활성화 가능).	기본값 = Calico (HA 모드의 최근 버전에서) 또는 간단한 기본값. (MicroK8s는 과거에 flannel을 사용했지만, 엄격한 제한을 위해 Calico를 사용하는 경향이 있음). CoreDNS는 기본적으로 활성화됨. NGINX ingress는 `microk8s enable ingress`를 통해 추가 기능으로 사용 가능.	기본값 = kubenet/bridge (드라이버에 따라 다름; 일반적으로 간단한 NAT 네트워크 사용). CoreDNS는 기본적으로 실행됨. 필요 시 NGINX ingress 추가 기능을 활성화할 수 있음. 네트워킹은 단일 VM에 제한됨; NodePort는 `minikube ip`를 통해 접근 가능함.	CNI 선택. Kubeadm은 어떤 CNI 플러그인도 설치하지 않음 – 우리가 하나를 설치해야 함(Calico, Flannel, Weave 등). 우리는 전체 제어권을 가짐. 대부분의 가이드는 kubeadm init 이후 Calico YAML을 적용함. CoreDNS는 kubeadm에 의해 기본적으로 클러스터 DNS로 설치됨. Ingress 컨트롤러는 우리가 선택하고 설치해야 함(예: NGINX 또는 Traefik을 manifests/Helm을 통해).
다노드 클러스터링	예. 다노드용으로 설계됨. 토큰을 통해 쉽게 조인 가능. 다마스터를 위해 외부 DB 또는 내장 etcd 사용 가능. 2-3+ 노드 홈랩에 적합. 추가 의존성 없음 – K3s는 자체 클러스터링이 내장됨.	예. 여러 MicroK8s 노드를 클러스터링 지원( `microk8s join`을 통해). 3+ 마스터에서 HA 활성화 가능(Dqlite). 클러스터 형성 매우 간단, 특히 모든 노드가 Ubuntu + snap을 실행하는 경우.	아니요(물리적). 단일 노드로 설계됨. 하나의 머신에서 다노드를 시뮬레이션 가능(다중 노드 Docker 컨테이너), 하지만 하나의 클러스터에서 여러 물리 호스트를 확장할 수 없음. 별도의 Minikube 인스턴스를 사용하여 별도의 클러스터를 생성해야 함.	예. 다노드 완전 지원(그것이 목적). 1 마스터 + 여러 워커 또는 여러 마스터(하지만 kubeadm HA 설정은 더 복잡함) 가능. 클러스터 크기에 대한 내장 제한 없음.
자원 부하	매우 낮음. 컨트롤 플레인은 ~<0.5 GB 메모리가 필요함. 컨트롤 플레인은 단일 프로세스로 작동하여 작은 부하를 가짐. CPU 효율적(하지만 일부 보고서에 따르면 MicroK8s보다 약간 더 많은 CPU를 사용할 수 있음). 저전력 또는 많은 여유 용량이 있는 환경에 이상적.	낮음. 컨트롤 플레인은 ~0.5–0.6 GB 메모리가 필요함. K3s보다 약간 더 높은 기본 메모리 사용량이 있지만 안정적임. Ubuntu snap 사용(일부 오버헤드 존재). 전체 Kubernetes보다는 여전히 가볍지만.	중간. VM 기본 2 GB 할당(사용량 ~0.6 GB). 단일 노드 Kubernetes와 VM 계층이 함께 실행됨. 16 GB 시스템에서는 문제가 없지만, 하나의 머신에서 작은 클러스터의 자원을 사용하는 것과 유사함.	중간. 하나의 마스터와 하나의 워커가 일반적인 추가 기능을 추가한 후 ~1 GB의 메모리가 필요함. 각 추가 노드는 최소한의 오버헤드(단지 kubelet, 프록시)를 추가함. 동일한 크기의 클라우드 VM에서 Kubernetes를 실행하는 것과 유사함. 3 노드, 각각 16 GB이면 오버헤드는 맥락상 무시할 수 있음.
CLI 도구	`k3s`를 사용하여 설치 및 `kubectl`의 래퍼로 사용(또는 표준 `kubectl` 사용 가능). 별도의 관리 CLI 없음(K3s는 대부분 “설치 후 무시"됨). 일부 도움 스크립트(예: `k3s-killall.sh`). 원하는 경우 Rancher의 GUI를 추가할 수 있음.	풍부한 `microk8s` CLI: 예: `microk8s enable/disable <addon>`, `microk8s status`. 또한 `microk8s kubectl` 포함됨. 일반적인 작업을 단순화하도록 설계됨(기본적인 작업을 위해 시스템 매니페스트를 직접 편집할 필요 없음).	`minikube` CLI를 사용하여 클러스터 시작/중지, 구성 및 추가 기능 관리, 정보 얻기(아이피, 서비스 URL, 로그 등). 또한 `minikube dashboard`와 같은 편의 명령어 제공. 클러스터와의 상호작용은 `kubectl`을 통해(설정은 minikube 컨텍스트 자동 설정됨).	초기 설정 및 업그레이드에 `kubeadm`만 사용. 일상적인 작업은 표준 `kubectl` 및 기타 Kubernetes 도구를 통해 수행. 부트스트랩 외에 디스트리뷰션 특화 CLI는 없음. 원시 Kubernetes 명령어와 운영 체제 도구를 사용하여 유지보수를 수행해야 함.
UI / 대시보드	기본적으로 포함되지 않음. Kubernetes 대시보드를 수동으로 설치하거나 외부 도구 사용 가능(단, Rancher를 별도로 추가하지 않으면 Rancher 관련 없음). K3s는 헤드리스 운영에 초점을 맞춤.	기본적으로 포함되지 않음, 하지만 `microk8s enable dashboard` 명령어로 표준 대시보드 UI를 배포할 수 있음. `microk8s dashboard-proxy`를 통해 클러스터에 쉽게 접근 가능. 또한 Canonical의 Lens GUI와 잘 통합될 수 있음(원하는 경우 Lens는 MicroK8s에 직접 접근 가능).	기본적으로 활성화되지 않음, 하지만 `minikube dashboard` 명령어는 대시보드 웹 UI를 우리 대신 배포하고 열어 줌. 이는 로컬 개발에서 편리함을 위해 설계됨 – 하나의 명령어로 GUI를 통해 워크로드를 볼 수 있음.	포함되지 않음. 원하는 경우 대시보드를 설치할 수 있음(예: YAML을 적용). 아니라면 CLI 또는 제3자 대시보드 앱을 사용. 홈랩에서는 대시보드를 설치하고 NodePort를 생성하거나 `kubectl proxy`를 사용하여 볼 수 있음. Kubeadm은 UI에 관심이 없음.

참고자료: 위의 데이터는 공식 문서 및 사용자 가이드에서 합성됨: 예를 들어, 메모리 사용량은 MicroK8s 자체의 비교에서, K3s의 기본 스토리지는 K3s 문서에서, K3s의 서비스 LB 동작은 K3s 문서에서, MicroK8s의 추가 기능 세부 사항은 Canonical 문서에서, Minikube의 PV 및 터널은 Kubernetes 문서에서, 일반적인 경험 보고서에서 참조됨. (참고문헌을 참조하여 전체 인용을 확인할 수 있음.)

3노드 홈랩을 위한 Kubernetes 배포판 비교

K3s (Rancher의 가벼운 Kubernetes)

MicroK8s (Canonical의 저유지비용 Kubernetes)

Minikube (단일 노드 로컬 K8s)

Kubeadm (우리 노드에서의 Vanilla Kubernetes)

병렬 비교 표

추천 사항

Kubernetes 배포판 홈페이지

기타 유용한 링크