외전: Ambient 네트워킹과 Cloud Service Mesh
Cloud Service Mesh는 Envoy와 Istio API를 데이터 평면·제어 평면 표준으로 삼는 구글 쿠버네티스 엔진(GKE)의 service mesh 제품입니다. Google Cloud Next 2026 발표는 추론·학습·보안 축의 신기능에 무게가 실려 있었지만, 이들 워크로드가 실제로 사용자 트래픽과 만나는 지점은 결국 mesh 위에 놓입니다. 본 글은 본 시리즈 외전입니다. Cloud Service Mesh가 East-West 트래픽과 North-South 트래픽을 어떻게 분리해 다루는지, sidecar 모델과 sidecar-less 모델이 어떻게 공존하는지를 정리합니다. 이 글은 네트워킹 축의 외전입니다.
배경: 왜 Ambient 방향으로 진화하는가
기존 사이드카 모델은 Pod마다 Envoy 프록시를 띄워 트래픽을 가로채 보안·가시성을 일관되게 책임지는 대신, Pod 단위 자원 오버헤드와 주입 라이프사이클이 운영 부담으로 남습니다. Cloud Service Mesh는 이 흐름 위에서 데이터 평면을 sidecar-less 옵션까지 넓히고 제어 평면을 글로벌 멀티 클러스터로 옮기는 두 축의 진화를 진행해 왔으며, 본 시리즈는 그 결합을 Ambient라는 말로 묶습니다.
그림 1. 기존 sidecar 모델의 자원·운영 부담과 Cloud Service Mesh의 데이터 평면 진화(Ambient · proxyless gRPC) · 제어 평면 진화(Traffic Director)
트래픽 두 방향: East-West와 North-South
그림 2. Cloud Service Mesh가 트래픽을 분리해 다루는 두 결
mesh 트래픽은 두 방향으로 나뉩니다. East-West는 mesh 내부 서비스 간 호출이고, North-South는 외부에서 mesh로 들어오는 진입 트래픽입니다. Cloud Service Mesh는 두 방향을 서로 다른 리소스 묶음으로 다룹니다. East-West는 Mesh 리소스에 HTTPRoute, GRPCRoute, TCPRoute를 붙여 라우팅을 구성합니다. North-South는 Gateway API의 Gateway 리소스에 같은 Route 리소스 묶음을 붙입니다.
그림 3. East-West는 클라이언트와 서버가 같은 mesh 안에 있을 때의 서비스 간 호출입니다
그림 4. North-South는 외부 클라이언트가 Gateway 리소스를 거쳐 mesh로 들어오는 흐름입니다
이 분리가 갖는 의미는 역할 분담입니다. mesh의 진입점과 라우팅 골격(Mesh, Gateway)은 메시 관리자가 잡고, 그 위에서 서비스 단위 라우팅 규칙(Route)은 서비스 오너가 자기 네임스페이스에서 정의합니다. 같은 Route 리소스가 East-West와 North-South 양쪽에서 재사용된다는 점은 운영 일관성을 살립니다.
데이터 평면: Envoy 사이드카와 proxyless gRPC
Cloud Service Mesh의 데이터 평면은 Envoy 프록시를 기본으로 합니다. 클라이언트 Pod가 보낸 요청은 같은 Pod의 Envoy 사이드카에 가로채여 mesh 정책을 통과한 뒤 목적지로 흐릅니다.
그림 5. 사이드카는 Pod의 모든 인·아웃바운드 트래픽을 가로채 mesh 정책을 적용합니다
사이드카 주입은 네임스페이스 레이블 한 줄로 켭니다.
ubectl label namespace sidecar-example mesh.cloud.google.com/csm-injection=sidecar
레이블이 붙은 네임스페이스에 새로 뜨는 Pod는 자동으로 Envoy 컨테이너를 곁에 둔 채 2/2 Running 상태가 됩니다. 이때 적용할 라우팅을 HTTPRoute로 표현합니다. 다음은 whereami 서비스를 부모로 삼아 같은 서비스의 8080 포트로 트래픽을 보내는 East-West Route입니다.
💻 예시 코드
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: whereami-route
namespace: sidecar-example
spec:
parentRefs:
– name: whereami
kind: Service
group: “”
rules:
– backendRefs:
– name: whereami
port: 8080
그림 6. Envoy 사이드카는 Mesh 리소스가 정의한 mesh에 속하고, HTTPRoute가 라우팅 규칙을 채웁니다
gRPC 워크로드라면 두 가지 선택지가 있습니다. 사이드카 모델로 갈 경우 Service에 networking.gke.io/app-protocols: ‘{“50051”: “HTTP2”}’ 어노테이션을 붙여 백엔드 프로토콜을 HTTP2로 알려야 합니다. 사이드카를 두지 않는 proxyless gRPC 모델로 갈 경우 클라이언트 라이브러리가 직접 xDS로 제어 평면과 통신해 라우팅을 받아옵니다. 두 모델은 같은 mesh 안에서 공존합니다. gRPC 라우팅 규칙을 표현하는 GRPCRoute는 표준 Gateway API CRD이므로 클러스터에 별도로 설치합니다. kubernetes-sigs/gateway-api 저장소의 표준 CRD YAML을 받아 적용하면 됩니다. TCP 트래픽을 다루려면 같은 방식으로 TCPRoute 리소스를 함께 쓸 수 있습니다.
글로벌 제어 평면: Traffic Director
Cloud Service Mesh의 새 관리형 제어 평면은 Traffic Director 구현으로, 단일 클러스터 전용 제어 평면에서 다중 테넌트·글로벌 제어 평면으로 이동합니다.
그림 7. 클러스터별 Istiod가 N×N으로 통신하던 방식에서 모든 클러스터가 글로벌 Traffic Director로 직접 엔드포인트를 보내는 구조로 진화. 글로벌 cross-zonal·cross-region 로드밸런싱, 중앙 집중 헬스 체크, 트래픽 기반 오토스케일링, 관리형 rate limiting이 같은 제어 평면 위에서 결합됩니다.
새 서비스 배포나 정책 변경이 처음 전파될 때는 두 단계 검증을 거치므로 첫 푸시 지연이 다소 늘어나지만, 이미 떠 있는 Pod의 설정 패치나 HPA에 의한 Pod 추가·제거 같은 엔드포인트 이벤트 처리는 동등하거나 빠릅니다.
Gateway API를 쓰려면 fleet 단위로 mesh feature를 켠 뒤 config-api를 gateway로 맞춥니다.
💻 예시 코드
gcloud container fleet mesh enable –project PROJECT_ID
gcloud alpha container fleet mesh update \
–config-api gateway \
–memberships CLUSTER_NAME \
–project PROJECT_ID
같은 fleet 안에서 gateway config-api와 istio config-api 클러스터를 섞어 쓰는 것은 지원하지 않습니다. fleet 안 모든 클러스터의 config-api를 한 가지로 통일해야 합니다.
적용 시나리오
mesh가 이미 깔린 환경에서 외부 진입 트래픽을 정리할 때는 Gateway 리소스 한 곳으로 진입점을 모으고, 서비스 오너가 Route 리소스로 자기 백엔드를 붙이는 방식이 자연스럽습니다. 진입점과 라우팅 규칙이 다른 리소스로 분리되어 있으므로, 메시 관리자는 도메인·TLS·정책을 Gateway에서 관리하고 서비스 오너는 자신의 네임스페이스 안에서 Route만 갱신하면 됩니다. 멀티클러스터 환경에서는 Traffic Director가 mesh 전역의 엔드포인트를 알고 있으므로, 한 클러스터 장애 시 다른 클러스터로 라우팅을 회피하는 글로벌 로드밸런싱 시나리오가 가능합니다. mesh가 GKE 클러스터와 VM 백엔드, 여러 리전을 동시에 품을 수 있다는 점은 East-West와 North-South의 경계를 흐리는 흐름과도 맞닿아 있습니다.
Service Dashboard로 서비스 상태를 보려면 Canonical Service의 [namespace, name] 쌍을 mesh 전체에서 유일하게 잡고, 환경(prod·stage·dev)을 같은 Canonical Service로 묶지 않는 것이 권장 운영입니다. 이름이 같은 두 서비스가 다른 클러스터·리전에 있어도 Cloud Service Mesh는 같은 논리 서비스로 간주합니다. 결제 정산 API와 결제 거래 API처럼 의도가 다른 두 서비스를 같은 [namespace, name]으로 두면 의도치 않게 한 대시보드로 합쳐지므로 운영 단계에서 미리 구분이 필요합니다.
도입 검토 시 짚을 점
도입 평가는 데이터 평면 모델 선택, 제어 평면 마이그레이션 일정, fleet 구성 세 단계로 정리됩니다.
그림 8. 데이터 평면 모델 선택·제어 평면 마이그레이션 일정·fleet 구성 세 단계로 정리한 도입 검토 체크리스트
본 시리즈와의 연결
Ambient 방향의 Cloud Service Mesh는 본 시리즈의 다른 글들과 다음과 같이 이어집니다.
- 본 시리즈 2편의 GKE Inference Gateway는 LLM 추론을 위한 North-South 진입 경로를 정의합니다. 외전이 다룬 Gateway 리소스와 Route 리소스 모델은 추론 게이트웨이가 mesh 위에서 동작할 때의 라우팅 골격을 이룹니다.
- 본 시리즈 8편의 Hypercluster는 클러스터 다수를 묶어 운영하는 환경입니다. 글로벌 제어 평면이 mesh 전역 엔드포인트를 직접 들고 있는 구조는 멀티클러스터 라우팅과 헬스 체크의 일관성을 받쳐 주는 전제가 됩니다.
참고 자료
- Google Cloud, “AI infrastructure at Next 26”, https://cloud.google.com/blog/ko/products/compute/ai-infrastructure-at-next26/
- Google Cloud, “Google Cloud Next 2026 wrap-up”, https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2026-wrap-up
- Google Cloud Documentation, “GKE Service networking overview”, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/service-networking
- Google Cloud Documentation, “Managed control plane for continuing customers”, https://docs.cloud.google.com/service-mesh/docs/managed-control-plane-overview
- Google Cloud Documentation, “Set up an Envoy sidecar service mesh on GKE”, https://docs.cloud.google.com/service-mesh/docs/gateway/set-up-envoy-mesh
- Google Cloud Documentation, “Prepare to setup the Gateway API for Cloud Service Mesh”, https://docs.cloud.google.com/service-mesh/docs/gateway/prepare-gateway
- Google Cloud Documentation, “Canonical Service Best Practices”, https://docs.cloud.google.com/service-mesh/docs/canonical-service-best-practices
자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
