쿠버네티스 도구(Minikube, K3s, Rancher) 비교 및 핵심 개념

Minikube (미니쿠브)

누구에게 적합한가? 쿠버네티스를 처음 배우는 학습자, 개발자

장점: 로컬 PC에 쉽게 설치 가능 (Windows/Mac/Linux 모두 지원), 개발 도구(IntelliJ 등)와 연동 가능
단점: 단일 노드만 지원, 가상화 도구(Docker, VirtualBox) 필요
활용 예시: 내 컴퓨터에서 쿠버네티스 기능 테스트하기

K3s

누구에게 적합한가? 리소스가 제한적인 환경, IoT 장치

장점: 매우 가볍고 빠른 설치, SQLite 사용으로 경량화, 라즈베리파이에서도 실행 가능
단점: 구조가 단순해서 대규모 운영 환경에는 부적합할 수 있음
활용 예시: 사물인터넷(IoT) 프로젝트, 소규모 서비스

Rancher (랜처)

누구에게 적합한가? 기업 환경, 대규모 시스템 운영자

장점: 모니터링/보안 기능 기본 제공, 여러 클러스터 통합 관리, 멀티 클라우드 지원
단점: 상대적으로 무거움, 소규모 환경에는 과할 수 있음
활용 예시: AWS, Azure, GCP 등 여러 클라우드를 동시에 관리

Kubeadm

누구에게 적합한가? 쿠버네티스 전문가, 커스터마이징이 필요한 경우

특징: 기본 클러스터만 구성, 세부 설정은 직접 해야 함
난이도: 높음 (초보자에게는 어려움)
활용 예시: 특정 요구사항에 맞춘 맞춤형 클러스터 구축

매니지드 쿠버네티스 서비스

누구에게 적합한가? 빠른 시작을 원하는 모든 사용자

종류: AWS EKS, Azure AKS, GCP GKE, Samsung SCP
장점: 설치/관리 부담 없음, 클라우드 제공업체가 관리
활용 예시: 프로덕션 환경 빠른 구축

**개념 간 관계도

[개발자] 
   ↓ 작성
[컨테이너 이미지] (예: nginx, mysql)
   ↓ 실행
[컨테이너] → [파드]로 묶임
   ↓
[컨트롤러]가 파드 관리
   ↓
[스케줄러]가 배치 결정
   ↓
[노드]에서 실행

각 개념 자세히 다시 정리

컨테이너 (Container)

비유: 도시락 통

애플리케이션 + 실행에 필요한 모든 것이 하나로 포장됨
Docker 이미지로 만들어짐

예시:
- nginx 컨테이너 = 웹서버
- mysql 컨테이너 = 데이터베이스
- python 앱 컨테이너 = 백엔드 서버

파드 (Pod)

비유: 도시락 가방 (여러 도시락 통을 함께 들고 다님)

왜 필요한가?

컨테이너는 혼자서는 쿠버네티스에서 실행 불가
반드시 파드 안에 들어가야 함

특징:

보통 1개 파드 = 1개 컨테이너
가끔 긴밀하게 협력하는 컨테이너들을 같은 파드에 넣음

예시:
Pod "웹서버파드"
├─ nginx 컨테이너 (메인)
└─ 로그수집 컨테이너 (보조)

중요: 파드는 일시적! 죽으면 새로 만들어짐

컨트롤러 (Controller)

비유: 자동 온도 조절기 (설정 온도 유지)

역할: “항상 원하는 상태를 유지”

주요 컨트롤러 종류:

A. Deployment (디플로이먼트) ⭐ 가장 많이 사용

설정: "nginx 파드 3개를 항상 실행"

실제 상황:
- 파드 1개 죽음 → 자동으로 1개 새로 생성
- 업데이트 필요 → 하나씩 교체 (무중단 배포)

B. ReplicaSet (레플리카셋)

Deployment가 내부적으로 사용
보통 직접 안 만듦

C. DaemonSet (데몬셋)

설정: "모든 노드마다 1개씩 실행"
용도: 모니터링 에이전트, 로그 수집기

D. StatefulSet (스테이트풀셋)

특징: 파드에 고정된 이름/저장소 제공
용도: 데이터베이스처럼 상태를 저장하는 앱

E. Job / CronJob

Job: 한 번만 실행 (예: 데이터 마이그레이션)
CronJob: 주기적 실행 (예: 매일 밤 백업)

스케줄러 (Scheduler)

비유: 택배 배송 센터 (어느 지역으로 보낼지 결정)

역할: 새 파드를 어느 노드(서버)에 배치할지 자동 결정

판단 기준:
✓ 노드에 여유 CPU/메모리 있는가?
✓ 특정 노드에만 배치해야 하는가?
✓ 같은 파드들을 분산해야 하는가?

