노트북 홈서버 k3s 구축기 - 1. 왜 k3s, 왜 Proxmox

1. 계기 — 왜 이걸 시작했나

회사 수습 기간에 k3s 위에서 대시보드를 관리했다. 그런데 만질수록, 쿠버네티스도 그 밑의 리눅스도 내가 제대로 이해하고 있는 게 아니란 걸 알게 됐다.

 

수습을 종료하기로 한 후 다시금 취업 준비를 하면서 이번엔 아예 처음부터 k3s 클러스터와 k3s가 올라갈 인프라를 직접 세워보기로 했다. 마침 부트캠프(cloudwave) 팀 프로젝트에서 내가 온전히 맡았던 CGV 대기열 시스템이 있었다 — 그때는 AWS 클라우드에 올렸던 걸, 이번엔 온프렘 k3s에 내 손으로 다시 배포해보기로 했다.

 

서버가 필요했다. 홈서버를 새로 사긴 아까웠고, 마침 쓰던 노트북이 램 32GB에 디스크·CPU도 넉넉해 이걸 서버로 삼기로 했다.

 

2. 목표 — 뭘 만들려고

올릴 서비스는 새로 만든 게 아니다. 작년에 했었던 부트캠프에서 내가 맡은 CGV 대기열 시스템(당시 정리 글)을 리팩토링하고 재설계한 것이다.

 

