Kubernetes(EKS) 설계 - 100-hours-a-week/20-real-wiki GitHub Wiki
초기 프로젝트는 단일 EC2 인스턴스에 Docker 기반 컨테이너를 수동으로 배포하는 방식으로 시작되었다. 이후 kubeadm을 통해 자체 Kubernetes 클러스터를 구축하여 컨테이너 오케스트레이션의 핵심 개념을 직접 학습하는 과정을 거쳤다. 이러한 방식은 초기 학습 목적과 단기 운영에는 유효했으나, 다음과 같은 구조적, 운영적 한계에 직면하게 되었다:
- 운영자 의존성 과다: 제어 플레인의 업그레이드, 인증서 자동 갱신, 컨트롤 플레인 장애 복구 등 모든 운영 작업에 수동 개입이 필요했다.
- 확장성의 제약: 노드 오토스케일링과 로드밸런서 구성 시 다수의 수동 작업이 요구되어 서비스 확장에 시간과 비용이 과다 소요되었다.
- 보안 및 컴플라이언스 미흡: IAM 연동, Secret 암호화 저장, TLS 인증서 자동 갱신 등의 보안 구성에 별도의 운영 스크립트가 필요했다.
- 고가용성 구성의 복잡성: Control Plane의 멀티 AZ HA 구성이 비표준적이며 유지 관리가 어려웠다.
이러한 한계를 극복하고 프로덕션 수준의 안정성, 확장성, 자동화, 보안을 확보하기 위해 AWS의 완전관리형 Kubernetes 서비스인 Amazon EKS로 클러스터를 이식하고자 한다. EKS는 다음과 같은 핵심 기능을 제공한다:
- 제어 플레인 자동 관리 및 고가용성: AWS가 Control Plane을 자동으로 다중 AZ에 배치하고 관리한다.
- IAM 연동 및 보안 강화: Pod 단위 IAM 제어(IRSA)와 Secrets Manager 연동으로 안전한 리소스 접근 제어가 가능하다.
- Auto Scaling 연동: EC2 기반 NodeGroup과 Fargate 기반 Pod 수준의 유연한 오토스케일링이 가능하다.
- VPC CNI 기반 고성능 네트워킹: 클러스터 내부 Pod가 VPC IP를 직접 사용하여 네트워크 지연을 최소화한다.
| 서비스명 | 리소스 유형 | 배포 전략 | 선택 근거 |
|---|---|---|---|
| Web (Next.js) | Deployment | Rolling Update | SSR 웹 서비스로 빠른 배포 및 무중단 롤링 배포에 적합 |
| App (Spring Boot) | Deployment | Rolling Update | REST API 기반 서비스로 Stateless 환경에 적합 |
| AI 서비스 (FastAPI) | Deployment | Rolling Update | 추론 API 성격으로 Pod 독립성과 수평 확장에 유리 |
| DB (MySQL) | AWS RDS | - | 상태 저장 관리, 백업, 보안 관리에 RDS가 적합 |
| 로그 수집기 (Fluent Bit) | DaemonSet | - | 각 노드의 로그 수집을 위해 DaemonSet으로 구성 |
| 모니터링 서버 (Prometheus) | StatefulSet | - | 시계열 데이터 저장에 따른 Persistent Volume 유지 필요 |
| 대시보드 (Grafana) | Deployment | - | 외부 연동 가능하며 Stateless 구성으로 용이 |
| GitOps 배포 툴 (ArgoCD) | Deployment | - | Git 저장소 기반 선언형 배포 적용을 위함 |
- VPC 설계: 3개 가용 영역(AZ)에 퍼블릭, 프라이빗 서브넷을 각각 구성하여 고가용성 확보
-
NodeGroup 구성:
- EC2 기반 Auto Scaling Group으로 운영
- 최소 1개, 최대 3개까지 가용영역별 확장 가능
- Pod 네트워킹: Amazon VPC CNI 플러그인으로 Pod에 직접 VPC IP 할당
- Ingress Controller: AWS Load Balancer Controller로 ALB Ingress 리소스 구성
- IAM Roles for Service Account (IRSA): 서비스별로 세분화된 AWS IAM 권한을 Pod 단위로 부여
- Secrets Manager 연동: Spring Boot App의 DB 비밀번호, 외부 API 키 등을 안전하게 저장하고 Pod에서 참조
-
TLS 구성:
- AWS ACM을 이용한 도메인 인증서 자동 관리
- Cert-Manager와 연동하여 클러스터 내 자동 인증서 갱신
- 기본 전략: Rolling Update를 활용한 무중단 배포
-
확장 전략:
- Canary 배포를 위한 Argo Rollouts 또는 Flagger 도입 고려
- Blue-Green 전략은 필요 시 CodeDeploy 또는 ALB Weighted Target 방식으로 확장 가능
-
HPA (Horizontal Pod Autoscaler):
- CPU, 메모리 기반 자동 스케일링 설정
- metrics-server 설치 필요
-
Cluster Autoscaler:
- EC2 Auto Scaling Group과 연동하여 노드 수를 자동 조절
-
KEDA (옵션):
- Kafka, SQS, Redis 등 이벤트 기반 오토스케일링 적용 가능
| 구성 요소 | 방식 | 역할 |
|---|---|---|
| Fluent Bit | DaemonSet → CloudWatch Logs | 노드 로그 수집 및 전송 |
| Prometheus | Helm Chart + ServiceMonitor | 리소스 사용량 및 메트릭 수집 |
| Grafana | Datasource 연동 | Prometheus, Loki를 기반으로 대시보드 구성 |
| AlertManager | Webhook 연동 | Slack, Discord 등으로 경고 알림 발송 |
- Loki를 활용한 로그 검색 기능 추가 가능
- EKS Metrics Server와 통합하여 Pod 및 노드 리소스 지표 실시간 시각화
- 모든 애플리케이션 리소스를 Helm Chart로 템플릿화
-
infra/helm디렉토리에서 서비스별 Chart 관리 - 버전별 릴리스 및 롤백이 용이
- Git 저장소를 선언형 소스로 활용한 GitOps 배포
- EKS 클러스터에 ArgoCD 설치 후 Application CRD로 서비스 배포
- 롤백, 드리프트 감지, 배포 이력 관리를 중앙에서 수행
| 단계 | 주요 작업 내용 |
|---|---|
| 1단계 | eksctl또는 Terraform으로 EKS 클러스터 생성 |
| 2단계 | VPC, Subnet, IAM 연동 구성 |
| 3단계 | Helm Chart 기반 서비스 이식 (Next.js, Spring, FastAPI 등) |
| 4단계 | ArgoCD 배포 및 GitHub Actions와 연계된 CI/CD 구성 |
| 5단계 | Fluent Bit, Prometheus, Grafana 등 운영 인프라 통합 |
- Fargate 기반 Pod 이식: 서버리스 기반 워크로드로의 점진적 이전 고려
- Spot Instance 활용: 비핵심 워크로드에 대한 비용 최적화 전략 적용
- Service Mesh 도입 검토: Istio, Linkerd 등을 통한 Multi-Cluster 통신과 보안 강화 검토
- OIDC 인증 연동: SSO 통합을 위한 Cognito, Keycloak 등과의 연계
기존의 kubeadm 기반 클러스터 운영은 컨테이너 오케스트레이션의 전반적인 개념을 학습하는 데 적절했으나, 안정성과 확장성 측면에서는 수동 운영의 한계를 명확히 드러냈다. AWS EKS로의 이식은 다음과 같은 측면에서 전략적인 전환이다:
- 제어 플레인 운영의 자동화: 관리 부담을 줄이고 장애 복구 시간을 최소화한다.
- 보안 및 권한 제어 강화: IAM, Secrets Manager, ACM 등 AWS 리소스와의 긴밀한 통합으로 보안 체계를 강화한다.
- 고가용성과 확장성 확보: 다중 AZ, Auto Scaling, 서비스 메시 확장 등 현대적 인프라 요건을 충족한다.
- CI/CD 및 GitOps 통합: ArgoCD, Helm, GitHub Actions 기반 자동화된 배포 환경을 정착시킨다.
따라서, 본 클러스터 이식은 단순한 기술 변경이 아닌, 프로덕션 수준의 안정성과 유연성을 확보하기 위한 필수적 진화 과정이다.