GCP 네트워크 트래픽 전달 과정

GCP의 네트워크 트래픽 전달 과정

 

GKE에서 Gateway API는 Kubernetes 네트워킹과 상호작용하는 특성을 위해 설계된 역할 중심 리소스 모델입니다. 즉, Kubernetes에서 네트워크 트래픽을 수신, 매칭, 라우팅 그리고 전달하기 위한 전체적인 구조를 정의하는 API표준입니다.

GKE가 Gateway Class를 제공하여 운영자는 해당 클래스를 기준으로 Gateway 리소스를 만들고, 애플리케이션 개발자는 리소스에 바인딩될 HTTPRoute리소스를 배포합니다.

 

Gateway API의 주요 리소스 (https://gateway-api.sigs.k8s.io/)

• Gateway Class: 클러스터 수준의 리소스로, Gateway의 동작 방식을 정의 (controller에 따라 nginx, GCP lb, contour)
• Gateway: 클라이언트 요청이 처음 도착하는 listener를 정의하는 리소스로 트래픽 수신을 위한 포트, 프로토콜, 인증 등을 설정. Gaeway Class를 참조하며, Listener를 통해 HTTPRoute 등으로 트래픽을 전달
• HTTPRoute: 트래픽 라우팅 규칙을 정의하는 리소스로 Host, Path, Header 등의 조건 기반으로 트래픽 전달
• BackendPolicy(Optional): 백엔드 리소스의 인증 및 정책을 정의

 

https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ko

게이트웨이  |  Google Kubernetes Engine (GKE)  |  Google Cloud

 

GKE의 Gateway API가 HTTPRoute를 처리하면서 kubernetes의 service의 pod를 NEG(network endpoint group)으로 변환

이 과정에서 Pod의 IP와 port가 NEG에 등록되며, NEG는 HTTP load Balancer가 Pod레벨에서 트래픽을 전달할 수 있도록 지원합니다. (NEG는 개별 Kuberentes Pod의 IP와 Port를 직접 참조하는 리소스입니다.)

 

HTTPRoute를 기반으로 GCP HTTP Load Balancer 설정이 생성되며, 이와 함께 Backend Service도 생성됩니다.

Backend Service는 NEG를 참조하여 트래픽을 전달하며, 분배 정책, Health Check, Caching등의 설정이 포함 됩니다.

또한, Backend Service는 Google Cloud Load Balancer가 트래픽을 처리할 때 어디로 전달해야 하는지를 정의하는 구성요소로 NEG, Instance Group, Cloud Storage를 백엔드로 참조합니다.

 

추가로 HTTPRoute는 GEK환경에서 Gateway API를 사용할 때, 트래픽 라우팅 규칙을 정의하는 역할을 합니다. 이를 통해 클라이언트의 요청이 Load Balancer, Backend Service, NEG, Kubernetes Pod에 전달되기까지의 흐름을 제어합니다.

HTTPRoute의 역할로는 트래픽 매칭 및 라우팅 규칙 정의가 있는데, 트래픽을 매칭하는 조건(Host, Path, Headers)과 전달할 대상(Backend Service)을 정의합니다. 즉, 특정 path로 오는 요청을 어떤 service로 전달할 지에 대한 정의를 합니다.

HTTPRoute는 GCP에서 직접적으로 리소스를 생성하지는 않지만, GKE Gateway Controller가 이를 해성하여 필요한 GCP 리소스를 생성합니다.

 

HTTPRoute, Gateway Controller에 의해 생성되는 리소스

• HTTP Load Balancer : HTTPRoute에 연결된 Gateway를 기반으로 GCP HTTP Load Balancer가 생성
• Backend Service: HTTPRoute의 backendRefs에 명시된 kubernetes service를 GCP backend service로 변환
  bakend service는 LB와 NEG를 연결하고, health check 및 트래픽 정책을 관리
• Network Endpoint Groups(NEG): backendRefs에 참조된 kubernetes service에 연결된 pod들이 NEG로 변환
  NEG는 pod의 IP와 port를 저장하며, LB가 pod와 직접 통신할 수 있도록 지원

 

정리해보면, Kubrenete Gateway API를 통해 GCP의 각 리소스가 생성되며, 

kubernetes resource인 Gateway를 통해 Load Balancer가 생성되며, 해당 리소스에서 Listener도 정의하게 됩니다.

또한 kubernetes resource인 HTTPRoute를 통해 각 backend service를 정의하며 여기서 어떤 gateway에서 오는 요청을 처리할 지, 어떤 path와 규칙에 의해 kubernetes backend로 요청을 전달할 지에 대해 정의합니다. 이 과정을 통해 위에서 언급한 것처럼 kubernetes service, pod는 NEG(network enndpoint groups)를 통해 트래픽을 전달받을 수 있습니다.

 

 

[ GKE 트래픽 흐름 요약 ]

• 클라이언트가 도메인 이름 또는 IP주소를 통해 요청을 전송
• 전송된 요청은 DNS(Domain Name Server)를 통해 Load Balancer public IP로 Request 전송
• GCP HTTP Load Balancer는 전역적으로 관리되며, 가장 가까운 엣지 로케이션으로 트래픽을 전달
• 전달받은 Load Balancer는 트래픽을 처리하기위해 연결된 적절한 Gateway Listener로 전달
• Gateway 리소스가 정의한 Listener가 요청을 프로토콜에 따라 처리 (HTTP, HTTPS)
• Listener는 HTTPRoute로 전달하고 Host, Path, Header 매칭 조건에 따라 Backend Service로 요청을 전달
• Backend Service는 Kuberentes Service로부터 생성된 NEG(Network Endgine Group)를 참조
• 최종적으로 NEG를 통해 트래픽이 개별 Pod로 전달되며 Pod는 클러스터 내에서 트래픽을 처리하고 응답합니다.

 

 

GCP에서 GKE를 사용할 때, 어떻게 클라이언트에서 전송된 트래픽이 최종 애플리케이션까지 전달되는 지에 대해 알아봤습니다. 피드백은 언제나 환영합니다. 긴 글 읽어주셔서 감사합니다 🙌