[cloud] 5단계 : Kubeadm 오케스트레이션 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

Kubeadm을 활용한 k8s cluster 구축

Kubeadm을 활용한 k8s cluster 구축

1. 단계 개요

이 단계는 기존의 Docker, Docker Compose 기반 단일 호스트 운영 모델에서 발생하는 한계를 해결하기 위해, kubeadm을 활용하여 Kubernetes 클러스터를 직접 구성하고, 컨테이너 기반 애플리케이션을 멀티 노드 환경에서 오케스트레이션하는 구조를 구현하는 것을 목표로 한다.

2. 기술 선택 배경

2.1 kubeadm 선택 이유

기존 Docker 기반의 한계

  • 단일 호스트에 의존 → 확장 불가, 장애 시 전체 서비스 중단
  • 컨테이너 간 통신은 로컬 네트워크에 한정 → 멀티 노드 간 통신 불가
  • 수동 배포 및 업데이트 → 자동화와 무중단 배포 어려움
  • 서비스 복구, 리소스 제한, 상태 점검 기능 부재

kubeadm의 장점

  • 멀티 노드 클러스터 구성 → 수평 확장 가능
  • 서비스 상태 감지 및 자동 복구(Self-healing)
  • Deployment, ReplicaSet 등을 활용한 무중단 롤링 배포
  • HPA, Resource Quota 등을 통한 자원 기반 자동 제어
  • Kubernetes의 핵심 컴포넌트(api-server, etcd 등)를 직접 설치/운영하며 구조 학습 가능

2.2 Calico 선택 이유

Flannel의 한계

  • Flannel은 Overlay 네트워크 방식(VXLAN) 을 기본으로 사용하여,

    Pod 간 통신 시 터널링 오버헤드가 발생함 → 고속 처리에 불리

  • Layer 2 기반의 단순한 네트워크 구성만 제공하며,

    Kubernetes의 NetworkPolicy를 완전하게 지원하지 않음

  • 보안 정책 기능이 제한적이어서, 네임스페이스 간 통신 제어나 서비스 격리에 불리

  • 운영 환경 확장 시(BGP, eBPF, 외부 통신 연동 등) 사용 범위가 좁음

Calico의 장점 (Flannel 대비)

  • Layer 3 기반 Native Routing 구조 → VXLAN 없이 직접 라우팅 가능,

    → 오버헤드가 없고, 고속 통신에 적합

  • Kubernetes의 NetworkPolicy를 100% 지원 →

    보안 제어, 서비스 격리, 제로 트러스트 네트워크 구축 가능

  • Flannel과 달리 BGP, IPIP, eBPF 등 고급 네트워크 기능을 지원 →

    멀티 노드/멀티 클러스터/클라우드 연동에 유리

  • 성능 면에서도 Flannel보다 낮은 지연 시간과 높은 처리량을 제공

2.3 서비스 관점 고려사항

트래픽 폭발성에 대한 대응 필요

  • 온기 서비스는 사진 업로드를 기반으로 하며, 이벤트, 친구 초대 등 외부 요인에 의해 사용자 수가 급격히 늘어날 가능성이 있다.
  • 모든 사용자가 사진을 동시에 업로드할 경우, 서버 부하는 순간적으로 폭발할 수 있다.
  • Kubernetes는 트래픽이 몰리면 Pod 수를 자동으로 확장하여 빠르게 대응할 수 있으므로, 트래픽 급증에도 서비스 가용성을 유지할 수 있다.

소규모 팀의 운영 효율성 확보

  • 온기 팀은 소수의 인원으로 서비스를 개발 및 운영하고 있다.
  • 단순한 3-Tier 아키텍처만으로는 장애 발생 시 수동 대응이 필수이며, 소규모 인력으로는 신속하고 지속적인 장애 대응이 어렵다.
  • Kubernetes는 기본적으로 Self-healing(자가 복구), Auto-scaling(자동 확장) 등 자동화 메커니즘을 제공하여, 적은 인원으로도 안정적인 서비스 운영이 가능하게 한다.

3. 클러스터 구성 및 설계

클러스터 토폴로지

노드 역할 수량 인스턴스 유형 설명
Control Plane (Master) 1 t3.medium API 서버, etcd, 컨트롤러 관리
Worker Node 2 t3.medium 애플리케이션 Pod 배포 대상

주요 구성 요소

  • CNI: Calico (CIDR: 192.168.0.0/16)
  • Pod 통신 방식: Native IP 기반 라우팅
  • 네트워크 보안: Calico NetworkPolicy
  • 배포 전략: Deployment → ReplicaSet → Pod
  • 무중단 배포: RollingUpdate 전략
  • 자동 확장: HPA + Metrics-server
  • 배포 자동화: Helm, ArgoCD

