Kubernetes 클러스터 유형 완전 가이드

Kubernetes를 처음 도입할 때 가장 먼저 결정해야 할 것이 클러스터 유형입니다. 그런데 많은 팀이 이 결정을 충분히 생각하지 않고 넘어갑니다. 개발 환경에서 쓰던 minikube를 프로덕션에 올리거나, 반대로 처음부터 복잡한 HA 구성을 도입해 운영 부담을 키우는 경우가 대표적입니다.

클러스터 유형은 단순히 노드 수의 문제가 아닙니다. 컨트롤 플레인 구성, 가용성 목표, 운영 책임 범위, 비용 구조까지 함께 결정됩니다. 이 글은 각 유형의 구조와 트레이드오프를 실무 관점에서 정리합니다.

클러스터의 핵심 구성 요소

유형별 차이를 이해하기 전에 Kubernetes 클러스터가 어떤 요소로 이루어지는지 먼저 봐야 합니다.

┌─────────────────────────────────────────────────┐
│                  Control Plane                  │
│  ┌──────────┐  ┌──────────┐  ┌───────────────┐  │
│  │ API      │  │ etcd     │  │ Scheduler     │  │
│  │ Server   │  │ (상태 저장) │  │ Controller Mgr│  │
│  └──────────┘  └──────────┘  └───────────────┘  │
└─────────────────────────────────────────────────┘
         │               │               │
┌────────┴──┐    ┌───────┴───┐    ┌──────┴────┐
│  Worker   │    │  Worker   │    │  Worker   │
│  Node 1   │    │  Node 2   │    │  Node 3   │
│  (kubelet)│    │  (kubelet)│    │  (kubelet)│
└───────────┘    └───────────┘    └───────────┘

API Server: 모든 요청의 진입점. kubectl, 내부 컴포넌트 모두 API Server를 통해 통신
etcd: 클러스터 전체 상태를 저장하는 분산 key-value 스토어. 이것이 죽으면 클러스터가 죽음
Scheduler: 새로운 Pod를 어느 노드에 배치할지 결정
Controller Manager: Deployment, ReplicaSet 등 원하는 상태를 유지하는 루프 실행
kubelet: 각 Worker Node에서 Pod를 실제 실행하는 에이전트

클러스터 유형의 차이는 결국 컨트롤 플레인을 얼마나, 어디에, 어떻게 두느냐의 차이입니다.

유형 1: 단일 노드 클러스터

컨트롤 플레인과 워커 역할을 하나의 노드가 동시에 수행합니다. 프로덕션 목적이 아닌 개발, 학습, 로컬 테스트에 적합합니다.

┌──────────────────────────┐
│     Single Node          │
│  Control Plane + Worker  │
│  ┌──────┐  ┌──────────┐  │
│  │etcd  │  │ kubelet  │  │
│  └──────┘  └──────────┘  │
└──────────────────────────┘

대표 도구

도구	특징	적합 상황
minikube	VM/컨테이너 위에 단일 노드 구성. 멀티노드 실험도 가능	로컬 개발, Kubernetes 학습
kind (Kubernetes IN Docker)	Docker 컨테이너로 노드를 시뮬레이션. CI에 적합	CI 파이프라인 통합 테스트
k3s (단일 노드 모드)	초경량 배포판. 실제 엣지/IoT 환경에도 사용	리소스 제한 환경, 엣지 컴퓨팅

minikube 빠른 시작

# 설치 (macOS)
brew install minikube

# 클러스터 시작
minikube start --cpus 4 --memory 8192

# 멀티노드 시뮬레이션
minikube start --nodes 3 --driver docker

# 상태 확인
minikube status
kubectl get nodes

트레이드오프

가용성 없음. 노드 하나가 죽으면 클러스터 전체 중단
빠른 시작과 낮은 비용
프로덕션 절대 비권장

유형 2: 단일 컨트롤 플레인 클러스터

컨트롤 플레인 노드 1개 + 워커 노드 N개 구성입니다. 소규모 팀이나 비핵심 프로덕션 환경에서 사용합니다.

┌──────────────────────┐
│   Control Plane (1)  │
│  API / etcd / 스케줄러 │
└──────────┬───────────┘
           │
    ┌──────┴──────┐
    │             │
