클라우드‐WHY‐kubeadm - 100-hours-a-week/16-Hot6-wiki GitHub Wiki

Kubeadm

왜 Kubeadm을 사용하나요?

Docker → kubeadm 전환은 단순한 컨테이너 실행을 넘어서,
안정적이고 확장 가능한 서비스 운영 체계를 갖추기 위한 필수 단계였습니다.
Kubeadm을 통해 우리는 자체 클러스터를 구성하고, 고도화된 오케스트레이션 환경을 마련할 수 있었습니다.

단순한 Docker 단일 배포에서 벗어나, 복잡한 서비스를 안정적으로 운영하기 위해 Kubernetes 기반 오케스트레이션이 필요했고, 그 도구로 kubeadm을 선택했습니다.

1. 운영 대상의 규모와 복잡도가 증가했기 때문입니다.

  • 초기에 프론트/백엔드 하나씩만 있을 때는 docker run으로도 충분했지만,
  • 지금은 마이크로서비스처럼 여러 개의 서비스가 서로 연결되고, 관리해야 할 컨테이너 수가 많아졌습니다.
  • 컨테이너 간 통신, 배포 순서, 상태 관리까지 고려해야 하므로 단순한 Docker CLI로는 한계가 분명합니다.

2. 고가용성과 자동 복구가 필요한 운영 환경이 되었기 때문입니다.

  • 실서비스는 단순히 “잘 뜨는 것”이 아니라, “항상 떠 있어야 하고, 장애 시 자동 복구돼야” 합니다.
  • Kubernetes는 Pod 단위의 헬스체크, 자동 재시작, Self-healing, 리소스 스케줄링을 기본으로 제공합니다.

3. 무중단 배포 및 롤링 업데이트를 기본 제공하기 때문입니다.

  • 수동 배포 방식에서는 문제가 생기면 직접 롤백하거나 재배포해야 했습니다.
  • Kubernetes의 Deployment 객체는 롤링 업데이트와 자동 롤백을 지원해, 서비스 중단 없이 안전하게 배포할 수 있습니다.

4. 트래픽 증가에 대응할 수 있는 자동 스케일링이 필요했기 때문입니다.

  • Docker 환경에서는 컨테이너 수를 수동으로 늘려야 했지만,
  • Kubernetes에서는 HPA(Horizontal Pod Autoscaler) 를 통해 트래픽에 따라 Pod 수를 자동 조절할 수 있습니다.

5. CI/CD 및 GitOps 연동을 위한 기반이 필요했기 때문입니다.

  • Docker만으로는 이미지 빌드 후 수동 배포가 일반적이지만,
  • Kubeadm 기반 Kubernetes 클러스터 위에서는 Helm, ArgoCD 등을 이용한 배포 자동화(GitOps) 가 가능합니다.

6. 직접 컨트롤 가능한 클러스터가 필요했기 때문입니다.

  • kubeadm은 클라우드에 종속되지 않고, 자체적으로 Kubernetes 클러스터를 구성할 수 있게 해줍니다.
  • 보안 정책, 네트워크 구성(CNI), 클러스터 구성 등을 세밀하게 직접 통제하고자 할 때 적합합니다.

🔝 Top

왜 Dev 클러스터 인프라 관점 아키텍처를 저렇게 구성했나요?

alt text

1. 왜 Master Node가 1개뿐인가요?

개발 환경에서는 고가용성(HA)이 필수가 아니기 때문에, 마스터 노드를 하나만 두기로 하였습니다. 이렇게 하면 리소스를 아끼고, 구성이 간단해지며, 디버깅과 테스트에도 유리하다고 생각했습니다. 운영 환경에서는 마스터가 죽으면 서비스 전체가 마비되지만, 개발 환경은 일시적인 중단이 용인되기 때문입니다.

2. etcd는 왜 내부(Master Node)에 같이 있나요?

개발 환경에서는 별도의 외부 etcd 클러스터를 구성하는 건 과하고 복잡도도 높기 때문에, 마스터 노드 내부에 내장된 etcd를 사용하기로 했습니다. 내장 etcd는 kubeadm 등으로 간편하게 설치 가능하며, 단일 노드에서는 충분히 안정적으로 작동합니다.

3. 왜 Worker Node는 1개인가요?

개발 목적에서는 하나의 워커 노드만으로도 충분히 다양한 워크로드 테스트와 애플리케이션 배포 실험이 가능합니다.
리소스를 효율적으로 사용하고 비용을 최소화하기 위한 선택이며, 필요 시 나중에 추가하면 되기때문에 1개로 구성하였습니다.
또한 Pod 간 통신, 서비스 연결 등의 기능은 워커가 1개여도 동일하게 실험 가능합니다.

4. 개발자는 어디로 어떻게 접속하나요?

개발자는 kubectl CLI를 통해 마스터 노드의 API Server에 접속합니다.
보통은 kubeconfig 파일에 정의된 인증 정보와 API endpoint를 통해 접속하며,
클러스터 내부가 아닌 외부에서도 접근 가능하게 SSH 포트포워딩이나 NodePort를 사용할 수 있습니다.
운영에서는 보통 Load Balancer를 통해 접근하지만, 개발에서는 직접 연결 방식도 자주 사용합니다.

5. 왜 Load Balancer 없이 구성했나요?

