13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] ARM 서버

  • [홈랩] Proxmox ARM64 홈랩 1년 회고: 라즈베리 파이 5 기반 운영 경험과 교훈

    [홈랩] Proxmox ARM64 홈랩 1년 회고: 라즈베리 파이 5 기반 운영 경험과 교훈

    목차

    [홈랩] Proxmox ARM64 홈랩 1년 회고: 라즈베리 파이 5 기반 운영 경험과 교훈

    Proxmox ARM64 조합이 궁금한 분들이 꽤 많으시더라고요. 특히 라즈베리 파이 5로 홈랩 구축을 시작하려는 분들은 “전력도 적게 먹고 조용한데, 이걸 ARM 서버처럼 굴릴 수 없을까?” 하는 생각 한 번쯤 해보셨을 겁니다. 저도 딱 그랬습니다. x86 미니 PC는 성능이 좋지만, 늘 켜두는 장비에서는 발열, 소음, 소비전력이 계속 신경 쓰이거든요. 그래서 한동안은 라즈베리 파이 5를 중심으로 ARM 서버 성격의 홈랩을 꾸려보면서, 어디까지 실전에 쓸 수 있는지 꽤 집요하게 확인해봤습니다.

    다만 여기서 먼저 짚고 가야 할 게 있습니다. Proxmox VE는 전통적으로 x86_64 중심으로 많이 쓰여 왔고, ARM64 환경은 공식 배포판보다는 커뮤니티 포팅(community port, 비공식 이식판)이나 실험적 구성에 가깝습니다. 이 포인트를 빼고 이야기하면 괜히 기대만 높아지거든요. 저도 처음엔 “가볍게 되겠지” 했다가 삽질 좀 했습니다 ㅎㅎ 그래도 결론부터 말하면, 목적만 분명하면 꽤 재미있고 배울 점도 많았습니다.

    이번 글은 “무조건 추천”보다도, 1년 가까이 ARM 기반 홈랩을 굴리며 느낀 현실적인 장단점에 더 가깝습니다. 혹시 지금 Proxmox ARM64, 라즈베리 파이 5, 홈랩 구축 사이에서 고민 중이시라면, 시행착오 줄이는 데 도움이 될 겁니다.

    Proxmox ARM64와 라즈베리 파이 5 기반 홈랩 구축 전체 아키텍처 이미지

    라즈베리 파이 5, 스토리지, 네트워크, 컨테이너와 VM 흐름을 한눈에 보여주는 전체 아키텍처 이미지입니다.

    Proxmox ARM64를 어떻게 이해하면 좋을까

    쉽게 말해 Proxmox VE는 KVM(커널 기반 가상머신)과 LXC(리눅스 컨테이너)를 웹 UI로 관리하기 편하게 묶어둔 가상화 플랫폼입니다. x86 서버에서는 워낙 익숙한 선택지죠. 문제는 ARM으로 오면 이야기가 조금 달라집니다.

    왜냐하면 ARM64 환경에서는 CPU 아키텍처 자체가 다르기 때문에, x86에서 별생각 없이 쓰던 이미지나 패키지가 그대로 안 돌아가는 경우가 꽤 있더라고요. 예를 들어 Docker 이미지도 amd64만 제공하는 경우가 있고, VM 이미지도 cloud image(클라우드 이미지) 지원이 제각각이거든요. 즉, Proxmox ARM64 홈랩은 '설치가 끝'이 아니라 워크로드 호환성까지 같이 봐야 하는 구조입니다.

    제가 직접 써보니 운영 감각은 이렇습니다.

    • LXC(Container, 컨테이너) 위주의 경량 워크로드는 꽤 잘 맞습니다.
    • KVM VM은 가능하더라도 이미지 호환성과 리소스 여유를 더 따져야 합니다.
    • 스토리지와 전원 안정성이 생각보다 중요합니다. 여기서 삐끗하면 OS보다 먼저 데이터가 흔들립니다.
    • 홈랩 구축 관점에서는 학습 가치가 매우 큽니다. 다만 프로덕션 흉내를 내기보다, 제약을 이해하는 실험실에 더 가깝습니다.

    라즈베리 파이 5가 홈랩에 매력적인 이유

    라즈베리 파이 5는 이전 세대보다 체감 성능이 꽤 좋아졌고, 네트워크/스토리지 주변 구성을 신경 쓰면 단순 장난감 수준은 확실히 넘습니다. 물론 기업용 서버 대체는 아니지만, 저전력 ARM 서버 실험 용도로는 진입 장벽이 낮더라고요. 실제로 써보니까 책상 한쪽에서 조용히 계속 돌아가는 점이 진짜 편했습니다.

    항목 라즈베리 파이 5 기반 ARM 홈랩 x86 미니 PC 홈랩
    전력/소음 유리한 편 상대적으로 높을 수 있음
    호환성 ARM64 제약 있음 대체로 넓음
    학습 재미 매우 높음 실용성 중심
    가상화 유연성 워크로드별 편차 큼 전반적으로 안정적
    권장 용도 실험, 경량 서비스, 학습 범용 홈서버, VM 다수 운영

    제가 잡았던 운영 목표: “적게, 가볍게, 오래”

    처음엔 이것저것 다 올리고 싶었습니다. 근데 라즈베리 파이 5 기반 Proxmox ARM64 환경에서 욕심내면 금방 한계가 보이더라고요. 그래서 운영 원칙을 아주 단순하게 잡았습니다.

    1. 컨테이너 우선: 가능하면 LXC로 먼저 배치합니다.
    2. 서비스 분리: DNS, 리버스 프록시(reverse proxy, 역방향 프록시), 모니터링, 파일 동기화처럼 역할을 분리합니다.
    3. 스토리지 외장 분리: microSD 한 장에 모든 걸 맡기지 않습니다.
    4. 백업 자동화: 실험 환경일수록 백업이 더 중요합니다.

    여기서 중요한 포인트! ARM 서버 홈랩은 “최대한 많은 걸 띄우는 경쟁”보다 “어디까지 안정적으로 굴러가는지 이해하는 과정”이 훨씬 값집니다.

    Proxmox ARM64 실전 구현: 설치 전 준비

    비공식 ARM64 포팅 환경은 세부 절차가 배포 방식마다 조금씩 다를 수 있습니다. 그래서 저는 설치 문서의 명령을 그대로 외우기보다, 어떤 구성 원칙이 필요한지를 기준으로 접근하는 편을 추천드립니다. 아래 예시는 Debian/ARM64 기반에 가상화 관련 패키지와 브리지 네트워크(bridge network, 가상 스위치 역할)를 준비하는 흐름입니다.

    1. 라즈베리 파이 5에 안정적인 전원을 준비합니다.
    2. 운영체제는 microSD보다 SSD/NVMe 성격의 외장 스토리지를 우선 검토합니다.
    3. 고정 IP를 잡고, 관리용 네트워크 대역을 분리합니다.
    4. 업데이트 후 재부팅해서 기본 상태를 먼저 안정화합니다.
    sudo apt update
