시스템 개발 및 관리/이커머스 효율화: NLP 모델 적용

[Kubernetes 배포 환경 구축] Kubernetes 클러스터 생성

Data Jun 2025. 3. 1. 18:59

현재(AS-IS) 배포 환경을 나타낸 다이어그램으로, 서버와 Google Cloud Storage 간의 연동 구조를 보여준다.

 

  • 서버에서는 Docker 컨테이너를 사용하고 있으며, 사용자는 서버에 접근하여 서비스를 이용한다.
  • 서버에서 Google Cloud Storage와 데이터를 주고받는 구조이다.
  • 현재 배포 환경의 문제점으로 On-premise 리소스 부족, Docker Container 관리 한계, Container Registry 부재가 언급되어 있다.

현재 배포 환경은 온프레미스(로컬 서버)에서 애플리케이션을 실행하고, Google Cloud Storage(GCS)를 데이터 저장소로 활용하는 하이브리드 구조입니다.

문제점

  1. 온프레미스 리소스 부족
    • 로컬 서버의 성능이 제한적이며, 트래픽 증가 시 확장(Scaling)이 어려움.
  2. Docker Container 관리 한계
    • 컨테이너 운영 및 배포를 수동으로 관리해야 해 유지보수 부담이 큼.
  3. Container Registry 부재
    • 컨테이너 이미지를 체계적으로 저장·관리할 저장소가 없어 배포 및 버전 관리가 비효율적임.

 

TO-BE 배포 환경 설명

이 TO-BE 배포 환경은 GCP 기반의 Kubernetes 및 Container Registry를 활용한 클라우드 네이티브 아키텍처로 전환하는 것을 목표로 합니다.

구성 요소

  1. GCP Registry
    • Docker 컨테이너 이미지를 저장 및 관리하는 GCP Artifact Registry를 사용.
    • Helm을 활용해 Kubernetes 애플리케이션을 패키징하고 배포.
  2. GCP Kubernetes (GKE)
    • Kubernetes 환경을 GCP에서 운영하여 자동 확장, 자동 복구, 배포 자동화 가능.
    • 사용자 요청을 처리하고, GCS와 데이터를 주고받음.
  3. Google Cloud Storage
    • 애플리케이션 데이터 및 기타 저장소 역할.

변경 및 개선점

온프레미스에서 GCP Kubernetes 환경으로 이전 → 확장성 및 안정성 강화
GCP Registry 도입 → 컨테이너 이미지의 체계적인 관리 가능
Helm을 활용한 Kubernetes App 배포 → 자동화된 배포 및 관리 효율성 향상

이전 AS-IS 환경의 문제점(온프레미스 리소스 부족, 수동 배포, 이미지 관리 부재)을 해결하며, 클라우드 네이티브 방식으로 운영을 최적화하는 방향입니다. 🚀

 

💡 TO-BE 방향

  • 애플리케이션 실행 환경을 클라우드(GCP)로 이전하여 확장성과 운영 효율성을 개선.
  • Kubernetes(GKE)와 Container Registry 도입으로 자동화된 배포 및 관리 체계 구축.

 

사용자와 각 구성 요소의 관계

  1. 사용자 → GCP Kubernetes (GKE) 접근
    • 사용자는 웹 애플리케이션이나 API 등을 GCP Kubernetes에서 실행 중인 서비스에 요청합니다.
    • GKE는 이러한 요청을 처리하고 필요한 리소스를 자동으로 할당합니다.
  2. GCP Kubernetes ↔ GCP Registry
    • GKE에서 실행될 애플리케이션 컨테이너 이미지는 GCP Registry에서 가져옵니다.
    • Helm을 사용하여 Kubernetes에 배포할 때, GCP Registry에서 최신 컨테이너 이미지를 다운로드하여 배포합니다.
  3. GCP Kubernetes ↔ Google Cloud Storage
    • GKE에서 실행 중인 애플리케이션이 데이터를 저장하거나 불러올 때, Google Cloud Storage(GCS)를 활용합니다.
    • 예를 들어, 애플리케이션이 사용자 업로드 파일을 저장할 경우 GCS에 저장됩니다.

 

즉, GCP Registry는 애플리케이션 실행을 위한 컨테이너 이미지를 저장하는 곳이고, GCS는 애플리케이션이 다루는 데이터(파일, 로그 등)를 저장하는 곳이에요! 🚀

결론

  • 사용자는 GCP Kubernetes(GKE)에 배포된 애플리케이션을 사용하게 됩니다.
  • Kubernetes는 GCP Registry에서 컨테이너 이미지를 가져와 실행하고,
  • 데이터는 Google Cloud Storage(GCS)에 저장하여 효율적인 운영이 가능해집니다. 🚀

 

 

Autopilot 모드 (자동 관리 모드)

완전 관리형 Kubernetes → GCP가 클러스터 운영을 자동으로 관리
노드 및 인프라 자동 관리 → 사용자가 직접 노드를 생성하지 않아도 됨
운영 부담 최소화 → Kubernetes 설정, 리소스 할당, 스케일링 등을 GCP가 자동 처리
비용 최적화 → 사용한 리소스만큼만 과금

Standard 모드 (사용자 관리 모드)

사용자가 클러스터와 노드 풀을 직접 관리
노드 크기, 개수, 업그레이드 등을 수동으로 설정해야 함
운영의 유연성이 높지만 관리 부담이 있음
고정된 노드 비용이 부과됨

 

어떤 모드를 선택할까?

  • 운영 부담을 줄이고 자동화를 원하면 → Autopilot 모드
  • 세부적인 클러스터 설정과 관리가 필요하면 → Standard 모드

Autopilot 모드는 관리가 편리하지만 세부적인 설정이 제한적이고, Standard 모드는 관리 부담이 있지만 유연성이 높습니다. 

 

 

GCP 콘솔에서 Kubernetes Engine → 클러스터 만들기 → Standard 모드 선택 → 기본 설정 후 생성하면 클러스터가 생성됩니다.