Google PCNE: GKE, 컨테이너 및 애플리케이션 네트워킹 — 학습 가이드

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Network Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Google Kubernetes Engine(GKE)은 Google Cloud 네트워킹과 긴밀하게 통합됩니다. 안정성과 보안을 위한 설계에는 VPC 네이티브 IP 주소 지정, 비공개 컨트롤 플레인, 이그레스, 남-북 및 동-서 트래픽, 정책 적용, 멀티 클러스터 구성에 대한 이해가 필요합니다. 이 섹션에서는 Google Cloud의 컨테이너 및 애플리케이션 네트워킹에 대한 설계 지침, 운영상의 고려 사항, 일반적인 장애 모드를 제공합니다.

GKE IP 아키텍처 및 비공개 클러스터

VPC 네이티브 클러스터

VPC 서브넷에서 두 개의 보조 범위를 사용하는 alias IP를 사용합니다. 하나는 Pod용(PodCIDR), 다른 하나는 Service용(ServiceCIDR)입니다. 이를 통해 노드에서 iptables 기반 SNAT를 방지하고, NEG를 사용한 컨테이너 네이티브 부하 분산을 활성화하며, 경로 기반 클러스터보다 확장성이 뛰어납니다.
크기 조정 가이드라인:
- Pod: PodsPerNode × MaxNodes를 할당하고, 추가 여유 공간(20–30%)을 확보합니다. 예를 들어, 현재 10개 노드 × 20개 Pod에서 100 × 200으로 증가할 경우 /17 Pod 범위가 권장되며, Service는 2,000개 이상의 서비스를 위해 /21 범위에 충분히 들어갑니다.
- Service: 각 ClusterIP는 하나의 IP를 소비합니다. 헤드리스에서 ClusterIP로의 마이그레이션 및 애드온을 위한 여유 공간을 고려해야 합니다.
장애 모드:
- Pod IP 고갈: Pod가 Pending 상태로 유지되거나 CNI/IPAM 오류가 나타납니다. 보조 Pod 범위를 확장하거나 노드당 최대 Pod 수를 줄인 다음 노드를 재생성합니다.
- Service IP 고갈: 새 Service가 ClusterIP를 할당하지 못합니다. Service 보조 범위를 확장합니다.
- 별칭 범위 중복: 클러스터 생성이 실패하거나 라우팅 블랙홀이 발생합니다. 다른 서브넷이나 피어링된 VPC와 중복되지 않는지 확인합니다.

비공개 클러스터, 컨트롤 플레인 액세스 및 노드 이그레스

비공개 클러스터는 컨트롤 플레인 엔드포인트를 생산자 피어링을 통해 VPC에서만 연결 가능한 비공개 RFC1918 주소로 제한합니다. 노드에는 외부 IP가 필요하지 않습니다.
운영자를 위한 선택 사항:
- 비공개 엔드포인트만 사용: VPC 서브넷 및 연결된 네트워크에서 컨트롤 플레인에 연결할 수 있습니다. 배스천 또는 Private Service Connect와 함께 Cloud Shell을 사용하여 연결합니다.
- 승인된 네트워크가 있는 공개 엔드포인트: 특정 소스 CIDR로 제한된 공개 IP에 컨트롤 플레인을 노출합니다. 이는 편리하지만 노출이 증가하므로, 엄격한 CIDR 범위 지정 및 강력한 관리자 ID 제어와 함께 사용해야 합니다.
노드 이그레스:
- 외부 IP가 없는 노드의 경우 Cloud NAT를 통해 인터넷 바운드 이그레스를 제공합니다. 이를 통해 노드를 비공개로 유지하면서 OS 업데이트, 외부 레지스트리에서 컨테이너 이미지 가져오기, 파트너 API 액세스가 가능합니다.
- 외부 IP 없이 Google API 및 Artifact/Container Registry에 액세스하려면 노드 서브넷에서 Private Google Access(PGA)를 활성화합니다. PGA는 공개 소스 IP 없이 Google API/레지스트리 트래픽을 Google 에지로 확인하고 라우팅합니다. 이미지를 가져올 때는 PGA가 선호됩니다. Google 이외의 이그레스도 필요한 경우 Cloud NAT와 함께 사용합니다.
- 타사 방화벽을 통해 0.0.0.0/0을 전송하는 경우에도 PGA를 활성화하고, Google API VIP 범위에 대한 정적 경로를 기본 인터넷 게이트웨이에 추가하여 Google 서비스에 대한 방화벽을 우회하도록 합니다.