sudo apt full-upgrade -y
sudo reboot

    재부팅 이후에는 기본 정보부터 확인합니다. 이 과정을 은근히 많이 건너뛰시는데, 나중에 문제 생겼을 때 제일 먼저 다시 보게 되는 값들입니다.

    uname -a
arch
ip addr
lsblk
free -h

    실제로 써보니까 여기서 디스크 인식 상태와 네트워크 인터페이스 이름을 미리 확인해두는 게 중요했습니다. 예전 습관대로 `eth0`만 보고 설정했다가 이름이 달라서 한참 헤맨 적이 있거든요.

    브리지 네트워크 구성 예시

    Proxmox 계열 환경을 쓰면 결국 브리지 네트워크를 많이 만지게 됩니다. 브리지(bridge)는 쉽게 말해 호스트와 VM/LXC가 같은 스위치에 물린 것처럼 보이게 해주는 방식입니다.

    auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.10.20/24
    gateway 192.168.10.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

    이런 식의 구성은 개념 이해용으로 좋습니다. 다만 실제 파일 위치나 관리 방식은 사용 중인 배포 환경에 따라 달라질 수 있으니, 현재 배포판의 네트워크 관리 체계를 먼저 확인하고 적용하시는 게 안전합니다.

    Proxmox ARM64 홈랩의 브리지 네트워크와 LXC VM 연결 구조 이미지

    브리지 네트워크, 호스트, 컨테이너, VM이 어떻게 연결되는지 이해하기 쉽게 보여주는 구성도입니다.

    실전 운영: 어떤 워크로드가 잘 맞았나

    제가 1년 가까이 굴리면서 느낀 건 명확했습니다. Proxmox ARM64에서는 '가볍고 분리하기 쉬운 서비스'가 잘 맞습니다. 예를 들면 이런 부류입니다.

    • Pi-hole 같은 DNS 기반 서비스
    • Nginx Proxy Manager나 Caddy 같은 리버스 프록시
    • Prometheus, Grafana 계열의 경량 모니터링
    • 테스트용 Git 러너나 작은 자동화 작업
    • 내부 문서, 파일 동기화, 간단한 API 실험

    반대로 무거운 데이터베이스를 여러 개 올리거나, x86 전용 이미지 의존성이 큰 서비스는 금방 피곤해집니다. 처음엔 “이 정도면 되겠지” 했었는데, 막상 이미지 아키텍처가 안 맞거나 메모리 여유가 줄어들면 체감이 확 오더라고요.

    LXC 우선 운영 예시

    저는 가능한 서비스는 컨테이너 중심으로 나눠서 운영했습니다. 서비스가 꼬여도 한 덩어리 전체가 죽지 않게 하려는 의도였죠.

    pct list