개발 환경에서는 고가용성이나 복잡한 트래픽 분산이 요구되지 않기 때문에,
단순히 NodePort나 Ingress로 직접 접근할 수 있도록 구성하는 것이 더 간단하고 효율적이라고 생각했습니다. 또한 Load Balancer는 비용도 발생하고 관리 포인트도 늘어나기 때문에 Dev에서는 생략하기로 했습니다. 만약 개발 과정에서 문제가 생기면 추가 하면 됩니다.

6. Prometheus와 Grafana는 왜 포함되었나요?

비록 개발 환경이지만, Pod 상태, 리소스 사용량(CPU, 메모리), 네트워크 트래픽 등을 시각적으로 확인하는 것이 디버깅과 성능 테스트에 유용하고, 바람직하다고 생각햇습니다. Prometheus는 Exporter를 통해 메트릭을 수집하고, Grafana는 이를 시각화해주기 때문에 운영과 유사한 관찰 환경을 Dev에서도 재현할 수 있습니다.

7. 왜 Exporter는 Master Node에만 붙어 있나요?

기본적인 클러스터 상태나 컨트롤 플레인 동작 정보는 마스터 노드에서 수집 가능하므로,
Exporter를 마스터 노드에만 배치해도 개발 목적에는 충분합니다.
필요 시 worker 노드에도 node-exporter를 붙일 수 있지만, 초기 구성에선 생략하기로 했습니다.

🔝 Top

왜 Prod 클러스터 인프라 관점 아키텍처를 저렇게 구성했나요?

image

1. 왜 Load Balancer를 사용했나요?

클러스터 외부 또는 내부의 사용자 요청을 분산 처리하기 위해 사용합니다. API 요청이 여러 마스터의 apiserver로 균등하게 전달되어 부하가 분산되고, 특정 노드 장애 시 자동으로 우회할 수 있습니다. HA 클러스터에서 필수 요소입니다.

2. 왜 worker 노드를 분리해서 3개나 구성했나요?

  • 워크로드 분산 및 리소스 확보를 위해서입니다.
  • 하나의 노드에 장애가 나도 다른 노드에서 파드를 다시 실행시킬 수 있어 가용성이 올라갑니다.
  • 향후 오토스케일링도 고려하여 설계하였습니다.

3. worker 노드 안에 proxy, kubelet, CRI이 무엇인가요?

  • kubelet: 마스터의 명령을 받아서 컨테이너를 생성/관리
  • kube-proxy: 클러스터 내 네트워크 연결 관리
  • CRI (container runtime): 실제 컨테이너를 실행시키는 엔진 (예: containerd, Docker)

이들은 모두 노드에서 반드시 필요한 핵심 컴포넌트입니다.

4. 왜 외부 etcd를 사용하나요?

etcd란?
  • Kubernetes의 상태 데이터 저장소 (예: Pod 목록, ConfigMap, Secret 등)
  • 마스터 노드의 kube-apiserver가 etcd에 읽고 씀
두 가지 구성 방식
구성 설명 주로 사용되는 환경
내부 etcd 마스터 노드 안에 etcd도 같이 돌림 작은 개발 클러스터, 테스트 환경
외부 etcd 마스터와 별도의 VM/EC2에서 etcd만 따로 돌림 실무/운영환경 (HA, 보안, 백업 분리)
외부 etcd를 사용하는 이유
이유 설명
1. 고가용성 마스터와 별도로 클러스터링 가능 (etcd만 3개 구성 가능)
2. 독립 백업 마스터 장애와 무관하게 etcd 데이터 백업/복구 쉬움
3. 보안/경계 분리 제어 노드와 데이터 저장소 분리로 보안 격리
4. 성능 최적화 etcd는 디스크 성능이 중요해서, 전용 인스턴스에 배치하면 안정성↑

6. 왜 운영(Prod) 구조와 개발(Dev) 구조가 다른가요?

운영 환경과 개발 환경은 목적, 요구사항, 우선순위가 다르기 때문에 구조도 달라지는 게 자연스럽다고 생각했습니다. 개발 환경은 운영 환경과 같은 수준의 안정성을 요구하지 않기 때문에, 구조를 단순화하여 리소스를 절약하고 빠른 테스트와 실험에 초점을 맞추기 위해서 입니다. 그러나 배포 방식이나 설정은 운영 환경과 유사하게 유지하여 호환성과 일관성을 확보하도록 노력했습니다.

목적의 차이
항목 운영(Prod) 개발(Dev)
목적 안정적 서비스 제공 빠른 개발 & 테스트
중단 허용 여부 ❌ 절대 불가 ⭕ 일시적 가능
트래픽 규모 높음 낮음

운영 환경은 장애가 용납되지 않기 때문에 고가용성(HA) 구조가 필수입니다. 반면 개발 환경은 비용 최소화와 빠른 반복 개발이 더 중요하다고 생각했습니다.

구조 차이
구성 요소 운영 환경 개발 환경
마스터 노드 1개 (단일 구성) 1개 (단일 구성)
etcd 외부 1개 마스터에 내장
워커 노드 3개 이상 1~2개
Load Balancer 필수 NodePort로 대체 가능

개발 환경은 구조를 단순화함으로써 리소스와 비용을 절약하려합니다.

비용/운영 효율 고려
  • 운영 환경에서는 서비스 중단이 금전적 손실로 이어지므로, 비용을 들여서라도 고가용성을 확보해야 합니다.
  • 개발 환경은 짧은 생명 주기, 빈번한 배포, 실험 중심이기 때문에 최소한의 구성으로도 충분하다고 판단했습니다.

🔝 Top