GCP GKE 기본 구조: Autopilot vs Standard, Node Pool, Networking

GCP GKE 기본 구조: Autopilot vs Standard, Node Pool, Networking

2026. 6. 8. 09:43ㆍCloud/GCP

"GKE 클러스터를 만드는데 Autopilot이랑 Standard 중에 뭘 골라야 하죠?" GKE는 Google Cloud에서 제공하는 매니지드 Kubernetes 서비스입니다. 다른 매니지드 서비스와 달리 Google이 Kubernetes를 처음 설계한 팀이 직접 운영하는 서비스라는 점이 특징입니다. 이 글에서는 GKE 클러스터를 처음 설계할 때 반드시 결정해야 하는 세 가지 축(Autopilot vs Standard 모드, Node Pool, Networking)을 정리합니다.

핵심 요약

GKE는 두 가지 운영 모드를 제공합니다. Autopilot은 Google이 노드까지 관리하고, Standard는 사용자가 Node Pool을 직접 설계합니다.
클러스터 관리 비용은 $0.10/시간(~$73/월)이며, Autopilot 또는 Zonal Standard 클러스터 1개에 대해 월 $74.40 크레딧이 제공됩니다.
GKE는 VPC-native 모드가 기본입니다. Pod와 Service에 별도의 Secondary IP Range를 할당하여 VPC 내 다른 리소스와 직접 통신이 가능합니다.
Dataplane V2(Cilium 기반)가 기본 네트워킹 레이어로, kube-proxy 없이 eBPF로 패킷을 처리합니다.

1. GKE란 무엇인가

GKE(Google Kubernetes Engine)는 Google Cloud에서 제공하는 매니지드 Kubernetes 서비스입니다. Control Plane(API Server, etcd, Scheduler, Controller Manager)을 Google이 관리하고, 사용자는 워크로드 배포와 운영에 집중합니다.

스타트업에서 마이크로서비스 15개를 운영한다고 가정합니다. GKE를 사용하면 etcd 백업, Control Plane 업그레이드, 인증서 갱신을 Google이 처리합니다. 사용자는 "어떤 모드로 클러스터를 운영할 것인가"와 "Pod 네트워크를 어떻게 설계할 것인가"에 집중하면 됩니다.

구분	자체 운영 (kubeadm 등)	GKE
Control Plane 관리	직접 설치, 업그레이드, 모니터링	Google이 완전 관리
etcd 백업	직접 구성	Google이 자동 백업
업그레이드	수동 (다운타임 관리 필요)	Release Channel 기반 자동/수동 선택
인증서 관리	수동 갱신	자동 갱신
비용	VM + 운영 인력	클러스터 관리비 + Compute 비용
SLA	직접 설계	Regional: 99.95% / Zonal: 99.5%

2. GKE 전체 아키텍처 구조

GKE 클러스터는 크게 세 영역으로 나뉩니다.

영역	관리 주체	핵심 구성 요소
Control Plane	Google (사용자 접근 불가)	API Server, etcd, Scheduler, Controller Manager, Cloud Controller Manager
Compute (Node)	모드에 따라 다름	Autopilot: Google 관리 / Standard: 사용자 관리
Networking	사용자 설계 + Google 인프라	VPC, Subnet, Secondary IP Range, Cloud Load Balancer, Cloud DNS

핵심 설계 포인트: GKE의 Control Plane은 Google이 관리하는 별도 프로젝트에서 동작합니다. 사용자 프로젝트에는 Worker Node(Compute Engine VM)만 표시됩니다. EKS, AKS와 동일한 구조이지만, GKE는 Regional 클러스터가 기본이며 Control Plane이 3개 Zone에 자동 분산됩니다.

3. Autopilot vs Standard: 모드 선택

GKE에서 클러스터를 만들 때 가장 먼저 결정하는 것이 운영 모드입니다. Autopilot은 Google이 노드 프로비저닝, 스케일링, 보안 패치까지 관리합니다. Standard는 사용자가 Node Pool을 직접 설계하고 관리합니다.

3.1 Autopilot 모드

Autopilot은 "Pod만 정의하면 나머지는 Google이 처리"하는 모드입니다.

동작 방식: 1. 사용자가 Pod spec(CPU, Memory 요청)을 정의합니다. 2. Google이 요청에 맞는 노드를 자동 프로비저닝합니다. 3. Pod가 종료되면 노드도 자동으로 축소됩니다.

