☁️ 5단계: Kubeadm 오케스트레이션 - 100-hours-a-week/7-team-ddb-wiki GitHub Wiki

Docker 기반으로 서비스 기반에서 Kubernetes 기반의 클러스터 환경으로 전환하는데 필요한 Kubeadm 도입 및 클러스터 설계 방안을 다룬다. Kubeadm을 활용한 확장성, 고가용성 및 안정적인 서비스 운영 환경을 마련하여 지속적으로 증가하는 서비스 요구사항을 효과적으로 관리한다.

현재 컨테이너 기반으로 운영되고 있는 서비스의 트래픽이 증가하고 있다. 또한 서비스를 지원하기 위한 사이드카가 많아지면서 관리에 어려움을 겪고 있다. 특히 무중단 배포 및 자동 복구 같은 고급 기능 구현이 어려워 Kubernetes 오케스트레이션 도구의 도입이 필요하다.

Kubeadm을 선택한 이유는 Kuberenetes의 표준 구조를 유지하면서 클러스터 설정을 유연하게 구성하기 위함이다. 또한 CI/CD, 모니터링, 보안 설정 등 요구하는 세부적인 통제와 효율적 관리가 가능하다.

• 서비스 확장성 향상 및 안정적인 운영
• 무중단 서비스 배포 및 자동 복구 기능 확보
• Kubernetes 표준 구조 기반의 유연한 클러스터 구성

• 서비스 운영 환경 (마스터 1개, 워커노드 2개)
• Kubernetes 클러스터 관리 (calico CNI, nginx ingress)
• 배포 자동화 및 관리 (ArgoCD, Jenkins, Helm, App of Apps 패턴)

1. Application Developer가 Application Repository에 commit을 날린다.
2. github webhook이 이를 감지하여 jenkins server에 webhook을 날린다.
3. jenkins server에서 application image를 빌드 후 container registry에 push한다.
4. 생성된 image의 tag를 GitOps Repository에 반영하여 commit한다.
5. GitOps Repository를 Observe하고 있던 Argo CD가 변경사항을 가져온다.
6. Argo CD는 변경된 사항을 반영하여 kubernetes에 Sync한다.

네트워크

클러스터의 네트워크 구성에는 CNI 플러그인으로 Calico를 사용한다. kubeadm으로 클러스터를 초기화한 뒤, 공식에서 제공하는 Calico 매니페스트를 적용하여 CNI를 구성한다. Kubernetes의 NetworkPolicy를 기본적으로 지원해 보안 제어가 가능하고, 필요 시 더 정교한 정책도 적용할 수 있어 유연성이 뛰어나다.

다른 도구와의 비교

• Flannel vs Calico
  • Flannel은 오버레이만 제공하는 단순한 구조지만 NetworkPolicy가 없다.
  • Calico는 동일한 수준의 간단한 설치도 가능하면서 정책, 성능 모두 압도적이다.
• Cilium vs Calico
  • Cilium은 L7, eBPF, Service Mesh까지 되는 하이엔드 솔루션이지만, 구성과 트러블슈팅이 어렵고, 커널 호환성 이슈도 종종 있다.
  • Calico는 eBPF도 지원하면서, 안정성과 운영 난이도는 낮다.
• Weave vs Calico
  • Weave는 설치 간편하고 시각화 도구도 예쁘지만, 대규모 운영에는 부적합하고 성능이 낮다.
  • Calico는 스케일 아웃에 강하고, 성능 손실이 적다.
• Canal vs Calico
  • Canal은 Flannel + Calico 조합이지만, 결국 Calico에서 제공하는 기능 일부만 쓰는 구조고 BGP, eBPF는 사용하지 않는다

모니터링

Prometheus를 메트릭 수집과 알림 시스템으로 채택했다. 채택한 가장 큰 이유는 자가-호스팅 환경에서도 손쉽게 설치하고 유지할 수 있다는 점이다. Helm 차트를 한 번 배포하면 설치·업데이트가 모두 GitOps 파이프라인에 자연스럽게 녹아들고, 이후 버전 관리까지 코드로 일관되게 처리된다. 게다가 Prometheus는 Service Discovery 기능과 Exporter 연동 기능을 갖추고 있어, Pod IP가 바뀌어도 메트릭 수집이 자동으로 따라붙는다. Alertmanager가 기본 내장돼 있어 규칙만 정의하면 즉시 Discord Webhook으로 경보를 보낼 수 있다.

