Big Data Anaysis Service Solution

리눅스 기반 컨테이너 개발 환경 구축

1. 강의 개요

이 강의는 Google Cloud Platform(GCP) 환경에서 컨테이너 이미지를 관리하고, Kubernetes 클러스터를 생성하여 실제 애플리케이션(예: 파이썬 Flask 앱)을 배포하고 스케일링하는 방법을 다룹니다. 학습자는 기본 개념부터 실습까지 단계별로 배워나가며, 다음과 같은 주요 목표를 달성하게 됩니다.

  • GCP Artifact Registry vs. Container Registry 차이점 이해
  • gcloud CLI 초기 설정 및 API 활성화 방법 습득
  • Minikube와 GKE 클러스터 구성 및 네트워크 요구사항 확인
  • Python Flask 애플리케이션을 컨테이너화 및 Kubernetes에 배포하는 과정을 실습
  • 트러블슈팅 및 포트 충돌, 리소스 소비, 설정 난이도 비교 분석

강의 시간별 세부 계획

강의는 15시간을 6개 모듈로 분할하여 진행합니다. 각 모듈별 필수 실습 과제 및 예상 문제 상황은 다음과 같습니다:

모듈시간내용실습 과제예상 문제 상황
12GCP 소개 및 환경 설정gcloud CLI 설치인증 문제
23컨테이너 기본 개념Docker 이미지 생성이미지 빌드 실패
33Artifact Registry와 Container Registry의 차이점이미지를 Artifact Registry에 푸시권한 문제
43Kubernetes 클러스터 구성Minikube 설치 및 설정네트워크 문제
52Python Flask 애플리케이션 배포Flask 앱 배포포트 충돌
62실전 문제 해결 워크숍실습 문제 해결IAM과 네트워크 문제

2. GCP Artifact Registry와 Container Registry의 차이점

가장 먼저, 컨테이너 기본 개념을 이해하는 것이 중요합니다.

컨테이너 기본 개념

  • 가상 머신 vs. 컨테이너 비교
    • 가상 머신은 하드웨어 가상화를 기반으로 하여 전체 OS를 포함하므로 더 많은 리소스를 사용합니다.
    • 반면, 컨테이너는 OS의 커널을 공유하며 애플리케이션과 라이브러리만 패키지하여 경량화된 실행 환경을 제공합니다.
  • 이미지 레이어 구조
    • 컨테이너 이미지는 여러 개의 레이어로 구성되어 있으며, 각 레이어는 변경되지 않는 파일 시스템의 스냅샷을 나타냅니다. 이를 통해 효율적인 저장과 전송이 가능합니다.

GCP에서 제공하는 두 저장소 서비스는 각기 다른 기능과 특징을 가지고 있습니다. 주요 차이점은 다음과 같습니다:

  • 지원 형식
    • Container Registry: 오로지 Docker 컨테이너 이미지 전용 저장소입니다.
    • Artifact Registry: Docker 이미지 외에도 Maven, npm, OS 패키지 등 다양한 아티팩트 형식을 지원합니다.
    • Transition from Container Registry1
  • 레지스트리 생성 방식
    • Container Registry: 최초 이미지 푸시 시 자동 생성됩니다.
    • Artifact Registry: 사용자가 명시적으로 레포지토리 생성을 요구합니다.
    • Repository overview2
  • 접근 제어
    • Container Registry: 이미지 단위의 접근 제어만 지원합니다.
    • Artifact Registry: 리포지토리 수준의 상세한 IAM 정책을 지원합니다.
    • Access control with IAM3
  • 보안 및 취약점 스캐닝 기능
    • Container Registry: Docker 이미지에 한정된 취약점 스캐닝 기능만 제공하며, 외부 도구가 필요한 경우가 많습니다.
    • Artifact Registry: OS와 애플리케이션 언어 패키지 등 다양한 아티팩트에 대해 자동 및 수동 CVE 취약점 스캐닝 기능을 제공합니다.
    • Artifact analysis and vulnerability scanning4