pct start 101
pct enter 101
apt update && apt install -y curl vim

    여기서 `pct`는 Proxmox 환경에서 LXC를 다룰 때 자주 보는 명령입니다. 컨테이너 안으로 들어가서 패키지를 설치하고, 로그를 분리해서 보는 흐름이 익숙해지면 운영이 꽤 편해집니다.

    백업과 스냅샷 관점에서 배운 점

    홈랩은 어차피 실험용이라고 생각하면 백업을 소홀히 하게 되는데, 이상하게 꼭 주말 밤에 터집니다. 저도 그랬습니다. 그래서 나중엔 백업 정책을 단순하게 잡았습니다.

    1. 설정 파일은 Git 또는 별도 백업 저장소로 이중화
    2. 컨테이너 단위 백업 정기 실행
    3. OS 디스크와 데이터 디스크를 논리적으로 분리
    4. 업데이트 전 스냅샷 또는 설정 백업 선행
    vzdump 101 --mode snapshot --compress zstd --storage local
vzdump 102 --mode stop --compress zstd --storage local

    모든 환경에서 똑같이 동작하는 건 아니지만, 이런 식의 백업 흐름 자체는 꼭 익혀두시는 걸 추천드립니다. 실패를 빨리 복구하는 능력이 홈랩 만족도를 많이 좌우하거든요.

    ⚠️ 실제로 많이 부딪힌 문제들

    이 섹션은 좀 현실적으로 적어보겠습니다. “잘 된다”보다 중요한 게, 어디서 잘 안 되는지 아는 거니까요.

    1. ARM64 이미지 호환성 문제

    가장 자주 맞닥뜨린 문제입니다. Docker든 VM 이미지든 amd64만 준비된 경우가 생각보다 많습니다. 이럴 땐 에뮬레이션(emulation, 다른 아키텍처 흉내)로 우회하고 싶어지는데, 홈랩에서는 성능과 복잡도가 동시에 올라갑니다.

    해결 팁은 단순합니다.

    • 먼저 공식적으로 arm64 이미지를 제공하는지 확인합니다.
    • 같은 역할의 대체 소프트웨어를 찾습니다.
    • x86 전용 워크로드는 과감히 다른 노드로 분리합니다.

    2. 스토리지 병목과 안정성

    처음엔 microSD로도 되겠지 싶었는데, 로그와 업데이트, 컨테이너 쓰기 작업이 쌓이니까 금방 신경 쓰이더라고요. 드디어 됐다 싶다가도 I/O가 흔들리면 체감이 확 옵니다. 라즈베리 파이 5 홈랩 구축에서는 저장장치 품질이 성능만큼 중요합니다.

    그래서 저는 운영 기준을 이렇게 바꿨습니다.

    • 부팅 매체와 데이터 매체를 가능하면 분리
    • 쓰기 많은 서비스는 별도 스토리지 고려
    • SMART 확인 가능한 장치를 선호

    3. 발열과 장시간 부하

    라즈베리 파이 5는 성능이 올라간 만큼 발열 관리도 같이 봐야 합니다. 짧게 테스트할 때는 괜찮아도, 백업이나 업데이트처럼 부하가 길게 가면 차이가 납니다. 팬, 케이스, 통풍 구조를 너무 가볍게 보면 나중에 후회하더라고요.

    4. 커뮤니티 포팅 특유의 변수

    이건 정말 중요합니다. Proxmox ARM64는 공식 지원 범위보다 커뮤니티 정보 의존도가 큰 편이라서, 검색했을 때 나오는 글이 작성 시점마다 다릅니다. 어떤 글은 잘 되는데, 내 환경에서는 안 되기도 합니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 핵심은 버전보다도 현재 커널, 패키지 상태, 네트워크/스토리지 구성을 같이 보는 거였습니다.

    dmesg | tail -n 50
journalctl -xe
systemctl --failed
df -h

    문제 생기면 꼭 위 네 가지는 같이 보세요. 특히 `journalctl`과 `dmesg`를 같이 보면 실마리가 빨리 잡힙니다.

    Proxmox ARM64 트러블슈팅과 로그 분석 중인 라즈베리 파이 5 홈랩 이미지

    로그 확인, 서비스 실패, 스토리지 상태 점검 등 실제 트러블슈팅 흐름을 보여주는 이미지입니다.

    검증: 1년 운영 후 무엇이 남았나

    성능 수치를 화려하게 적고 싶지만, 홈랩은 벤치마크 숫자보다 운영 감각이 더 중요하더라고요. 제가 얻은 결론은 이렇습니다.

    • 경량 서비스 위주의 분산 운영에는 충분히 재미있고 실용적입니다.
    • ARM 서버 특성상 호환성 점검이 습관이 됩니다.
    • 장애 대응, 백업, 네트워크 분리 같은 기본기가 훨씬 단단해집니다.
    • 무거운 VM 중심 환경을 기대하면 아쉬울 수 있습니다.

    특히 좋았던 건 서비스를 작게 쪼개는 습관이 생겼다는 점입니다. 예전엔 한 VM 안에 이것저것 몰아넣곤 했는데, ARM 홈랩에서는 그렇게 하면 금방 관리가 복잡해집니다. 그래서 역할별 분리, 로그 분리, 백업 분리를 자연스럽게 하게 되더라고요. 이건 x86 환경으로 돌아가도 그대로 도움이 됐습니다.

    그리고 Proxmox ARM64를 만져보면, “가상화 플랫폼은 단순히 설치해서 쓰는 게 아니라 하드웨어 제약과 운영 철학까지 같이 보는 거구나” 하는 감각이 생깁니다. 이건 숫자로 표현하기 어렵지만 정말 큰 수확이었습니다.

    평가 항목 1년 운영 후 느낌
    학습 가치 매우 높음
    안정성 구성을 보수적으로 잡으면 괜찮음
    확장성 무거운 워크로드에는 한계가 분명함
    운영 편의성 익숙해지면 좋지만 초반 삽질 있음
    재구성 의향 실험용/보조 노드로는 충분히 있음
    Proxmox ARM64 홈랩 운영 결과와 모니터링 상태를 보여주는 이미지

    CPU, 메모리, 네트워크, 컨테이너 상태가 안정적으로 보이는 운영 결과 이미지입니다.

    정리: Proxmox ARM64 홈랩을 추천할 사람, 말릴 사람

    여기서 정리해보겠습니다. 혹시 이런 경험 있으신가요? 시작할 땐 “작고 조용한 서버 하나면 다 되겠지” 싶은데, 막상 운영해보면 내가 원하는 게 성능인지, 안정성인지, 학습인지 헷갈릴 때가 있습니다. Proxmox ARM64 + 라즈베리 파이 5 조합은 그 질문에 답하게 해주는 환경이었습니다.

    이런 분께 추천합니다

    • 홈랩 구축 자체가 재미있는 분
    • ARM 아키텍처 제약을 배우고 싶은 분
    • LXC 중심 경량 서비스를 나눠 운영하고 싶은 분
    • 전력과 소음을 중요하게 보는 분

    이런 분께는 x86이 더 낫습니다

    • 여러 개의 무거운 VM을 안정적으로 돌려야 하는 분
    • amd64 전용 이미지 의존성이 큰 분
    • 트러블슈팅 시간을 줄이고 바로 결과가 필요한 분

    제가 배운 가장 큰 교훈은 하나였습니다. 홈랩은 '최고 사양'보다 '운영을 계속하게 만드는 구조'가 더 중요하다는 점입니다. 라즈베리 파이 5 기반 ARM 서버는 분명 제약이 있지만, 그 제약 덕분에 오히려 운영 기본기를 더 제대로 배우게 되더라고요.

    다음 글에서는 이 ARM 홈랩 위에 모니터링 스택을 어떻게 얹었는지, 그리고 어떤 서비스는 컨테이너로 두고 어떤 서비스는 분리했는지 더 자세히 다뤄볼 예정입니다. 이전 글에서 다룬 홈 네트워크 분리 전략과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    Proxmox ARM64와 라즈베리 파이 5 홈랩의 장단점 요약 이미지

    장점, 한계, 추천 사용 시나리오를 한 장으로 정리한 요약 인포그래픽 이미지입니다.

    자주 묻는 질문

    Q. 라즈베리 파이 5에 Proxmox를 공식 지원하나요?

    제가 확인하고 운영 방향을 잡을 때 기준으로는, x86_64 중심의 공식 흐름을 먼저 보는 게 맞았고, ARM64는 커뮤니티 포팅 성격을 염두에 두는 편이 안전했습니다. 그래서 실험/학습 목적이라면 좋지만, 무조건 공식 지원 장비처럼 기대하면 실망할 수 있습니다.

    Q. Proxmox ARM64 홈랩에서 VM보다 컨테이너가 더 나은가요?

    대체로 그렇습니다. 물론 워크로드에 따라 다르지만, 제가 직접 운영해보니 LXC 중심이 훨씬 가볍고 관리도 수월했습니다.

    Q. 홈랩 구축 입문자도 바로 시작해도 될까요?

    가능은 합니다. 다만 첫 홈랩이라면 x86 미니 PC가 더 수월할 수 있고, ARM 서버는 배움의 밀도가 높은 대신 변수도 많습니다. 본인이 “조금 돌아가더라도 배우면서 가겠다” 쪽이면 재미있게 하실 수 있습니다.

    마무리

    Proxmox ARM64는 만능 해법은 아니었습니다. 하지만 라즈베리 파이 5로 만든 홈랩 구축 경험은, 단순히 서버 한 대 굴린 것 이상을 남겨줬습니다. 아키텍처 차이, 이미지 호환성, 스토리지 안정성, 백업 습관, 장애 대응. 이런 것들이 전부 한 번에 묶여서 들어오거든요. 저도 처음엔 헷갈렸는데, 지나고 보니 그 과정 자체가 가장 큰 자산이었습니다.

    한 줄로 정리하면 이렇습니다. “ARM 홈랩은 불편해서 배운다. 그리고 그 배움이 의외로 오래 간다.” 혹시 지금 라즈베리 파이 5 기반 ARM 서버를 고민 중이시라면, 너무 큰 기대보다는 분명한 목표 하나를 잡고 시작해보세요. 그게 DNS든, 프록시든, 모니터링이든 상관없습니다. 작게 시작하면 생각보다 오래, 그리고 꽤 재미있게 갑니다. 🎉

  • [k8s] MicroK8s 벤치마크: K3s와 엣지 환경 성능 비교 [실전 가이드]

    [k8s] MicroK8s 벤치마크: K3s와 엣지 환경 성능 비교 [실전 가이드]

    목차

    [인프라] MicroK8s 벤치마크: K3s와 엣지 환경 리소스 사용량 비교

    홈랩을 굴리다 보면 결국 한 번은 부딪히는 주제가 있습니다. 바로 MicroK8s 벤치마크를 어떻게 봐야 하느냐는 점이거든요. 저도 ARM 서버를 만지면서 처음엔 “둘 다 경량 쿠버네티스인데 뭐가 그렇게 다르지?” 싶었는데, 실제로 써보니까 꽤 차이가 있더라고요. 특히 엣지 컴퓨팅이나 소형 ARM 보드, 미니 PC처럼 자원이 넉넉하지 않은 환경에서는 이런 차이가 더 크게 체감됩니다.

    이번 글에서는 MicroK8s와 K3s 성능 비교를 단순한 스펙 나열이 아니라, 실제로 어떤 항목을 벤치마크해야 의미가 있는지 중심으로 정리해보겠습니다. 제가 직접 홈랩에서 테스트할 때 썼던 방식, 삽질했던 포인트, 그리고 해석할 때 조심해야 할 점까지 같이 적어볼게요.

    MicroK8s 벤치마크를 위한 엣지 환경 ARM 서버 아키텍처 다이어그램

    엣지 환경에서 경량 쿠버네티스를 비교하는 전체 구성을 한눈에 보여주는 이미지입니다.

    1. 왜 엣지 환경에서는 MicroK8s 벤치마크가 중요할까

    데이터센터에서는 CPU랑 메모리를 조금 더 쓰더라도 관리 편의성이 좋으면 넘어가는 경우가 많습니다. 근데 엣지에서는 얘기가 달라집니다. 1~2GB 메모리 차이, 디스크 I/O 초기화 시간, 컨트롤 플레인(control plane, 클러스터 제어 영역) 기동 속도 같은 게 꽤 민감하게 다가오거든요.

    쉽게 말해, 같은 Kubernetes(쿠버네티스, 컨테이너 오케스트레이션 플랫폼) 계열이라도 무엇을 기본으로 포함하느냐, 어떤 런타임을 묶어 배포하느냐, 초기 설치와 운영 자동화가 어디까지 되어 있느냐에 따라 체감 리소스 사용량이 달라집니다. 그래서 MicroK8s 벤치마크를 볼 때는 숫자 하나보다도 “어떤 조건에서 잰 숫자인가?”를 먼저 보셔야 합니다.

    2. MicroK8s와 K3s, 쉽게 말해 뭐가 다를까

    저도 처음엔 둘 다 그냥 작은 경량 쿠버네티스 배포판 정도로 이해했었는데요, 실제로는 운영 철학이 꽤 다릅니다.

    항목 MicroK8s K3s
    배포 성격 Canonical에서 제공하는 경량 쿠버네티스 배포판 Rancher 진영에서 시작된 경량 쿠버네티스 배포판
    설치 방식 snap 기반 설치가 대표적 단일 바이너리 중심 설치 경험이 간단한 편
    체감 특징 애드온(add-on, 부가 기능) 관리가 편함 가볍고 빠르게 올리기 좋음
    엣지 적합성 기능 일체감이 좋음 최소 자원 환경에서 선호되는 경우가 많음

    여기서 중요한 포인트! 경량 쿠버네티스라고 해서 무조건 가장 적은 메모리만 쓰는 제품을 고르면 끝은 아닙니다. 예를 들어 Ingress(인그레스, 외부 트래픽 진입점), DNS, StorageClass(스토리지 클래스, 동적 볼륨 정책) 같은 기본 기능을 나중에 붙이기 시작하면, 처음의 “가벼움”이 생각보다 금방 상쇄되거든요.

    3. MicroK8s 벤치마크는 무엇을 비교해야 의미가 있을까

    MicroK8s 벤치마크라고 검색하면 CPU, 메모리 그래프 하나 딱 보여주는 자료가 많은데요, 실무에서는 그걸로 판단하기 어렵습니다. 제가 실제로 비교할 때는 아래 항목을 기준으로 잡았습니다.

    • Idle resource usage(유휴 리소스 사용량): 아무 워크로드 없을 때 CPU와 메모리 사용량
    • Cold start time(콜드 스타트 시간): 설치 후 API 응답 가능 상태까지 걸리는 시간
    • Pod scheduling latency(파드 스케줄링 지연): 테스트 파드가 실제 Running 상태가 되기까지의 시간
    • Add-on overhead(부가 기능 오버헤드): DNS, Ingress, Metrics 추가 후 증가 폭
    • Disk footprint(디스크 점유): 설치 후 데이터 디렉터리 증가량

    사실 이 다섯 개만 잡아도 꽤 감이 옵니다. 특히 ARM 서버에서는 디스크 성능이 병목이 되는 경우가 많아서, 메모리만 보면 놓치는 게 많더라고요.

    4. 제가 홈랩에서 잡은 테스트 조건

    벤치마크는 조건 통제가 핵심입니다. 같은 하드웨어, 같은 OS 계열, 같은 컨테이너 이미지, 같은 측정 횟수로 맞춰야 비교가 그나마 공정해집니다. 저는 아래처럼 맞춰서 보는 편입니다.

    1. 테스트 대상 노드는 동일한 ARM 기반 장비 또는 동일 사양 미니 PC로 구성합니다.
    2. 운영체제는 같은 Ubuntu 계열로 맞춥니다.
    3. 백그라운드 서비스와 자동 업데이트는 측정 전 최대한 정리합니다.
    4. MicroK8s와 K3s는 각각 단일 노드로 먼저 비교합니다.
    5. 기본 상태와 add-on 활성화 상태를 따로 측정합니다.
    6. 각 측정은 3회 이상 반복해서 편차를 확인합니다.

    이 부분을 안 맞추면 진짜 헷갈립니다. 저도 처음엔 결과가 들쭉날쭉해서 한참 헤맸는데, 알고 보니 한쪽은 메트릭 수집기가 떠 있었고 다른 쪽은 아니더라고요. 삽질 좀 했습니다 ㅎㅎ

    5. 실전 구현: MicroK8s와 K3s 벤치마크 준비

    5-1. MicroK8s 설치와 기본 확인

    sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
