GitHub

최근 집에 구비해놓은 미니 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의 가벼운 버전일 뿐, 핵심 원리는 똑같다. 이제 “왜 쓰는지”는 알았으니, 다음 포스팅부터는 “어떻게 생겨먹었는지” 그 내부 구조를 파헤쳐 보려고 한다.

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

📂 [시리즈] 쿠버네티스(k8s) 기초 완전 정복

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

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