3. gcloud CLI 초기 설정 절차

gcloud CLI를 사용하여 GCP 리소스를 관리할 때는 초기 설정이 필수적입니다. 기본 커맨드 시퀀스는 다음과 같습니다:

  1. 초기화 및 로그인
    • 터미널에서 gcloud init 명령어를 실행하여 Google 계정으로 로그인하고 기본 설정을 진행합니다.
    • # 사전 체크 항목: gcloud CLI가 설치되어 있는지 확인합니다.
    • Initializing the gcloud CLI5
  2. 프로젝트 선택
    • gcloud config set project [PROJECT_ID] 명령어를 사용하여 사용할 프로젝트 ID를 지정합니다.
    • # 사전 체크 항목: 필요한 프로젝트 ID가 준비되어 있는지 확인합니다.
    • 이 과정은 CLI 명령어들이 올바른 Google Cloud 프로젝트와 연계되도록 하기 위해 필수적입니다.
  3. 필수 API 활성화
    • 예를 들어, Artifact Registry API를 활성화하려면 gcloud services enable artifactregistry.googleapis.com 명령어를 실행합니다.
    • # 사전 체크 항목: 사용할 API의 이름과 기능을 확실히 이해합니다.
    • Install the Google Cloud CLI6
  4. IAM 권한 부여
    • 필요에 따라, 특정 사용자의 권한을 추가하기 위해 다음과 같이 명령어를 실행합니다:gcloud projects add-iam-policy-binding [PROJECT_ID] --member='user:[USER_EMAIL]' --role='roles/container.developer'
    • # 사전 체크 항목: 사용자의 이메일 주소와 프로젝트 ID를 정확히 입력했는지 확인합니다.
    • Access control with IAM3

4. 저장소 요금 체계 비교 (2025년 기준)

저장소의 요금 체계는 사용량 및 기능에 따라 다릅니다.

저장소 종류요금 부과 방식링크
Container RegistryCloud Storage 사용량 및 데이터 전송 비용을 기반으로 요금이 부과됩니다.Pricing
Artifact Registry저장 용량, 요청 수, 메타데이터 저장 및 네트워크 비용 등 다양한 요소에 따라 요금 산정이 이루어집니다.Pricing

5. 이미지 배포 시 Latency 비교 데이터

현재 제공된 자료에는 100MB 컨테이너 이미지 배포 시의 구체적인 latency 수치(예: 밀리초 단위)가 포함되어 있지 않습니다.
Artifact Registry는 지역 최적화 기능을 제공하여 네트워크 지연을 줄일 수 있지만, 정확한 성능 데이터는 추가적인 벤치마크 결과가 필요합니다.

6. Artifact Registry의 CVE 취약점 스캐닝 기능

Artifact Registry와 Container Registry의 취약점 스캐닝 기능은 다음과 같이 차이가 있습니다:

  • Artifact Registry
    • OS 및 애플리케이션 언어 패키지 등 다양한 아티팩트에 대해 자동 및 수동 CVE 취약점 스캐닝을 제공합니다.
    • 보안 강화 및 취약점 관리에 유리합니다.
    • Artifact analysis and vulnerability scanning4
  • Container Registry
    • 기본적으로 Docker 이미지에 한정된 취약점 스캐닝 기능만 제공하며, 외부 도구를 활용해야 할 경우가 많습니다.
    • Transition from Container Registry1

7. gcloud CLI 설치 시 최소 요구사항

Google Cloud CLI는 다양한 운영체제에서 사용할 수 있으며, 설치 전에 다음 최소 요구사항을 충족해야 합니다:

  • Python 버전:
    • 최소 Python 3.8 이상, 3.13 이하를 요구합니다.
    • 최신 릴리즈 노트에서는 Python 3.12 이상 사용을 권장합니다.
    • Quickstart: Install the Google Cloud CLI6, Google Cloud CLI – Release Notes8

8. gcloud init 실행 시 필수 파라미터

