Istio를 사용하면서, 인터넷에서 애플리케이션으로 트래픽이 흐르는 과정을 살펴보다가, 거기서 GCLB(Google Cloud Load Balancer)를 로드밸런서로 사용하는 경우에, **GCLB가 Ingress Gateway가 위치한 노드(또는 Pod)를 어떻게 파악해서 트래픽을 전달하는가?**에 대한 궁금증이 생겨서 문의드립니다.
GCLB는 모든 노드에 트래픽을 보내는 걸까요? 아니면 특정 노드로만 보내고, 이후 IP 라우팅이 이루어지는 걸까요?
혹은 임의의 노드로 트래픽을 보낸 다음, 그곳에서 내부 라우팅이 일어나는 방식일까요?
이 부분을 명확히 설명해주는 자료를 찾고 싶은데, 많은 글을 봐도 깊이 있게 다루지 않았습니다. 관련된 참고 자료가 있다면 함께 알려주시면 더욱 감사드립니다.
일반적으로 DNS 작동방식을 보시면 기본 작동 원리는 이해하실꺼같아요. 즉, LB가 트래픽을 Ingress Gateway로 라우팅하는 방식은 설정된 라우팅 정책에 따라 다릅니다. 예를 들어, TLS passthrough를 활성화하려면 LB는 클라이언트의 TLS 연결이 동일한 Istio Ingress Gateway 파드로 일관되게 전달되도록 해야 합니다.
Google Cloud Load Balancer(GCLB)는 기본적으로 Kubernetes Service(Type=LoadBalancer) 객체를 통해 Ingress Gateway 엔드포인트를 인식합니다. Istio Ingress Gateway가 NodePort 형태로 노출되고, GCLB는 해당 Service의 백엔드(즉, Gateway Pod가 동작 중인 Node들의 NodePort) 정보를 기반으로 트래픽을 전달하게 됩니다.
일반적으로 GCLB는 모든 노드에 균등하게 트래픽을 전달하는 방식이 아니라, GKE가 관리하는 NEG(Network Endpoint Group) 또는 Instance Group 기반의 백엔드 셋을 활용하여, 실제 Ingress Gateway Pod가 연결된 노드들의 엔드포인트를 식별합니다. 따라서 트래픽은 임의의 노드 전체로 흩어지는 것이 아니라, 백엔드로 등록된 노드에만 전달되며, 그 이후에는 해당 노드에서 Pod로 직접 전달됩니다. 노드에서 다른 노드로 다시 포워딩하는 추가 hop은 발생하지 않습니다.
즉, 구조를 요약하면 다음과 같습니다.
Ingress Gateway Service가 NodePort/NEG 형태로 노출됨
GCLB는 이 Service의 백엔드 엔드포인트 목록을 지속적으로 동기화
트래픽은 백엔드로 지정된 노드의 NodePort로 직접 전달
노드는 kube-proxy 혹은 IPVS를 통해 Gateway Pod로 트래픽 전달
GCLB가 *“임의의 노드로 뿌리고 내부에서 다시 라우팅하는 구조”*는 아니며, GCLB는 Pod가 존재하는 노드들만 정확히 백엔드로 등록해 전달합니다. 이 때문에 Istio의 Ingress Gateway Pod가 이동하거나 스케일링될 때 NEG와 백엔드 목록이 자동으로 업데이트됩니다.