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

목차

Kubernetes

왜 Kubernetes를 사용하나요?

기존에는 kubeadm 기반의 단일 클러스터 환경에서 서비스를 운영했지만, 다음과 같은 유연성 및 안정성의 한계가 명확히 드러났습니다:

1. 장애 복구에 지나치게 많은 수작업이 필요했습니다.

  • 예를 들어, 마스터 노드에서 etcd가 crash되었을 때:
    • 클러스터 전체가 정지되며, 즉시 서비스 중단이 발생합니다.
    • 운영자는 직접 snapshot 복원, CA 인증서 재배포, kubeadm init 재설정 등을 수행해야 했습니다.
    • 복구 절차는 다음과 같이 복잡합니다: 
      etcdctl snapshot restore /var/lib/etcd/snapshot.db \
  --data-dir /var/lib/etcd-from-backup
  • 이 과정은 운영자의 숙련도에 의존적이며, 복원 시간도 예측 불가능합니다.
  • 반면, EKS는 Control Plane을 AWS가 관리하므로, 장애 감지 및 복구가 자동으로 이루어집니다.
    • 운영자는 워커 노드와 워크로드에만 집중하면 됩니다.

2. 트래픽 변화에 대응하기 어렵습니다.

  • kubeadm 기반 환경에서는 늘어나는 트래픽에 대비하기 위해 수동으로 Pod를 늘리거나 노드를 추가해야 하며, Cluster Autoscaler 및 HPA 구성도 직접 유지 관리해야 합니다.
  • Kubernetes (특히 EKS)는 다음과 같은 기능을 통해 이를 자동화합니다:
    • HPA (Horizontal Pod Autoscaler)
    • Managed Node Group
    • Cluster Autoscaler
  • 덕분에 실시간으로 Pod와 Node가 자동 확장되어, 트래픽 증가에도 서비스가 안정적으로 유지됩니다.

3. 운영환경이 복잡해졌습니다.

  • 저희 서비스는 더 이상 단일 서버 기반이 아닙니다:
    • FastAPI 기반 AI 서버 (GCP)
    • 프론트엔드 정적 자산 (AWS S3 + CloudFront)
    • 이미지 업로드 스토리지
  • Kubernetes의 네임스페이스, 서비스 디스커버리, ConfigMap/Secret 관리, RBAC 등의 기능을 통해 환경을 명확하게 분리하고, 배포/운영을 체계적으로 구성할 수 있게 되었습니다.

이외에도, 쿠버네티스를 도입하면서 다음과 같은 운영상 이점을 크게 체감할 수 있었습니다:

인프라 추상화: 인스턴스를 직접 관리할 필요 없이, 워커 노드만 운영하면 됩니다.

  • 어떤 서버에 어떤 애플리케이션을 배치할지 고민하지 않아도 되며,
  • Kubernetes가 스케줄링, 재시작, 복구를 자동으로 처리해줍니다.

선언형 배포와 빠른 확장성:

  • Kafka, Redis, Vector DB 등 새로운 기술을 도입할 때도, 선언형 YAML 기반으로 명확한 설정만 준비되면 손쉽게 HA 구성 및 롤링 배포가 가능합니다.

  • 특히 프로젝트 막바지에 기능이 급히 추가되거나, 트래픽 변화에 대응해야 할 때, 빠른 배포와 안정성을 동시에 확보할 수 있는 구조입니다.

이러한 이유로, kubeadm 환경의 한계를 넘어서기 위해 Kubernetes(EKS)를 도입하게 되었습니다.