┌───┴───┐   ┌────┴──┐
│Worker1│   │Worker2│
└───────┘   └───────┘

kubeadm으로 구성하기

# 컨트롤 플레인 노드에서 초기화
kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=<CONTROL_PLANE_IP>

# kubeconfig 설정
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# CNI 플러그인 설치 (Flannel 예시)
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

# 워커 노드 조인 (kubeadm init 출력 결과의 join 커맨드 사용)
kubeadm join <CONTROL_PLANE_IP>:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<HASH>

트레이드오프

컨트롤 플레인이 단일 장애점(SPOF). etcd 장애 = 클러스터 운영 불가
구성이 단순해 관리 부담이 낮음
개발팀 내부 도구, 비핵심 서비스에는 수용 가능한 수준

유형 3: 고가용성(HA) 클러스터

컨트롤 플레인을 3개 이상의 홀수 노드로 구성합니다. etcd 쿼럼을 유지하기 위해 반드시 홀수여야 합니다. 프로덕션 환경의 표준입니다.

         ┌─────────────────────────────────────┐
         │         Load Balancer               │
         └──────────┬──────────────────────────┘
                    │
       ┌────────────┼────────────┐
       │            │            │
┌──────┴─────┐ ┌────┴──────┐ ┌──┴────────┐
│Control     │ │Control    │ │Control    │
│Plane 1     │ │Plane 2    │ │Plane 3    │
│(etcd + API)│ │(etcd + API)│ │(etcd + API)│
└──────┬─────┘ └────┬──────┘ └──┬────────┘
       │            │            │
       └────────────┼────────────┘
                    │
       ┌────────────┼────────────┐
       │            │            │
  ┌────┴────┐  ┌────┴────┐  ┌───┴─────┐
  │Worker 1 │  │Worker 2 │  │Worker 3 │
  └─────────┘  └─────────┘  └─────────┘

etcd 쿼럼 이해

etcd는 Raft 합의 알고리즘을 사용합니다. 클러스터가 정상 동작하려면 과반수 노드가 살아 있어야 합니다.

etcd 노드 수	허용 장애 수	비고
1	0	HA 아님
3	1	최소 HA 구성
5	2	대규모 프로덕션 권장
7	3	매우 큰 규모 또는 멀티 데이터센터

짝수 구성(4, 6개)은 허용 장애 수가 홀수 대비 늘지 않으면서 노드만 추가되므로 불필요합니다.

kubeadm으로 HA 구성

# 첫 번째 컨트롤 플레인 초기화
kubeadm init \
  --control-plane-endpoint "LOAD_BALANCER_DNS:6443" \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

# 출력된 join 커맨드로 두 번째, 세 번째 컨트롤 플레인 추가
kubeadm join LOAD_BALANCER_DNS:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<HASH> \
  --control-plane \
  --certificate-key <CERT_KEY>

# 워커 노드 추가
kubeadm join LOAD_BALANCER_DNS:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<HASH>

로드 밸런서 요구사항

컨트롤 플레인 앞단의 로드 밸런서는 6443 포트(API Server)를 대상으로 합니다. 헬스체크는 TCP 또는 HTTPS /healthz 엔드포인트를 씁니다.

# HAProxy 예시
frontend kubernetes-apiserver
    bind *:6443
    mode tcp
    option tcplog
    default_backend kubernetes-apiserver

backend kubernetes-apiserver
    mode tcp
    balance roundrobin
    option tcp-check
    server cp1 192.168.1.11:6443 check
    server cp2 192.168.1.12:6443 check
    server cp3 192.168.1.13:6443 check

유형 4: 관리형 클러스터 (Managed Kubernetes)

클라우드 제공자가 컨트롤 플레인을 관리합니다. 사용자는 워커 노드(노드 그룹)만 관리합니다.

┌─────────────────────────────────────┐
│  Cloud Provider (AWS / GCP / Azure) │
│  ┌───────────────────────────────┐  │
│  │  Control Plane (관리됨)        │  │
│  │  API Server / etcd / 스케줄러  │  │
│  └───────────────────────────────┘  │
└───────────────┬─────────────────────┘
                │ 사용자가 관리
       ┌────────┴────────┐
       │                 │
  ┌────┴────┐       ┌────┴────┐
  │Node     │       │Node     │
  │Group A  │       │Group B  │
  │(일반)   │       │(GPU)    │
  └─────────┘       └─────────┘

