홈 서버에 쿠버네티스(k3s) 도입하기: 오버엔지니어링일까?
홈 서버에 쿠버네티스(k3s) 도입하기: 오버엔지니어링일까?
결론 3줄 요약
- 단일 노드 홈 서버에 쿠버네티스를 얹는 것은 분명 과도한 스펙(Over-engineering)일 수 있지만, 현대 인프라의 표준을 학습하기에는 최고의 개인용 샌드박스입니다.
- 시스템 리소스를 갉아먹는 무거운 표준 K8s 대신 Rancher에서 만든 초경량 배포판 k3s를 활용하면 라즈베리파이 환경에서도 쾌적한 클러스터 구동이 가능합니다.
- YAML 기반의 선언적 배포와 GitOps(ArgoCD) 자동화, 그리고 컨테이너 자가 복구(Self-healing) 기능은 도커 컴포즈 시절로 돌아가기 싫게 만드는 강력한 마력입니다.
1. 서론: 우리는 왜 잘 돌고 있는 도커를 놔두고 사서 고생을 하는가?
안녕하세요! 무사고 무중단 홈 서버 아키텍처를 꿈꾸며 오늘도 터미널 창의 깜빡이는 커서를 보며 잠드는 10년 차 시스템 개발자입니다. 지난번 포스팅에서는 우분투(Ubuntu) 환경에 도커(Docker) 컴포즈를 활용하여 아주 실용적이고 깔끔한 개인용 클라우드 홈 서버를 구축하는 방법을 자세히 다루어 보았습니다.
사실 도커 컴포즈 기반의 홈 서버는 정말이지 훌륭하고 군더더기가 없습니다. docker-compose.yml 파일 하나에 내가 올리고 싶은 웹 서버, 데이터베이스, 블로그 애플리케이션을 선언해 두고 명령어 한 줄만 엔터 치면 마법처럼 전체 시스템이 깔끔하게 기동 되니까요. 하지만 우리 엔지니어들의 호기심은 언제나 현재의 안정감에 만족하지 못하고 끝없는 탐구의 길로 우리를 이끕니다.
"도커 엔진 프로세스가 뻗어버리면 서버 안의 서비스가 다 같이 죽는데, 서랍 속에 굴러다니는 라즈베리파이 3대를 네트워크로 묶어서 고가용성(HA) 클러스터를 만들 순 없을까?" "수동으로 서버에 접속해서 설정 파일을 건드리는 구시대적인 방식 말고, Github에 코드를 푸시하기만 하면 내 홈 서버의 서비스가 자동으로 무중단 배포되는 GitOps(깃옵스) 환경을 흉내 내볼 순 없을까?"
이런 근질근질한 호기심이 머릿속에서 발동하는 순간, 우리는 업계의 대세이자 컨테이너 오케스트레이션(Container Orchestration)의 사실상 표준(De facto standard)인 **쿠버네티스(Kubernetes, K8s)**의 거대한 세계로 눈을 돌리게 됩니다. 방문자 수도 고작 가족 몇 명뿐인 방구석 홈 서버에 글로벌 빅테크 기업들이나 쓴다는 거창한 쿠버네티스를 올리다니, 이것은 누가 봐도 완벽한 오버엔지니어링(Over-engineering)이 맞습니다. 하지만 뭐 어떻습니까? 우리는 끊임없이 새로운 기술의 뚜껑을 열어보고 부수고 조립하며 쾌감을 느끼는 운명인 것을요!
2. 본론: 무거운 K8s 대신 뼈를 깎는 다이어트에 성공한 k3s의 등장
하지만 막상 부푼 꿈을 안고 홈 서버에 쿠버네티스를 쌩으로 올리려다 보면 금세 거대한 좌절의 벽에 부딪힙니다. 표준 쿠버네티스(우리가 흔히 말하는 바닐라 K8s)는 수천 대의 서버를 엮는 엔터프라이즈 환경을 타겟으로 설계되었기 때문에, 베이스로 요구하는 시스템 사양이 어마어마합니다.
아무런 컨테이너도 띄우지 않은 빈 깡통 클러스터의 마스터 노드(Control Plane)를 돌리는 데만 벌써 기가바이트(GB) 단위의 RAM과 묵직한 CPU 자원을 몽땅 씹어 먹습니다. 라즈베리파이 4 같은 빈약한 싱글 보드 컴퓨터나 미니 PC에서는 쿠버네티스의 심장 역할인 kube-apiserver와 분산 저장소 etcd 프로세스를 간신히 띄우는 것조차 버거워서 시스템이 헐떡거리기 일쑤죠.
이 답답하고 막막한 상황에 마치 한 줄기 빛처럼 등장한 구원투수가 바로 **Rancher Labs(수세 랜처)에서 내놓은 k3s(케이-쓰리-에스)**입니다.
2.1. k3s: 임베디드와 엣지 컴퓨팅을 위해 태어난 초경량 쿠버네티스
k3s는 본래 쿠버네티스의 철자 수 8개(K-ubernete-s)에서 의미상 무거운 부분을 덜어내어 5개를 뜻하는 'k3s'로 이름 지어진, 말 그대로 용량을 절반 이하로 확 줄인 초경량 쿠버네티스 배포판입니다. 과거 쿠버네티스의 레거시 코드, 알파(Alpha) 상태의 불필요한 기능들, 특정 클라우드 벤더(AWS, GCP 등)에 종속된 수많은 무거운 플러그인과 드라이버들을 소스 코드 레벨에서 과감하게 싹 다 도려냈습니다.
사용자는 단일 50MB짜리 앙증맞은 바이너리 파일 하나만 실행하면 클러스터 전체가 설치되며, 엄청나게 무거웠던 데이터베이스 etcd를 제거하고 그 자리에 작고 가벼운 파일 기반의 SQLite를 기본 저장소로 채택하는 유연성까지 갖췄습니다. 이 눈물겨운 다이어트 덕분에 놀랍게도 불과 512MB 남짓한 RAM 점유율만으로도 완벽한 쿠버네티스 컨트롤 플레인을 아주 쾌적하게 구동해 냅니다. 원래는 통신망이 열악한 IoT 기기나 열악한 스마트 팩토리 엣지 컴퓨팅 노드에 배포할 목적으로 만들어진 배포판이지만, 특유의 가벼움과 설치의 간편함 덕분에 방구석 홈 서버 매니아와 개인 개발자들에게 폭발적이고 열광적인 사랑을 받는 플랫폼으로 거듭났습니다.
2.2. 설치는 단 1분 컷, 터미널 명령어 한 줄의 마법
도커 기반으로 운영되던 기존 홈 서버를 갈아엎고 k3s를 올리는 과정은, 예전 Kubeadm을 써서 며칠을 고생하던 시절과 비교하면 너무나도 싱겁고 허무해서 웃음이 나올 정도입니다. 터미널 창에 딱 한 줄의 쉘 스크립트만 복사해서 붙여넣으면 마법이 시작됩니다.
curl -sfL https://get.k3s.io | sh -
키보드의 엔터를 치고 커피 한 모금을 마시고 나면, 약 1분 후 시스템의 systemd 서비스에 등록되고 내부적으로 파드 간 통신을 위한 네트워크 CNI(Flannel)와 외부 트래픽을 받는 로드밸런서(Traefik Ingress)가 모조리 자동으로 훌륭하게 세팅된 상태로 서버가 기동 됩니다. 떨리는 손으로 터미널에 kubectl get nodes 명령어를 쳤을 때, Ready 상태로 영롱하게 빛나는 내 홈 서버의 호스트명을 바라볼 때의 그 엔돌핀 솟구치는 짜릿함은 해본 사람만이 알 수 있습니다.
3. 본론: 홈 서버 k3s 실전 운용을 위한 현업 생존 가이드
설치는 명령어 한 줄의 마법으로 순식간에 끝났지만, 그 거대한 바다 안에서 헤엄치며 튜닝을 하는 일은 본격적인 쿠버네티스 학습 스터디의 연속입니다. 10년 차 시스템 개발자가 몸으로 들이받으며 부딪혀 터득한 방구석 k3s 실전 튜닝 및 운영 가이드를 몇 가지 소개합니다.
3.1. 기본 설치된 Traefik은 빼고 전통의 Nginx Ingress로 가자
k3s를 처음 설치하면 기본 Ingress Controller(인터넷의 외부 접속을 내부 파드 컨테이너로 연결해 주는 톨게이트 역할) 컴포넌트로 Traefik이 자동으로 세팅됩니다. 성능 좋고 고버전의 훌륭한 녀석이지만, 설정 방식이 조금 독자적이고 CRD(사용자 정의 리소스) 문법이 쿠버네티스 초심자에게는 다소 낯설고 이질적일 수 있습니다.
만약 회사 현업에서 광범위하게 쓰이는 가장 전통적인 Nginx 기반의 아키텍처에 익숙하다면, k3s를 맨 처음 설치하는 단계에서 아예 Traefik을 제외(INSTALL_K3S_EXEC="--disable traefik")시키는 옵션을 주고, 우리에게 친숙한 ingress-nginx 컨트롤러를 쌩으로 직접 배포하는 것을 강력히 추천합니다. 스택오버플로우 레퍼런스와 트러블슈팅 문서가 압도적으로 방대해서, 야밤에 설정이 꼬여 삽질하는 억울한 시간을 극적으로 줄여줍니다.
3.2. 영구 볼륨 데이터 보존 문제 해결하기 (Local Path Provisioner)
쿠버네티스의 핵심 철학은 "컨테이너(파드)는 소모품이며 언제든지 죽고 다른 노드에서 다시 살아날 수 있는 상태 없음(Stateless)을 유지해야 한다"는 것입니다. 하지만 우리의 홈 서버 세계에는 내가 애써 쓴 블로그 포스트가 담긴 데이터베이스 파일이나, 소중한 가족 여행 사진 보관함처럼 단 1바이트라도 날아가면 멘탈이 바스러지는 영구적인 상태(Stateful) 데이터가 존재합니다.
돈 많은 엔터프라이즈 환경이나 AWS 같은 퍼블릭 클라우드에서는 EBS 스토리지 같은 훌륭한 외부 마운트 볼륨이 무한하게 대기하고 있지만, 방구석 홈 서버에는 그런 럭셔리한 인프라가 없습니다. 다행히 k3s에는 호스트 PC의 특정 로컬 디렉토리를 쿠버네티스의 영구 볼륨(PV, Persistent Volume)으로 동적으로 예쁘게 쪼개서 파드에 붙여주는 Local Path Provisioner가 내장형으로 포함되어 있습니다. 이 녀석의 StorageClass를 적극 활용하여 노드 내 SSD의 안전한 특정 경로를 마운트시키면, 파드가 재시작되거나 죽더라도 데이터 증발 걱정 없이 맘 편하게 DB 컨테이너를 돌릴 수 있습니다.
3.3. 궁극의 배포 자동화, ArgoCD를 통한 방구석 GitOps의 실현
방구석에 초소형 쿠버네티스 클러스터를 무사히 구축했다면, 개발자로서 궁극의 종착지인 **GitOps(깃옵스)**의 로망을 반드시 실현해 보아야 합니다. 아주 귀엽게 생긴 문어 모양의 로고를 가진 ArgoCD라는 도구를 클러스터에 배포하고, 내 개인 Github 저장소와 연동 파이프라인을 뚫어 봅니다.
이제 더 이상 맥북의 터미널을 열고 서버에 SSH로 접속해서 구질구질하게 kubectl apply -f deployment.yaml 명령어를 손가락으로 치는 시대는 끝났습니다. 나는 그저 편하게 IDE(VS Code)에서 YAML 파일의 컨테이너 이미지 태그 버전을 v1.0에서 v1.1로 숫자 하나 수정하고 Git 저장소에 커밋 후 git push 명령어만 던지면 됩니다. 클러스터 안에 떠 있는 ArgoCD 봇이 1분 단위로 Git 저장소를 매의 눈으로 감시하다가 "어랏? 사용자가 선언한 원하는 상태(Desired State)의 코드가 바뀌었네?"라고 똑똑하게 인지하고, 지체 없이 내 홈 서버의 서비스 컨테이너를 새로운 버전으로 무중단 롤링 배포(Rolling Update) 시켜버립니다. 개발자로서 이보다 우아하고 짜릿한 마법 같은 배포 경험은 두 번 다시 없을 겁니다.
4. 결론: 세상에서 가장 작은 클러스터, 하지만 가장 거대한 배움터
누군가는 고작 하루 방문자 수십 명 남짓한 조촐한 개인 블로그 서비스나 토이 프로젝트 API 서버를 돌리는데, 복잡한 쿠버네티스를 쓰는 것은 소 잡는 칼로 닭을 잡는 미친 오버엔지니어링이라고 손가락질하며 비웃을지도 모릅니다. 네, 시스템 리소스 오버헤드와 효율성 측면의 ROI만 따지고 본다면 그들의 말이 100% 맞는 말입니다. 단순히 단일 서비스를 띄워 굴리는 게 목적이라면 가벼운 도커 컴포즈만으로도 이미 너무나 훌륭하니까요.
하지만 우리 개발자들에게 홈 서버는, 단순히 트래픽을 받아내고 서비스를 돌리기 위한 상업적 목적 그 이상의 성소입니다. 새로운 기술 스택을 마음대로 씹고 뜯고 부수고 망가뜨리며 놀 수 있는 세상에서 가장 안전하고 자유로운 나만의 '모래놀이터(Sandbox)'입니다.
회사 서비스의 살얼음판 같은 상용 K8s 운영 클러스터에서는 장애 날까 무서워 감히 건드려볼 엄두조차 못 냈던 Ingress Nginx 설정 파괴, 핵심 파드(Pod) 강제 삭제(kill), 무자비한 네트워크 격리 정책(Network Policy) 적용 같은 아찔하고 스릴 넘치는 실험들을 내 방구석 클러스터에서는 눈치 보지 않고 마음껏 저지를 수 있습니다. 그러다가 서버가 완전히 뻗어서 먹통이 되면 어떻게 하냐고요? 괜찮습니다, 그냥 콘센트 플러그 한 번 쑥 뽑았다 끼우고 설치 쉘 스크립트 한 줄만 다시 돌리면 그만이니까요!
수십 줄의 들여쓰기 꼬인 YAML 매니페스트 파일과 밤새도록 씨름하며, 쿠버네티스의 복잡한 개념과 아키텍처를 머리가 아닌 온몸으로 얻어맞으며 체득하는 이 거칠고도 즐거운 삽질의 과정. 이 소중한 경험의 시간들은 분명 훗날 여러분이 대규모 클라우드 네이티브 아키텍처를 당당하게 설계하고 리딩하는 핵심 인재로 거듭나는 가장 든든하고 강력한 기술적 근육이 되어줄 것이라 확신합니다.
오늘 퇴근길, 혹은 이번 주말에 책상 서랍 속에 방치되어 먼지가 뽀얗게 쌓여가는 불쌍한 라즈베리파이 서너 대나 구형 노트북을 주섬주섬 챙겨보시는 건 어떨까요? 어두운 방 안에서 작은 이더넷 포트 불빛이 쉴 새 없이 반짝이는 나만의 초소형 쿠버네티스 클러스터를 꼭 한 번 만들어보시길 강력하게 권해드립니다.
다음 개발 관련 포스팅에서는, 이렇게 땀 흘려 공들여 만든 소중한 클러스터 서버를 인터넷의 무자비한 해킹 위협으로부터 철통같이 안전하게 지켜내는 홈 서버 네트워크 최적화 설정과 VPN 방화벽 구축 노하우에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다. 모두 이번 주도 치명적인 배포 장애 없는 평온한 릴리스 되시기 바랍니다. 코딩 화이팅!
This post was drafted with the help of AI tools and personally reviewed and edited.
Thanks for reading!
If you found this post useful, check out more articles on the homepage.
Read More Posts