Docker Compose 기반 운영의 구조적 한계로 인해 다음과 같은 문제들이 발생했다:

• 오케스트레이션 부재: 컨테이너 단위 헬스체크, 자동 복구 기능 미지원
• 네트워크 통제 한계: ALB 트래픽 분산은 가능하지만, 컨테이너 간 세부 통신 정책 적용 불가
• 모니터링 및 장애 대응 부족: Compose 자체 상태 감시 기능 미비, 수동 점검 의존
• 보안 정책 미흡: 네트워크 분리는 가능하나, 서비스 간 인증/인가(mTLS) 미지원
• 확장성 부족: 대규모 컨테이너 수 관리 및 클러스터링 자동화 기능 미비

Docker Compose 한계를 극복하고, 다음 요구사항을 충족하기 위해 Kubernetes를 도입한다:

• 고가용성(HA): 무중단 운영 및 장애 자동 복구(Self-healing)
• 확장성 확보: 멀티 노드 운영 및 오토스케일링
• 서비스 간 통신 정책 제어: Kubernetes NetworkPolicy 적용
• 운영 자동화: 배포, 복구, 모니터링 체계 구축
• 멀티 클라우드 지원: AWS-GCP 간 연동 구성

외부 → AWS ALB → Kubernetes NGINX Ingress Controller → Kubernetes Service → Pod

• VPC: 192.168.0.0/16
• Private Subnet
  • 192.168.110.0/24 (AZ 2a/2c)
    • Kubernetes Master Node
    • Kubernetes Worker Node
  • 192.168.210.0/24 (AZ 2a/2c)
    • DB 서버 전용 인스턴스 배치
• Master Nodes (kubeadm init):
  • AZ 2a: t3.medium (vCPU 2, RAM 4GB)
  • AZ 2c: t3.medium (vCPU 2, RAM 4GB)
• Worker Nodes (kubeadm join):
  • AZ 2a: m5.large (vCPU 2, RAM 8GB)
  • AZ 2c: m5.large (vCPU 2, RAM 8GB)
• DB Nodes:
  • AZ 2a: r6i.large (vCPU 2, RAM 16GB)
  • AZ 2c: r6i.large (vCPU 2, RAM 16GB)
  • 스토리지: gp3 EBS, IOPS 3000 설정
• 스토리지:
  • Kubernetes용: EBS PVC 자동 프로비저닝
  • DB용: 별도 gp3 EBS 고성능 디스크 사용
• 로드밸런서:
  • AWS ALB 사용, 외부 트래픽 수신

• VPC: 10.0.0.0/16
• Private Subnet:
  • 10.0.20.0/24 (Master Node, Worker Node 배치)
• Master Nodes (kubeadm init):
  • AZ a: e2-medium (vCPU 2, RAM 4GB)
  • AZ b: e2-medium (vCPU 2, RAM 4GB)
• Worker Nodes (kubeadm join):
  • CPU 전용 노드: e2-medium
  • GPU 전용 노드: g2-standard-8 (NVIDIA L4)
• 스토리지:
  • GCP Persistent Disk(PD) 기반 PVC 자동 프로비저닝

• AWS ALB 앞단에 Route53을 통해 도메인 DNS 관리 구성
• HTTPS 통신을 위해 AWS ACM 인증서 발급 및 NGINX Ingress Controller와 연동
• ALB에 AWS WAF를 적용하여 OWASP Top 10 기반 공격 방어 구성
• AWS-GCP 간 VPC Peering을 통한 사설망 통신 구성
• Kubernetes 네트워크 정책(NetworkPolicy)을 통한 서비스 간 통신 통제
• Frontend 서버에서 DB 서버(192.168.210.0/24)로의 직접 접근 차단
• Backend API 서버를 통한 데이터베이스 요청 수행
• ECR을 통한 이미지 관리 및 배포
  • AWS ECR을 Docker 이미지 저장소로 사용하여 배포 이미지를 관리
  • GitHub Actions에서 빌드된 Docker 이미지를 ECR로 Push
  • 이미지 버전 관리는 태그(Tag) 기반으로 관리하며, 커밋 SHA 또는 버전 넘버를 사용하여 롤백 및 버전 추적을 용이하게 구성
  • 롤백 전략: 문제가 발생한 버전의 이미지를 이전 태그를 통해 쉽게 복구 가능

• Control Plane 고가용성 확보
  • Kubernetes Master Node를 AZ 2a, 2c에 이중 배치
  • 단일 AZ 장애 발생 시에도 클러스터 제어 무중단 유지
• Data Plane 가용성 확보
  • Kubernetes Worker Node를 AZ 2a, 2c에 분산 배치
  • 특정 AZ 장애 시에도 서비스 트래픽 무중단 복구
• DB 서버 고가용성 확보
  • Database 서버를 Private Subnet(192.168.210.0/24)에 AZ 2a, 2c로 이중 배치
  • 데이터 계층 무중단 운영 및 연속성 확보
• 데이터 플레인 확장성 확보
  • AWS와 GCP를 기반으로 Kubernetes Worker Node 수평 확장 지원
  • 멀티 클라우드 워크로드 분산 구성
• 보안 강화
  • AWS-GCP VPC Peering을 통한 사설망 통신 구성
  • Kubernetes NetworkPolicy를 통한 서비스 간 통신 통제
  • Frontend 서버의 DB 서버 직접 접근 차단
  • Backend API 서버를 통한 데이터베이스 요청 수행
• 운영 자동화 기반 마련
  • GitOps 기반 Git 상태 기준 Kubernetes 리소스 자동 동기화
  • 운영 수작업 최소화

