실제 쿠버네티스 클러스터를 내 로컬 PC 위의 Docker 컨테이너로 흉내내는 프로그램
도커 컨테이너 안에 쿠버네티스 클러스터를 만들어주는 도구
구조
┌────────────────────────────┐
│ 🖥️ macOS / Windows / Linux │
│ └── Docker Desktop │
│ └── Kind │
│ ├── control-plane (K8s master 역할)
│ └── worker (Pod이 도는 노드)
└────────────────────────────┘
Markdown
복사
Kind가 하는 일은, 도커 컨테이너 몇 개를 쿠버네티스 노드처럼 만들어서 완전한 쿠버네티스 클러스터처럼 동작하게 하는 것!!
구분 | 설명 | 비유 |
Kubernetes | 컨테이너를 여러 서버에 배포하고 관리하는 시스템 | 실제 회사의 서버 운영센터 |
Kind | “그 쿠버네티스 운영센터”를 Docker 컨테이너로 흉내내는 도구 | 회사의 데이터센터를 “가상으로 만들어보는 시뮬레이터” |
•
진짜 클러스터 : 클라우드나 물리 서버에 구축
•
Kind 클러스터 : Docker 위에 가상으로 구축
Kind를 사용하는 이유
쿠버네티스는 원래 서버 여러 대가 필요한 시스템이지만, 개발자가 학습 및 테스트할 때 서버 여러 대를 생성할 수는 없음. 그래서 나온 게 로컬 클러스터 에뮬레이터(종류 다양)
도구 | 설명 | 특징 |
Kind | Docker 위에 K8s 클러스터 | 가볍고 빠름 |
Minikube | VM 위에 K8s 클러스터 | GUI/기능 풍부 |
Docker Desktop (K8s) | Docker에 내장된 K8s | 설정 간단 |
K3s | 경량 쿠버네티스 (리소스 적음) | IoT용 등에서도 사용 |
클러스터 생성
쿠버네티스는 기본 내장 클러스터가 존재하지 않음. 쿠버네티스는 그 자체가 클러스터를 다루는 시스템.
먼저 클러스터를 만들어야 쿠버네티스를 사용 가능 :
환경 | 클러스터 제공 방식 |
로컬 개발환경 | Kind / Minikube / Docker Desktop |
클라우드 | AWS EKS / GCP GKE / Azure AKS |
온프레미스(직접 서버) | kubeadm / kops / RKE 등으로 구축 |
정리하자면 :
개념 | 설명 |
Kubernetes | 컨테이너 오케스트레이션 시스템 (컨테이너 자동 배포·확장·관리) |
Cluster | 여러 노드(서버)가 모여서 쿠버네티스를 구성한 단위 |
Kind | Docker 컨테이너를 이용해 로컬에서 “가짜 클러스터”를 만들어주는 도구 |
기본 클러스터 | 따로 없음. 직접 Kind/Minikube 등으로 생성해야 함 |
Kind vs 실제 쿠버네티스 클러스터
결론
Kind : 로컬 테스트용, 가벼움, 도커 안에서 흉내
실제 클러스터 : 운영용, 고가용성, 네트워크/스토리지 완전 지원
구분 | Kind (로컬) | 실제/프로덕션 k8s |
설치 위치 | Docker 컨테이너 | 물리 서버 / 가상머신 / 클라우드 |
노드 수 | 보통 1~2개 (테스트용) | 수십~수백 노드 가능 |
목적 | 학습, 테스트, CI/CD | 실서비스 운영 |
성능 | 제한적 (호스트 리소스 공유) | 실제 서버 리소스 사용 |
영속성(Persistent Storage) | 제한적 / 가상화 | 실제 볼륨, 네트워크 스토리지 연결 가능 |
네트워크 | Docker NAT / 포트 포워딩 | 실제 LoadBalancer, Ingress, DNS 등 완전 지원 |
고가용성(HA) | 거의 없음 | Control plane + Node 다중화 가능 |
예시 비교
Kind
•
Docker 위에 1~2개 컨테이너 노드
•
Pod 실행, NodePort 테스트 가능
•
포트 접근은 kubectl port-forward 필요
•
학습용, 로컬 CI/CD 테스트용
실제 클러스터
•
AWS EKS / GCP GKE / 사내 데이터센터에 설치
•
Node 여러 대
•
Pod → NodePort / LoadBalancer → 외부 접속 바로 가능
•
PersistentVolume, Ingress, RBAC, 네트워크 정책 등 모두 지원
•
프로덕션 환경 운영
구조 비교 그림
[Kind 로컬 클러스터] [실제 클러스터]
┌───────────────────┐ ┌───────────────────────────────┐
│ macOS / Windows │ │ 클라우드 / 데이터센터 서버 │
│ └─ Docker │ │ │
│ └─ Kind │ │ ┌───── Control Plane ─────┐ │
│ └─ Node │ │ │ API Server / Scheduler │ │
│ └─ Pod │ │ │ Controller Manager │ │
│ │ │ └─────────────────────────┘ │
└───────────────────┘ │ ┌───── Worker Node ────────┐ │
│ │ Pod (nginx, 앱 등) │ │
│ │ Pod (다른 서비스) │ │
│ └─────────────────────────┘ │
│ ┌───── Worker Node ────────┐ │
│ │ Pod │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘
Markdown
복사
주요 차이점 :
구분 | Kind | 실제 클러스터 |
노드 수 | 1~2 (Docker 컨테이너) | 수십~수백 (물리/VM/클라우드) |
외부 접근 | kubectl port-forward 필요 | NodePort, LoadBalancer, Ingress로 바로 접근 가능 |
스토리지 | 로컬 Docker volume | 클라우드 블록 스토리지 / NFS / Ceph 등 사용 가능 |
고가용성 | 거의 없음 | Control plane 다중화, Node 다중화 가능 |
성능/리소스 | 호스트 리소스 공유 | 전용 서버/VM 리소스 사용 |
결론
쿠버네티스는 관리 시스템이고, Kind는 그걸 테스트할 수 있게 도커 위에 만들어주는 가상 실험실