gcloud CLI를 초기화할 때 가장 중요한 파라미터는 프로젝트 ID입니다.
로그인 및 인증 과정과 함께 올바른 프로젝트 ID를 입력해야 이후 모든 gcloud 명령어들이 해당 프로젝트와 연계되어 작동합니다.

  • Initializing the gcloud CLI5

9. IAM 권한 부여 명령어

컨테이너 개발 및 클러스터 관리 시 필요한 container.developer 역할을 부여하기 위한 정확한 명령어는 다음과 같습니다:

gcloud projects add-iam-policy-binding [PROJECT_ID] --member='user:[USER_EMAIL]' --role='roles/container.developer'

여기서,

  • **[PROJECT_ID]**는 사용자가 작업하는 프로젝트 ID
  • **[USER_EMAIL]**은 권한을 부여할 사용자 이메일 주소
  • Access control with IAM3

10. Docker 인증: Credential Helper 설정 차이점

두 저장소에서 Docker 인증 설정 방법은 다음과 같이 다릅니다:

  • Container Registry
    • gcloud auth configure-docker 명령어를 사용하여 기본 Docker 인증 정보를 구성합니다.
  • Artifact Registry
    • 특정 지역 호스트를 명시하여, 예를 들어 gcloud auth configure-docker us-central1-docker.pkg.dev와 같이 설정합니다.
    • Configure authentication to Artifact Registry for Docker9

11. Artifact Registry 기본 이미지 보존 정책

Artifact Registry에서 기본적으로 설정되는 이미지 보존 정책(리텐션 정책)은 일반적으로 30일입니다.
이 값은 Cleanup Policies를 통해 관리할 수 있으며, 필요에 따라 사용자가 원하는 기간으로 변경할 수 있습니다.

  • Repository overview2, Pricing | Artifact Registry | Google Cloud7

12. Minikube 설치 및 시스템 요구사항

Minikube는 로컬 환경에서 간편하게 Kubernetes 클러스터를 실행할 수 있도록 해주는 도구입니다.
설치 전 최소 시스템 요구사항은 다음과 같습니다:

  • CPU: 최소 2개 이상의 CPU (일부 자료에서는 4개 이상의 가상 CPU 권장)
    • Minikube start10, NERc Docs11
  • RAM: 최소 2GB (원활하게 실행하려면 4GB 이상 권장)
    • Minikube start10
  • 저장 공간: 최소 20GB 이상의 여유 공간
    • Top Kubernetes Tools for 202512
  • 네트워크 연결 및 Docker(또는 가상 머신 관리자) 사용 가능 환경

또한, Minikube에서 리눅스 컨테이너 구동을 위한 최소 요구사항도 위와 동일하게 적용됩니다.

13. GKE 클러스터 생성 전 네트워크 구성 요구사항

GKE 클러스터를 생성하기 전에 다음 네트워크 구성 요소들을 필수적으로 준비해야 합니다:

  • VPC 네트워크
    • 클러스터 배포 전에 사용될 VPC 네트워크를 미리 생성합니다.
    • 여러 서브넷이 포함되어야 하며, 각 서브넷은 고유의 CIDR 블록이어야 합니다.
    • CIDR 충돌이 발생할 경우 이를 해결하기 위한 방법은 다음과 같습니다:
      1. 현재 설정된 서브넷의 CIDR 블록을 검토하여 중복된 CIDR 블록을 파악합니다.
      2. gcloud CLI를 사용하여 gcloud compute networks subnets list --project [PROJECT_ID] 명령어로 서브넷 목록을 확인합니다.
      3. 필요한 경우, 서브넷의 CIDR 블록을 변경하여 해결합니다.
    • Network overview13
  • 방화벽 규칙
    • 클러스터 제어 평면과 내부 통신을 위해 *.googleapis.com, *.gcr.io, 및 제어 평면 IP에 대한 인그레스 또는 egress가 허용되는 방화벽 규칙을 구성합니다.
    • 외부 접속을 위한 경우, HTTP(포트 80)와 HTTPS(포트 443)를 개방합니다.
    • Automatically created firewall rules14