장점: - 운영 부담 최소화: Node Pool 설계, OS 패치, 보안 강화를 Google이 처리합니다. - Pod 기반 과금: 실행 중인 Pod의 리소스 요청분만 과금됩니다. 유휴 노드 비용이 발생하지 않습니다. - 보안 강화 기본 적용: Container-Optimized OS, Workload Identity, Shielded GKE Nodes가 기본 설정됩니다.

제약: - DaemonSet 사용에 제한이 있습니다(Google이 승인한 DaemonSet만 허용). - Privileged 컨테이너를 실행할 수 없습니다. - Node에 SSH 접근이 불가능합니다. - Node 수준의 커스터마이징(sysctl, 커널 모듈 등)이 불가능합니다.

3.2 Standard 모드

Standard는 사용자가 Node Pool을 직접 설계하고, Machine Type, Autoscaling 정책, OS 이미지를 선택하는 모드입니다.

장점: - 완전한 제어권: Machine Type, Disk 타입, 네트워크 태그, Taint/Label을 자유롭게 설정할 수 있습니다. - DaemonSet 자유 사용: 모니터링 에이전트, 로그 수집기 등을 DaemonSet으로 배포할 수 있습니다. - Privileged 컨테이너: GPU 드라이버, 커널 모듈 로드 등 특권이 필요한 워크로드를 실행할 수 있습니다. - Node 접근: SSH로 노드에 접근하여 디버깅이 가능합니다.

제약: - Node VM에 대해 과금됩니다. Pod가 사용하지 않는 유휴 리소스도 비용이 발생합니다. - OS 패치, 보안 강화를 사용자가 관리하거나 자동 업그레이드를 설정해야 합니다. - Node Pool 설계를 잘못하면 리소스 낭비 또는 스케줄링 실패가 발생할 수 있습니다.

3.3 비교 정리

기준	Autopilot	Standard
노드 관리	Google	사용자
과금 모델	Pod 리소스 요청 기준	Node VM 기준
DaemonSet	제한적 (승인된 것만)	자유
Privileged 컨테이너	불가	가능
SSH 접근	불가	가능
Autoscaling	자동 (Pod 기반)	Cluster Autoscaler + NAP 설정 필요
보안 기본값	강화된 기본 설정	사용자가 설정
SLA	99.95% (Regional) / 99.9% (Multi-zone Pod)	99.95% (Regional) / 99.5% (Zonal)
적합 환경	일반 웹 서비스, 운영 팀이 작은 조직	GPU 워크로드, 커스텀 네트워킹, 대규모 클러스터

3.4 모드 선택 기준

실무에서의 판단 기준:

Autopilot을 선택하는 경우: 운영 팀이 2~3명이고, 표준 웹 서비스(API, Frontend)를 운영할 때. DaemonSet이나 Privileged 권한이 필요 없고, Pod 기반 과금으로 유휴 비용을 줄이고 싶을 때.
Standard를 선택하는 경우: GPU/TPU 워크로드 비중이 높거나, 커스텀 모니터링 에이전트(Datadog DaemonSet 등)를 사용해야 할 때. 노드 수준 튜닝(큰 Page Size, 커널 파라미터)이 필요하거나, 전체 노드 리소스를 효율적으로 사용해야 하는 대규모 배치 처리에 적합합니다.

# Autopilot 클러스터 생성
gcloud container clusters create-auto my-autopilot-cluster \
  --region=asia-northeast3 \
  --release-channel=regular

# Standard 클러스터 생성
gcloud container clusters create my-standard-cluster \
  --region=asia-northeast3 \
  --release-channel=regular \
  --num-nodes=3 \
  --machine-type=e2-standard-4 \
  --enable-dataplane-v2

4. Node Pool: 워크로드를 실행하는 단위 (Standard 모드)

4.1 Node Pool이란

Node Pool은 동일한 Machine Type, Disk 타입, Label, Taint를 공유하는 노드들의 그룹입니다. Standard 모드에서는 워크로드 특성에 맞게 여러 Node Pool을 추가하여 리소스를 효율적으로 분배합니다.

Autopilot 모드에서는 Node Pool을 사용자가 직접 관리하지 않습니다. Google이 Pod 요청에 따라 자동으로 적절한 노드를 프로비저닝합니다.

4.2 Node Pool 분리 전략

워크로드 특성이 다르면 Node Pool을 분리하는 것이 일반적입니다. 분리하는 이유는 세 가지입니다.

