Design Kubernetes

 

1) 클러스터 설계 전에 반드시 답해야 하는 질문

클러스터 목적

• 학습(Learning) / 개발(Development) / 테스트(Testing) / 운영(Production) 중 어디에 해당하는가?
• 목적에 따라 가용성(HA), 업그레이드/유지보수, 보안, 비용 우선순위가 달라집니다.

조직의 클라우드 채택 수준

• 클라우드 기반이 가능한가? (GCP/AWS/Azure)
• 온프레미스가 필요한가? (규제/데이터 거버넌스/네트워크 제약)

관리형(Managed) vs 자가호스팅(Self-hosted)

• 클라우드 제공사가 컨트롤 플레인을 관리해주는 형태(Managed)가 좋은가?
• 아니면 직접 설치/업그레이드/백업까지 책임지는 Self-hosted가 필요한가?

워크로드 특성

• 몇 개의 애플리케이션을 올릴 것인가? (소수 vs 다수)
• 어떤 유형의 애플리케이션인가?
  • 웹 애플리케이션(HTTP 중심)
  • 배치/데이터 처리(Big Data, Analytics)
  • AI/ML 등 고성능(GPU/고IO) 워크로드
• 트래픽 패턴은?
  • 지속적인 고트래픽(steady heavy)
  • 이벤트성/버스트(burst)

이 질문들에 답이 나와야, 노드 스펙/스토리지/네트워크/토폴로지(HA 포함) 설계를 현실적으로 결정할 수 있습니다.

---

2) 목적별 추천 클러스터 형태 (학습 → 개발/테스트 → 프로덕션)

아래는 “목적”에 따라 흔히 선택되는 구성과 도구를 요약한 것입니다.

목적	추천 구성	대표 도구/옵션
학습(Learning)	단일 노드 또는 로컬/VM 기반 간단 클러스터	minikube, kind, (VM 위) kubeadm
개발/테스트(Dev/Test)	멀티 노드(컨트롤 플레인 1 + 워커 N)	kubeadm, (클라우드) GKE/EKS/AKS
프로덕션(Production)	HA 멀티 노드(컨트롤 플레인 3+ 권장) + 운영 도구 체계	kubeadm/kOps/Managed(GKE/EKS/AKS)

2.1 학습용: 빠르게 “동작하는 Kubernetes”

학습이라면 “가용성/운영 난이도”보다 “빠른 셋업/반복 실습”이 중요합니다.

• minikube: 로컬에서 가장 빠른 체험
• minikube start kubectl get nodes
• (옵션) kind: 로컬 Docker 기반으로 멀티 노드 실습도 쉬움
• kind create cluster --name lab --config kind-multi-node.yaml kubectl get nodes
• kubeadm(로컬 VM/클라우드 VM): “실제 운영 형태”에 가까운 구성 학습에 좋음

2.2 개발/테스트용: 멀티 노드 + 현실적인 네트워킹/스토리지

개발/테스트 환경에서는 보통 컨트롤 플레인 1대 + 워커 여러 대로 시작합니다.

• Self-hosted라면 kubeadm이 정석적인 선택지입니다.
• 클라우드라면 관리형 서비스를 활용해 빠르게 프로비저닝하고, 애플리케이션 배포/운영에 집중할 수 있습니다.
  • GCP: GKE (Google Kubernetes Engine) — 과거 “Container Engine”에서 이름이 바뀌었습니다. (Google Cloud Blog)
  • AWS: EKS
  • Azure: AKS

2.3 프로덕션용: HA(High Availability) + 업그레이드/운영 전략이 핵심

프로덕션은 “클러스터가 살아있는가”가 곧 비즈니스 가용성이므로, 고가용성 멀티 마스터(컨트롤 플레인) 구성이 강하게 권장됩니다.

• Managed를 쓰면 컨트롤 플레인이 클라우드에서 관리되며, 예를 들어 EKS는 컨트롤 플레인을 여러 AZ에 걸쳐 운영하는 구조를 문서에서 설명합니다. (AWS 문서)
• Self-hosted라면 kubeadm이나 (AWS 중심이면) kOps 같은 도구로 프로덕션급 클러스터를 구성할 수 있습니다. (kops.sigs.k8s.io)

---

3) 클러스터 규모와 “상한선” 감각 잡기

클러스터 설계 시 “얼마나 커질 수 있나”를 알고 있으면, 처음부터 과하게 설계하거나 반대로 너무 작게 잡는 실수를 줄일 수 있습니다.

Kubernetes 문서의 대규모 클러스터 가이드에서는(특정 버전 기준) 다음 범위 내 구성을 목표로 잡도록 설명합니다. (Kubernetes)

• 노드: 최대 5,000
• 전체 파드: 최대 150,000
• 전체 컨테이너: 최대 300,000
• 노드당 파드: 최대 110

이 수치를 외울 필요는 없고, “대략 이 정도 스케일에서 컨트롤 플레인/네트워크/etcd 병목이 현실 이슈가 된다”는 감각을 가져가면 충분합니다. (문서에 항상 최신 값이 있습니다.) (Kubernetes)

---

4) 노드 스펙(컴퓨팅)과 디스크(스토리지)는 워크로드가 결정한다

노드 스펙(Compute)

• 같은 노드 수라도, 애플리케이션 종류에 따라 CPU/메모리 요구량이 크게 달라집니다.
  • 웹/API: 요청 처리량과 레이턴시 중심
  • 데이터/분석: CPU/메모리 + 디스크 IO가 중요
  • 고성능(예: 대량 동시 처리): CPU/메모리뿐 아니라 네트워크/스토리지 병목이 더 빨리 옵니다.