시각화 층에는 Grafana를 선택했다. Grafana는 Prometheus가 수집한 메트릭뿐 아니라 Loki의 로그 트레이스, CloudWatch 등 데이터 소스를 한 대시보드에서 자유롭게 조합할 수 있어 풀스택 관찰을 단일 화면에 집약할 수 있다. 대시보드 정의를 JSON 파일로 내보내 Git 리포지터리에 커밋하면 Argo CD가 자동으로 동기화해 주기 때문에, 대시보드 자체도 쿠버네티스 리소스처럼 형상 관리·롤백이 가능하다. 또한 SLA 지표, 배포 이벤트 주석, 시간 범위나 네임스페이스 필터 같은 기능을 패널 변수만으로 손쉽게 추가할 수 있다.

다른 도구와의 비교

Google Cloud Monitoring (Ops Agent) vs Prometheus

• Google Cloud Monitoring : GKE 노드에 Ops Agent를 설치하면 GCP 서비스 지표를 자동 수집하지만, 자체 애플리케이션 메트릭은 추가로 custom.googleapis.com 형식으로 전송해야 하며, 데이터·알림 모두 샘플·MiB 단위 과금이라 빈번한 스크래핑·초단위 알림에 비용 부담이 커질 수 있다.
• Prometheus : kube-prometheus-stack Helm 한 번으로 설치 후 Service Discovery가 자동 동작하고, 원하는 15초 스크래핑·초단위 Alertmanager 알람도 추가 비용 없이 처리된다.

Datadog vs Prometheus

• Datadog : Agent 하나로 인프라·APM·RUM을 한 번에 볼 수 있고 UI·ML 알람이 훌륭하지만 호스트·DPM 단위 과금이라 노드·트래픽이 늘면 비용이 급증할 수 있다.
• Prometheus : 오픈소스라 라이선스 비용이 0원이며, 필요한 기능은 Pyroscope·Tempo 등 CNCF 프로젝트로 단계적 도입이 가능해 초기 투자 비용이 낮다.

InfluxDB(+Telegraf) vs Prometheus

• InfluxDB : Flux 쿼리로 복잡한 시계열 계산이 가능하지만, Kubernetes Exporter·Alertmanager 생태계가 상대적으로 빈약하다.
• Prometheus : kube-state-metrics·node-exporter 등 공식 Exporter가 풍부하고, Alertmanager를 통해 Discord Webhook으로 즉시 알림을 전송할 수 있다.

Kibana vs Grafana

• Kibana : Elasticsearch 로그 탐색·SIEM 분석에 강하지만 메트릭·트레이스 합성은 유료 X-Pack에 의존한다.
• Grafana : Loki 플러그인으로 로그·트레이스를 같은 패널에 얹고, 패널 조건을 Discord으로 직접 알림 보낼 수 있다.

부가 도구

• cAdvisor : 컨테이너/Pod 단위의 CPU·메모리·디스크·네트워크 실사용량을 실시간으로 수집해 /metrics/cadvisor 엔드포인트로 노출한다. kubelet에 기본 내장돼 별도 데몬을 설치할 필요가 없고, kube-prometheus-stack이 배포하는 kubelet ServiceMonitor가 자동으로 스크랩한다.
• Promtail : Loki 계열의 공식 로그 수집 에이전트. DaemonSet 배포로 노드 로컬 로그 파일과 컨테이너 stdout을 실시간 tail하며, Prometheus와 동일한 scrape_configs/서비스 디스커버리 문법을 사용해 Pod 라벨을 그대로 로그 라벨로 승계한다.
• Node Exporter : 리눅스 노드(OS) 레벨의 CPU, 메모리, 파일시스템, 네트워크, 커널 pressure stall(PSI) 등 하드웨어·커널 지표를 수집한다. 역시 DaemonSet 하나면 모든 워커 노드가 커버된다.
• kube-state-metrics (KSM) : Kubernetes API Server를 Subscribe 해 Deployment·Pod·HPA·PVC 등 오브젝트의 스펙과 상태를 메트릭으로 변환한다.

CI/CD - GitOps