리소스 격리: 시스템 컴포넌트(kube-dns, metrics-server)와 애플리케이션이 리소스를 경쟁하지 않도록 합니다.
비용 최적화: Spot VM을 사용할 수 있는 워크로드와 안정적 VM이 필요한 워크로드를 분리합니다.
하드웨어 요구사항: GPU가 필요한 ML 워크로드와 범용 CPU 워크로드를 분리합니다.

4.3 실무 Node Pool 설계 예시

웹 서비스를 운영하는 팀이 다음 요구사항을 가진다고 가정합니다: - API 서버: 안정적인 CPU, 항상 3개 이상 Pod 유지 - 배치 처리: 야간 대량 처리, 중단되어도 재시작 가능 - ML 추론: GPU 필요, 요청량에 따라 스케일

# Default Pool (시스템 + 가벼운 워크로드)
gcloud container node-pools create default-pool \
  --cluster=my-standard-cluster \
  --region=asia-northeast3 \
  --machine-type=e2-standard-4 \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=3 \
  --max-nodes=5

# API Workload Pool
gcloud container node-pools create api-pool \
  --cluster=my-standard-cluster \
  --region=asia-northeast3 \
  --machine-type=n2-standard-4 \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=3 \
  --max-nodes=10 \
  --node-labels=workload=api \
  --node-taints=dedicated=api:NoSchedule

# Batch Pool (Spot VM으로 비용 절감)
gcloud container node-pools create batch-pool \
  --cluster=my-standard-cluster \
  --region=asia-northeast3 \
  --machine-type=n2-standard-8 \
  --num-nodes=0 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=20 \
  --spot \
  --node-labels=workload=batch \
  --node-taints=dedicated=batch:NoSchedule

# GPU Pool (ML 추론)
gcloud container node-pools create gpu-pool \
  --cluster=my-standard-cluster \
  --region=asia-northeast3 \
  --machine-type=a2-highgpu-1g \
  --accelerator=type=nvidia-tesla-a100,count=1 \
  --num-nodes=1 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=3 \
  --node-labels=workload=gpu \
  --node-taints=nvidia.com/gpu=true:NoSchedule

4.4 Node Auto-Provisioning (NAP)

Node Auto-Provisioning은 Cluster Autoscaler의 확장 기능입니다. 기존 Node Pool에 스케줄할 수 없는 Pod가 발생하면, 해당 Pod의 요구사항에 맞는 새로운 Node Pool을 자동으로 생성합니다.

Standard 모드에서도 Autopilot과 유사한 자동화를 원한다면 NAP를 활성화할 수 있습니다. 다만 NAP가 생성하는 Node Pool의 Machine Type과 크기를 완전히 통제하기 어려우므로, 비용 예측이 중요한 환경에서는 수동 Node Pool 설계가 더 적합할 수 있습니다.

# NAP 활성화
gcloud container clusters update my-standard-cluster \
  --region=asia-northeast3 \
  --enable-autoprovisioning \
  --min-cpu=4 \
  --max-cpu=100 \
  --min-memory=16 \
  --max-memory=400

4.5 Node Pool 설계 시 고려사항

관점	고려 사항
가용성	Regional 클러스터는 Node Pool이 3개 Zone에 자동 분산
비용	Spot VM 활용, min-nodes 0으로 유휴 비용 제거
격리	Taint/Toleration + nodeSelector로 워크로드 격리
업그레이드	Node Pool별 독립 업그레이드 가능 (Blue-Green 노드 전략 가능)
OS 이미지	Container-Optimized OS(기본), Ubuntu, Windows 선택 가능
Machine Type	E2(비용 효율), N2(균형), C2(CPU 집약), A2/G2(GPU)

주의
GKE Regional 클러스터에서 num-nodes는 Zone당 노드 수입니다. --num-nodes=3으로 설정하면 3 Zone × 3 Node = 총 9개 노드가 생성됩니다. 비용 계산 시 이 점을 반드시 고려해야 합니다.

5. Networking: VPC-native 구조

GKE에서 네트워킹 설계는 IP 주소 관리, 성능, Google Cloud 서비스 통합에 직접적으로 영향을 미칩니다.

5.1 VPC-native 클러스터 (기본)

GKE는 VPC-native 모드가 기본입니다. 이 모드에서는 Alias IP Range를 사용하여 Pod와 Service에 VPC 내 IP를 할당합니다.

