[홈랩] 홈랩 인프라 현황과 Kubernetes로 옮기는 이유

제 홈랩은 ESXi 호스트 2대 위에서 한때 VM이 약 68대까지 늘었고, 정리를 거쳐 지금은 24대를 운영하고 있습니다. 필요할 때마다 VM을 하나씩 만들다 보니 이런 상태가 되었습니다. 하이퍼바이저는 지원이 끝났고, 서비스 VM의 절반 이상도 지원이 종료된 OS를 쓰고 있었습니다. 실제로 쓰는 자원은 할당량의 4분의 1에도 못 미쳤습니다. 그래서 서비스 VM을 컨테이너로 바꿔 Kubernetes 클러스터로 옮기기로 했습니다. 이 글에서는 현재 인프라 상태와 문제점, Kubernetes를 고른 이유, 옮기기 전에 정리한 것과 이전 계획을 정리합니다. 홈랩 재구성 시리즈의 1편입니다.

1. 현재 홈랩 구성

물리 서버는 ESXi 호스트 2대이고, vCenter 1대로 관리합니다. 두 호스트는 클러스터로 묶지 않고 자원 자동 분배(DRS)와 장애 시 자동 재시작(HA) 없이 따로 운영하고 있습니다.

 

구분	구성
호스트	2소켓 서버 2대, 메모리 128GB와 64GB
네트워크	서비스망과 관리망을 나눠 운영, 두 호스트 사이는 10Gbps로 연결
스토리지	호스트별 로컬 SSD와 HDD, Synology NAS의 NFS 볼륨
VM	관리용 7대, 서비스용 17대 (한때 약 68대, 이번 정리 직전 32대)

 

두 호스트 사이가 10Gbps로 연결되어 있어서, 공유 스토리지가 없어도 VM을 디스크째 다른 호스트로 옮기는 vMotion을 빠르게 할 수 있습니다. 이 점은 나중에 클러스터 노드를 두 호스트에 나눠 배치할 때 도움이 되었습니다.

VM은 크게 관리용과 서비스용으로 나뉩니다.

 

구분	VM
관리용 (7대)	vCenter, 모니터링 2대, 네트워크 장비 관리, VDI, VPN, CI 서버
서비스용 (17대)	웹 사이트 7대, LMS 앱과 DB 2대, 스트리밍과 인코딩 3대, 화상회의 1대, 게임 서버 1대, 로드밸런서 2대, Docker 호스트 1대

 

웹 사이트와 스트리밍, 로드밸런서는 대부분 메인과 백업 VM 두 벌로 운영하고 있습니다. 서비스 하나를 이중화하려면 VM을 하나 더 만들어 같은 설정을 맞춰야 하는 구조입니다.

2. 지금 구성의 문제

하나씩 점검해 보니 문제가 생각보다 많았습니다.

 

문제	내용
하이퍼바이저	vSphere 7은 2025년 10월 2일에 일반 지원이 끝남
OS	리눅스 VM 12대와 Windows 10 1대가 이미 지원 종료(EOS), 6개월 안에 끝나는 VM도 1대
자원	DB를 뺀 서비스 VM 16대에 vCPU 31개와 메모리 52GB를 할당, 실제 사용은 CPU 약 1.8GHz와 메모리 약 12GB
트래픽	웹 VM 하나는 14일 동안 로그 512만 줄 중 실제 사용자 요청이 0건, 나머지는 모두 상태 확인 요청
쌓인 것	2023년에 만든 스냅샷, 쓰지 않는 VM, 어느 VM에도 속하지 않은 파일 약 1TB

 

가장 큰 문제는 자원 낭비였습니다. 작은 웹 서비스 하나에 VM 하나를 주다 보니, 자원 대부분을 서비스가 아니라 VM마다 따로 실행되는 OS가 쓰고 있었습니다. 지원이 끝난 OS를 쓰는 VM 12대도 같은 이유로 생겼습니다. VM이 많을수록 OS 업그레이드를 미루게 되고, 미룬 VM이 쌓이면 한꺼번에 지원이 끝납니다.

3. 왜 Kubernetes로 옮기나

해결 방법은 크게 세 가지를 검토했습니다.

 

방법	장점과 한계
VM마다 OS 업그레이드	구성이 그대로라 부담이 적음 / 12대를 하나씩 올리고 PHP 같은 앱 호환성도 함께 확인해야 하며, 몇 년 뒤 같은 일이 반복됨
하이퍼바이저만 교체	Proxmox 등으로 옮기면 지원 종료 문제는 해결 / VM 수, 오래된 OS, 남는 자원은 그대로
서비스를 컨테이너로	관리할 OS를 노드 몇 대로 줄이고 배포 상태를 Git에 기록 / 처음 구축하고 익히는 데 시간이 듦

 

저는 세 번째를 골랐습니다. OS를 관리해야 하는 대상이 VM 전체에서 노드 몇 대로 줄고, 서비스마다 VM을 두 벌씩 만들던 이중화도 Pod 복제 수로 대신할 수 있기 때문입니다. 또 서비스가 컨테이너로 옮겨 가면 하이퍼바이저를 나중에 Proxmox 등으로 바꾸더라도 노드 VM 몇 대만 옮기면 됩니다. Proxmox로 옮길 때 확인할 것은 VMware ESXi와 Proxmox VE 비교, 이전 전 확인할 것에서 정리했습니다.

4. 옮기기 전에 정리한 것

