시리즈 안내
이 글은 “중소기업 쿠버네티스 구축” 시리즈의 0편입니다. 여기서는 손으로 무언가를 설치하지 않습니다. 대신 쿠버네티스가 무엇이고, 우리 회사에 정말 필요한지를 먼저 따져봅니다. 실제 클러스터 구축은 다음 편(01. 클러스터 아키텍처 설계)부터 시작합니다.
들어가며
서버 한두 대로 서비스를 돌리던 시절에는 배포가 단순했습니다. SSH로 접속해서 코드를 내려받고, 프로세스를 재시작하면 끝이었죠. 그런데 서비스가 늘어나고, 프론트엔드·API·DB·캐시·오브젝트 스토리지가 제각기 따로 놀기 시작하면 이야기가 달라집니다.
- A 서버가 죽으면 누가 대신 띄워주나?
- 트래픽이 몰리면 어떻게 늘리고, 빠지면 어떻게 줄이나?
- “지금 운영에 떠 있는 게 정확히 어떤 버전이지?”에 자신 있게 답할 수 있나?
이 질문들에 사람이 손으로 답하는 대신 시스템이 알아서 답하게 만드는 것 — 그게 쿠버네티스가 하는 일입니다.
이 시리즈는 거창한 클라우드 네이티브 이론서가 아닙니다. 중소기업 규모에서, 가진 VM 몇 대로, 실제로 돌아가는 클러스터를 처음부터 끝까지 세우는 기록입니다. 0편인 이 글에서는 그 여정을 시작하기 전에 꼭 짚어야 할 개념과 판단 기준을 정리합니다.
1. 컨테이너부터: 쿠버네티스 이전의 이야기
쿠버네티스를 이해하려면 먼저 컨테이너를 알아야 합니다.
전통적인 방식에서는 애플리케이션을 실행하려면 서버에 OS, 런타임(Java·Node 등), 라이브러리, 환경 변수를 일일이 맞춰야 했습니다. “내 PC에서는 되는데 서버에서는 안 돼요”라는 악명 높은 문제가 여기서 나옵니다.
컨테이너(대표적으로 Docker)는 애플리케이션과 그 실행에 필요한 모든 것을 하나의 이미지로 묶어 이 문제를 해결합니다. 어디서 실행하든 동일하게 동작하는, 가볍고 격리된 실행 단위죠. 가상 머신(VM)이 OS 전체를 통째로 복제하는 것과 달리, 컨테이너는 호스트 OS의 커널을 공유하기 때문에 훨씬 가볍고 빠릅니다.
여기까지는 좋습니다. 그런데 컨테이너가 수십, 수백 개가 되면 새로운 문제가 생깁니다.
- 어느 서버에 어떤 컨테이너를 띄울까? (스케줄링)
- 컨테이너가 죽으면 누가 다시 띄울까? (자가 치유)
- 컨테이너끼리 어떻게 서로를 찾고 통신할까? (서비스 디스커버리)
- 무중단으로 새 버전을 배포하려면? (롤링 업데이트)
이 “여러 컨테이너를 관리·조율하는 문제”를 풀어주는 것이 컨테이너 오케스트레이션이고, 그 사실상의 표준이 쿠버네티스입니다.
2. 쿠버네티스란 무엇인가
쿠버네티스(Kubernetes, 줄여서 K8s — k와 s 사이에 8글자가 있어서 붙은 이름입니다)는 구글이 내부에서 쓰던 컨테이너 관리 시스템을 오픈소스로 공개한 데서 출발했습니다. 지금은 클라우드 네이티브 생태계의 중심이 되었죠.
핵심 아이디어는 선언적 관리(Declarative Management)입니다.
전통적인 운영은 “이 명령을 실행하고, 그다음 저 명령을 실행하라”는 절차적(how) 방식입니다. 반면 쿠버네티스는 “나는 이 앱이 항상 3개 떠 있길 원한다”는 원하는 상태(what)만 선언하면, 시스템이 알아서 그 상태를 유지합니다. 컨테이너 하나가 죽으면? 쿠버네티스가 알아서 새로 띄워 3개를 맞춥니다. 사람이 새벽에 일어나 서버를 재시작할 필요가 없습니다.
쿠버네티스가 기본으로 제공하는 것들
| 기능 | 설명 |
|---|---|
| 자가 치유 | 죽은 컨테이너를 자동 재시작, 응답 없는 컨테이너 교체 |
| 자동 스케일링 | 부하에 따라 컨테이너 수를 늘리고 줄임 |
| 서비스 디스커버리 | 컨테이너끼리 이름으로 서로를 찾고 부하 분산 |
| 롤링 업데이트/롤백 | 무중단 배포, 문제 시 이전 버전으로 되돌리기 |
| 선언적 구성 | 원하는 상태를 YAML로 정의 → Git으로 버전 관리 가능 |
| 스토리지 추상화 | 로컬·NFS·클라우드 스토리지를 동일한 방식으로 연결 |
말로만 들으면 “마법 같다” 싶지만, 공짜는 아닙니다. 이 모든 기능을 쓰려면 그만한 복잡성을 감당해야 합니다. 바로 이 지점이 도입 판단의 핵심입니다.
3. 쿠버네티스는 어떤 기업에 어울리는가
쿠버네티스는 강력하지만, 모든 회사에 정답은 아닙니다. 솔직하게 양쪽을 다 봅시다.
도입이 잘 맞는 경우
- 여러 개의 서비스(마이크로서비스)를 운영한다. 프론트엔드, 여러 API, 인증 서버, 결제 서비스처럼 독립적으로 배포·확장해야 하는 컴포넌트가 많을수록 쿠버네티스의 가치가 커집니다.
- 무중단 배포와 빠른 롤백이 중요하다. 배포가 잦고, 실패 시 즉시 되돌려야 하는 서비스라면 롤링 업데이트가 큰 무기입니다.
- 트래픽 변동이 크다. 평소엔 한가하다가 특정 시간에 몰리는 패턴이면 자동 스케일링이 비용과 안정성을 동시에 잡아줍니다.
- 인프라를 코드로 관리하고 싶다. 모든 구성을 YAML로 선언하고 Git에 두면, 인프라 변경 이력이 코드 리뷰처럼 남습니다. (이 시리즈 후반의 GitOps가 이 지점입니다.)
- 여러 환경(dev/staging/prod)을 일관되게 운영한다. 동일한 매니페스트로 환경만 바꿔 배포하면 “개발에선 됐는데 운영에선 안 돼요”가 줄어듭니다.
도입이 과한 경우 (오버엔지니어링)
- 단순한 모놀리식 앱 하나만 돌린다. 서비스가 1~2개뿐이고 배포도 가끔이라면, 쿠버네티스의 복잡성이 얻는 것보다 큽니다. 차라리 단일 서버 + Docker Compose나 관리형 PaaS가 낫습니다.
- 운영 인력이 매우 적고 학습 여력이 없다. 쿠버네티스는 배워야 할 개념(Pod, Service, Ingress, PV/PVC, ConfigMap…)이 많습니다. 이걸 감당할 사람이 없으면 오히려 장애 대응이 더 어려워집니다.
- 트래픽이 일정하고 작다. 스케일링이 필요 없는 규모라면 핵심 이점 하나가 사라집니다.
그래서 중소기업은?
중소기업은 보통 “마이크로서비스를 몇 개 운영하긴 하는데, 거대 IT 기업처럼 전담 인프라팀은 없는” 애매한 중간 지대에 있습니다. 풀스택 쿠버네티스(vanilla K8s)는 운영 부담이 크고, 그렇다고 단일 서버로 돌리기엔 서비스가 여럿이라 손이 많이 가죠.
이 중간 지대를 위한 답이 다음 절의 K3s입니다.
4. K8s vs K3s: 왜 우리는 K3s를 골랐는가
쿠버네티스를 설치하는 방법(배포판)은 여러 가지입니다. 대표적으로 셋을 비교했습니다.
| 배포판 | 특징 | 적합한 곳 |
|---|---|---|
| kubeadm | 정통 vanilla 쿠버네티스. 모든 컴포넌트를 직접 구성 | 대규모, 전담 인프라팀 보유 |
| K3s | 경량 쿠버네티스. 단일 바이너리, 설치 간단, 리소스 절약 | 홈랩·엣지·중소 규모 |
| RKE2 | 보안 강화형(정부/규제 환경 대응) | 보안 컴플라이언스가 핵심인 곳 |
이 시리즈에서는 K3s를 선택했습니다. 이유는 명확합니다.
K3s는 Rancher(SUSE)가 만든 경량 쿠버네티스 배포판으로, 쿠버네티스의 핵심 기능은 그대로 유지하면서 군더더기를 걷어냈습니다.
- 단일 바이너리, 설치가 간단하다. vanilla K8s는 etcd, API server, controller-manager, scheduler를 각각 구성해야 하지만, K3s는 명령어 한 줄로 컨트롤 플레인이 뜹니다.
- 리소스를 적게 먹는다. 메모리 footprint가 작아 8GB 마스터 노드에서도 여유 있게 돌아갑니다. 중소기업의 제한된 VM 자원에 딱 맞습니다.
- 필요한 건 다 있고, 불필요한 건 끌 수 있다. K3s는 기본 로드밸런서(servicelb)와 인그레스(traefik)를 내장하지만, 우리는 이걸 끄고 MetalLB + Ingress-NGINX 조합으로 대체할 겁니다. 이 유연함이 K3s의 장점입니다. (자세한 건 03편에서.)
- 완전한 쿠버네티스다. “경량”이라고 기능이 빠진 게 아닙니다. 표준 쿠버네티스 API를 그대로 쓰므로, 나중에 vanilla K8s로 옮겨도 매니페스트는 거의 그대로 통합니다.
정리하면, 중소기업이 vanilla K8s의 운영 부담 없이 쿠버네티스의 이점을 누리기에 K3s가 가장 합리적인 출발점이라는 판단입니다.
5. 이 시리즈에서 만들 것
말로만 개념을 설명하면 와닿지 않으니, 우리가 실제로 세울 결과물을 미리 그려보겠습니다. 전체 트래픽 경로는 이렇게 흐릅니다.
[외부 클라이언트]
│ HTTPS (와일드카드 인증서)
▼
[OPNsense + Caddy] ← TLS 종단 + 내부 DNS (이전 "네트워크 구축" 시리즈에서 구성)
│ HTTP
▼
[MetalLB VIP] ← 클러스터의 진입 IP를 발급
│
▼
[Ingress-NGINX] ← 도메인(Host 헤더)으로 어느 서비스에 보낼지 라우팅
│
▼
[Service → Pod] ← 실제 애플리케이션 컨테이너
│ (레거시 DB 호출 시)
▼
[레거시 인프라] ← OPNsense SNAT로 연결이 경로를 완성하기 위해, 앞으로 다음 순서로 진행합니다.
- 01. 클러스터 아키텍처 설계 — 4대 VM(마스터 1 + 워커 3)을 어떻게 나누고, IP는 어떻게 할당할지
- 02. OS 사전 준비 — 전 노드 공통 세팅(swap off, 시간 동기화, 커널 모듈 등)
- 03. K3s 부트스트랩 — 마스터 설치와 워커 조인, 노드 역할 분리
- 04. 스토리지와 로드밸런서 — local-path와 MetalLB
- 05. Ingress와 TLS 연동 — 외부 노출 완성
- 06. 웹 대시보드 — Headlamp로 클러스터 시각화
- 07. GitOps 배포 자동화 — ArgoCD 도입 (그리고 “꼭 필요한가?”에 대한 답)
- 08. 오브젝트 스토리지 — MinIO + NFS
- 09. 워크로드와 레거시 연동 — 실전 트러블슈팅
이 시리즈는 앞선 “중소기업 네트워크 구축” 시리즈에서 만든 OPNsense·Caddy·Unbound DNS 환경을 토대로 합니다. 네트워크 기반이 이미 있다는 전제이지만, 쿠버네티스 자체에 집중하므로 그 부분을 모르더라도 따라오는 데 큰 무리는 없습니다.
마치며
0편에서는 손에 흙을 묻히기 전에 큰 그림을 그렸습니다. 핵심을 다시 정리하면:
- 컨테이너가 “어디서든 똑같이 도는 실행 단위”를 만들어줬고, 쿠버네티스는 그 컨테이너 수십·수백 개를 자동으로 관리·조율해줍니다.
- 쿠버네티스의 본질은 선언적 관리 — “원하는 상태”를 선언하면 시스템이 그 상태를 유지합니다.
- 다만 만능은 아닙니다. 서비스가 여럿이고 배포가 잦고 인프라를 코드로 관리하고 싶다면 강력한 무기지만, 단순한 단일 앱에는 과합니다.
- 중소기업에는 vanilla K8s의 부담 없이 핵심 이점을 누리는 K3s가 합리적인 선택입니다.
다음 편에서는 본격적으로 클러스터 아키텍처를 설계합니다. VM을 몇 대로, 어떤 사양으로, 어떻게 역할을 나눌지 — 실제 숫자를 가지고 이야기하겠습니다.
다음 글: 중소기업 쿠버네티스 구축 – 01. 클러스터 아키텍처 설계: 4-노드 VM 구성 (master·worker·IP 정책)