주요 관리형 서비스 비교

서비스	제공자	특징
EKS (Elastic Kubernetes Service)	AWS	Fargate 지원, IAM 통합, AWS 생태계 친화적
GKE (Google Kubernetes Engine)	GCP	Autopilot 모드, 업그레이드 자동화 성숙도 높음
AKS (Azure Kubernetes Service)	Azure	Azure AD 통합, Windows 노드 지원
OKE (Oracle Container Engine)	Oracle Cloud	비용 경쟁력, Oracle DB 연동

EKS 클러스터 생성 (eksctl)

# eksctl 설치
brew install eksctl

# 클러스터 생성
eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-2 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5 \
  --managed

# kubeconfig 업데이트
aws eks update-kubeconfig \
  --region ap-northeast-2 \
  --name my-cluster

EKS 노드 그룹 분리 전략

# 일반 워크로드용 노드 그룹
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: ap-northeast-2

nodeGroups:
  - name: general
    instanceType: t3.large
    minSize: 2
    maxSize: 10
    labels:
      role: general

  - name: gpu-workers
    instanceType: g4dn.xlarge
    minSize: 0
    maxSize: 4
    labels:
      role: gpu
    taints:
      - key: nvidia.com/gpu
        value: "true"
        effect: NoSchedule

GKE Autopilot vs Standard

GKE는 두 가지 운영 모드를 제공합니다.

항목	Standard	Autopilot
노드 관리	사용자 직접	GCP 완전 관리
비용 기준	노드 프로비저닝	실제 Pod 요청 리소스
커스터마이징	높음	제한적
운영 부담	중간	낮음
권장 상황	세밀한 제어 필요 시	빠른 도입, 소규모 팀

관리형 클러스터 트레이드오프

장점

컨트롤 플레인 HA 및 업그레이드를 클라우드 제공자가 처리
클라우드 서비스(로드 밸런서, 스토리지, IAM)와 자연스럽게 통합
운영 초기 진입 장벽이 낮음

단점

컨트롤 플레인 커스터마이징 제한
클라우드 제공자 락인 가능성
장기적으로 온프레미스 대비 비용이 높을 수 있음

유형 5: 온프레미스 클러스터

자체 서버에 Kubernetes를 직접 설치하고 운영합니다. 보안 요구사항, 규제, 비용 최적화 등이 주요 동기입니다.

주요 배포 방식

kubeadm — 가장 표준적인 방식

# 모든 노드에서 사전 준비
swapoff -a
modprobe br_netfilter

cat <<EOF | tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
sysctl --system

# containerd 설치 후 kubeadm, kubelet, kubectl 설치
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

k3s — 경량 배포판 (50MB 미만 단일 바이너리)

# 서버(컨트롤 플레인) 설치
curl -sfL https://get.k3s.io | sh -

# 노드 토큰 확인
cat /var/lib/rancher/k3s/server/node-token

# 에이전트(워커) 노드 추가
curl -sfL https://get.k3s.io | K3S_URL=https://<SERVER_IP>:6443 \
  K3S_TOKEN=<NODE_TOKEN> sh -

k0s — 사전 구성 없이 단일 바이너리

# 컨트롤러 설치
curl -sSLf https://get.k0s.sh | sudo sh
k0s install controller --single
k0s start

# 워커 조인 토큰 생성
k0s token create --role=worker

# 워커 노드에서 조인
k0s install worker --token-file /path/to/token
k0s start

온프레미스 CNI 선택

네트워크 플러그인(CNI)은 온프레미스에서 직접 선택해야 합니다.

CNI	특징	권장 상황
Calico	네트워크 정책 강력, BGP 지원	보안 정책이 중요한 환경
Flannel	단순, 오버헤드 적음	단순한 구성 선호 시
Cilium	eBPF 기반, 고성능, 관측성 뛰어남	대규모, 고성능 요구 환경
Weave Net	설정 간단, 암호화 내장	소규모, 빠른 도입