14. GKE 클러스터 생성 시 노드 풀에 필요한 IAM 권한

GKE 클러스터 및 노드 풀을 생성하기 위해서는 다음과 같은 IAM 권한들이 필요합니다:

  • Google Kubernetes Engine API 관련 권한
  • roles/container.admin : 클러스터 및 노드 풀 생성, 관리 권한.
  • roles/compute.networkUser : VPC 네트워크, 방화벽 규칙 관리 권한.
  • 추가적으로, 클러스터 생성 시 필요한 서비스 계정에 최소 권한을 할당하는 것이 중요합니다.
  • Add and manage node pools15, Prerequisites for GKE clusters on Google Cloud16

15. Minikube 초기 설정 시 컨테이너 런타임 지원 및 버전 제약조건

Minikube는 Docker를 기본 컨테이너 런타임으로 사용하며, 다음 요구사항을 충족해야 합니다:

  • Docker: 최소 20.10 버전 이상이 필요합니다. 이는 최신 기능과 안정적인 컨테이너 구동을 보장합니다.
    • Minikube – Drivers, Docker17
  • containerd 또는 cri-o도 지원하지만, 특별한 버전 제약은 명시적으로 제시되지 않습니다. 최신 안정 버전을 사용하는 것이 좋습니다.
    • Runtimes18

16. Minikube와 GKE 클러스터 설정 난이도 비교

두 환경의 설정 난이도를 비교하면 다음과 같습니다:

  • Minikube
    • 설정 시간: 약 2~5분 내에 단일 노드 클러스터로 빠르게 설정 가능
    • 실패율: 로컬 환경에서 간단한 설정이므로 오류 발생률이 낮음
  • GKE
    • 설정 시간: 클라우드 API, 인증, 네트워크 설정 등 추가 단계로 인해 5~10분 이상이 소요될 수 있음
    • 실패율: IAM, 네트워크 및 기타 구성 오류로 인해 상대적으로 오류 발생 가능성이 높을 수 있음
    • Pingcap Docs19

정확한 수치와 비교는 최신 벤치마크나 공식 문서를 참조할 필요가 있습니다.

17. Python Flask 앱을 GKE에 배포하는 검증 절차

Python Flask 앱을 GKE에 배포하는 간소화된 검증 절차는 다음 3단계로 요약할 수 있습니다:

  1. Docker 이미지 생성 및 푸시
    • Flask 앱의 Dockerfile을 작성하고, 이미지를 빌드한 후
      예:docker build -t gcr.io/YOUR_PROJECT_ID/flask-app:latest . docker push gcr.io/YOUR_PROJECT_ID/flask-app:latest
  2. Kubernetes 배포 구성
    • deployment.yaml 파일을 작성하여 GKE 클러스터에 애플리케이션을 배포합니다.
      예:kubectl apply -f deployment.yaml
  3. 서비스 검증
    • kubectl get pods로 파드 상태를 확인하고, kubectl logs <pod-id>로 로그를 점검하여 서비스 정상 동작 여부를 확인합니다.
    • 배포 시 발생 가능한 5대 오류 유형:오류 코드원인조치 방법404서비스 없음서비스 배포 확인403권한 없거나 부족IAM 권한 점검500서버 오류로그 분석 및 수정CrashLoopBack파드 크래시설정 파일 및 리소스 점검ImagePullBack이미지 불러오기 실패이미지 이름 및 접근 권한 확인
    • Mastering Kubernetes Deployments in 202520

18. 로컬 Minikube 포트 충돌 오류 해결 사례