예시:
파드 생성 요청 → 스케줄러 분석 → "Node-2에 배치!"

전체 흐름 예시

시나리오: nginx 웹서버 3개를 실행하고 싶다

1. 개발자: Deployment 작성
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
   spec:
     replicas: 3  # 3개 유지
     template:
       spec:
         containers:
         - name: nginx
           image: nginx:1.14
   ---

2. 컨트롤러 (Deployment Controller):
   "3개 파드를 만들어야겠군"
   → 파드 3개 생성 요청

3. 스케줄러:
   "Node-1에 여유 많네, 2개 배치"
   "Node-2에 1개 배치"

4. 각 노드에서 파드 실행:
   Node-1: [nginx파드] [nginx파드]
   Node-2: [nginx파드]

5. 만약 Node-1의 파드 1개가 죽으면?
   컨트롤러: "어? 2개밖에 없네, 1개 더 만들자"
   → 스케줄러: "Node-3에 배치"
   → 다시 3개 유지 ✓

Minikube - 깊이 파기

내부 동작 원리

[내 컴퓨터]
  └─ [가상머신 (VirtualBox/Docker)]
       └─ [리눅스 OS]
            └─ [쿠버네티스 클러스터]
                 ├─ Control Plane (마스터)
                 └─ Worker Node (실제로는 같은 머신)
```

**핵심 포인트**:
- 실제로는 **가상머신 1개**를 만들어서 그 안에 쿠버네티스를 설치
- Control Plane + Worker가 **한 노드에 함께** 존재 (실제 환경과 다름)

### 💡 **왜 가상화가 필요한가?**
```
문제: 쿠버네티스는 원래 리눅스 환경 전용
해결: Windows/Mac에서는 가상머신으로 리눅스 환경 구축

필요한 가상화 도구:
- Docker Desktop (Docker 드라이버)
- VirtualBox (VirtualBox 드라이버)
- Hyper-V (Windows 전용)
- VMware (VMware 드라이버)

실무 관점: 언제 사용하나?

적합한 경우:

쿠버네티스 명령어 연습
로컬에서 앱 개발/테스트
CI/CD 파이프라인 테스트
쿠버네티스 인증 시험 (CKA/CKAD) 준비

부적합한 경우:

다중 노드 클러스터 테스트 (노드 장애, 네트워크 분리 등)
고가용성(HA) 구성 실습
실제 부하 테스트

추가 학습 포인트

# Minikube 명령어 예시
minikube start --driver=docker    # Docker로 시작
minikube start --nodes=3           # ❌ 가능하지만 모두 가상노드
minikube dashboard                 # 웹 UI 자동 실행
minikube addons enable ingress     # 부가 기능 쉽게 활성화

질문: “IntelliJ와 연동”이 뭘 의미하나? → 코드 수정하면 자동으로 컨테이너 빌드 → 미니쿠브에 배포 → 결과 바로 확인

K3s - 깊이 파기

경량화의 비밀

아티클의 다이어그램을 분석하면:

일반 쿠버네티스:
├─ ETCD (클러스터 정보 저장, 별도 프로세스)
├─ API Server
├─ Scheduler
├─ Controller Manager
└─ 각각 독립 프로세스로 실행

K3s:
└─ 단일 실행 파일 (약 70MB!)
    ├─ SQLite (ETCD 대체) ← 핵심!
    ├─ API Server
    ├─ Scheduler
    └─ Controller Manager (모두 하나로 통합)

ETCD → SQLite 변경의 의미

ETCD란?

쿠버네티스의 “두뇌” (모든 상태 정보 저장)
분산 데이터베이스 (클러스터로 구성, 고가용성)
메모리 사용량 큼

SQLite 사용 시:

장점:
✓ 단일 파일 DB (설정 간단)
✓ 메모리 사용량 1/10 수준
✓ 설치 과정 불필요

단점:
✗ 고가용성 구성 어려움
✗ 대규모 클러스터 부적합 (수백 개 노드)
✗ 성능 한계 명확

📊 실무 관점: K3s의 실제 사용 사례

예시 1: IoT 엣지 컴퓨팅

시나리오: 공장 현장 100곳에 각각 소형 서버 설치
요구사항: 
- 각 서버는 저사양 (라즈베리파이 수준)
- 중앙에서 관리 필요
- 네트워크 단절 시에도 동작

해결책: K3s 설치
- 메모리 512MB로도 실행 가능
- 각 현장이 독립적으로 동작

예시 2: 개발/테스트 환경

문제: 팀원 10명이 각자 쿠버네티스 환경 필요
기존 방법: Minikube → 무겁고 느림
K3s 방법: 
- 각자 로컬 PC에 K3s 설치 (5분 완료)
- 실제 쿠버네티스와 거의 동일한 환경

🎓 아티클의 “높은 호환성” 의미

호환성 = Kubernetes Conformance Test 통과

의미:
✓ 표준 kubectl 명령어 모두 사용 가능
✓ Helm 차트 그대로 사용 가능
✓ 쿠버네티스 API 100% 호환
✓ 다른 도구로 마이그레이션 쉬움

단, 내부 구현은 다름:
- 컨테이너 런타임: containerd (고정)
- 네트워크 플러그인: Flannel (기본)
- Ingress 컨트롤러: Traefik (내장)

3️⃣ Rancher - 깊이 파기

🔍 “관리 플랫폼”의 의미 분석

아티클 다이어그램의 핵심:

[Rancher] = 쿠버네티스를 관리하는 쿠버네티스!

구조:
Rancher 자체도 쿠버네티스 클러스터 위에서 실행됨
    ↓ 관리
Target Cluster 1 (GKE - Google)
Target Cluster 2 (EKS - AWS)
Target Cluster 3 (RKE - 온프레미스)

💡 “마켓 플레이스”의 실체

Rancher Catalog = Helm Chart 저장소

클릭 한 번으로 설치되는 것들:
├─ Monitoring (Prometheus + Grafana)
├─ Logging (ELK Stack)
├─ Service Mesh (Istio)
├─ CI/CD (Jenkins, GitLab)
└─ Backup (Velero)

내부 동작:
1. 사용자가 "Prometheus" 선택
2. Rancher가 Helm Chart 다운로드
3. 자동으로 values.yaml 구성
4. 타겟 클러스터에 배포
5. 대시보드에 연동

📊 실무 관점: 언제 “무겁다”가 문제가 되나?

Rancher 자체 리소스 사용량:

최소 요구사항:
- CPU: 4 core
- Memory: 8GB
- 스토리지: 50GB

실제 사용량 (중규모):
- Rancher Server: 2-4GB 메모리
- Monitoring Stack: 4-8GB 메모리
- Logging Stack: 2-4GB 메모리
───────────────────────────────
총: 8-16GB 메모리 필요

문제 상황 예시:

시나리오 1: 스타트업, 작은 클러스터
클러스터 전체: 노드 3개 (각 4GB RAM)
→ Rancher에만 절반 이상 메모리 사용
→ 실제 앱 실행 공간 부족!

시나리오 2: 단일 서비스만 운영
→ Monitoring/Logging 필요 없는데 기본 설치됨
→ 리소스 낭비

🎓 “멀티 클라우드 관리”의 실전 의미

실제 사용 케이스:

상황: 기업이 AWS + GCP 동시 사용
이유: 
- AWS: 주요 서비스 (계약 체결)
- GCP: 빅데이터 분석 (BigQuery 활용)

Rancher 없으면:
- AWS Console 로그인 → EKS 관리
- GCP Console 로그인 → GKE 관리
- 두 곳 다 kubectl 설정 변경

Rancher 있으면:
- Rancher UI 하나에서
- 클러스터 선택 → 즉시 전환
- 통합 모니터링, 통합 로깅
- 통합 사용자 권한 관리

4️⃣ kubeadm - 깊이 파기

🔍 “세부 구성 요소 직접 설정”의 의미

다른 도구들:
설치 버튼 → 완성 ✓

kubeadm:
1. 서버 준비 (OS 설치)
2. 컨테이너 런타임 설치 (Docker/containerd)
3. kubeadm, kubelet, kubectl 설치
4. kubeadm init (마스터 노드 초기화)
5. 네트워크 플러그인 수동 설치 (Calico/Flannel)
6. kubeadm join (워커 노드 추가)
7. 스토리지 클래스 수동 설정
8. Ingress 컨트롤러 수동 설치
9. 모니터링 직접 구축

💡 왜 이렇게 복잡하게?

실무 시나리오:

요구사항:
- 특정 컨테이너 런타임 사용 (cri-o)
- 특정 네트워크 정책 (Calico with BGP)
- 특정 보안 요구사항 (PSP 설정)
- 온프레미스 환경 (인터넷 제한)

→ 사전 패키지 도구로는 불가능
→ kubeadm으로 하나하나 커스터마이징

📊 kubeadm vs 다른 도구 비교

기능	Minikube	K3s	Rancher	kubeadm
네트워크 플러그인 선택	❌ 고정	⚠️ 제한적	⚠️ 제한적	✅ 자유
컨테이너 런타임 선택	❌ 고정	❌ containerd	⚠️ 제한적	✅ 자유
ETCD 구성 변경	❌ 불가	❌ SQLite 고정	⚠️ 제한적	✅ 자유
인증서 관리	❌ 자동	❌ 자동	❌ 자동	✅ 수동

