유연성: 멀티 클라우드 및 하이브리드 환경 지원(GKE Autopilot, Anthos 등과 연계)
효율성: 필요할 때만 노드를 스케일링하고 비용 최적화 가능
🗂️ 일반적인 GKE 사용
1️⃣ 클러스터 생성
GCP 콘솔 또는 gcloud CLI로 생성
Autopilot 모드와 Standard 모드 중 선택
2️⃣ 노드풀 구성
워커 노드 그룹 설정 (머신 타입, 크기, Autoscaling)
3️⃣ 애플리케이션 배포
kubectl 사용해서 Deployment, Service, Ingress 등 Kubernetes 리소스 관리
4️⃣ 모니터링 및 로깅
Stackdriver Logging & Monitoring과 연계
Pod 상태, 리소스 사용량 모니터링
5️⃣ 보안 및 IAM
RBAC 설정, 네트워크 폴리시, Secret 관리
※ 표로 간편하게 정리
1️⃣ 클러스터 생성
GCP Console 또는 gcloud CLI 사용
2️⃣ 노드풀 구성
머신 타입, Autoscaling, Preemptible 설정
3️⃣ 애플리케이션 배포
kubectl apply 로 YAML 배포
4️⃣ 외부 노출
LoadBalancer 서비스 or Ingress Controller 설정
5️⃣ 모니터링/로깅 연동
Stackdriver Monitoring, Logging
6️⃣ 권한 관리
RBAC, IAM, Service Account 연계
✅ 핵심 요약
GKE(Google Kubernetes Engine) 는 Google Cloud에서 제공하는 관리형 Kubernetes 서비스
클러스터 생성부터 노드풀 관리, Auto Scaling, 모니터링, 보안까지 Google이 관리 → 사용자는 워크로드에 집중
Autopilot 모드 vs Standard 모드
Autopilot (자동 모드) : Google이 노드를 자동으로 관리, 운영 부담 ↓ 즉, 관리형 쿠버네티스 제품으로 클라우드에서 쉽고 간단하게 컨테이너 환경을 관리 할 수 있도록 하는 서비스
Standard (표준 모드) : 노드 설정과 관리까지 사용자가 직접, 더 세밀한 튜닝 가능 위크로드 최적화부터 노드확장까지 운영의 대부분을 추가 관리 해주는 서비스 모드
🔑 Autopilot 모드 특징
장점
노드 설정 필요 없음 → 운영 부담 ↓
노드 장애시 자동 대체됨
리소스 낭비 최소화
주의점
일부 고급 커스터마이징 제한
노드별 다이나믹한 OS/커널 설정이 어려움
✅ 팁 : 초기에는 Autopilot으로 시작 → 추후 필요시 Standard로 전환
🔹 비용 최적화
Preemptible VM 사용 → 일시적인 워크로드에 적합 (비용 최대 80% 절감)
Autoscaling 설정 → 트래픽에 따라 Pod와 Node 자동 증가/감소
Cluster Autoscaler → 유휴 노드 자동 제거
✅ 팁 : 고정 워크로드는 스테이블 VM, 배치/배경작업은 Preemptible로 혼합
🔹 네트워크 및 Ingress
Service 유형
ClusterIP (내부 통신)
NodePort (노드 IP + 포트)
LoadBalancer (Cloud LB 생성)
Ingress Controller
GCP 기본 Ingress or NGINX Ingress 선택 가능
HTTPS 인증서 자동 프로비저닝 가능 (Managed Certificate)
✅ 팁 : kubectl describe ingress 로 오류 상황 파악 필수 !
🔹 모니터링 & 로깅
Stackdriver 연동
기본 모니터링 + 로깅 제공
Alert Rule, 대시보드 설정
Pod 로그 확인
kubectl logs <pod-name>
CrashLoopBackOff 시 이벤트 확인: kubectl describe pod
✅ 팁 : CrashLoopBackOff 원인 대부분 환경 변수 오타 혹은 리소스 부족 → 리소스 요청/제한 확인 !
🔹 Helm & Config 관리
Helm
K8s 패키지 매니저
재배포/롤백 쉽게 가능
ConfigMap & Secret
설정값 및 비밀정보 분리 관리
✅ 팁 : ConfigMap은 수정 즉시 Pod에 반영되지 않음 → Rolling Update 필요
✔️ 클러스터 이름 규칙: 프로젝트-환경-리전 (ex: shop-prod-asia-northeast3)
✔️ kubectl config use-context 로 클러스터 변경 관리
✔️ 사전 Terraform, gcloud CLI 자동화 추천 → 인프라 일관성 유지
✔️ YAML 배포는 GitOps(CI/CD)로 관리 → 수동 배포 방지
✔️ Kustomize 활용하면 환경별 오버레이 쉽게 관리
📌 요약
항목
Autopilot
Standard
노드 관리
Google 자동 관리
직접 관리
비용
유휴 리소스 최소화
사용자 설정에 따라
권한/커스터마이징
제한적
자유로움
추천 상황
빠른 PoC, 비용 절감
대규모, 고급 튜닝 필요
✅ HPA vs VPA 비교
항목
HPA (Horizontal Pod Autoscaler)
VPA (Vertical Pod Autoscaler)
개념
Pod 개수를 가로로 늘림/줄임
Pod 1개당 CPU/메모리 할당량 조정
동작 방식
현재 리소스 사용량(Metrics)을 기준으로 Pod Replica 수 조정
현재 리소스 사용량을 분석해 리소스 요청(Request)/제한(Limit)을 자동 조정
주요 활용 케이스
요청이 많아질 때 Pod 수 증가 → 처리량 확장
Pod가 항상 과소/과다 Provisioning 되어 있을 때 자동 튜닝
지원 리소스
CPU, 메모리, 사용자 정의 Metric
CPU, 메모리
특징
ReplicaSet 스케일과 직접 연동됨
Pod 재생성이 발생할 수 있음 (ResourceSpec 변경 필요)
적용 범위
Deployment, ReplicaSet 등
Pod(컨테이너별 리소스)
제한 사항
과부하 시에도 Pod 내 리소스 부족은 해결 안됨
Scale-out은 못함 (Pod 수는 고정)
실무 Tip
짧은 급격한 트래픽 대응에 유리 즉, 트래픽 분산에 적합
장기적인 리소스 효율 최적화에 유리 즉, 운영 초반 최적의 CPU, Memory를 찾기 위해 사용
✅ 구조 다이어그램
🔹 HPA: 가로 확장 흐름
+-------------------+ +----------------+
| Metrics Server | | K8s API Server|
+-------------------+ +----------------+
| |
v |
+-------------------+ |
| HPA Controller | -----------------+
+-------------------+
|
v
+-------------------------+
| ReplicaSet (Pod 수 조정)|
+-------------------------+
|
v
+---------------+
| Pod x N 개 |
+---------------+
핵심
Metrics Server가 Pod 리소스 사용량 모니터링
HPA Controller가 이를 감시해 ReplicaSet의 Pod 수를 늘리거나 줄임
Scale Out/Scale In 담당
🔹 VPA: 세로 확장 흐름
+-------------------+ +----------------+
| Metrics Server | | K8s API Server|
+-------------------+ +----------------+
| |
v |
+-------------------+ |
| VPA Controller | -----------------+
+-------------------+
|
v
+-----------------------------+
| Pod Template Resource Spec |
| (CPU/Memory Request/Limit) |
+-----------------------------+
|
v
+-------------------+
| Pod (재생성됨) |
+-------------------+