확장 및 IP 문제 해결

서브넷 보조 범위 수준에서 alias IP 사용량을 모니터링합니다. IP 압박이 증가하는 경우:
- 보조 범위 크기를 늘립니다(더 큰 범위를 추가하고, 필요한 경우 클러스터를 재생성하거나 워크로드를 마이그레이션합니다).
- 노드당 IP 사용량과 스케줄링 단편화 사이의 균형을 맞추기 위해 노드당 최대 Pod 수를 조정합니다.
- 방치된 Service를 정리합니다. 헤드리스 Service는 ClusterIP를 할당하지 않지만, ClusterIP로 변환하면 IP를 소비합니다.
Shared VPC, VPC Peering 또는 멀티 클러스터 서비스를 사용할 때 IP 재할당을 피하기 위해, 중복되지 않는 보조 범위를 사용하여 멀티 리전 확장을 계획합니다.

Ingress, Gateway API, 서비스 및 정책

서비스와 로드 밸런서

서비스 유형:
- ClusterIP: 클러스터 내부 접근 전용. east–west 트래픽은 kube-proxy 또는 dataplane v2를 사용합니다.
- NodePort: 각 노드에 포트를 할당합니다. 많은 LB에서 백엔드로 사용되지만 인터넷에 직접 노출하는 것은 피해야 합니다.
- LoadBalancer: 클라우드 로드 밸런서를 프로비저닝합니다. 외부 또는 내부 L4 로드 밸런서는 TCP/UDP를 지원하며, 필요한 경우 세션 어피니티 ClientIP를 통해 여러 프로토콜에 걸쳐 고정성(stickiness)을 제공합니다.
컨테이너 네이티브 로드 밸런싱은 Network Endpoint Groups (NEGs)를 사용하여 로드 밸런서가 Pod IP:포트를 직접 타겟팅하므로, 상태 신호 전달을 개선하고 노드 홉을 줄입니다. GKE의 경우 GKE Pod NEG(GCE_POD)를 사용합니다. 다른 NEG 유형으로는 VM_IP_PORT, Internet FQDN, PSC가 있습니다.
GKE Ingress 및 Gateway API:
- Ingress는 Google의 전역 외부 HTTP(S) 로드 밸런서 또는 리전 내부 HTTP(S) 로드 밸런서를 사용하는 HTTP(S) north-south 트래픽에 안정적입니다. 컨트롤러는 표준 패턴에 대해 상태 확인 및 방화벽 규칙을 자동으로 프로그래밍합니다.
- Gateway API는 Gateways 및 HTTPRoutes/TCPRoutes를 통해 더 표현력이 풍부한 모델을 제공합니다. 멀티테넌트 구성, 고급 라우팅, 여러 환경에 걸친 일관된 사양을 지원합니다. 미래 경쟁력을 고려한다면 Gateway API를 선택하고, 단순성과 호환성이 중요하다면 Ingress를 사용하세요.

클라이언트 제한 및 상태 확인

클라이언트를 특정 소스 범위로 제한하는 것은 L4에서는 백엔드 인스턴스를 타겟팅하는 VPC 방화벽 규칙으로, L7에서는 HTTP(S) 로드 밸런서의 Cloud Armor 정책으로 수행할 수 있습니다.
상태 확인이 통과되도록 항상 Google 상태 검사기 소스 범위를 백엔드 타겟이나 Pod에 허용해야 합니다. 일부 배포에서는 GKE가 k8s-fw 규칙을 자동으로 생성합니다. 제한적인 규칙을 추가하는 경우, 상태 검사기 범위에 대한 명시적인 허용 규칙을 유지해야 합니다.
L4 백엔드에 대한 예시 접근 방식: 노드에 “application” 태그를 지정하고, 허용된 클라이언트 CIDR 및 Google 상태 확인 범위로부터의 tcp:NodePort에 대한 허용 방화벽 규칙을 생성합니다. 그리고 다른 모든 소스에 대해서는 더 높은 우선순위의 거부 규칙을 생성하고 로깅을 활성화하여 차단된 트래픽을 관찰합니다.