동작 방식: 1. Subnet의 Primary IP Range에서 Node IP를 할당합니다. 2. Subnet의 Secondary IP Range(Pod Range)에서 각 Pod에 IP를 할당합니다. 3. Subnet의 또 다른 Secondary IP Range(Service Range)에서 ClusterIP를 할당합니다. 4. Pod IP가 VPC의 일급 시민(first-class citizen)으로 동작합니다. VPC 내 다른 리소스에서 Pod IP로 직접 라우팅이 가능합니다.

장점: - Pod가 VPC IP를 사용하므로 Firewall Rule, Cloud NAT, VPC Flow Log에서 Pod 트래픽을 직접 확인할 수 있습니다. - NAT나 오버레이 없이 다른 Compute Engine 인스턴스, Cloud SQL, Memorystore 등과 직접 통신합니다. - Network Policy를 IP 기반으로 정밀하게 적용할 수 있습니다.

5.2 IP 주소 설계

VPC-native 클러스터를 만들 때 세 가지 IP 범위를 결정해야 합니다.

IP Range	용도	기본 크기	계산 기준
Node Subnet (Primary)	Node IP	/24 (254개)	Node 수 + 여유분
Pod Range (Secondary)	Pod IP	/14 (262,144개)	Node당 최대 110 Pod × Node 수
Service Range (Secondary)	ClusterIP	/20 (4,096개)	예상 Service 수

실무 설계 예시 — 50개 노드, 워크로드 확장 가능성 고려:

# VPC와 Subnet 생성
gcloud compute networks create gke-vpc \
  --subnet-mode=custom

gcloud compute networks subnets create gke-subnet \
  --network=gke-vpc \
  --region=asia-northeast3 \
  --range=10.0.0.0/24 \
  --secondary-range=pod-range=10.4.0.0/14,service-range=10.8.0.0/20

# GKE 클러스터에서 기존 Subnet 사용
gcloud container clusters create my-cluster \
  --region=asia-northeast3 \
  --network=gke-vpc \
  --subnetwork=gke-subnet \
  --cluster-secondary-range-name=pod-range \
  --services-secondary-range-name=service-range

Tip
Pod Range를 너무 작게 잡으면 Node 추가 시 "IP exhaustion" 오류가 발생합니다. 초기 설계 시 넉넉하게 /14 수준을 권장합니다. Secondary Range는 VPC 외부로 라우팅되지 않으므로 IP 충돌 걱정 없이 넓게 할당할 수 있습니다.

5.3 Dataplane V2 (Cilium 기반)

GKE Dataplane V2는 Cilium 기반의 네트워킹 레이어입니다. 기존 kube-proxy + iptables 방식을 대체하여 eBPF로 패킷을 처리합니다.

구분	기존 (kube-proxy + iptables)	Dataplane V2 (Cilium/eBPF)
패킷 처리	iptables 규칙 체인	eBPF 프로그램 (커널 레벨)
성능	Service 수 증가 시 성능 저하	Service 수에 관계없이 일정
Network Policy	Calico 별도 설치 필요	기본 포함 (Kubernetes + Cilium Policy)
관측성	제한적	Hubble 기반 실시간 트래픽 모니터링
상태	레거시	기본값 (신규 클러스터)

Dataplane V2의 운영상 이점: - kubectl 없이도 Hubble UI에서 Pod 간 트래픽 흐름을 실시간으로 확인할 수 있습니다. - Network Policy가 기본 포함되어 별도 CNI 플러그인을 설치하지 않아도 됩니다. - Identity 기반 보안으로, IP가 아닌 Label 기준으로 트래픽을 제어합니다.

5.4 Private Cluster vs Public Cluster

구분	Public Cluster	Private Cluster
Node 외부 IP	있음	없음
API Server 접근	인터넷에서 접근 가능	Authorized Networks 또는 VPN/IAP 필요
보안 수준	Master Authorized Networks로 제한 가능	네트워크 레벨 격리
외부 통신	직접 가능	Cloud NAT 필요
적합 환경	개발/테스트, 빠른 프로토타이핑	프로덕션, 규제 환경

# Private Cluster 생성
gcloud container clusters create private-cluster \
  --region=asia-northeast3 \
  --enable-private-nodes \
  --enable-private-endpoint \
  --master-ipv4-cidr=172.16.0.0/28 \
  --enable-master-authorized-networks \
  --master-authorized-networks=10.0.0.0/24

