[k8s 기초 1편] 홈서버 k3s 구축하다 정리해보는 쿠버네티스 개념과 필요성

최근 집에 구비해놓은 미니 PC를 활용해 홈서버를 구축하고 있다.
단순히 도커(Docker)만 띄워서 쓸까 하다가, 기왕 하는 거 요즘 대세인 쿠버네티스(Kubernetes)를 제대로 활용해보자 싶어 가벼운 버전인 k3s를 설치했다.

그런데 막상 클러스터를 구축하고 나니, Gemini를 활용하거나 웹 서치를 통해 돌아가게는 만들었지만, “이게 왜 돌아가는지” 명확히 설명하기가 어려웠다.

그래서 이번 기회에 쿠버네티스의 A to Z를 기초부터 탄탄하게 정리해 보려고 한다. 이 시리즈는 나처럼 “도커는 좀 써봤는데 쿠버네티스는 아직 낯선” 개발자들을 위한 정리 노트다.

---

1. 도커(Docker)만으로도 충분하지 않았나?

처음 개발을 배울 때 docker run 명령어를 치고, 내 코드가 컨테이너 안에서 독립적으로 돌아가는 걸 봤을 때의 희열은 대단했다. docker-compose를 쓰면 DB랑 웹 서버를 한 번에 띄우는 것도 쉬웠다.

하지만 실제 운영(Production) 환경이나, 나처럼 한정된 자원의 홈서버를 굴리다 보니 단순 도커만으로는 한계가 명확했다.

내가 느낀 수동 관리(Docker)의 3가지 한계

① 장애 대응의 한계 (Retry는 만능이 아니다)

물론 도커에도 restart: always 옵션이 있다. 컨테이너가 죽으면 다시 살려주긴 한다.
하지만 이건 단순한 재시작일 뿐이다.

• 만약 서버(노드) 자체가 죽으면? -> 그 안에 있던 컨테이너도 영영 돌아오지 못한다.
• 애플리케이션 내부는 꼬여있는데 프로세스만 살아있다면? -> 도커는 “살아있다”고 판단해서 놔두고, 서비스는 먹통이 된다.

② 자원 관리의 어려움 (OOMKilled의 공포)

도커에서도 메모리나 CPU 제한(--memory, --cpus)을 걸 수 있다. 하지만 이 제한은 ‘Hard Limit’에 가깝다.

• 자바 앱이 잠깐 메모리를 많이 써서 제한을 초과했다? -> 도커는 가차 없이 그 컨테이너를 죽여버린다(OOMKilled).
• 그렇다고 제한을 안 걸자니? -> 배치 작업 하나가 CPU를 다 끌어다 써서 멀쩡한 웹사이트까지 멈춰버린다.

③ 배포와 비용의 딜레마 (Canary 배포는 비싸다)

무중단 배포를 위해 카나리(Canary)나 블루/그린 배포 방식을 흉내 낼 수는 있다.
문제는 비용(리소스)이다. 수동으로 이걸 하려면 구버전과 신버전 서버를 동시에 띄워야 하니 일시적으로 2배의 자원이 필요하다.

결국 “한정된 자원으로, 죽지 않게 관리하고, 효율적으로 배포하려면” 오케스트레이션 도구가 필요하다는 결론에 도달했다.

---

2. 쿠버네티스(Kubernetes)란?

쿠버네티스(이하 k8s)는 구글이 자사의 엄청난 트래픽을 감당하기 위해 만든 ‘Borg’라는 시스템에서 시작되어 오픈소스로 풀린 컨테이너 오케스트레이션 툴이다.

쉽게 말해 “컨테이너 운영 자동화 시스템”이라고 정의할 수 있다.

왜 이름이 쿠버네티스인가?

그리스어로 ‘조타수(항해사)’라는 뜻이다. 로고가 배의 키(Wheel) 모양인 이유다.
개발자가 화물(컨테이너)을 잘 포장해두면, k8s라는 조타수가 이 화물들을 싣고 거친 바다(운영 환경)를 항해하며 목적지까지 안전하게 배달하고 관리해 준다.

---

3. k8s의 강력함 (핵심 기능)

k3s를 설치하고 이것저것 만져보며 “아, 이래서 쓰는구나” 싶었던 핵심 기능 4가지를 정리해 봤다.
특히 리소스 관리 부분은 홈서버 운영자 입장에서 정말 매력적이다.

① 자동 복구 (Self-healing) : 좀비 같은 생명력

k8s에는 Desired State(원하는 상태)라는 중요한 개념이 있다. 단순 재시작을 넘어선다.

• 서버 A가 고장 나면? -> 서버 B에 자동으로 컨테이너를 다시 띄운다.
• 헬스 체크(Health Check)를 통해 앱이 멍청해진 상태(Deadlock)면? -> 알아서 재시작한다.

② 칼 같은 자원 관리와 비용 절감 (Bin Packing)

도커의 단순 제한과 달리, k8s는 Request(최소 요구량)와 Limit(최대 제한량)으로 나누어 관리한다.

• 유연함: 평소엔 적게 쓰다가 바쁠 때만 많이 쓰도록 허용할 수 있다(Burst).
• 효율성(비용 절감): 마치 테트리스를 하듯, 남는 자원 공간에 컨테이너를 촘촘하게 배치해 준다(Bin Packing). 서버 한 대의 성능을 극한으로 뽑아먹을 수 있다.

③ 오토 스케일링 (Auto-scaling)

트래픽이 많아지면 알아서 컨테이너 개수를 늘리고(Scale-out), 밤에 사용자가 줄어들면 다시 개수를 줄여 리소스를 확보한다. 클라우드 환경이라면 이게 바로 비용 절감이다.

④ 효율적인 무중단 배포 (Rolling Update)

k8s는 리소스를 2배로 쓰지 않고도 무중단 배포가 가능하다.
기존 버전(v1)을 하나 줄이고 새 버전(v2)을 하나 늘리는 롤링 업데이트 방식을 통해, 최소한의 여유 자원만으로도 부드럽게 버전을 교체한다.

---

4. 정리: 결국 운영의 효율화

공부하면 할수록 쿠버네티스는 단순한 도구가 아니라 하나의 운영체제(OS) 같다는 느낌을 받는다.

• Docker: 애플리케이션을 ‘포장’하는 기술
• Kubernetes: 포장된 애플리케이션을 ‘효율적으로 배치’하고 ‘관리’하는 기술

홈서버에 올린 k3s도 결국 이 k8s의 가벼운 버전일 뿐, 핵심 원리는 똑같다. 이제 “왜 쓰는지”는 알았으니, 다음 포스팅부터는 “어떻게 생겨먹었는지” 그 내부 구조를 파헤쳐 보려고 한다.

마스터 노드니 워커 노드니 하는 용어들이 튀어나올 텐데, 최대한 쉽게 풀어서 정리해 봐야겠다.

---

이 글은 개인적인 학습 목적으로 작성되었으며, 잘못된 내용이 있다면 댓글로 피드백 부탁드립니다!