네트워크 정책과 dataplane v2

Kubernetes NetworkPolicy를 활성화하고 GKE Dataplane V2를 사용하여 eBPF 기반으로 정책을 적용하면, iptables 기반 엔진에 비해 성능과 정확성이 향상됩니다.
기본 보안 태세:
- 네임스페이스에 대해 기본적으로 egress와 ingress를 거부하고, Pod-to-Pod 및 Pod-to-Service 흐름을 명시적으로 허용합니다.
- namespace와 podSelectors를 사용하여 서비스 계층(프런트엔드, 백엔드, 데이터)을 만들고, 최소한으로 필요한 방향과 포트만 허용합니다.
안전한 서비스 통신:
- 클러스터 내 제로 트러스트를 위해서는 서비스 메시를 통해 mTLS를 제공하는 것이 가장 좋습니다. NetworkPolicy는 L3/L4를 처리하며 신원을 인증할 수 없습니다.
- north-south 트래픽의 경우, HTTP(S) LB에 Cloud Armor를 연결하여 WAF, 비율 제한(rate limiting) 기능을 사용하고, 미리보기 모드를 통해 사용자에게 영향을 주지 않으면서 의심스러운 공격자에 대한 거부 규칙을 테스트할 수 있습니다.

장애 모드와 트레이드오프

NetworkPolicy가 너무 많거나 범위가 너무 넓으면 예기치 않은 트래픽 차단이 발생할 수 있습니다. 단계적 출시, 로깅, 정책 설명 도구를 통해 검증해야 합니다.
NodePort와 외부 방화벽 규칙에 의존하는 방식은 취약합니다. 관리형 로드 밸런서와 Pod NEG를 사용하는 것이 좋습니다.
Gateway API는 더 풍부한 기능을 제공하지만 컨트롤러의 성숙도와 팀의 숙련도가 필요합니다. 헤더 기반 라우팅이나 mTLS passthrough와 같은 기능은 릴리스 채널별로 검증해야 합니다.

다중 클러스터, 서비스 메시, 아이덴티티

다중 클러스터 서비스 및 플릿 네트워킹

클러스터를 플릿에 등록하여 Multi-Cluster Services(MCS)를 사용하면 클러스터 간 서비스 검색 및 부하 분산이 가능합니다. 각 클러스터에서 서비스를 내보내면(export) 클라이언트는 여러 클러스터의 엔드포인트로 지원되는 단일 DNS 이름을 확인(resolve)합니다.
클러스터 간 트래픽 패턴:
- 동일 VPC, 다른 서브넷: 트래픽이 비공개 RFC1918을 통해 흐르므로 비용과 지연 시간이 최적화됩니다.
- 다른 VPC: VPC Peering을 사용하여 비공개로 간단하게 연결할 수 있지만 전이적(transitive) 연결은 지원되지 않습니다. 조직이 다르거나 인터넷을 통한 암호화가 필요한 경우 Cloud VPN/Cloud Router를 사용합니다. 중앙 집중식 관리를 위해서는 Shared VPC를 사용하여 서비스 프로젝트에 필요한 서브넷만 노출합니다.
장애 모드:
- 중첩되는 CIDR은 라우팅을 차단합니다. 피어링이나 VPN을 구성하기 전에 PodCIDR과 ServiceCIDR이 겹치지 않는지 확인해야 합니다.
- DNS split-horizon 문제는 클러스터 간 이름 확인을 방해할 수 있습니다. 검색 경로(search path)와 스텁 도메인(stub domain)을 검증해야 합니다.

서비스 메시, east-west, 관측성