Private Cluster에서 Node가 외부 이미지(Docker Hub, ghcr.io 등)를 Pull하려면 Cloud NAT를 설정해야 합니다. Artifact Registry(Google 내부)에서 Pull하는 경우에는 Private Google Access가 활성화되어 있으면 NAT 없이 가능합니다.

5.5 Ingress와 외부 트래픽 흐름

외부 트래픽이 GKE 내 Pod에 도달하는 일반적인 경로:

사용자 요청 → Cloud DNS가 Load Balancer VIP를 반환
Cloud Load Balancer → Backend Service(NEG 기반)로 트래픽 전달
NEG(Network Endpoint Group) → Pod IP로 직접 라우팅 (VPC-native 덕분)
Pod → 응답 처리 후 반환

GKE Ingress / Gateway API 선택지: - GKE Ingress Controller: Google Cloud Load Balancer와 자동 연동. NEG 기반으로 Pod에 직접 트래픽 전달. - Gateway API: Kubernetes 표준 API. GKE에서 공식 지원. Multi-cluster Gateway로 여러 클러스터 간 트래픽 분배 가능. - NGINX Ingress Controller: 커뮤니티 솔루션. Node 레벨에서 트래픽 처리.

Tip
GKE의 Container-native Load Balancing(NEG 기반)은 NodePort를 거치지 않고 Pod에 직접 트래픽을 전달합니다. 이는 불필요한 hop을 줄이고 Source IP를 보존하는 이점이 있습니다. VPC-native 클러스터에서 GKE Ingress를 사용하면 자동으로 NEG가 생성됩니다.

6. 비용 관점 정리

6.1 클러스터 관리 비용

항목	비용
클러스터 관리비	$0.10/시간/클러스터 (~$73/월)
Free Tier 크레딧	$74.40/월 (Billing Account당, Autopilot 또는 Zonal Standard 1개에 적용)
Extended Support	추가 $0.50/시간/클러스터 (표준 지원 기간 종료 후)

6.2 Compute 비용 비교

모드	과금 기준	예시
Standard	Node VM 전체	e2-standard-4 × 3 Node × 24시간 = 고정 비용
Autopilot	Pod 리소스 요청	vCPU $0.0445/시간 + Memory $0.0049/GiB/시간 (us-central1 기준)

비용 최적화 전략: - Spot VM (Standard): 중단 가능한 워크로드에 활용하면 60~91% 할인됩니다. - Autopilot Spot: Pod spec에 cloud.google.com/gke-spot: "true" nodeSelector를 추가하면 Spot 노드에서 실행됩니다. - Committed Use Discount: 1년/3년 약정으로 최대 57% 할인됩니다. - Node Pool min-nodes=0: Standard에서 유휴 시간에 노드를 0으로 축소합니다. - Autopilot 미사용 Pod 없음: Pod가 Running 상태가 아니면 과금되지 않습니다.

6.3 비용 시나리오 비교

동일한 워크로드(vCPU 8, Memory 32GiB 상시 사용)를 두 모드에서 운영할 때:

모드	월 비용 (us-central1 기준)	비고
Standard (e2-standard-4 × 3 Node)	~$290 + $73(관리비) = ~$363	유휴 리소스 비용 포함
Autopilot	~$257(vCPU) + ~$115(Memory) + $73(관리비) = ~$445	유휴 비용 없지만 단가 높음

Autopilot이 단가는 높지만 유휴 리소스가 없으므로, Pod 사용률이 낮은 환경(평균 40% 이하)에서는 오히려 Autopilot이 저렴할 수 있습니다. 반대로 Node 활용률이 70% 이상으로 높다면 Standard가 비용 효율적입니다.

7. 운영 시 주의사항

7.1 Release Channel과 업그레이드

GKE는 Release Channel을 통해 자동 업그레이드를 관리합니다.

Channel	특징	적합 환경
Rapid	최신 버전 빠르게 적용	개발/테스트
Regular (기본)	안정화된 후 적용	대부분의 프로덕션
Stable	가장 보수적, 충분히 검증된 후 적용	안정성 최우선 환경
Extended	장기 지원 (최대 24개월)	업그레이드 주기를 최소화해야 하는 환경

# 업그레이드 가능 버전 확인
gcloud container get-server-config --region=asia-northeast3