Jenkins를 CI 도구로 선택했다. 선택한 이유는 유연성과 확장성 때문이다. GitHub Webhook이 커밋을 감지하면 Jenkins가 즉시 빌드를 실행하고, 결과물인 컨테이너 이미지를 Docker Registry(GAR 등)에 푸시한다. 플러그인을 통해 다양한 SCM과 손쉽게 통합할 수 있어 복잡한 빌드·배포 파이프라인을 구성하기 용이하다.

Argo CD는 Kubernetes 환경에서 GitOps를 구현하기 위해 도입되었다. 애플리케이션과 인프라 정의를 Git 저장소에 선언적으로 관리한 뒤, Argo CD가 레포지토리를 지속적으로 모니터링해 변경 내용을 클러스터 상태에 자동으로 반영한다. 덕분에 배포 이력과 현재 상태를 모두 Git으로 추적할 수 있어 감사·검토가 쉬워지고, 문제가 발생하면 원하는 시점의 커밋으로 손쉽게 롤백할 수 있다. Git을 원본 진실 저장소로 삼아 변경 과정을 투명하게 기록하고, 배포 자동화까지 아우르는 점이 Argo CD를 선택한 핵심 이유다.

다른 도구와의 비교

Jenkins vs GitHub Actions

• Jenkins는 복잡한 워크플로우를 처리하거나 대규모 환경에 적합한 도구로, 시각적인 UI를 통해 파이프라인의 상태를 직관적으로 확인할 수 있다. 또한, 다양한 상황에 대응할 수 있는 레퍼런스와 커뮤니티 자료가 풍부하다는 강점이 있다. 반면 GitHub Actions는 GitHub과 연동성이 높고 간편한 설정으로 사용할 수 있지만, 대규모 환경에서는 복잡한 파이프라인 구성의 유연성과 외부 시스템과의 통합 측면에서 제약이 있으며, 실행 환경 커스터마이징이 제한적이다.

ArgoCD vs Flux

• ArgoCD는 GitOps 도구 중에서도 직관적인 GUI를 제공하여 배포 상태를 시각적으로 모니터링하고 관리하기에 용이하다. Flux에 비해 웹 기반의 사용자 친화적인 인터페이스를 통해 변경 이력, 동기화 상태, 배포 오류 등을 한눈에 파악할 수 있어, 팀 단위 협업이나 운영 환경에서 특히 효율적이다. Flux는 커맨드라인과 YAML 중심의 선언적 설정 방식에 강점을 가지지만 웹 UI가 기본 제공되지 않아 시각적 피드백이 부족하고 상태 확인이나 문제 추적이 어려울 수 있으며, 학습 곡선이 상대적으로 높다는 단점이 있다. 이러한 점에서 시각적 관리 편의성과 접근성이 중요한 프로젝트에는 ArgoCD가 더 적합하다.

kubeadm 초기화 파라미터

sudo kubeadm init \
--pod-network-cidr=10.96.0.0/12 \
--apiserver-advertise-address=172.16.211.110

노드 토폴로지

서비스 논리 단위 & 네이밍

가이드

• 한 컨테이너 = 한 마이크로서비스 → Pod 당 하나의 main 컨테이너 원칙
• 로그 수집용 sidecar(promtail)·메트릭 sidecar(Prometheus Exporter)는 필요 시만 포함

운영 전략

워크로드 오브젝트 사용 정책

네이밍 규칙: <svc>-<type>

레이블 표준: app.kubernetes.io/{name,component,version,part-of}

스토리지 볼륨 전략

로깅 전략

로깅 정책

• 어플리케이션 → STDOUT JSON 로그
• 노드/시스템 → systemd-journald
• 수집 : Promtail (DS) → Loki (1 replica, S3 chunk)
• 보존 / 검색
  • 30 일 – Loki
  • 90 일 – S3 Glacier Deep Archive
• 상관추적 : TraceID 헤더 → Grafana Explore 에서 한 화면 3-pane(Trace·Metric·Log)

배포(Deployment) 설계

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: svc-fe-rollout
  labels: {tier: frontend, env: prod}
spec:
  replicas: 2
  revisionHistoryLimit: 5
  selector:
    matchLabels: {tier: frontend}
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels: {tier: frontend, env: prod}
    spec:
      containers:
      - name: frontend
        image: be:1
        imagePullPolicy: always
        ports:
        - containerPort: 8080
        resources:
          requests: {cpu: "250m", memory: "512Mi"}
          limits:   {cpu: "500m", memory: "1Gi"}
        livenessProbe:   {httpGet: {path: /health, port: 8080}, initialDelaySeconds: 10, periodSeconds: 15}
        readinessProbe:  {httpGet: {path: /ready,  port: 8080}, initialDelaySeconds: 5,  periodSeconds: 5}