4. 기대 효과

  • 기존 Docker 단일 노드 모델에서 제공되지 않았던 수평 확장 구조 도입
  • 장애 상황에서도 Pod 재스케줄링으로 서비스 지속 가능
  • Calico를 통한 고속 통신, 대량 트래픽 수용 및 보안 통신 가능
  • 수동 배포에서 벗어나 Git 기반 선언적 배포 구조로 전환
    • ArgoCD는 Git 저장소를 지속적으로 감시(polling)하는 방식
  • 리소스 제한, 상태 점검, 자동 스케일링 등을 통한 운영 안정성 확보

5. HPA 구성 설명 (Horizontal Pod Autoscaler)

도입 배경

  • 트래픽 증가 시 수동으로 컨테이너 수를 조정해야 했던 Docker의 한계를 극복
  • 사용률 기반으로 Replica 수를 자동 조정하여 유연한 자원 관리 가능

구성 요소

구성 항목 설명
Metrics-server Pod의 CPU, Memory 사용률 수집
HPA 목표 사용률 기준으로 Replica 수 자동 증가/감소

작동 방식

  1. Metrics-server가 Pod별 리소스 사용률 수집
  2. HPA가 정의된 target (예: CPU 70%) 초과 여부 판단
  3. 초과 시 Replica 수 증가, 미만 시 감소
  4. ReplicaSet이 자동 확장/축소됨

6. ArgoCD 기반 배포 자동화 흐름 설명

도입 배경

  • 수동 kubectl apply 또는 docker-compose 배포의 한계를 극복
  • Git 기반의 선언적 배포, 변경 이력 관리, 자동화 배포 체계를 구현

흐름 요약

  1. 개발자가 Git에 배포 정의 파일(deployment.yaml 등) 수정/커밋
  2. ArgoCD가 Git Repo를 주기적으로 동기화(Sync)
  3. 변경사항 발견 시 Kubernetes에 자동 적용
  4. 배포 상태, 이력은 ArgoCD UI 또는 CLI로 확인

ArgoCD 구성 요약

구성 요소 설명
Git 저장소 선언적 배포 정의 파일 보관
ArgoCD App 동기화 대상 Git Repo 지정
Sync 정책 수동 또는 자동 동기화
UI 배포 상태 시각화, 롤백, 차이 비교 등 가능

7. Calico NetworkPolicy 구성 설명(Calico 활용)

도입 배경

  • Docker에는 기본적으로 서비스 간 네트워크 통제가 불가능했음
  • 보안 요구에 따라 서비스 간 통신을 세분화하여 제어할 필요가 있음

개념

  • Calico는 Kubernetes의 NetworkPolicy를 완전하게 지원
  • Pod 간 통신을 라벨, 네임스페이스, 포트 등 기준으로 제한 가능

8. Prometheus + Grafana 모니터링 구성

목적

  • 클러스터의 리소스 사용 상태를 시각화하고 운영 중 이상 징후를 조기에 탐지하기 위함

구성 요소

구성 요소 설명
Prometheus Node 및 Pod 메트릭 수집 (CPU, 메모리, 디스크 등)
Grafana Prometheus 데이터를 시각화 (대시보드 구성)
Node Exporter 노드 수준 메트릭 수집
kube-state-metrics K8s 리소스 상태 (Deployment 수, Ready 상태 등)

구성 방식 요약

  • Helm 또는 Manifest로 Prometheus + Grafana 설치
  • Grafana 대시보드를 통해 실시간 리소스 확인
  • AlertManager 연동 시 디스코드, 이메일 등 알림 기능 추가 가능

9. 현 단계의 한계점 (향후 문제가 될 수 있는 지점)

항목 상세 설명
수동 운영 부담 kubeadm init/join, 인증서, CNI 설정 등 초기 구성이 복잡하고 수동
인프라 통합 로드밸런서, DNS, IAM 등 외부 서비스와의 연동 자동화 어려움
고가용성 구성 Control Plane이 단일 구성 → 장애 발생 시 전체 영향
클러스터 업그레이드 자동화된 업그레이드 경로 없음, 수동 절차 필요
비용 최적화 트래픽 증가에 따른 노드 증설, 자동 자원 조정은 별도 설정 필요

이러한 부분은 현재 단계에서는 학습과 구조 이해에 초점이 맞춰져 있기 때문에 감내할 수 있지만,

운영 규모가 커지거나 서비스 중요도가 높아질수록 명확한 한계로 작용할 수 있다.

최종 정리 문장

온기 서비스는 순간적인 사진 업로드 트래픽 폭발과 소규모 인력의 운영 부담을 해결하기 위해, 단일 3-Tier 아키텍처를 넘어 kubeadm 기반 Kubernetes 클러스터를 구축하고, 자동 확장성과 자가 복구 기능을 통해 서비스를 안정적으로 운영할 수 있는 기반을 마련했다