VMware → Multipass 마이그레이션 (1/2) — 사전 조사와 실행

MacBook Air(RAM 8GB, Apple Silicon 8코어)에서 VMware Fusion으로 운영하던 K3s 3노드 클러스터(마스터 1 + 워커 2)를 Multipass 기반으로 전환한 작업 기록 1/2부를(사전 조사~실행 절차). 후속 트러블슈팅과 검증은 2/2부 참고.

0. 왜 옥겼나

VMware Fusion은 SVGA 3D 에뮬레이션, VMware Tools 상주 데몬, 스냅샷/체크포인트 관리 같은 데스크톱 가상화 기능이 붙어 있어 하이퍼바이저 자체 오버헤드가 있다. Apple Silicon에서 Multipass는 macOS 네이티브 Virtualization.framework(vz)를 사용해 훨씬 가벼다.

다만 실측 결과, 하이퍼바이저 교체 자체의 절감분보다 VM 스펙 재설계(구성 5.6GB → 신규 6GB로 유사하지만, 이 과정에서 리포 문서에 남아있던 "OOM 이후 상향 조정된 진짜 운영 스펙"을 발견해 반영한 것)의 영향이 더 쿼다 (2절 참고).

1. 마이그레이션 전 상태 조사

1.1 호스트 환경

<table header-row="true"><tr><td>항목</td><td>값</td></tr><tr><td>OS</td><td>macOS 26.5.2 (arm64, Apple Silicon)</td></tr><tr><td>CPU</td><td>8코어 (Performance 4 + Efficiency 4)</td></tr><tr><td>RAM</td><td>8GB</td></tr><tr><td>디스크 여유</td><td>약 37GB</td></tr></table>

1.2 기존 VMware VM 실제 스펙 (중요한 발견)

리포에 기록된 원래 설계는 마스터 2GB / 워커 1GB×2였지만, K3s-Node-Resource-Planning-Troubleshooting에 기록된 과거 OOM 장애(워커 노드가 랜덤하게 NotReady에 빠지는 연쇄 장애) 이후 실제 운영 중인 VM은 이미 상향 조정되어 있었다.

<table header-row="true"><tr><td>VM</td><td>역할</td><td>설계 스펙(문서)</td><td>실제 운영 스펙</td></tr><tr><td>server1</td><td>Control-plane</td><td>2GB/2vCPU</td><td>2.5GB(2560MB)/2vCPU</td></tr><tr><td>server2</td><td>Worker</td><td>1GB/2vCPU</td><td>1.5GB(1536MB)/2vCPU</td></tr><tr><td>server3</td><td>Worker</td><td>1GB/2vCPU</td><td>1.5GB(1536MB)/2vCPU</td></tr></table>

작업 시작 시점에 VM 3대가 모두 켜져 있었고, 호스트 여유 메모리는 memory_pressure 기준 약 260MB로 사실상 포화 상태였다.

1.3 기존 클러스터 구성 조사 결과

k3s 버전: v1.34.5+k3s1
네트워킹: --flannel-iface tailscale0 (server, agent 모두 동일 플래그)
swap: 노드당 2GB, vm.swappiness=10
마스터 taint: 미적용(문서엔 권장 사항으로 기록되었으나 실제로 적용된 적 없음)
ArgoCD: target-tracking-service 1개만 Synced/Healthy 배포 중, defense-api-gateway.yaml은 리포에는 있지만 실제 클러스터에는 미배포
c4i 네임스페이스: kafka, postgres(pgvector, PVC 2Gi), redis, target-tracking-service

2. 마이그레이션 방침 결정 (사용자 확인 사항)

VMware VM 처리: 절대 삭제 금지, 필요시 언제든 재기동 가능한 형태로만 보존 → 정상 종료(clean shutdown)로 RAM만 회수 (suspend는 디스크를 더 쓰므로 미채택)