• 관리형 클라우드 환경에서는 보통 “노드 수/노드풀 구성” 기반으로 운영하고, 필요하면 오토스케일을 결합합니다. (다만 ‘자동으로 노드 크기를 골라준다’기보단, 서비스/노드풀 전략으로 표준화하는 형태가 일반적입니다.)

스토리지 설계(중요)

워크로드에 따라 노드/디스크 구성이 달라집니다.

• 고성능 워크로드: SSD 기반 스토리지 고려 (동시 IO, 낮은 레이턴시)
• 공유 볼륨이 필요한 워크로드: 네트워크 기반 스토리지(NFS/EBS/EFS/Filestore 등) 고려
• Kubernetes 관점에서는:
  • PV/PVC(영구 스토리지) 설계
  • StorageClass(스토리지 등급) 분리
  • 애플리케이션별로 “맞는 스토리지 클래스”를 할당

---

5) 클러스터를 이루는 노드 형태: 물리/가상/클라우드

Kubernetes 노드는 다음 어디든 가능합니다.

• 물리 서버(on-prem)
• 가상머신(VM) — 예: VirtualBox, vSphere
• 클라우드 VM — GCP/AWS/Azure 등

학습/실습에서는 흔히 3노드(컨트롤 플레인 1 + 워커 2)로 시작합니다. 이 구성만으로도:

• 스케줄링(파드가 워커로 배치되는 흐름)
• 네트워크(CNI, Service, DNS)
• 장애 대응(노드 장애 시 재스케줄링)
  같은 핵심을 충분히 실습할 수 있습니다.

---

6) 컨트롤 플레인(마스터) 노드에 워크로드를 올려도 되나?

결론부터 말하면:

• 기술적으로는 가능합니다. 컨트롤 플레인 노드도 “노드”이기 때문입니다.
• 하지만 베스트 프랙티스는 특히 프로덕션에서 컨트롤 플레인 전용으로 두는 것입니다.

kubeadm 같은 도구는 기본적으로 컨트롤 플레인 노드에 taint를 걸어서 일반 워크로드가 올라가지 않게 막습니다.

(학습용) 컨트롤 플레인에 파드를 올리고 싶다면

kubectl get nodes
kubectl describe node <control-plane-node-name> | grep -i taint -n

# taint 제거 (학습 환경에서만)
kubectl taint nodes <control-plane-node-name> node-role.kubernetes.io/control-plane:NoSchedule-
# (구버전/환경에 따라 master 키를 쓰는 경우도 있음)
kubectl taint nodes <control-plane-node-name> node-role.kubernetes.io/master:NoSchedule-

---

7) OS/아키텍처 기본 요구사항: 64-bit Linux

노드에는 일반적으로 64-bit Linux가 필요합니다(실무에서도 사실상 표준입니다). CPU 아키텍처(amd64/arm64)에 따라 이미지 호환성까지 함께 고려해야 합니다.

---

8) 큰 클러스터에서의 토폴로지: etcd 분리 옵션

일반적인 클러스터는 컨트롤 플레인 노드에:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• etcd
  등을 함께 둡니다.

하지만 규모가 커지거나 성능/안정성을 더 강하게 요구하면, etcd를 별도 노드(또는 별도 클러스터)로 분리하는 토폴로지도 고려합니다. 이 부분은 HA/확장(대규모) 설계에서 더 깊게 다루는 주제입니다.

---

9) 구축/운영 도구 선택 요약

Self-hosted (직접 운영)

• kubeadm: 표준적인 설치/부트스트랩 도구
  • 장점: upstream에 가깝고, 이해/통제가 쉬움
  • 단점: HA/업그레이드/백업/운영 자동화는 직접 설계 필요
• kOps: “클러스터를 위한 kubectl” 느낌의 운영 도구(특히 AWS에서 많이 언급) (kops.sigs.k8s.io)
• # 예시 (개념용) kops create cluster --name example.k8s.local --state s3://my-kops-state --zones ap-northeast-2a kops update cluster --name example.k8s.local --state s3://my-kops-state --yes kops validate cluster --name example.k8s.local --state s3://my-kops-state

Managed Kubernetes (클라우드 제공사 관리)

• GKE: 과거 Container Engine에서 Kubernetes Engine으로 리브랜딩 (Google Cloud Blog)
  노드 자동 업그레이드 같은 운영 편의 기능이 문서로 제공됩니다. (Google Cloud Documentation)
• EKS: 컨트롤 플레인을 AWS가 관리(다중 AZ 구성 등) (AWS 문서)
• AKS: 관리형 Kubernetes로 운영 오버헤드를 줄이는 방향을 강조 (Microsoft Learn)

---

10) 실무적으로 추천하는 “설계 체크리스트”

클러스터를 설계할 때 아래 항목을 문서로 남기면, 팀/조직에서 합의가 빨라집니다.

• 목적: 학습/Dev/Test/Prod
• 운영 방식: Managed vs Self-hosted
• 가용성 목표: 컨트롤 플레인 HA 필요 여부, 멀티 AZ/멀티 리전 여부
• 워크로드: 유형(웹/배치/데이터), 트래픽 패턴(steady/burst)
• 규모 예상: 노드/파드/컨테이너의 상한 감각(문서 기준) (Kubernetes)
• 스토리지: SSD 필요 여부, 공유 스토리지 필요 여부, StorageClass 설계
• 컨트롤 플레인 정책: 전용 노드 유지(taint), etcd 분리 필요 여부
• 유지보수: 업그레이드 방식(자동/수동), 백업/복구, 관측(로그/메트릭)