# Calico 설치
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml

# Cilium 설치 (Helm)
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true

유형 6: 멀티 클러스터 아키텍처

여러 Kubernetes 클러스터를 운영하는 패턴입니다. 단일 대형 클러스터 대신 목적별로 분리합니다.

┌──────────────────────────────────────────────────┐
│                  멀티 클러스터                    │
│                                                  │
│  ┌─────────────┐    ┌─────────────┐              │
│  │  Prod 클러스터│    │  Dev 클러스터│              │
│  │  (ap-ne-2)  │    │  (ap-ne-2)  │              │
│  └─────────────┘    └─────────────┘              │
│                                                  │
│  ┌─────────────┐    ┌─────────────┐              │
│  │  Prod 클러스터│    │  GPU 전용   │              │
│  │  (us-east-1)│    │  클러스터   │              │
│  └─────────────┘    └─────────────┘              │
└──────────────────────────────────────────────────┘

멀티 클러스터를 선택하는 이유

이유	설명
장애 격리	프로덕션 클러스터 장애가 다른 환경에 영향 없음
지역 분산	글로벌 서비스의 레이턴시 감소, DR 구성
보안 경계	테넌트, 사업부, 규제 요건에 따른 분리
워크로드 특성	GPU 집약형, CPU 집약형, 일반형 분리 운영
팀 자율성	플랫폼 팀이 각 팀에 독립 클러스터 제공

kubeconfig 여러 클러스터 관리

# 여러 클러스터 kubeconfig 병합
KUBECONFIG=~/.kube/config-prod:~/.kube/config-dev \
  kubectl config view --merge --flatten > ~/.kube/config

# 컨텍스트 확인
kubectl config get-contexts

# 컨텍스트 전환
kubectl config use-context prod-cluster
kubectl config use-context dev-cluster

# 빠른 전환 도구 (kubectx 권장)
brew install kubectx
kubectx prod-cluster
kubectx dev-cluster

멀티 클러스터 관리 도구

# Argo CD로 멀티 클러스터 배포
argocd cluster add prod-cluster
argocd cluster add dev-cluster

# Argo CD 앱 배포 대상 클러스터 지정
argocd app create my-app \
  --repo https://github.com/org/repo \
  --path k8s/overlays/prod \
  --dest-server https://prod-cluster-api:6443 \
  --dest-namespace production

클러스터 유형 선택 기준

어떤 유형을 선택할지는 다음 질문을 바탕으로 결정합니다.

가용성 요구사항이 99.9% 이상인가?
    Yes → HA 클러스터 (관리형 or 온프레미스 HA)
    No  → 단일 컨트롤 플레인으로 시작 가능

클라우드 환경인가?
    Yes → 관리형 클러스터 (EKS / GKE / AKS) 우선 검토
    No  → kubeadm / k3s / k0s

팀 규모와 운영 여력은?
    소규모 → 관리형 클러스터 또는 k3s
    중간   → 관리형 클러스터 + 노드 그룹 커스터마이징
    대규모 → 온프레미스 HA 또는 멀티 클러스터

워크로드 격리 요구가 있는가?
    Yes → 멀티 클러스터 검토
    No  → 네임스페이스 + RBAC으로 격리 후 필요 시 분리

환경별 권장 구성 요약

환경	권장 유형	도구
로컬 개발	단일 노드	minikube / kind / k3s
CI/CD 테스트	단일 노드	kind
개발/스테이징 (클라우드)	단일 컨트롤 플레인 관리형	EKS / GKE / AKS
프로덕션 (클라우드)	HA 관리형	EKS / GKE / AKS (멀티 AZ)
프로덕션 (온프레미스)	HA 클러스터	kubeadm + HA LB
엣지 / IoT	경량 단일 노드	k3s / k0s
엔터프라이즈 멀티팀	멀티 클러스터	관리형 + Argo CD / Fleet

클러스터 운영 공통 체크리스트

유형에 상관없이 프로덕션 클러스터에 공통으로 적용해야 할 항목입니다.

# 1. 노드 상태 확인
kubectl get nodes -o wide
kubectl describe node <NODE_NAME>

