홈서버에 K3s를 도입하려다 환경 구축 단계에서 멈췄다. 후회는 없다. 직접 해봤기에 확신을 갖고 선택할 수 있게 되었다.

왜 시도했나

나는 홈서버를 Docker Compose로 운영하고 있었다. 돌아가는 서비스가 늘어나면서 "쿠버네티스를 써야 하나?" 하는 생각이 자연스럽게 들었다.

사실 머리로는 답이 나와 있었다. 홈서버는 단일 노드고, 정전에서 자유로울 수 없고, 쿠버네티스가 제공하는 고가용성은 이 환경에서 의미가 없다. Docker Compose면 충분하다.

그런데 써보지도 않고 "과하다"고 결론 내리는 건 성급하고, 전문적이지도 않다고 느꼈다. 잘 모르는 걸 안 맞는다고 해봐야 나 스스로에게도 설득이 안 된다. 직접 경험하고 싶었고, 쿠버네티스를 구축하고 운영하는 과정에서 배울 게 많으리라 생각했다.

여정

2025년 8월, K3s 설치부터 시작했다.

설치와 첫 번째 벽

K3s 자체의 설치는 간단했다. curl -sfL https://get.k3s.io | sh - 한 줄이면 끝이다. 하지만 바로 문제를 만났다.

  • 기본 설치 시 root 파티션을 사용하는데, 20~30GB 정도만 할당해두었다면 서비스 몇 개 설치하는 순간 디스크가 가득 차서 K3s가 죽는다. --data-dir로 별도 경로를 잡아야 했다.
  • kubectl 사용에 sudo가 필요했다. --write-kubeconfig-mode 644 옵션이 필요하다는 걸 알게 됐다.

Docker Compose → K8s 매니페스트 변환

기존 docker-compose.yml을 쿠버네티스 매니페스트로 변환하기 위해 kompose를 사용했다. 결과는 실망스러웠다.

  • Namespace를 붙여주지 않았다.
  • 여러 Dockerfile로 구성된 서비스를 제대로 변환하지 못했다.
  • docker-compose.yml 자체에 포트가 비명시적인 부분이 있었는데, 이것도 변환 시 문제가 됐다.

결국 kompose convert --namespace wise로 다시 변환하고, 원본 compose 파일의 불완전한 부분을 수정하고 나서야 동작했다.

이미지 문제: containerd의 세계

K8s는 containerd의 이미지 스토어를 사용한다. podman에서 빌드한 이미지와는 완전히 별개다. 이미지를 넘기려면 이런 식으로 파이프해야 했다:

sudo podman save localhost/my-app:latest \
  | sudo k3s ctr images import -

"빌드는 어떻게 하지?" 싶어서 nerdctl을 시도했다. containerd 소켓 경로가 K3s에서는 다르다는 것도 알게 됐다. 그런데 nerdctl로 빌드하려면 buildctl이 또 필요하고, 그걸 또 설정해야 한다. 결국 드랍. 그냥 podman으로 빌드해서 containerd에 복사하는 게 더 빠르다.

알아보니 K8s는 애초에 이미지를 "당겨 쓰는 것"만 생각하지, 로컬 빌드는 고려 대상이 아닌 것으로 보였다. 정석은 레지스트리를 구축하고 거기에 push/pull 하는 것이다.

Rancher: 기대와 현실

K3s 클러스터를 관리할 UI가 필요해서 Rancher를 설치했다. 이것도 만만치 않았다.

  • Rancher는 기본적으로 Ingress + HTTPS를 요구한다. cert-manager가 선행 설치되어야 한다.
  • Ingress를 쓰려면 FQDN이 필요하고, 사설 DNS 운영으로 이어진다. 단순히 Rancher 하나 띄우자고 네트워크 전체 설계를 건드리는 건 수지타산이 안 맞아서, NodePort 방식으로 우회했다.
  • Helm 설치 후 cluster unreachable 에러가 났다. K3s의 kubeconfig 경로가 표준 K8s와 달라서 생긴 문제였다. (해결 과정)
  • 설치에 성공하고 나니, Rancher가 RAM을 1~2GB 먹었다.
  • 가장 치명적인 건: K3s에 문제가 생기면 모든 서비스가 내려가는데, Rancher도 같이 내려간다. 정작 상태를 확인해야 할 때 쓸 수가 없다.

