GKE가 다른 매니지드 쿠버네티스와 다른 이유
Google Kubernetes Engine(GKE)은 AWS EKS, Azure AKS와 함께 주요 퍼블릭 클라우드의 매니지드 쿠버네티스 서비스입니다. GKE를 구별 짓는 것은 Google이 쿠버네티스 프로젝트의 원 창시자이며, GKE가 그 위에서 가장 오랫동안 운영 노하우를 쌓아온 서비스라는 점입니다.
GKE는 컨트롤 플레인(API 서버, etcd, 스케줄러)을 Google이 관리합니다. Regional 클러스터에서 컨트롤 플레인은 3개 존에 분산되어 존 장애에도 API가 살아남습니다. Autopilot 모드는 노드까지 Google이 관리하므로 운영 부담이 극적으로 줄어듭니다. GCP-ACE 시험은 운영 모델 차이, 스케일링 전략, 보안 통합을 집중 검증합니다.
---
GKE Standard vs Autopilot: 무엇을 선택할까
GKE를 처음 접하는 팀이 가장 먼저 마주치는 결정이 Standard와 Autopilot 중 무엇을 쓸 것인가입니다. 두 모드는 쿠버네티스 API를 동일하게 제공하지만, 노드 인프라의 책임 주체가 다릅니다.
| 항목 | GKE Standard | GKE Autopilot | |------|-------------|---------------| | 노드 프로비저닝 | 운영자 직접 관리 | Google 자동 관리 | | 노드 OS 패치 | 운영자 책임 (자동 업그레이드 옵션 있음) | Google 책임 | | 노드 풀 구성 | 완전 커스터마이징 가능 | 불가 (pod 단위 리소스 요청으로 대체) | | 과금 기준 | 노드 VM 시간 | Pod 요청 CPU/메모리 | | 특권 컨테이너(privileged) | 허용 | 금지 | | 커스텀 DaemonSet | 허용 | 제한적 (시스템 DaemonSet만) | | 운영 오버헤드 | 높음 | 낮음 | | Spot 노드 사용 | 노드 풀 단위 설정 | Pod 어노테이션으로 설정 |
Autopilot은 Kubernetes 운영 경험이 부족한 팀, 개발 속도가 우선인 초기 스타트업에 유리합니다. 특권 컨테이너나 커스텀 DaemonSet이 필요하다면 Standard가 필수입니다. 시험에서 자주 나오는 Autopilot 함정은 Pod 수준 리소스 requests를 반드시 명시해야 한다는 점입니다. requests가 없으면 Pod를 배포할 수 없습니다.
!GKE Standard vs Autopilot
클러스터 토폴로지: Zonal·Regional, Public·Private
GKE 클러스터는 두 가지 축으로 분류됩니다. 가용성 범위(Zonal vs Regional)와 네트워크 노출 수준(Public vs Private)입니다.
| 클러스터 유형 | 컨트롤 플레인 위치 | 노드 배치 | 주요 특징 | |------------|-----------------|--------|----------| | Zonal | 단일 존 | 단일 존 | 저렴, 존 장애 시 전체 다운 | | Regional | 3개 존 분산 | 3개 존 분산 | 고가용성, 컨트롤 플레인 SLA 99.95% | | Public (기본) | 공개 엔드포인트 | 공개 IP 할당 | 인터넷 접근 허용 | | Private | VPC 내부 엔드포인트 | 외부 IP 없음 | 인터넷 격리, Cloud NAT 필요 |
Regional 클러스터는 컨트롤 플레인이 3개 존에 분산되므로 단일 존 장애에도 kubectl과 Pod 스케줄링이 계속 동작합니다. Zonal 클러스터는 해당 존 장애 시 컨트롤 플레인이 응답하지 않아 운영 중단 위험이 있습니다. 프로덕션에는 Regional 클러스터를 권장합니다.
Private 클러스터는 노드와 컨트롤 플레인이 VPC 내부에 격리됩니다. 외부 인터넷 통신이 필요한 컨테이너를 위해서는 Cloud NAT를 구성합니다. 컨트롤 플레인에 내부 VPC에서만 접근하려면 Private Endpoint를 활성화하고 마스터 승인 네트워크(Authorized Networks)로 접근 가능한 CIDR을 제한합니다.
VPC-native 클러스터와 IP 별칭(Alias IP)도 시험에 등장합니다. VPC-native 모드는 Pod IP가 VPC 서브넷의 보조 IP 범위에서 직접 할당되므로, Pod IP가 VPC 내 다른 리소스와 직접 라우팅됩니다. 레거시 routes 기반 클러스터와 달리 VPC 수준의 방화벽 규칙을 Pod IP에 직접 적용할 수 있습니다.
---
노드 풀과 워크로드 분리 전략
노드 풀(Node Pool)은 동일한 구성을 가진 노드 집합입니다. 하나의 GKE 클러스터에 여러 노드 풀을 두어 워크로드를 분리하는 것이 실무에서 자주 쓰는 패턴입니다.
| 활용 패턴 | 노드 풀 구성 예시 | 목적 | |---------|----------------|------| | GPU 워크로드 분리 | GPU 장착 n1-standard 노드 풀 별도 | ML 학습 Pod만 GPU 노드에 배치 | | Spot 비용 절감 | Spot 노드 풀 + On-demand 노드 풀 병행 | 중단 허용 배치 작업에 Spot 활용 | | 고사양 메모리 요구 | 메모리 최적화 인스턴스 풀 별도 | 인메모리 DB, 캐시 서버 분리 | | Windows 컨테이너 | Windows Server 노드 풀 추가 | Windows 기반 앱 지원 | | 시스템 구성요소 전용 | 소규모 전용 노드 풀 | kube-system 구성요소만 실행 |
Pod를 특정 노드 풀에 고정하려면 nodeSelector 또는 nodeAffinity를 사용합니다. Taint와 Toleration 조합도 자주 사용합니다. GPU 노드 풀에 Taint를 설정하면 Toleration이 없는 일반 Pod가 GPU 노드를 점유하지 않습니다.
노드 풀의 중요한 특성 하나를 기억해야 합니다. GKE 노드 풀은 불변(immutable)입니다. 기존 노드 풀의 머신 타입은 직접 수정할 수 없습니다. 머신 타입을 바꾸어야 한다면 새 노드 풀을 추가하고, 기존 노드 풀을 cordon·drain으로 비운 다음 삭제하는 것이 표준 절차입니다. cordon은 새 Pod 배치를 차단하고, drain은 기존 Pod를 graceful하게 종료·재스케줄링합니다. 이 과정에서 PodDisruptionBudget을 설정하면 최소 가용 복제 수가 보장됩니다.
---
스케일링 3총사: HPA, VPA, Cluster Autoscaler
GKE에서 스케일링은 세 가지 레이어에서 독립적으로 작동합니다.
| 스케일러 | 조절 대상 | 기준 메트릭 | 핵심 사용 사례 | |---------|---------|-----------|-------------| | HPA (Horizontal Pod Autoscaler) | Pod 수(레플리카) | CPU, 메모리, 커스텀 메트릭 | 웹 트래픽 급증 대응 | | VPA (Vertical Pod Autoscaler) | Pod의 CPU/메모리 requests·limits | 실제 사용량 히스토리 | 리소스 요청 자동 최적화 | | Cluster Autoscaler | 노드 수 | 스케줄 불가 Pod 존재 여부 / 유휴 노드 여부 | 비업무 시간대 비용 절감 |
HPA는 실행 중인 Pod 수를 늘리거나 줄입니다. 기본 메트릭은 CPU 사용률이며, Stackdriver 기반 커스텀 메트릭이나 외부 메트릭도 사용할 수 있습니다. HPA의 최소 복제 수는 1입니다. 0으로 줄이려면 KEDA(Kubernetes Event-driven Autoscaling)가 필요합니다.
VPA는 Pod가 실제로 소비하는 CPU와 메모리를 분석해 requests 값을 추천하거나 자동 적용합니다. Off 모드(추천만), Auto 모드(재시작하여 자동 적용), Initial 모드(최초 스케줄 시에만 적용) 세 가지 모드가 있습니다. VPA와 HPA를 동일 Pod에 함께 사용하면 CPU 기반 HPA와의 충돌이 발생하므로, VPA는 HPA가 CPU로 스케일링하지 않는 워크로드에 사용합니다.
Cluster Autoscaler는 노드 풀 단위로 최소·최대 노드 수를 설정하고, Pod가 리소스 부족으로 스케줄되지 못할 때 노드를 추가하며, 유휴 노드가 있으면 Pod를 재배치한 후 노드를 제거합니다. HPA와 Cluster Autoscaler를 함께 쓰면 Pod 레이어와 노드 레이어 양쪽의 이중 자동화가 완성됩니다.
시험에서 가장 흔한 혼동 포인트가 있습니다. GKE 노드 수 자동 조절 → Cluster Autoscaler, Pod 수 자동 조절 → HPA, Pod 리소스 요청 자동 최적화 → VPA. 이 세 가지를 명확히 구분해두어야 합니다.
---
Workload Identity로 안전한 ID 통합 만들기
GKE에서 실행되는 애플리케이션이 Cloud Storage, BigQuery, Cloud SQL 같은 GCP 서비스에 접근하려면 서비스 계정(Service Account) 권한이 필요합니다. 이때 인증 방식을 어떻게 구성하느냐가 보안의 핵심입니다.
| 인증 방식 | 설명 | 보안 위험 | |---------|------|----------| | 서비스 계정 키 파일 마운트 | JSON 키 파일을 Secret으로 Pod에 마운트 | 키 유출 시 전체 권한 노출, 키 순환 부담 | | 노드 서비스 계정 공유 | 노드에 부여된 서비스 계정 권한을 모든 Pod가 공유 | 최소 권한 원칙 위반, 과도한 권한 공유 | | Workload Identity | GKE 서비스 계정(KSA)과 GCP 서비스 계정(GSA) 연동 | 키 없음, Pod 단위 최소 권한 부여 |
Workload Identity는 Kubernetes Service Account(KSA)에 GCP IAM Service Account(GSA)를 바인딩하는 방식입니다. Pod가 GCP API를 호출할 때 GKE 메타데이터 서버가 KSA와 연결된 GSA의 자격 증명을 자동으로 제공합니다. 키 파일이 전혀 없으므로 유출 위험이 없고, 키 순환 문제도 사라집니다.
설정 단계는 크게 세 가지입니다. 첫째, 클러스터에서 Workload Identity를 활성화합니다. 둘째, GCP IAM에서 KSA에 GSA의 roles/iam.workloadIdentityUser 역할을 부여합니다. 셋째, Kubernetes Service Account에 iam.gke.io/gcp-service-account 어노테이션을 추가합니다.
시험에서 Workload Identity 관련 문제는 "GKE Pod에서 GCP 서비스에 안전하게 접근하는 방법"으로 등장합니다. 서비스 계정 키 파일을 마운트하는 방식은 보안상 좋지 않은 선택지로 제시되고, Workload Identity가 정답입니다. Google이 공식적으로 권장하는 방식이기 때문입니다.
---
시험에서 자주 헷갈리는 GKE 운영 시나리오
실제 시험에서 틀리기 쉬운 시나리오들을 정리합니다.
| 시나리오 | 정답 | 자주 나오는 오답 | |---------|------|----------------| | GKE 노드 수를 트래픽에 따라 자동 조절 | Cluster Autoscaler | HPA, MIG | | GKE Pod 수를 CPU 기준으로 자동 조절 | HPA | Cluster Autoscaler | | GKE Pod의 리소스 요청 값 자동 최적화 | VPA | HPA | | GKE에서 GCP 서비스에 키 없이 안전 접근 | Workload Identity | 서비스 계정 키 Secret 마운트 | | 노드 풀 머신 타입 변경 | 새 노드 풀 추가 후 cordon·drain | 기존 풀 직접 수정 (불가) | | 존 장애에도 클러스터 API 유지 | Regional 클러스터 | Zonal 클러스터 | | Kubernetes 관리 없이 컨테이너 실행 | Cloud Run 또는 GKE Autopilot | GKE Standard | | GKE에서 인터넷 없이 GCP API 접근 | Private Google Access + VPC Service Controls | NAT 게이트웨이 |
클러스터 업그레이드 순서도 시험에 등장합니다. 컨트롤 플레인을 먼저 업그레이드한 뒤 노드를 업그레이드합니다. 노드 버전은 컨트롤 플레인보다 한 마이너 버전 이상 뒤처질 수 없습니다. GKE 스토리지는 emptyDir(Pod 종료 시 삭제), hostPath(노드 종속), PVC(Pod 독립 영구 보존)를 구분해야 합니다. 여러 Pod가 동시에 같은 스토리지에 접근해야 한다면 ReadWriteMany(RWX)와 Google Cloud Filestore를 조합합니다. 컨테이너 이미지는 Artifact Registry를 사용하고(Container Registry는 레거시), 접근 권한은 roles/artifactregistry.reader를 노드 서비스 계정이나 Workload Identity로 부여합니다.
---
정리: GKE 운영 체크리스트와 자주 쓰는 kubectl 명령
시험 직전 최종 점검용 체크리스트입니다.
| 체크 항목 | 권장 설정 | |---------|----------| | 클러스터 가용성 | Regional 클러스터 (3존 분산) | | 인증 방식 | Workload Identity | | 네트워크 모드 | VPC-native (IP 별칭) | | 이미지 레지스트리 | Artifact Registry | | 노드 OS 업데이트 | 자동 업그레이드 활성화 | | 비용 최적화 | Spot 노드 풀 + Cluster Autoscaler | | Pod 스케일링 | HPA (수평) + VPA (수직, 선택적) | | 보안 격리 | Private 클러스터 + Authorized Networks | | 스토리지 | PVC + Persistent Disk (영구) / Filestore (다중 접근) | | 업그레이드 순서 | 컨트롤 플레인 먼저 → 노드 순차 |
자주 쓰는 kubectl 명령을 정리합니다.
GKE는 쿠버네티스 오케스트레이션의 복잡성을 Google의 관리형 서비스로 흡수하면서, 필요한 곳에서는 세밀한 제어권을 돌려주는 구조로 설계되어 있습니다. Autopilot로 시작해 워크로드 요구사항이 정교해지면 Standard로 전환하거나 병행하는 것이 현실적인 운영 경로입니다. 시험에서는 스케일링 레이어(HPA·VPA·Cluster Autoscaler)의 역할 구분과 Workload Identity 보안 모델을 정확히 이해하고 있는지를 반드시 확인합니다.