• *AWS Elastic Container Registry(ECR)**을 Docker 이미지 저장소로 사용하여 배포 이미지를 관리
• GitHub Actions에서 빌드된 Docker 이미지를 ECR로 Push
• 이미지 버전 관리는 태그(Tag) 기반으로 관리하며, 커밋 SHA 또는 버전 넘버를 사용하여 롤백 및 버전 추적을 용이하게 구성
• 롤백 전략: 문제가 발생한 버전의 이미지를 이전 태그를 통해 쉽게 복구 가능

[장애 발생 또는 배포 실패 감지]
        ↓
[이전 정상 버전 Docker 이미지 선택 (예: :v1.2.3)]
        ↓
[kubectl set image 또는 Deployment Manifest 수정]
        ↓
[ArgoCD 자동 Sync 또는 수동 Sync 수행]
        ↓
[이전 버전 서비스 정상 복구]

• GitHub Actions를 사용해 애플리케이션 빌드, 테스트, 이미지 빌드/푸시, Kubernetes 배포 자동화
• PR(Pull Request) 생성 시 코드 품질 검사 및 테스트 자동 실행
• main 브랜치 머지 시 Docker 이미지 Build & ECR Push
• ArgoCD가 Git 변경을 감지하여 Kubernetes에 자동 배포

• ArgoCD를 사용해 Git 리포지토리를 클러스터 상태의 단일 소스(Single Source of Truth)로 구성
• Git 상태 기준으로 클러스터를 자동 동기화
• Drift(편차) 발생 시 자동 복구 처리
• Git 커밋만으로 배포 및 롤백 수행

• 기본 모니터링 도구 구성
  • AWS CloudWatch (EC2, EBS, ALB Metrics)
  • GCP Monitoring (Compute Engine, PD Metrics)
• 추가 확장 가능성 고려
  • 필요 시 Prometheus + Grafana Stack 추가 구성
• 알림 체계 구성
  • CloudWatch Alarm, GCP Alerting을 Slack Webhook과 연동
  • 장애, 스케일링 이벤트, 배포 성공/실패를 Slack으로 실시간 통보

[GitHub Repository]
    ↓ (Push/PR Event)
[GitHub Actions]
    ↓ (Docker Build/Push, Manifest Update)
[ECR Registry] + [Git Repository 변경]
    ↓ (Auto Sync)
[ArgoCD]
    ↓ (Deploy/Sync)
[Kubernetes Cluster]
    ↓ (Metrics/Logs Export)
[CloudWatch/GCP Monitoring]
    ↓ (Alarm Trigger)
[Slack Notifications]

[Worker Node 장애 발생]
        ↓
[Kubernetes Node 상태 "NotReady"로 변경]
        ↓
[Kubernetes Scheduler가 해당 노드에서 실행 중이던 Pod를 다른 정상 노드로 자동 재스케줄링]
        ↓
[Ingress Controller 및 ALB가 새로 스케줄된 Pod로 트래픽 자동 전달]
        ↓
[서비스 무중단 유지]

[Worker Node 장애로 Capacity 부족 발생]
        ↓
[Cluster Autoscaler가 신규 워커노드 자동 추가]
        ↓
[Kubernetes Scheduler가 신규 노드에 Pod 스케줄링]
        ↓
[서비스 확장 및 복구 완료]

• Kubernetes Node Controller가 node-monitor-grace-period 동안 Heartbeat 수신 실패 시 노드를 "NotReady"로 표시
• ReplicaSet을 통해 보장된 Pod 수를 유지하기 위해 Scheduler가 다른 정상 노드로 Pod 자동 재배치
• AWS ALB + Ingress Controller는 Kubernetes Service 레벨 라우팅을 사용해 Pod IP 변경에도 트래픽 자동 연결
• Cluster Autoscaler가 노드 Capacity 부족 시 워커노드를 자동 확장하여 부하를 분산

롤링 업데이트 흐름

[New Docker Image Build & Push (GitHub Actions)]
        ↓
[Deployment Manifest Update (GitHub Actions)]
        ↓
[Git Repository 업데이트 감지 (ArgoCD)]
        ↓
[Kubernetes Deployment Rolling Update 시작]
        ↓
[기존 Pod를 순차적으로 종료하고 새 버전 Pod를 순차적으로 기동]
        ↓
[ALB-Ingress-Service를 통한 무중단 트래픽 유지]

대규모 트래픽 변동이나 고위험 배포의 경우

신규 버전과 기존 버전을 병렬 배포 후 트래픽 스위칭 방식으로 무중단 전환하는 Blue-Green Deployment 전략 고려

• Rolling Update 전략은 기존 Pod를 한 번에 모두 교체하지 않고 순차적으로 새 버전으로 교체
• maxUnavailable, maxSurge 설정을 통해 배포 중 가용성 보장
• ArgoCD가 Git 변경사항을 실시간 감지해 Deployment 자동 동기화 수행
• 필요 시 Blue-Green Deployment로 배포 안정성과 롤백 신속성 확보

Control Plane 장애 복구 흐름

[Master Node 장애 발생]
        ↓
[etcd 스냅샷 복원 절차 수행]
        ↓
[새 Master Node로 kubeadm init --skip-phases=etcd 실행]
        ↓
[Kubernetes API Server 및 Control Plane 기능 복구]
        ↓
[클러스터 정상화]

• Kubernetes NetworkPolicy를 통해 서비스 간 통신 제어
• Frontend 서버에서 DB 서버로의 직접 접근 차단
• Backend API 서버를 통한 데이터베이스 접근만 허용
• 필요 시 Pod 간 통신 암호화를 위해 Calico IPsec 또는 WireGuard 적용 고려
• 서비스 간 인증 강화를 위해 Istio 기반 mTLS 적용 가능성 검토

📌 본 페이지는 2025년 4월 29일에 마지막으로 업데이트되었습니다.