Design Kubernetes - Choosing Infrastructure

이전 글에서 “클러스터 설계(목적/워크로드/운영 모델)” 관점으로 큰 그림을 잡았다면, 이번에는 Kubernetes 클러스터를 실제로 어디에, 어떤 방식으로 배포할 수 있는지를 좀 더 구체적으로 정리합니다.

핵심은 단순합니다.

• 학습/개발/테스트라면: 빠르게 띄우고 쉽게 지웠다 다시 만드는 것이 최우선
• 프로덕션이라면: 운영(업그레이드/보안 패치/가용성/백업/관측성)까지 포함해서 선택해야 함

---

1) Kubernetes는 어디에든 배포할 수 있다 (하지만 “운영 책임”이 다르다)

Kubernetes는 다음 어디든 배포할 수 있습니다.

• 개인 노트북/로컬 머신
• 사내 물리 서버(온프레미스)
• 사내 가상화 환경(VMware, VirtualBox 등)
• 퍼블릭 클라우드(GCP/AWS/Azure 등)

다만 요구사항(학습 vs 운영), 조직의 클라우드 채택 정도, 운영 책임을 어디까지 직접 질 것인지에 따라 선택지가 달라집니다.

---

2) 로컬(개인 PC)에서 시작하는 방법들

2.1 Linux 머신: “바이너리 수동 설치” vs “자동화 도구”

Linux에서는 이론적으로 Kubernetes 컴포넌트를 바이너리로 직접 설치해 로컬 클러스터를 만들 수 있습니다. 하지만 초반 학습자에게는 너무 번거롭고 실수 포인트가 많습니다.

그래서 보통은 몇 분 안에 클러스터를 띄워주는 자동화 솔루션을 씁니다.

---

2.2 Windows: “Kubernetes를 네이티브로 못 깐다”는 말의 정확한 의미

강의 스크립트에서는 “Windows는 네이티브로 Kubernetes를 설치할 수 없다”는 뉘앙스가 있는데, 정확히는:

• Kubernetes 컨트롤 플레인(control plane)은 Linux에서 동작해야 합니다.
• Windows는 워커 노드(worker node) 로는 지원됩니다(= Windows 컨테이너 워크로드를 실행 가능). (Kubernetes)
• 그래서 Windows only(윈도우만으로 구성된) 클러스터는 불가능이고, 최소 1개 이상의 Linux 노드(또는 Linux 기반 컨트롤 플레인)가 필요합니다. (Rancher Manager)

실무/학습에서 Windows 사용자는 보통 아래 중 하나로 “Linux 환경”을 확보합니다.

• WSL2
• Hyper-V / VMware / VirtualBox로 Linux VM 생성
• Docker Desktop 기반(kind/minikube 등)

---

3) 로컬에서 쉽게 시작하는 대표 옵션: Minikube / kind / kubeadm

3.1 Minikube: “단일 노드로 빠르게”

• 목적: 학습/개발/테스트에 최적
• 특징: 로컬 머신에서 가장 쉽게 1개 클러스터를 띄움
• 내부적으로 드라이버(예: VirtualBox, Hyper-V, Docker 등) 위에서 동작

예시:

minikube start
kubectl get nodes
kubectl get pods -A

포인트
Minikube는 “단일 노드” 이미지가 강하지만, 환경에 따라 멀티 노드도 가능해졌습니다. 다만 교육 흐름상 “가볍게 시작” 용도로 이해하면 충분합니다.

---

3.2 kind: “Kubernetes in Docker”

kind는 “Kubernetes 노드들을 Docker 컨테이너로” 구성합니다. 멀티 노드 토폴로지를 로컬에서 재현하기 좋아서, 요즘 학습/테스트에 많이 씁니다.

kind create cluster --name lab
kubectl get nodes

멀티 노드 예시(kind 설정 파일):

# kind-multi.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

kind create cluster --name lab --config kind-multi.yaml
kubectl get nodes

---

3.3 kubeadm: “진짜 클러스터 설치 흐름을 배우는 정석”

강의에서도 강조한 차이가 핵심입니다.

• Minikube/kind: VM/노드 준비까지 어느 정도 자동화
• kubeadm: 노드(VM/서버)는 사용자가 먼저 준비해야 함 → 그 위에 Kubernetes를 설치/부트스트랩

즉 kubeadm은 “클러스터 설치 도구”이고, 인프라(서버/VM)는 별도로 마련해야 합니다.

(개념 흐름 예시)

# 1) 컨트롤 플레인 초기화 (Linux 노드)
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# 2) kubectl 설정
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown "$(id -u):$(id -g)" $HOME/.kube/config

# 3) 워커 노드 조인 (kubeadm init 출력에 join 커맨드가 나옴)
sudo kubeadm join <control-plane-ip>:6443 --token <...> --discovery-token-ca-cert-hash sha256:<...>