# 유지보수 창 설정 (업그레이드 시간 제한)
gcloud container clusters update my-cluster \
  --region=asia-northeast3 \
  --maintenance-window-start=2026-01-01T02:00:00Z \
  --maintenance-window-end=2026-01-01T06:00:00Z \
  --maintenance-window-recurrence="FREQ=WEEKLY;BYDAY=SA,SU"

7.2 모니터링과 진단

도구	용도
Cloud Monitoring (GKE Dashboard)	Node/Pod 메트릭, Autoscaler 동작 확인
Cloud Logging	컨테이너 로그, 시스템 로그 수집
Hubble (Dataplane V2)	Pod 간 네트워크 트래픽 실시간 관측
Error Reporting	애플리케이션 오류 자동 그룹핑
Cost Management	Namespace/Label별 비용 할당

7.3 보안 기본 설정

설정	Standard 기본값	Autopilot 기본값	권장
Workload Identity	수동 활성화	기본 활성화	반드시 활성화
Shielded Nodes	수동 활성화	기본 활성화	활성화 권장
Binary Authorization	비활성화	비활성화	프로덕션에서 검토
Network Policy	Dataplane V2로 기본 지원	기본 지원	활성화
Pod Security Standards	미적용	Baseline 적용	최소 Baseline 적용

8. EKS, AKS와의 주요 차이점

AWS EKS, Azure AKS 경험이 있는 엔지니어를 위해 핵심 차이를 정리합니다.

기준	GKE	EKS	AKS
Control Plane 비용	$0.10/시간 (Free Tier 크레딧 있음)	$0.10/시간	Free 티어 있음 (SLA 없음)
완전 관리 모드	Autopilot (Pod 기반 과금)	Fargate (Pod 기반 과금)	없음 (Node 기반만)
기본 CNI	VPC-native (Alias IP)	VPC CNI (ENI 기반)	Azure CNI Overlay
Pod IP 특성	VPC Secondary Range IP	VPC ENI IP	Overlay IP (VNet IP 아님)
Network Policy	Dataplane V2 기본 내장	Calico 별도 설치	Azure NPM 또는 Calico
Node 관리 단위	Node Pool	Managed Node Group	Node Pool (System/User)
Ingress 연동	Cloud Load Balancer (NEG 직접 연결)	ALB Controller	NGINX / AGIC
자동 업그레이드	Release Channel 기반	제한적	Channel 기반
IAM 통합	Workload Identity	IRSA (IAM Roles for SA)	Workload Identity

정리

GKE 클러스터를 설계할 때 결정해야 하는 핵심 항목을 요약합니다.

결정 사항	선택지	판단 기준
운영 모드	Autopilot / Standard	운영 부담 vs 제어 필요성
Cluster 유형	Regional / Zonal	SLA 요구 수준 (99.95% vs 99.5%)
Node Pool 분리	워크로드별 Pool	리소스 격리, 비용 최적화, 하드웨어 요구
Machine Type	E2/N2/C2/A2/G2	워크로드 특성 (범용/CPU/GPU)
네트워크 접근	Public / Private Cluster	보안 요구 수준, 운영 복잡도
IP 설계	Pod Range + Service Range	Node 수, Pod 밀도, 향후 확장 계획
업그레이드	Release Channel 선택	안정성 vs 최신 기능
비용 모델	Spot VM / CUD / 기본	워크로드 중단 허용 여부, 사용량 예측 가능성

다음 글에서는 GKE에서 Workload Identity를 사용하여 Service Account를 안전하게 연결하는 방법을 다룹니다.

참고 자료 - GKE Pricing - Choose a GKE Cluster Mode - Autopilot and Standard Feature Comparison - GKE Dataplane V2 - VPC-native Clusters (Alias IP) - GKE Node Pools

'Cloud > GCP' 카테고리의 다른 글

GCP Cloud Storage 종류와 선택 기준: Standard, Nearline, Coldline, Archive (0)	2026.06.07
GCP Cloud Run vs Cloud Functions 차이: 서버리스 컴퓨팅 선택 기준 (0)	2026.06.06
GCP Cloud Load Balancing 기본 구조 정리: 종류, 구성 요소, 동작 원리 (0)	2026.05.30
GCP IAM 기본 개념: Role, Principal, Policy 이해하기 (0)	2026.05.30
GCP VPC란 무엇인가: Subnet, Firewall Rule, Route 개념 정리 (0)	2026.05.30

wero90