원래는 AWS EKS 위에서 Kinesis·WebSocket으로 돌던 단일 Spring 서비스였다. 이번엔 온프렘 k3s에 새로 다시 세운다 — 입장 통제(queue)는 Go, 예매(booking)는 Java로 나누고 Kafka로만 연결해 장애를 격리하고, 실시간 전달은 폴링으로 바꿨다. (재설계 근거는 깃레포에 정리. https://github.com/sss654654/cgv-onprem.git)

 

일단 이 시리즈의 주연은 앱이 아니라 인프라다.

 

목표는 물리 노드부터 CNI·LB·Ingress·스토리지·GitOps·4축 관측(LGTM)·오토스케일·장애 주입 실험까지, 클라우드가 대신 해주던 것 / AI에게 의탁하여 구축했던 것들을 흐름과 구조를 이해한채로 세우는 것.

 

예전 (부트캠프 · AWS EKS):

브라우저 ─HTTP→ EKS Pod (Spring 단일)
                 ├ Redis : 대기열(ZSet) · 활성세션
                 └ 승격 → Kinesis → Consumer(폴링) → WebSocket/STOMP → 브라우저(실시간 순위)

 

지금 (온프렘 k3s · 소규모 MSA):

                    frontend (nginx 게이트웨이)
          /api/admission ↙                    ↘ /api
        queue (Go)                              booking (Java)
          └ Redis(큐 상태)                        ├ MySQL(예매 확정)
                                                 └ Redis(좌석락·admitted)
                   queue  ⇄  Kafka  ⇄  booking
                   admissions →   |   ← bookings-completed
          실시간 = 폴링(GET /position)  ·  WebSocket 아님

 

3. 왜 k3s인가

쿠버네티스를 직접 세우는 방법도 하나가 아니다. 표준 컴포넌트를 kubeadm으로 조립하는 방법이 있고, 경량 배포판(k3s·MicroK8s 등)을 쓰는 방법이 있다.

 

나는 k3s를 골랐다. 이유는 두 가지다.

 

첫째, 회사에서 쓰던 것이 k3s였다. 온프레미스 구축용으로 선택된 경량 k3s 위에서 대시보드를 관리했고, 그 경험을 이어서 이번엔 클러스터 자체를 내 손으로 세운다.

둘째, 노트북 자원이다. VM 3대에 RAM을 나눠주는 구조라, 컨트롤플레인이 가벼울수록 서비스와 관측 스택(LGTM)에 줄 자원이 남는다.

항목	k3s	표준 k8s
형태	단일 바이너리 (70MB 미만)	컴포넌트 개별 구성
최소 사양	1 CPU · RAM 512MB	기본 클러스터에 2 CPU · RAM 4GB 이상
데이터스토어	SQLite(단일 노드) / HA는 외부 DB·etcd	etcd
번들	containerd·Flannel·CoreDNS·Traefik 포함	런타임·CNI·스토리지 드라이버 별도 구성
설치	명령 한 줄	런타임·네트워킹·스토리지 다단계 구성
표준 준수	CNCF 인증 쿠버네티스 배포판	표준 그 자체

(출처: SUSE — K3s and K8s: Key Differences )

 

노드 셋을 전부 컨트롤플레인으로 쓰는 구성이라, 이 차이만큼 노드마다 서비스에 줄 RAM이 남는다. 그리고 API는 표준과 같아(CNCF 인증) 여기서 배운 것은 표준 k8s·EKS로 그대로 이어진다.

 

두 가지는 미리 짚어둔다. k3s 기본 데이터스토어는 SQLite(단일 서버용)지만 이번 구성은 3대 HA라 embedded etcd 모드를 쓴다. 그리고 k3s가 번들로 주는 flannel·ServiceLB·Traefik은 이번 프로젝트에선 전부 끄고 Calico·MetalLB·자체 Traefik으로 교체한다 — 이유는 해당 편에서 다룬다.

 

4. 첫 갈림길 — 하이퍼바이저 선택

물리 노트북은 1대인데, k3s를 HA로 구성하려면 노드가 최소 3대 필요하다 — etcd 쿼럼 때문이다. 노드 하나가 죽어도 과반(2/3)이 살아야 클러스터가 유지되니, 홀수로 최소 3이다. 물리 1대로 노드 3대를 만드는 방법이 하이퍼바이저다. VM 하나 = k3s 노드 하나로 3개를 띄운다.

 

하이퍼바이저는 Type 1(베어메탈)과 Type 2(호스트형)로 나뉜다 (AWS — Type 1 vs Type 2). 층으로 그리면 이렇다:

── Type 1 (베어메탈) ─ VM이 하드웨어를 바로 탄다

     ┌────────┐   ┌────────┐   ┌────────┐
     │  VM 1  │   │  VM 2  │   │  VM 3  │
     └───┬────┘   └───┬────┘   └───┬────┘
 ┌───────┴────────────┴────────────┴───────┐
 │       하이퍼바이저 (하드웨어 직접 장악)      │ ← 호스트 몫 약 1–2GB
 ├─────────────────────────────────────────┤
 │                 하드웨어                  │
 └─────────────────────────────────────────┘
   요청 경로: VM → 하이퍼바이저 → 하드웨어  (2단)


── Type 2 (호스트형) ─ VM이 호스트 OS를 한 겹 더 거친다

     ┌────────┐   ┌────────┐
     │  VM 1  │   │  VM 2  │    (브라우저·게임 등 일반 앱과 동거)
     └───┬────┘   └───┬────┘
 ┌───────┴────────────┴───────┐
 │     하이퍼바이저 = 앱 하나    │
 ├────────────────────────────┴────────────┐
 │            호스트 OS (Windows)           │ ← RAM·CPU 상시 차지 · 업데이트/재부팅 = VM 전멸
 ├─────────────────────────────────────────┤
 │                 하드웨어                  │
 └─────────────────────────────────────────┘
   요청 경로: VM → 하이퍼바이저 → 호스트 OS → 하드웨어  (3단)

이 노트북은 상시 가동 서버로 쓸 물건이라, 층 하나 차이가 치명적이다 — Type 2는 Windows가 자원을 상시 깔고 앉고, Windows 업데이트·재부팅에 클러스터가 통째로 내려간다. → Type 1 확정. (VirtualBox·VMware Workstation = Type 2 = 데스크탑용, 탈락.)

 

 

Type 1 안에서 후보를 추려봤다(ESXi·순수 KVM·Hyper-V·Proxmox).

 

ESXi는 무료판이 vCenter가 막혀 Terraform 자동화가 안 되고 내 노트북 NIC와도 비호환이라 탈락. 순수 KVM은 엔진만 있고 관리도구가 없어 수작업이 과다해 탈락 — Proxmox가 이 KVM 엔진에 관리층을 얹은 완성품이다.

 

결승은 Hyper-V vs Proxmox. 둘 다 Type 1(베어메탈)이라 급은 대등하다 — Hyper-V도 켜면 Windows가 "루트 파티션"으로 내려앉고 하이퍼바이저가 하드웨어 주인이 된다. 즉, Hyper-V를 사용할 경우 노트북에서 따로 디스크에 하이퍼바이저 추가, 현재 디스크의 window 제거 같은 작업을 안해도 된다.

Hyper-V OFF:  하드웨어 → Windows                                   ← Windows가 주인
Hyper-V ON:   하드웨어 → Hyper-V → [Windows 루트파티션] [게스트 VM]   ← Hyper-V도 Type 1

 

Proxmox VE vs Hyper-V — 객관 비교 (공식·업계 자료 기준):

항목	Proxmox VE	Hyper-V
기반	Debian Linux + KVM(VM)·LXC(컨테이너)	Windows Server 통합 하이퍼바이저
관리	웹 UI (VM·컨테이너·스토리지·네트워크·클러스터)	Windows 중심 도구 (+옵션 Windows Admin Center)
성능 강점	Linux 워크로드 — 낮은 오버헤드	Windows 환경 — NUMA 최적화·하드웨어 통합
스토리지·HA	Ceph·ZFS·NFS·iSCSI · HA 클러스터 · 내장 백업	Storage Spaces Direct · Failover Clustering
자동화·통합	REST API	PowerShell · Active Directory · Azure
비용	무료 커뮤니티판 (유료 지원 $355–1,060/소켓·년)	Windows Server Standard $1,176 / Datacenter $6,771 (16코어 기준)

(출처: StarWind — Proxmox vs Hyper-V — 표의 내용·수치는 이 글 기준)

근데 내가 계획한 이 프로젝트의 목표는 리눅스·네트워크·스토리지를 온프렘에서 직접 다루며 숙달하는 것이다. 표에서 Proxmox의 성격(Linux 기반·KVM·오픈소스·웹UI)이 그 목표에 맞고, Hyper-V의 강점(Windows·Azure 통합)은 내 목표가 아니다. 즉 "더 우수해서"가 아니라 목표가 리눅스·온프렘 학습이라 Proxmox가 맞았다.

 

제약도 있다. Proxmox는 Type 1이라 설치 시 디스크를 차지하고 노트북 내장 Windows와 공존이 어렵다. 그래서 외장 USB SSD에 Proxmox를 설치하고 노트북을 그 SSD로 부팅한다 — 내장 NVMe의 Windows는 그대로 두고, 외장 SSD로 부팅할 때만 노트북이 하이퍼바이저 서버가 된다.

 

최종 그림은 이렇다 — 부팅 디스크 선택이 노트북의 정체를 가르고, 그 위로 층이 쌓인다:

 데스크탑 (콘솔)                             집 공유기
 브라우저(:8006 웹UI) · SSH · kubectl ──────┐   │
                                            └─[LAN]─┐
                                                    │ RJ-45 유선
┌─ 노트북 (RAM 32GB) ───────────────────────────────┼──────────────┐
│                                                   │              │
│  내장 NVMe ─▶ [ Windows ]   ← 안 건드림. Windows로 부팅할 때만    │
│                                                   │              │
│  외장 USB SSD(1TB) ─▶ 이걸로 부팅하면:             │              │
│  ┌─ Proxmox VE (Type 1 하이퍼바이저) ─────────────┼──────────┐   │
│  │                                                │          │   │
│  │      vmbr0 (가상 스위치) ═══════════ 물리 NIC ══┘          │   │
│  │       ║            ║            ║                         │   │
│  │  ┌─ VM 1 ─┐   ┌─ VM 2 ─┐   ┌─ VM 3 ─┐                    │   │
│  │  │ Ubuntu │   │ Ubuntu │   │ Ubuntu │    (VM = k3s 노드)  │   │
│  │  │  k3s-1 │   │  k3s-2 │   │  k3s-3 │                     │   │
│  │  └───┬────┘   └───┬────┘   └───┬────┘                     │   │
│  │      └────── k3s 클러스터 (etcd 쿼럼 3) ──────┘            │   │
│  │              │                                            │   │
│  │              └ 그 위: queue · booking · frontend          │   │
│  │                      Redis · Kafka · MySQL                │   │
│  │                      LGTM(관측) · ArgoCD(GitOps)          │   │
│  └───────────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────────┘

밖에서 안으로: 데스크탑은 콘솔일 뿐이고, 노트북이 서버다. 그 서버 안에서 하이퍼바이저가 VM 3대를 만들고, VM 3대가 k3s 클러스터가 되고, 그 클러스터 위에 서비스·미들웨어·관측이 올라간다.

 

Hyper-V가 나은 지점은 분명하다 — 설치·관리가 Windows에 통합돼 별도 디스크나 부팅 전환 없이 기능만 켜면 되고, Windows 워크로드에 최적화돼 있다. 그 편의를 리눅스 밑단 학습이라는 목표와 맞바꾼 것이다.

 

외장 USB SSD이기 때문에 홈랩의 성격으로는 유연하지않다. USB가 잘못해서 뽑히면 그대로 서버가 다운되고, 윈도우에서 작업할게 있어서 부팅을 윈도우가 부팅되는 디스크로 시작해도 서버가 다운된다.

5. 다음

• 2부. Proxmox 설치 실전 — 설치 USB(Rufus DD) · F12 부팅 · 설치 마법사(디스크 선택 함정) · 삽질 예정?.