옮길 대상을 정하기 전에 쓰지 않는 것부터 지웠습니다. 쓰지 않는 VM과 파일까지 이전 대상에 포함하면 이전 규모가 커지고, 정리로 확보한 자원이 새 클러스터 노드가 들어갈 자리가 되기 때문입니다.

먼저 어느 VM에도 속하지 않은 파일을 찾았습니다. VM 설정에는 그 VM이 쓰는 디스크와 설정, 스왑 파일 목록이 들어 있습니다. 데이터스토어의 전체 파일 목록에서 모든 VM이 쓰는 파일을 빼면, 아무도 쓰지 않는 파일만 남습니다.

데이터스토어 전체 파일에서 VM이 쓰는 파일을 빼면 아무도 쓰지 않는 파일이 남습니다

지우기 직전에는 사용 중임을 뜻하는 잠금 파일(.lck)이 없는지, 최근에 수정되지 않았는지 다시 확인했습니다. 그중 하루 전에 수정된 디스크가 하나 있었는데, vCenter에 등록되지 않은 디스크가 수정되었다면 다른 곳에서 쓰고 있을 수 있으므로 지우지 않았습니다.

 

대상	정리한 것
로컬 SSD	쓰지 않는 템플릿과 VM 폴더 8개, 약 280GB
NAS	쓰지 않는 VM 폴더 4개(약 300GB), 남은 스왑 파일 10개(약 15GB)
콘텐츠 라이브러리	저장소가 없어져 연결이 끊긴 라이브러리, 11.8GB
꺼진 VM	개발용 Jenkins VM과 디스크 복사본 약 74GB, 개인 실습 VM 33GB
기존 클러스터	한 호스트에 몰려 있고 이미 동작하지 않던 실습용 Kubernetes VM 5대
NSX Manager	연결된 구성 요소 없이 혼자 켜져 있던 관리 VM, vCPU 4개와 메모리 16GB

 

로컬 디스크는 지우자마자 여유 공간이 늘었지만, Synology NFS 볼륨은 지워도 여유 공간이 그대로였습니다. NAS의 Btrfs 스냅샷이 지운 데이터를 아직 보관하고 있기 때문으로 보입니다. NAS에 스냅샷을 설정해 두었다면 여유 공간은 보관 기간이 지난 뒤 다시 확인합니다.

 

항목	정리 전 → 정리 후
VM 수	32대 → 24대
호스트 1 메모리 사용률	83% → 61%
호스트 2 로컬 SSD 여유	340GB → 651GB
호스트 1 로컬 SSD 여유	138GB → 315GB

 

호스트 1에서 메모리 31GB가 비었고, 비어 있던 로컬 SSD 하나를 새 클러스터 노드의 디스크로 쓰기로 했습니다.

5. 이전 계획

모든 VM을 옮기지는 않습니다. 옮기기 쉬운 서비스부터 옮기고, 위험이 큰 것은 VM으로 남깁니다.

 

구분	대상
옮김	웹 사이트, LMS 앱, 인코딩 서버, Docker 호스트의 컨테이너
나중에	게임 서버, 스트리밍, 화상회의 (UDP 미디어 포트와 공인 IP 처리가 까다로움)
VM 유지	관리용 VM, LMS DB (NAS 스토리지 위에 DB를 올리는 것은 위험하다고 판단)
대체	로드밸런서 VM 2대는 클러스터의 Gateway API와 MetalLB로 대체

 

새 클러스터의 마스터 노드는 3대이지만, 물리 호스트가 2대뿐이라 지금은 한 호스트에 마스터 2대가 몰려 있습니다. 마스터의 데이터 저장소인 etcd는 과반수가 살아 있어야 동작하므로, 마스터 2대가 있는 호스트가 멈추면 3대 중 2대를 잃어 클러스터를 관리할 수 없습니다. 그래서 지금 상태를 완전한 이중화로 보지는 않고, 이후 장비를 추가해 마스터를 나눠 둘 계획입니다. 세 번째 마스터를 NAS의 VM이나 미니 PC처럼 다른 장비로 옮기면 어느 호스트 하나가 멈춰도 과반을 유지할 수 있습니다.

다음 글에서는 클러스터를 어떤 구성으로 설계했는지, 노드 OS와 네트워크 구성 요소를 어떤 기준으로 골랐는지 정리하겠습니다.

6. 정리

• 홈랩은 ESXi 호스트 2대와 VM 24대로 구성되어 있고, 서비스 VM이 메인과 백업 두 벌로 늘어나는 구조였습니다.
• vSphere 7 지원 종료, 지원이 끝난 OS를 쓰는 VM 12대, 할당한 자원의 4분의 1에 못 미치는 실제 사용량이 가장 큰 문제였습니다.
• OS 업그레이드나 하이퍼바이저 교체보다 서비스를 컨테이너로 옮겨 OS 관리 대상을 줄이는 쪽을 골랐습니다.
• 한때 약 68대였던 VM을 줄여 왔고, 이번 정리에서 쓰지 않는 VM과 파일을 지워 32대를 24대로 줄였습니다.
• 마스터 3대 중 2대가 한 호스트에 몰려 있어, 이후 장비를 추가해 마스터를 나눠 둘 계획입니다.

참고

• Broadcom - Product Lifecycle (vSphere 7)
• Ubuntu - Release cycle
• etcd Docs - FAQ (What is failure tolerance?)
• Kubernetes Docs - Options for Highly Available Topology