👉 Alt 텍스트 설정 (이미지 속성): Proxmox LXC 컨테이너 환경 위에 구축된 k3s 쿠버네티스와 WebAssembly 하이브리드 클러스터 아키텍처
들어가며: 도커 컴포즈(Docker Compose)의 한계와 쿠버네티스 도입 배경
안녕하세요, 시스템 엔지니어이자 4남매 아빠 수누다입니다.
홈랩을 처음 구축할 때만 해도 단일 서버에서 Docker Compose를 이용해 서비스를 하나씩 올려 나가는 것만으로도 충분한 만족감을 느낄 수 있었습니다. 하지만 운영하는 서비스가 10개를 넘어가고, 트래픽에 따른 노드 간의 리소스 배분이나 서비스 장애 시 자동 복구(Self-healing) 기능이 절실해지기 시작했습니다. 시스템 인프라를 다루는 엔지니어의 관점에서, 수동으로 컨테이너를 관리하는 단계를 넘어 선언적(Declarative)으로 인프라를 통제하는 쿠버네티스(Kubernetes) 오케스트레이션 환경을 고려하게 된 것은 아주 자연스러운 수순이었습니다.
솔직히 개인 서버 한 대에 무거운 순정 쿠버네티스를 돌리는 것은 심각한 전력 낭비이자 오버엔지니어링이 될 수 있습니다. 그래서 저는 경량화된 k3s를 선택하여 자원 효율을 극대화하기로 했습니다. 나아가 2026년 현재 컨테이너 기술의 다음 단계로 불리는 WebAssembly(Wasm)를 쿠버네티스 노드에 통합하는 최신 하이브리드 아키텍처까지 홈랩에 적용해 본 경험을 상세히 공유하고자 합니다.
홈랩 환경에 최적화된 쿠버네티스, 왜 k3s를 선택했는가?
1. 무거운 순정 k8s를 대체하는 단일 바이너리 경량 아키텍처
쿠버네티스는 본래 구글과 같은 엔터프라이즈급 대규모 데이터센터 인프라를 통제하기 위해 설계되었습니다. 그렇기 때문에 기본적으로 요구하는 메모리와 CPU 자원이 상당히 무거운 편입니다. 하지만 Rancher에서 개발한 k3s는 불필요한 레거시 드라이버와 클라우드 제공자(Cloud Provider) 코드를 덜어내고, 단일 바이너리로 패키징한 극강의 경량 배포판입니다.
수백 메가바이트(MB) 수준의 아주 적은 메모리로도 완벽하게 동작하기 때문에, 현재 제가 운용 중인 인텔 코어 i5-8500 기반의 Proxmox 환경에서도 호스트 자원에 전혀 부담을 주지 않고 원활하게 돌아갑니다.
2. 유지보수의 지옥을 벗어나는 단순한 배포 프로세스
13년 동안 수많은 인프라를 운영해 오며 얻은 교훈 중 하나는 "복잡한 인프라 구조는 결국 유지보수의 지옥으로 이어진다"는 사실입니다. k3s는 복잡한 인증서 설정이나 컴포넌트 구성 없이, 쉘 스크립트 명령어 단 한 줄이면 마스터 노드 세팅이 완료됩니다. 빠른 배포와 손쉬운 버전 업데이트가 가능하다는 점은 제한된 시간 속에 시스템을 관리해야 하는 홈랩 환경에서 최고의 장점으로 작용합니다.
2026년 차세대 컨테이너 기술, WebAssembly(Wasm) 노드 통합
👉 Alt 텍스트 설정 (이미지 속성): k3s 클러스터 내부에서 전통적인 OCI 컨테이너와 WebAssembly 워크로드가 분산 처리되는 하이브리드 로드밸런싱 구조
1. WasmEdge 런타임을 활용한 하이브리드 클러스터 구축
최근 클라우드 네이티브 및 인프라 엔지니어들 사이에서 가장 화두가 되는 기술은 단연 WebAssembly(Wasm)입니다. 기존 Docker로 대표되는 OCI 컨테이너보다 이미지 크기가 훨씬 작고 부팅 속도가 밀리초(ms) 단위로 빠르며, 운영체제 종속성 없이 안전한 샌드박스 환경에서 동작하는 차세대 런타임입니다.
저는 이 최신 기술을 검증하기 위해 쿠버네티스 워커 노드에 Krustlet 및 WasmEdge와 같은 전용 런타임을 추가했습니다. 이를 통해 일반적인 Docker 컨테이너와 Wasm 워크로드를 하나의 클러스터에서 동시에 오케스트레이션할 수 있는 하이브리드 클러스터를 성공적으로 구성했습니다.
2. 효율적인 시스템 자원 활용을 위한 워크로드 배치 전략
인프라의 한정된 자원을 100% 활용하기 위해서는 작업의 무거운 정도에 따라 노드를 분리하는 전략이 필수적입니다. 저희 4남매의 수만 장에 달하는 방대한 사진과 동영상을 AI 모델로 분석하고 인덱싱하는 무거운 작업(Immich 등)은 컴퓨팅 파워가 넉넉한 일반 노드에 스케줄링했습니다. 반면, 단순한 상태 알림 서비스나 가벼운 API 연산 작업은 극도로 가벼운 Wasm 노드로 밀어 넣어 시스템 전체의 자원 가용성을 극한으로 끌어올렸습니다.
Proxmox LXC 환경에서 k3s 구축 시 발생하는 핵심 트러블슈팅
1. AppArmor 및 cgroup 보안 권한 충돌 원인 분석
Proxmox가 제공하는 리눅스 컨테이너(LXC) 위에 k3s를 올릴 때 거의 모든 엔지니어가 겪게 되는 관문이 있습니다. 바로 호스트의 보안 정책 및 권한 제약으로 인한 충돌 현상입니다.
쿠버네티스의 kube-proxy와 컨테이너 런타임(Containerd)은 파드(Pod) 간의 네트워크 통신을 위해 호스트의 iptables를 수정하고, cgroup 리소스를 제어할 수 있는 높은 수준의 권한을 요구합니다. 하지만 LXC는 기본적으로 AppArmor를 통해 컨테이너 내부의 프로세스가 커널 자원에 접근하는 것을 엄격하게 차단하기 때문에, 파드 간 통신이 단절되거나 컴포넌트 자체가 실행되지 않는 치명적인 에러가 발생합니다.
2. LXC 컨테이너 설정 파일 수정을 통한 문제 해결
이러한 보안 제약 문제를 해결하기 위해서는 Proxmox 호스트 쉘(Shell)에 접속하여 해당 LXC 컨테이너의 설정 파일을 직접 수정해 주어야 합니다.
# /etc/pve/lxc/ID.conf 파일 편집 (ID는 해당 컨테이너의 번호)
# k3s가 iptables 및 시스템 자원을 정상적으로 제어할 수 있도록 권한을 대폭 부여함
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:
lxc.mount.auto: proc:rw sys:rw
위 코드를 설정 파일 하단에 추가한 뒤 컨테이너를 재시작하면, AppArmor의 제한이 해제되면서 k3s의 모든 컴포넌트가 호스트의 커널 네트워크 기능에 정상적으로 접근하게 되어 클러스터가 완벽하게 동작하기 시작합니다.
3. 홈랩 환경에서의 보안 정책과 현실적인 타협점 (Trade-off)
엔지니어의 관점에서 주의해야 할 점이 있습니다. unconfined 설정은 사실상 LXC 컨테이너가 가진 보안 격리벽을 가상머신(VM) 수준으로 크게 풀어버리는 결과를 낳습니다. 만약 외부의 공격을 직접적으로 받는 상용 운영(Production) 환경이라면 보안 정책을 훨씬 세밀하고 엄격하게 다듬어야 할 것입니다.
하지만 현재 구축하는 시스템은 내부망에서 관리되는 11TB 스토리지와 개인적인 서비스를 구동하는 홈랩(HomeLab) 환경입니다. 따라서 기술적 목적 달성과 효율적인 트러블슈팅을 위해 보안과 편의성 사이에서 이 정도의 타협을 하는 것은 매우 합리적인 아키텍처 결정이라고 볼 수 있습니다.
요약 및 결론
- 플랫폼 최적화: 홈랩의 제한된 하드웨어 자원을 깊이 있게 고려하여, 메모리 점유율이 낮고 단일 바이너리로 완벽하게 동작하는 k3s를 도입해 오케스트레이션 환경을 완성했습니다.
- 기술적 혁신: 차세대 런타임인 WebAssembly(Wasm)를 쿠버네티스 노드에 성공적으로 통합하여, 작업 특성에 맞게 워크로드를 효율적으로 분산하는 하이브리드 아키텍처를 구현해 냈습니다.
- 현실적인 문제 해결: Proxmox LXC가 가진 엄격한 보안 제약을 시스템 구조에 맞게 과감히 해제함으로써, 홈랩 환경에 가장 알맞고 빠른 트러블슈팅을 이뤄냈습니다.
앞으로도 직접 부딪히며 해결한 생생한 인프라 구축기와 시스템 엔지니어링 노하우를 꾸준히 공유하겠습니다. 긴 글 읽어주셔서 감사합니다.