# 2. 컨트롤 플레인 컴포넌트 상태
kubectl get componentstatuses   # 구버전
kubectl get pods -n kube-system

# 3. etcd 헬스 체크
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  endpoint health

# 4. 리소스 현황
kubectl top nodes
kubectl top pods -A

# 5. 이벤트 모니터링
kubectl get events -A --sort-by='.lastTimestamp' | tail -20

etcd 백업 (온프레미스 필수)

# etcd 스냅샷 백업
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 백업 검증
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-latest.db --write-out=table

# 복구
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-latest.db \
  --data-dir=/var/lib/etcd-restored

관리형 클러스터(EKS, GKE, AKS)는 etcd를 클라우드 제공자가 관리하므로 별도 백업이 필요 없습니다. 대신 클러스터 리소스 선언을 GitOps로 관리하는 것이 복구 전략의 핵심입니다.

클러스터 업그레이드 전략

Kubernetes는 마이너 버전 3개를 지원합니다. 업그레이드를 미루면 미룰수록 도약이 커집니다.

# 현재 버전 확인
kubectl version
kubeadm version

# 업그레이드 가능 버전 확인
apt-cache madison kubeadm

# kubeadm 업그레이드 계획 확인
kubeadm upgrade plan

# 컨트롤 플레인 업그레이드 (kubeadm)
apt-get install -y kubeadm=1.30.x-00
kubeadm upgrade apply v1.30.x

# 노드 drain 후 kubelet 업그레이드
kubectl drain <NODE> --ignore-daemonsets
apt-get install -y kubelet=1.30.x-00 kubectl=1.30.x-00
systemctl restart kubelet
kubectl uncordon <NODE>

관리형 클러스터는 콘솔 또는 CLI로 버전을 지정하면 컨트롤 플레인이 자동 업그레이드됩니다. 노드 그룹은 별도로 롤링 업그레이드합니다.

마무리

Kubernetes 클러스터 유형은 단순히 “어떤 명령어를 쓰느냐”가 아니라, 가용성 목표, 운영 책임, 비용, 팀 역량을 동시에 반영하는 아키텍처 결정입니다.

처음에는 관리형 클러스터로 시작해 운영 경험을 쌓고, 규모와 요구사항이 명확해지면 온프레미스 HA나 멀티 클러스터로 전환하는 방향이 현실적입니다. 클러스터 유형 결정에서 가장 흔한 실수는 처음부터 복잡하게 시작하는 것입니다. 단순하게 시작하고, 실제 운영 중에 생기는 문제를 해결하며 발전시키는 것이 장기적으로 더 안정적입니다.

다음으로 읽기 좋은 글

🚀 DevOps

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다

Kubernetes 클러스터 유형 완전 가이드

클러스터의 핵심 구성 요소

유형 1: 단일 노드 클러스터

대표 도구

minikube 빠른 시작

트레이드오프

유형 2: 단일 컨트롤 플레인 클러스터

kubeadm으로 구성하기

트레이드오프

유형 3: 고가용성(HA) 클러스터

etcd 쿼럼 이해

kubeadm으로 HA 구성

로드 밸런서 요구사항

유형 4: 관리형 클러스터 (Managed Kubernetes)

주요 관리형 서비스 비교

EKS 클러스터 생성 (eksctl)

EKS 노드 그룹 분리 전략

GKE Autopilot vs Standard

관리형 클러스터 트레이드오프

유형 5: 온프레미스 클러스터

주요 배포 방식

온프레미스 CNI 선택

유형 6: 멀티 클러스터 아키텍처

멀티 클러스터를 선택하는 이유

kubeconfig 여러 클러스터 관리

멀티 클러스터 관리 도구

클러스터 유형 선택 기준

환경별 권장 구성 요약

클러스터 운영 공통 체크리스트

etcd 백업 (온프레미스 필수)

클러스터 업그레이드 전략

마무리

다음으로 읽기 좋은 글

Kubernetes 기초 설계 가이드

Kubernetes 심화 — HPA, Resource 관리, Pod Scheduling

컨테이너와 쿠버네티스는 어떻게 배포의 감각을 바꿨나

Kubernetes v1.34 에서 플랫폼 팀이 봐야 할 것

이 주제를 시스템 관점으로 더 이어서 보기