5️⃣ 매니지드 서비스 - 깊이 파기

🔍 “관리까지 해준다”의 실체

사용자가 관리하는 것:
├─ Worker Node (VM)
│   ├─ OS 업데이트
│   ├─ kubelet 업데이트
│   └─ 리소스 모니터링
└─ 애플리케이션 (Pod, Service 등)

클라우드가 관리하는 것:
├─ Control Plane ← 핵심!
│   ├─ API Server (고가용성)
│   ├─ ETCD (백업/복구)
│   ├─ Scheduler
│   └─ Controller Manager
└─ 업그레이드 (버튼 클릭만)

💡 Control Plane 관리의 복잡성

직접 관리 시 (kubeadm):

1. ETCD 백업 (매일 자동화 스크립트 작성)
2. ETCD 장애 시 복구 절차
3. API Server 인증서 갱신 (만료 전)
4. 쿠버네티스 버전 업그레이드:
   - Control Plane 먼저
   - Worker Node 하나씩
   - 롤백 계획 수립
5. 보안 패치 적용

매니지드 서비스:

1. 버전 선택 → [업그레이드] 버튼 클릭
2. 끝

📊 비용 vs 편의성 분석

EKS 예시 (AWS):
- Control Plane: $0.10/시간 ($72/월)
- Worker Node: EC2 비용 (직접 관리와 동일)

자체 구축 시 숨은 비용:
- 엔지니어 인건비 (월 수백만원)
- 장애 대응 시간
- 학습 비용
- 실수로 인한 장애 리스크

결론: 대부분의 경우 매니지드 서비스가 저렴

6️⃣ “Kubernetes the Hard Way” - 깊이 파기

🔍 왜 “어려운 방법”이 중요한가?

실무 장애 사례:

장애: API Server 응답 없음
증상: kubectl 명령어 모두 실패

kubeadm만 아는 사람:
→ "재시작해봐야겠다" (무작정)

Hard Way 실습한 사람:
→ 원인 추적:
   1. API Server 로그 확인
   2. ETCD 상태 확인 ← 여기서 문제 발견
   3. ETCD 인증서 만료 확인
   4. 인증서 갱신 → 해결

💡 각 구성 요소를 직접 설정하는 의미

인증서 체계:

쿠버네티스는 모든 통신이 TLS 암호화

생성해야 하는 인증서:
├─ CA 인증서 (루트)
├─ API Server 인증서
├─ ETCD 인증서
├─ kubelet 인증서
└─ 사용자 인증서

Hard Way로 배우는 것:
- 각 인증서의 역할
- 만료 시 증상
- 갱신 방법
- 문제 해결 능력

🎓 실무 활용도

CKA/CKAD 인증 시험:
→ Hard Way 수준의 지식 필요

시니어 쿠버네티스 엔지니어:
→ 대부분 Hard Way 경험자

커리어 패스:
1단계: Minikube로 시작
2단계: 매니지드 서비스로 실무
3단계: Hard Way로 깊이 학습
4단계: 복잡한 온프레미스 환경 운영 가능

🎯 실전 선택 가이드

상황별 최적 도구

Q1: 혼자 쿠버네티스 처음 배울 때?
→ Minikube (의심의 여지 없음)

Q2: 팀 개발 환경 구축?
→ K3s (가볍고 빠름) 또는 매니지드 서비스

Q3: 스타트업 프로덕션 환경?
→ 매니지드 서비스 (EKS/GKE/AKS)

Q4: 대기업, 여러 클라우드 사용?
→ Rancher

Q5: 금융권, 보안 요구사항 많음?
→ kubeadm (또는 Red Hat OpenShift)

Q6: 쿠버네티스 전문가 되고 싶음?
→ 1) Minikube → 2) 매니지드 서비스 → 3) Hard Way

1.왜 K3s는 SQLite를 사용하는데도 “호환성”이 높을까요?

쿠버네티스 API는 표준화되어 있고, 데이터 저장 방식은 내부 구현일 뿐입니다. 2.Rancher가 “무겁다”는 것이 왜 단점일까요? 기능이 많은 건 좋은 거 아닌가요?
필요 없는 기능도 리소스를 차지하고, 복잡도가 올라갑니다. 3.매니지드 서비스를 사용하면서도 kubeadm 지식이 필요한 이유는?
Worker Node는 직접 관리해야 하고, 깊은 트러블슈팅이 필요합니다.

작성일: 2025-11-04

Quartz 4

탐색기