newgrp microk8s
microk8s status --wait-ready
microk8s kubectl get nodes -o wide

    MicroK8s는 snap 기반이라 설치 경험이 꽤 일관적입니다. 대신 snapd 상태나 채널(channel, 배포 트랙)에 따라 초기 준비 시간이 다르게 느껴질 수 있습니다.

    5-2. K3s 설치와 기본 확인

    curl -sfL https://get.k3s.io | sh -
sudo kubectl get nodes -o wide
sudo systemctl status k3s --no-pager

    K3s는 설치가 정말 간단합니다. 처음 써보면 “이렇게 빨리 올라온다고?” 싶은 느낌이 있어요. 엣지 환경에서 자주 언급되는 이유가 괜히 있는 게 아니더라고요.

    MicroK8s 벤치마크와 K3s 성능 비교를 위한 단일 노드 설치 상태 이미지

    단일 노드 환경에서 두 배포판의 설치 직후 상태를 비교하는 장면을 보여주는 이미지입니다.

    5-3. 공통 워크로드 배포

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-bench
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-bench
  template:
    metadata:
      labels:
        app: nginx-bench
    spec:
      containers:
      - name: nginx
        image: nginx:stable
        ports:
        - containerPort: 80
---
    kubectl apply -f nginx-bench.yaml