NodePort로 Rancher를 띄우는 최종 정리는 별도 글에 남겨두었다.

그리고 Harbor...

이미지 레지스트리로 Harbor를 설치하려고 했다. 드래프트에 한 줄 남겼다: "harbor 를 설치할 것이다." 거기서 멈췄다.

멈춘 이유

궁극적 목적은 서비스 운영이다. 서비스를 만드는 데에도 시간을 써야 한다. Docker Compose만으로도 그게 된다.

홈서버는 집 환경에 종속적이다. 생각보다 정전이나 네트워크 불안정 같은 문제가 있고, 그 수준에서는 Docker Compose가 제공하는 정도로 이미 충분하다.

K3s로 운영하려면 Docker Compose에서는 상상도 못한 것들이 "필요"해진다:

  • 이미지 레지스트리 (Harbor)
  • 인증서 관리 (cert-manager)
  • 서비스 도메인과 Ingress 설정
  • FQDN을 위한 사설 DNS 고려
  • 모니터링 UI (Rancher) — 그런데 이것도 자원을 먹고, 정작 필요할 때 같이 죽음

ROI가 안 나오는 걸 체감하고 있는 상태에서, 현실이 바빠지다 보니 우선순위에서 자연스럽게 밀렸다.

배운 것들

환경 구축 단계에서 멈췄지만, 꽤 많은 걸 배웠다.

  • K3s ≠ 작은 K8s. 쿠버네티스의 "배포판"에 가깝다. 자체 설정과 경로가 있고, 표준 K8s를 전제한 도구들(Helm 등)과 미묘한 차이가 있다.
  • containerd의 구조. 이미지 스토어가 Docker/podman과 독립적이라는 것, 소켓 경로가 K3s에서 다르다는 것.
  • K8s는 빌드를 고려하지 않는다. 이미지를 "당겨서 쓰는 것"이 전제. 로컬 빌드 → 배포는 레지스트리를 경유해야 한다.
  • Helm, cert-manager, Ingress, FQDN — 각각이 무엇이고 왜 필요한지를 실전에서 이해했다.
  • Rancher의 실용성 한계. 모니터링 도구가 모니터링 대상과 함께 죽는 구조적 문제.

결론

홈서버에 K3s는 안 맞았다 — 이건 이전에도 알고 있던 결론이다.

달라진 건 확신의 질이다. 4월에는 "아마 과하겠지"였다면, 지금은 "직접 해봤고, 이래서 안 맞는다"고 구체적으로 말할 수 있다. 써보지 않고 내린 판단과, 써보고 내린 판단은 무게가 다르다.

다시 Docker Compose로 돌아왔다. 정확히는, 돌아갈 것도 없었다. K3s 위에서 서비스를 운영한 적이 없으니까. 환경 구축에서 멈춘 것이 오히려 복귀를 깔끔하게 만들어주었다.

쿠버네티스를 공부하고 싶다면 해보는 게 맞다. 다만 홈서버 "운영"이 목적이라면, 그 시간에 서비스를 하나 더 만드는 게 낫다.

2026년, 돌아보며

이 글에서 다룬 경험은 2025년의 기록이다.

2026년이 된 지금, AI 시대가 본격적으로 도래했다. 당시 나를 지치게 했던 것들 — containerd 소켓 경로 찾기, Helm 옵션 조합 실험, cert-manager와 Ingress 설정, Rancher 설치 삽질 — 이런 종류의 작업은 이제 AI가 웬만큼 해줄 수 있는 시대가 되었다.

그래서 사실 지금은, 직접 구축해야 한다는 부담이 많이 줄었다. 만약 다시 K3s를 시도하게 된다면, 2025년에 겪었던 고생보다는 훨씬 덜하면서도 결과를 볼 수 있지 않을까 싶다.