Anthos Service Mesh와 같은 서비스 메시를 배포하여 다음을 구현합니다:
- 강력한 워크로드 아이덴티티를 사용한 mTLS, 트래픽 정책(재시도, 타임아웃, 이상 감지), 트래픽 분할.
- 메시 페더레이션 또는 다중 기본(multi-primary) 토폴로지를 통해 클러스터 전반에 일관된 east-west 정책을 적용합니다.
- 풍부한 원격 측정(telemetry): 워크로드별 골든 시그널, 요청 추적, 정책 감사.
장단점:
- 사이드카는 리소스 오버헤드를 증가시킵니다. 앰비언트(ambient) 또는 사이드카 없는(sidecarless) 모드는 비용을 줄일 수 있지만, 기능 동등성(feature parity)을 검증해야 합니다.
- 메시는 컨트롤 플레인 종속성을 추가합니다. HA 컨트롤 플레인과 정상적인 성능 저하(graceful degradation)를 고려하여 설계해야 합니다.

워크로드 아이덴티티, 보안 비밀, 최소 권한

Workload Identity를 사용하여 Kubernetes Service Accounts(KSA)를 Google 서비스 계정(GSA)에 매핑하여 수명이 긴 키를 제거합니다. KSA에 GSA 이메일로 어노테이션을 추가하고 GSA에 최소한의 IAM 역할을 부여합니다.
보안 비밀 관리:
- 민감한 데이터의 경우 일반 Kubernetes Secret 사용을 지양하고, Secret Manager와 CSI 드라이버를 사용하여 런타임에 보안 비밀을 마운트하는 것을 선호합니다. 만약 Kubernetes Secret을 유지해야 한다면 CMEK를 사용하여 미사용 시 암호화(encrypt at rest)합니다.
- GSA 수준에서 보안 비밀과 버킷에 대한 최소 권한 액세스를 부여합니다. 프로젝트 전체 역할을 피하고, 해당하는 경우 storage.objectViewer와 같이 리소스 수준 역할로 범위를 지정합니다.

복원력 및 보안 플랫폼 설계 고려사항

고가용성을 위해 리전 클러스터를 사용하고 노드를 여러 영역(zone)에 분산시킵니다. North-south 트래픽의 경우, 전역 HTTP(S) 부하 분산을 사용하여 전 세계 사용자에게 최저 지연 시간을 제공합니다.
컨트롤 플레인 연결: 비공개 컨트롤 플레인을 선택하고, 승인된 네트워크(Authorized Networks)를 사용하는 등 반드시 필요한 경우가 아니면 공개 노출을 피합니다.
이그레스(Egress): 외부 IP가 없는 노드와 Cloud NAT 및 PGA를 함께 사용하면 보안과 기능성의 균형을 맞출 수 있습니다.
관측성: 방화벽 로깅, VPC Flow Logs, 메시 원격 측정을 활성화하여 정책에 의한 차단이나 지연 시간 급증을 신속하게 진단합니다.

실제 문제 시나리오

Contoso Retail은 us-east1과 europe-west1에 두 개의 비공개 GKE 리전 클러스터를 운영하고 있습니다. 요구사항은 다음과 같습니다: 노드에 외부 IP 없음, 회사 CIDR로만 제한된 보안 인그레스, 스토어프런트 서비스의 글로벌 가용성, 인터넷 노출 없는 이미지 가져오기, API 계층의 클러스터 간 장애 조치. 이전에 트래픽 급증 시 Pod IP 고갈을 경험한 바 있습니다.

접근 방식

충분한 보조 범위를 가진 VPC 네이티브 서브넷을 설계합니다.
- 근거: 리전당 /17 Pod 범위와 /21 서비스 범위를 할당하여 100개 노드 × 노드당 200개 Pod 및 1,500개 서비스를 20–30%의 여유 공간을 두고 감당할 수 있도록 합니다. 이는 Pod IP 고갈 재발을 방지하고 성장 과정에서 IP 재할당을 피하게 해줍니다.
비공개 컨트롤 플레인 엔드포인트를 가진 비공개 클러스터를 생성합니다.
- 근거: 컨트롤 플레인 노출을 VPC로 제한합니다. 운영자는 관리 서브넷의 배스천 호스트를 통해 연결합니다. 이는 승인된 네트워크(Authorized Networks)를 사용하는 공개 엔드포인트에 비해 공격 표면을 줄여줍니다.
노드 서브넷에서 Cloud NAT와 Private Google Access를 활성화합니다.
- 근거: 노드에 외부 IP가 없지만 Artifact Registry에서 이미지를 가져오고 OS/패키지 미러에 도달해야 합니다. PGA는 공개 소스 IP 없이 Google API 액세스를 보장하고, Cloud NAT는 필요에 따라 Google 이외의 이그레스(egress)를 처리합니다.
Gateway API와 Pod NEG를 사용하여 전역 HTTP(S) 인그레스를 구현합니다.
- 근거: 단일 전역 애니캐스트(anycast) VIP는 전 세계 사용자의 지연 시간을 줄여줍니다. GKE Pod NEG는 상태 확인을 Pod로 직접 보내 장애 감지를 개선합니다. Gateway API는 인프라 Gateway와 앱 소유의 Route 간에 명확한 분리를 제공합니다.
클라이언트 액세스를 제한하고 상태 확인을 허용합니다.
- 근거: Cloud Armor 정책을 연결하여 회사 CIDR만 허용하고, 기본적으로는 거부하며, 미리보기 모드(preview mode)를 사용하여 새로운 차단을 안전하게 평가합니다. 또한, VPC 방화벽 규칙이 Google 상태 확인 소스 범위에서 백엔드 NEG로의 트래픽을 허용하여 상태 확인이 정상(green)으로 유지되도록 합니다.
GKE Dataplane V2를 사용하여 NetworkPolicy를 적용합니다.
- 근거: 네임스페이스별로 인그레스와 이그레스를 기본적으로 거부하고, 프론트엔드-백엔드 및 백엔드-데이터베이스 포트만 허용합니다. Dataplane V2는 eBPF를 사용하여 정책을 효율적으로 적용하여, 침해된 Pod의 영향 반경(blast radius)을 줄입니다.
플릿 전체에 Multi-Cluster Services를 활성화합니다.
- 근거: 두 리전 모두에서 API 서비스를 내보내고(export) 단일 DNS를 게시합니다. 클라이언트는 클러스터 전반의 정상 엔드포인트로 자동으로 장애 조치됩니다. 두 클러스터 모두 리전별 서브넷을 가진 동일한 VPC에 있으므로, 리전 간 트래픽은 비공개로 유지되며 최소한의 오버헤드만 발생합니다.
east-west 보안 및 관측성을 위해 서비스 메시를 도입합니다.
- 근거: 서비스 간 mTLS를 강제하고, 재시도/타임아웃 예산을 추가하며, 라우트별 메트릭과 추적 정보를 얻습니다. 메시 수준 정책은 NetworkPolicy를 보완합니다. NetworkPolicy는 L3/L4 연결 가능성을 제어하고, 메시는 L7에서 서비스 아이덴티티를 인증하고 권한을 부여합니다.
워크로드 아이덴티티와 보안 비밀을 강화합니다.
- 근거: Workload Identity를 통해 KSA를 좁은 범위의 GSA에 매핑하고, 보고서 페처(fetcher)를 위한 storage.objectViewer와 같이 필요한 역할만 부여합니다. Secret Manager CSI를 통해 자격 증명을 전달하여 매니페스트에 정적 보안 비밀이 포함되는 것을 방지합니다.
용량 및 로깅 가드레일을 구현합니다.
- 근거: IP 사용량의 균형을 맞추기 위해 노드당 최대 Pod 수(max-pods-per-node)를 신중하게 설정합니다. 보조 범위 사용률과 VPC Flow Logs를 모니터링합니다. 허용된 경로는 유지하면서 의도하지 않은 클라이언트 트래픽을 파악하기 위해, 애플리케이션 태그에 대해 로깅이 활성화된 명시적인 높은 우선순위의 ‘모두 거부’ 방화벽 규칙을 생성합니다.