kubectl get pods -w

    여기서는 복잡한 앱보다 단순한 워크로드가 낫습니다. 이유는 비교 대상을 경량 쿠버네티스 배포판 자체로 최대한 좁혀야 하기 때문입니다.

    5-4. 유휴 리소스와 파드 상태 측정

    free -h
vmstat 1 5
ps aux --sort=-%mem | head
kubectl get pods -A
kubectl top nodes
kubectl top pods -A

    Metrics Server(메트릭 서버, 리소스 수집 컴포넌트)가 없는 상태라면 kubectl top이 바로 안 될 수 있습니다. 이때는 OS 레벨 지표와 함께 보셔야 합니다.

    6. ⚠️ 실제로 겪었던 문제와 트러블슈팅

    6-1. 애드온 차이 때문에 공정 비교가 안 되는 문제

    이게 제일 흔합니다. MicroK8s는 add-on 활성화가 쉽고, K3s는 기본 구성이 상대적으로 간결한 편이라 시작점이 다를 수 있거든요. 그래서 기본 설치 상태와 필수 기능 포함 상태를 따로 비교해야 합니다.

    microk8s enable dns ingress metrics-server
kubectl get pods -A

    혹시 이런 경험 있으신가요? “왜 MicroK8s가 더 무겁지?” 하고 봤더니 사실 기능이 더 많이 켜져 있었던 겁니다.

    6-2. ARM 서버에서 스토리지 지연 때문에 체감이 달라지는 문제

    특히 SD 카드나 느린 eMMC 기반 장비에서는 API 응답보다 이미지 풀(image pull, 컨테이너 이미지 다운로드)과 파일 시스템 동기화가 더 큰 변수였습니다. 그래서 이미지를 미리 받아둔 상태와 처음 내려받는 상태를 분리해서 봐야 해요.

    6-3. 첫 부팅과 재부팅 후 상태가 다른 문제

    처음엔 이게 뭔가 싶었는데, 재부팅 후 서비스 재기동 순서와 캐시 영향으로 결과가 다르게 나오더라고요. 그래서 가능하면 아래처럼 측정 구간을 분리하는 게 좋습니다.

    • 설치 직후 측정
    • 재부팅 후 안정화 뒤 측정
    • 워크로드 배포 후 측정

    7. 검증과 결과 해석: 숫자보다 패턴을 보셔야 합니다

    제가 여러 번 비교해보면서 느낀 패턴은 이렇습니다. K3s는 초기 설치와 기동이 간결하게 느껴지고, MicroK8s는 기능 통합과 관리 편의성이 좋다는 점입니다. 그리고 K3s 성능 비교 자료를 볼 때 자주 나오는 “더 가볍다”는 평은, 대체로 최소 구성 기준에서 이해하면 맞습니다.

    반대로 실서비스에 가까운 구성으로 DNS, Ingress, 모니터링 관련 요소를 하나씩 붙이기 시작하면, 단순 메모리 숫자만으로는 승부가 잘 안 나기도 합니다. 여기서 중요한 건 운영 편의성 대비 리소스 비용입니다. CPU 몇 퍼센트, 메모리 몇백 MB보다도 내가 관리하면서 덜 고생하는 쪽이 전체 비용은 더 낮을 수 있거든요.

    MicroK8s 벤치마크 결과를 보여주는 CPU 메모리 대시보드 이미지

    유휴 상태와 워크로드 배포 후 상태를 비교하는 벤치마크 대시보드 이미지입니다.

    비교 관점 MicroK8s에서 보기 좋은 점 K3s에서 보기 좋은 점
    초기 셋업 애드온 중심 운영이 편함 빠르고 단순하게 시작 가능
    리소스 민감 환경 기능 포함 시 구성 일관성 확보 최소 구성에서 부담이 적은 편
    실험/홈랩 여러 기능을 켜보며 배우기 좋음 가볍게 여러 노드 실험하기 좋음
    운영 판단 기준 기능 통합성 경량성과 단순성

    즉, MicroK8s 벤치마크 결과를 해석할 때는 “기본 상태 비교인지”, “실제 운영 기능 포함 비교인지”를 꼭 구분하셔야 합니다.

    8. 어떤 환경에 무엇을 고르면 좋을까

    • 초소형 엣지 노드나 아주 타이트한 리소스 환경이면 K3s 쪽이 출발이 편할 가능성이 큽니다.
    • 학습, 홈랩, 기능 실험을 자주 하신다면 MicroK8s의 add-on 경험이 꽤 편합니다.
    • ARM 서버를 여러 대 운영하면서 자동화까지 보실 거라면 설치 이후 운영 스크립트와 모니터링 방식까지 같이 검토하셔야 합니다.

    저는 개인적으로 “최소 자원 + 빠른 프로비저닝”이 우선이면 K3s를 먼저 보고, “기능 포함 상태에서 일관된 운영 경험”이 중요하면 MicroK8s를 먼저 봅니다. 둘 중 하나가 절대적으로 우월하다기보다, 우선순위가 다르다고 보는 게 맞더라고요.

    9. 정리와 다음 단계

    정리해보면, MicroK8s 벤치마크는 단순히 누가 더 메모리를 덜 먹느냐로 끝나지 않습니다. 엣지 환경에서는 설치 방식, 애드온 구조, 스토리지 특성, 재부팅 후 복구 속도, 그리고 운영 중 손이 얼마나 가는지가 다 같이 중요합니다. 제가 직접 해보니 숫자 하나보다 패턴이 더 중요했고, 특히 비교 조건을 통일하는 게 절반이더라고요.

    다음 글에서는 실제 홈랩 기준으로 Prometheus(프로메테우스, 메트릭 수집 시스템)와 Grafana(그라파나, 시각화 도구)를 붙여서 MicroK8s와 K3s의 장기 모니터링 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 설계 내용과도 연결해서 보시면 더 이해가 쉬우실 겁니다.

    MicroK8s 벤치마크와 K3s 선택 기준을 요약한 인포그래픽

    어떤 조건에서 어떤 배포판이 더 잘 맞는지 한 장으로 정리한 요약 이미지입니다.

    자주 묻는 질문

    Q1. MicroK8s와 K3s 중 뭐가 무조건 더 빠른가요?

    무조건이라고 말하긴 어렵습니다. 최소 구성에서는 K3s가 가볍게 느껴지는 경우가 많지만, 운영 기능을 붙인 뒤에는 비교 조건에 따라 달라집니다.

    Q2. 엣지 컴퓨팅에서는 무엇을 먼저 봐야 하나요?

    CPU보다도 메모리, 디스크 I/O, 재기동 안정성을 먼저 보시는 걸 권장합니다. 특히 느린 저장장치에서는 체감 차이가 크게 납니다.

    Q3. 홈랩 입문자는 무엇으로 시작하면 좋을까요?

    기능을 빨리 배우고 싶으면 MicroK8s, 아주 가볍게 여러 노드를 올려보고 싶으면 K3s가 편할 수 있습니다.