로컬 Minikube에서 포트 충돌 오류가 발생하는 경우, 다음 절차로 문제를 진단하고 해결할 수 있습니다:

  1. 충돌 확인
    • kubectl describe service <service-name> 및 kubectl get pods 명령어를 사용하여 문제가 되는 포트와 현재 할당된 포트를 확인합니다.
  2. 포트 재설정
    • 충돌되는 포트 번호를 변경하거나, NodePort 범위를 조정합니다.
  3. 포트 포워딩 테스트
    • kubectl port-forward 명령어를 사용해 특정 포트를 임시로 다른 포트로 재할당하여 접근성을 테스트합니다.
  4. 문서화
    • 문제 해결 후, 해당 변경 사항을 문서화하여 향후 동일 문제 발생 시 참고합니다.
    • GitHub Issue 참고21

종합 문제 해결 워크숍 시나리오

  • 시나리오: 복합 장애 발생 – 네트워크 + IAM + 이미지 문제
    1. 네트워크 문제 진단: VPC 구성이 올바른지, 방화벽 설정이 제대로 되어 있는지 점검합니다.
    2. IAM 문제 진단: 사용자의 권한이 부족한지 확인한 후 필요한 역할을 부여합니다.
    3. 이미지 문제 진단: 이미지가 올바르게 배포되었는지 확인하고, 필요한 경우 이미지를 재빌드합니다.

19. 결론

이 강의 노트에서는 GCP 클라우드 환경에서 컨테이너 이미지를 효과적으로 관리하기 위한 Artifact Registry와 Container Registry의 차이점, gcloud CLI를 통한 초기 설정 방법, Minikube 및 GKE 클러스터 구성의 하드웨어 및 네트워크 요구사항, 그리고 Python Flask 애플리케이션 배포 및 검증 절차에 대해 상세히 다루었습니다. 또한, 로컬 및 클라우드 환경에서 발생할 수 있는 문제 해결 및 트러블슈팅 방법을 제시하여, 초보자도 실제로 환경을 구성하고 운영할 수 있도록 돕습니다.
각 단계마다 제공된 구체적인 명령어와 지침은 강의 실습을 통해 실전 경험을 쌓는 데 큰 도움이 될 것입니다.

이 강의 자료는 다양한 공식 문서와 최신 사례(예: Transition from Container Registry1, Minikube start10, Creating a zonal cluster22)를 기반으로 작성되었으며, 최신 업데이트 사항에 따라 개정할 수 있습니다.

학습자 여러분이 이 강의를 통해 실제 GCP 및 쿠버네티스 환경에서 컨테이너 개발, 배포, 스케일링 및 문제 해결 능력을 효과적으로 함양하시길 바랍니다.

핵심 요점

  • 강의는 15시간을 6개 모듈로 분할하여 진행되며, 각 모듈에는 필수 실습 과제와 예상 문제 상황이 포함되어 있습니다.
  • 강의 노트는 GCP의 Artifact Registry와 Container Registry 차이, gcloud CLI 초기 설정 및 API 활성화, 그리고 Minikube와 GKE 클러스터 구성을 상세하게 다루고 있습니다.
  • Artifact Registry는 Docker 이미지 외에도 Maven, npm, OS 패키지 등 다양한 아티팩트를 지원하며, 리포지토리 수준의 IAM 정책과 자동 및 수동 CVE 취약점 스캐닝 기능을 제공합니다.
  • gcloud CLI 초기 설정은 터미널에서 gcloud init 실행 후 프로젝트 선택과 필요한 API 활성화를 통해 진행되며, 정확한 [PROJECT_ID] 입력이 필수적입니다.
  • Minikube는 로컬 환경에서 단일 노드 클러스터를 약 2~5분 내에 설정할 수 있으나, GKE 클러스터는 네트워크, IAM 등 추가 구성으로 인해 5~10분 이상 소요될 수 있습니다.
  • Python Flask 애플리케이션 배포는 Docker 이미지 생성 및 푸시, Kubernetes 배포 구성, 그리고 서비스 검증의 3단계로 진행되며, 이미지 빌드 실패 및 포트 충돌과 같은 문제 해결 절차를 포함합니다.

부록: 보충 비디오 자료

youtube

Getting Started with Containers and Google Kubernetes …

Jul 25, 2018

Posted

in

by

david

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *