gRPC 라우팅¶
GRPCRoute 리소스를 사용하면 gRPC 트래픽을 매칭하고 이를 쿠버네티스 백엔드로 전달할 수 있다. 이 가이드에서는 GRPCRoute가 호스트, 헤더, 서비스 및 메서드 필드를 기반으로 트래픽을 매칭하고 서로 다른 쿠버네티스 Service로 전달하는 방법을 설명한다.
다음 다이어그램은 세 가지 서로 다른 Service에 걸친 필수 트래픽 흐름을 설명한다:
foo.example.com으로 향하는com.Example.Login메서드의 트래픽은foo-svc로 전달된다env: canary헤더가 포함된bar.example.com으로 향하는 트래픽은 모든 서비스와 메서드에 대해bar-svc-canary로 전달된다- 해당 헤더가 없는
bar.example.com으로 향하는 트래픽은 모든 서비스와 메서드에 대해bar-svc로 전달된다

점선은 이 라우팅 동작을 구성하기 위해 배포된 Gateway 리소스를 나타낸다.
동일한 prod 게이트웨이에 라우팅 규칙을 생성하는 두 개의 GRPCRoute 리소스가 있다.
이는 하나 이상의 라우트가 게이트웨이에 바인딩될 수 있음을 보여주며,
충돌하지 않는 한 라우트가 Gateway에서 병합될 수 있다. GRPCRoute는 동일한
라우트 병합 의미론을 따른다. 이에 대한 자세한 내용은
문서를 참조한다.
게이트웨이로부터 트래픽을 수신하려면 GRPCRoute 리소스에
연결할 상위 게이트웨이를 참조하는 ParentRefs를 구성해야 한다. 다음 예제는
Gateway와 GRPCRoute의 조합이 gRPC 트래픽을 서비스하도록 구성되는 방법을 보여준다:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
spec:
gatewayClassName: example-gateway-class
listeners:
- name: grpc
protocol: HTTPS
port: 50051
tls:
certificateRefs:
- kind: Secret
group: ""
name: example-com-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: example-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "example.com"
rules:
- backendRefs:
- name: example-svc
port: 50051
GRPCRoute는 단일 호스트명 집합에 대해 매칭할 수 있다.
이러한 호스트명은 GRPCRoute 내의 다른 매칭보다 먼저 매칭된다.
foo.example.com과 bar.example.com은 서로 다른 라우팅 요구사항을 가진
별개의 호스트이므로, 각각 자체 GRPCRoute인 foo-route와 bar-route로 배포된다.
다음 foo-route는 foo.example.com에 대한 모든 트래픽을 매칭하고 라우팅 규칙을
적용하여 트래픽을 올바른 백엔드로 전달한다. 매치가 하나만 지정되어 있으므로
foo.example.com으로의 com.example.User.Login 메서드 요청만 전달된다.
다른 메서드의 RPC는 이 라우트에 의해 매칭되지 않는다.
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: foo-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "foo.example.com"
rules:
- matches:
- method:
service: com.example
method: Login
backendRefs:
- name: foo-svc
port: 50051
마찬가지로 bar-route GRPCRoute는 bar.example.com에 대한 RPC를 매칭한다.
이 호스트명에 대한 모든 트래픽은 라우팅 규칙에 따라 평가된다. 가장 구체적인
매치가 우선하므로, env: canary 헤더가 있는 트래픽은 bar-svc-canary로
전달되고, 헤더가 없거나 값이 canary가 아닌 경우 bar-svc로 전달된다.
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: bar-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "bar.example.com"
rules:
- matches:
- headers:
- type: Exact
name: env
value: canary
backendRefs:
- name: bar-svc-canary
port: 50051
- backendRefs:
- name: bar-svc
port: 50051
gRPC
Reflection은
대상 서비스의 protocol buffers 사본을 로컬 파일시스템에 보유하지 않고도
grpcurl과 같은 대화형 클라이언트를
사용하는 데 필요하다. 이를 활성화하려면 먼저 애플리케이션 파드에서 gRPC reflection
서버가 수신 대기 중인지 확인한 다음, GRPCRoute에 reflection 메서드를 추가한다.
이 기능은 개발 및 스테이징 환경에서 유용할 수 있지만, 프로덕션 환경에서는
보안상의 영향을 충분히 고려한 후에만 활성화해야 한다.
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: foo-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "foo.example.com"
rules:
- matches:
- method:
service: com.example.User
method: Login
backendRefs:
- name: foo-svc
port: 50051
- matches:
- method:
service: grpc.reflection.v1.ServerReflection
backendRefs:
- name: foo-svc
port: 50051