스케일링 전략

1. 메트릭 파이프라인
   • metrics-server : CPU/메모리 확보
   • Prometheus Adapter : 필요한 메트릭 선별해서 노출
2. Vertical Pod Autoscaler(VPA) : 초기-리소스 탐색 단계에서만 사용, 운영 환경에서는 Horizontal Pod Autoscaler 사용
3. Horizontal Pod Autoscaler(HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    name: svc-fe-rollout
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

CPU 60 % 초과 시 30 초 평균으로 계산, 15 초 간격 재평가

장애 복구

모니터링·로그·알림

• 메트릭 : kube-state-metrics → Prometheus → Grafana 대시보드
• 로그 : Promtail → Loki → Grafana Explore
• 알림 : Prometheus ******Alertmanager → Discord Webhook

보안·네트워크 정책

• 네임스페이스별 RBAC 역할 묶음 (Role/RoleBinding)
• 서비스 간 통신 제어 : NetworkPolicy로 최소 권한 접근
• 시크릿 관리 : SealedSecret 또는 External-Secrets로 GitOps 연동

운영 체크리스트

목표: 점심 (11:30-13:30)·저녁 (18:00-20:00) 피크 트래픽에서도 P95 ≤ 1000 ms, Error Rate < 0.1 %를 유지하고 HPA 스케일-업 < 3 분, 스케일-다운 < 10 분임을 검증한다.

퍼포먼스 테스트 전략

테스트 시나리오

측정·판정 지표

합격 판정은 모든 지표가 통과 기준 이하이며 Alert 발생이 없을 때로 정의한다.

Soak

1. 스케줄링

   부하 테스트 일정에 맞추어 실행한다.

   Load → Stress를 수동 트리거하고, 스프린트당 1회 Soak 24h 를 수행한다.

2. nGrinder 스크립트 골격

   @Process
   public void process() {
       // RPS 프로파일 CSV 로드
       // Think Time = 1000/RPS – actual Latency
       // TraceID 헤더 삽입 → Loki·Tempo 연계
   }

3. 모니터링

   Grafana 대시보드를 nGrinder “External Monitor URL”에 등록하고, Latency 상승 시 Discord #perf-alert로 실시간 알림한다.

4. 리포트·이슈 관리

   nGrinder Report API JSON → Python 스크립트로 S3에 저장하고 PR comment에 요약표를 첨부한다.

   기준 초과 항목은 perf-label JIRA 티켓을 발행하여 원인 분석 후 재테스트를 거치기 전까지 배포를 보류한다.

환경별 총 비용

서비스별 상세 비용

• 초기 구축 단계에서의 수동 설정 필요성 존재 (스토리지 구성, 네트워크 설정 등)
• 클러스터 운영을 위한 Kubernetes 전문 지식 필수
• 외부 스토리지 및 볼륨 공유 설정 제한 가능성 존재 (Cloud Native Storage 솔루션 필요)

• 서비스의 높은 가용성 확보 및 장애 대응력 강화
• 확장성 향상을 통해 트래픽 증가에 유연한 대응 가능
• 무중단 배포 및 서비스 중단 최소화

• 클러스터 운영 시 모니터링 시스템을 활용하여 가용성 및 성능 지표 평가
• 장애 발생 시 복구 시간 및 자동 복구 효과 평가
• 지속적이고 빈번한 배포 자동화로 서비스 출시 속도 향상 평가

본 설계를 통해 Kubernetes 기반의 고가용성 및 확장 가능한 클러스터 환경을 구축하고, 안정적인 서비스 운영 환경을 확보할 수 있을 것으로 기대한다. 향후 계획으로는:

• Control Plane 고가용성을 위한 EKS 도입
• Kubernetes 고급 기능 추가 도입 검토 (예: 서비스 메시, 고급 모니터링 등)
• 서비스 규모 확대에 따른 노드 추가 및 클러스터 확장 전략 수립
• 주기적인 재평가를 통한 클러스터 운영 최적화 및 성능 개선을 지속적으로 수행할 예정이다.