포인트
kubeadm은 멀티 노드뿐 아니라, 프로덕션에서 필요한 멀티 컨트롤 플레인(HA) 구성의 기반도 됩니다(뒤의 HA 토폴로지 파트에서 확장).

---

4) 프로덕션/조직 환경의 배포 옵션: Turnkey(Self-managed) vs Managed(Hosted)

강의에서는 크게 두 부류로 나눴습니다.

4.1 Turnkey(자체 운영형): “구축은 도와주지만, VM 운영은 우리가”

정의:

• 우리가 VM/서버를 직접 준비
• 도구/스크립트가 Kubernetes 설치·구성·일부 운영을 쉽게 해줌
• 하지만 VM 패치/업그레이드/보안/장애 대응 책임은 우리에게 있음

예시(강의 언급):

• AWS에서 kOps로 Kubernetes 구축 (Self-managed) (AWS Documentation)
• 온프레미스에서 OpenShift 같은 엔터프라이즈 플랫폼(아래 참고)

kOps는 “AWS에 Kubernetes를 올리는 자동화” 성격이 강합니다.

# 개념용 예시 (상세는 환경/인증/네트워크에 따라 달라짐)
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

---

4.2 Managed(Hosted): “컨트롤 플레인/운영을 클라우드가 맡아줌”

정의:

• Kubernetes 클러스터(특히 컨트롤 플레인)를 클라우드 제공자가 관리
• 사용자는 노드풀/워크로드/정책에 집중
• 업그레이드/가용성/보안 패치 부담이 크게 줄어듦

대표 서비스:

• GKE (Google Kubernetes Engine) (Google Cloud)
• EKS (Amazon Elastic Kubernetes Service) (Amazon Web Services, Inc.)
• AKS (Azure Kubernetes Service) (강의에도 언급)

스크립트의 오타/구버전 표현 보정
“Amazon Elastic Container Service for Kubernetes(ECS for Kubernetes)”라고 표현했는데, AWS의 관리형 Kubernetes는 EKS가 정확한 명칭입니다. (Amazon Web Services, Inc.)

---

5) 엔터프라이즈/온프레미스 배포 플랫폼(강의에 나온 것들) 정리

강의는 “인증된 다양한 솔루션이 있다”는 메시지를 주면서 몇 가지를 예로 들었습니다. 요점은 다음입니다.

5.1 Red Hat OpenShift

• Kubernetes 위에 추가 기능(빌드/배포/GUI/보안/운영 도구) 을 얹은 엔터프라이즈 플랫폼
• 온프레/하이브리드에서 많이 검토됨 (레드햇)

5.2 VMware 계열(PKS → Tanzu로 리브랜딩)

• 기존 PKS가 VMware Tanzu 라인업으로 재정리됨(명칭 변경 이력 포함) (VMware Blogs)
• 이미 VMware 가상화 기반이 강한 조직이면 검토 대상

5.3 기타(강의 언급)

• Cloud Foundry 쪽 Kubernetes 배포/운영 도구(BOSH 기반) 등
• Vagrant로 VM 템플릿/스크립트를 활용해 클러스터 구성

여기서 중요한 건 “각 솔루션의 이름을 외우는 것”이 아니라,
(1) 우리가 VM까지 운영하나? (2) 컨트롤 플레인까지 맡겨도 되나? (3) 온프레 표준 플랫폼이 필요한가? 를 기준으로 고르는 방식입니다.

---

6) 학습용으로는 무엇을 선택할까? (강의의 결론)

강의의 결론은 매우 실용적입니다.

• 목적: 학습
• 제약: 모두가 퍼블릭 클라우드 계정이 있진 않음
• 선호: 설문에서 로컬 + VirtualBox 선호가 많음
• 그래서 선택: 로컬 머신에 VirtualBox로 VM 3대(컨트롤 플레인 1 + 워커 2) 만들고, 그 위에 클러스터를 직접 구성

이 방식의 장점:

• 네트워크/스토리지/스케줄링/트러블슈팅 등 “클러스터 내부”를 가장 잘 배우게 됨
• Managed 서비스처럼 숨겨진 부분이 적어, CKA/실무 기본기에 도움이 큼

---

7) 한 장으로 정리: 상황별 추천 “빠른 선택표”

상황	추천	이유
처음 배우는 중, 빠르게 실습	minikube / kind	설치/삭제가 빠르고 반복 학습에 최적
“클러스터 설치 흐름”을 제대로 학습	kubeadm (VM/서버 직접 준비)	노드 준비부터 조인까지 전체 그림 학습 가능
조직에서 프로덕션 운영(클라우드 가능)	GKE/EKS/AKS	운영 부담(HA/업그레이드/패치) 크게 감소 (Google Cloud)
온프레 표준 플랫폼 필요	OpenShift / Tanzu 계열	보안/운영/거버넌스 기능 포함 (레드햇)
Windows 워크로드 필요	Linux 컨트롤 플레인 + Windows 워커 혼합	Windows-only 불가, 혼합 구성 필요 (Kubernetes)