개요

Cloud Service Mesh는 고급 트래픽 관리, 관측 가능성, 보안을 포함하여 애플리케이션에 서비스 네트워킹 기능을 제공합니다. 하지만 서비스 메시 구성과 운영은 복잡한 태스크입니다. 이 페이지에서는 Kubernetes Gateway API로 Cloud Service Mesh를 구성하는 방법을 설명합니다. 이 API는 전반적으로 메시 구성 환경을 단순화하고 향상시킬 수 있도록 설계되었습니다.

메시용 Kubernetes Gateway API를 사용하면 프록시리스 gRPC 및 Envoy 프록시 배포 모두에 대해 Cloud Service Mesh를 구성할 수 있습니다. 메시용 Gateway API 모델은 다음과 같은 몇 가지 중요한 이점을 제공합니다.

Gateway API는 Kubernetes 클러스터 내에서 인그레스(종방향(North-South)) 및 서비스 메시(횡방향(East-West)) 트래픽을 모두 관리하기 위한 일관된 단일 인터페이스를 제공합니다.
서비스 메시를 사용하면 고급 트래픽 라우팅 패턴을 사용할 수 있습니다. Gateway API를 사용하면 복잡한 라우팅 규칙을 설계하고 관리할 수 있습니다.
기본 서비스 메시 구현에 대한 심층적인 지식이 없어도 개발자가 Gateway API를 사용하여 마이크로서비스에 대한 상위 라우팅 규칙과 정책을 정의하는 데 집중할 수 있습니다.
이 API는 확장 가능하도록 설계되었으므로 향후 개선과 새로운 프로토콜 및 사용 사례 지원이 가능합니다.
Gateway API는 강력한 커뮤니티를 갖추고 있으며 계속 성장하는 서비스 메시 제공업체 및 도구 생태계의 지원을 받습니다.

서비스 메시 사용 사례를 지원하는 GAMMA 이니셔티브 작업은 v1.1.0부터 표준 채널의 일부였으며 정식 버전으로 간주됩니다.

사양에서는 애플리케이션 소유자가 Kubernetes Service 리소스를 포함한 Route resource(xRoute라고도 함)를 parentRef로 구성하여 메시 서비스의 트래픽 규칙을 구성해야 한다고 제안합니다. 이 접근 방식은 GEP-1324: Gateway API의 서비스 메시에 정의된 Kubernetes Service의 '프런트엔드' 및 '백엔드' 역할에 따라 다릅니다. 여기서 '프런트엔드' 역할은 parentRef로 사용되고 Service의 '백엔드' 역할은 backendRef로 사용됩니다. 규정을 준수하는 구현은 Service 이름을 사용하여 정규 IP 주소에 대해 트래픽과 backendRef 엔드포인트를 일치시킵니다.

메시용 Gateway API

Kubernetes 프로젝트인 Gateway API는 Kubernetes 내 레이어 4 및 7 라우팅에 중점을 둡니다. 이 API는 인그레스, 부하 분산, 서비스 메시 API를 계승합니다. 다목적, 설명적, 역할 중심적으로 설계된 이 구성은 주로 라우팅 레이어에 있습니다. HTTPRoute 및 GRPCRoute와 같은 프로토콜별 리소스는 고급 인그레스 및 메시 라우팅을 사용 설정할 수 있습니다.

GAMMA 이니셔티브 (Service Mesh용 Gateway API)는 서비스 간 또는 동일 클러스터 내의 횡방향(East/West) 트래픽에 Gateway API를 사용하는 방법을 정의합니다. GAMMA는 Gateway API를 사용하여 역할 중심 특성을 유지하면서 Gateway API를 최소한으로 수정하여 서비스 메시를 구성하는 방안을 마련하는 것을 목표로 합니다. 또한 GAMMA는 기본 기술이나 프록시에 관계없이 Gateway API의 다양한 서비스 메시 구현 간에 일관성을 개선하는 것이 중요하다고 강조합니다.

GAMMA는 Gateway API 사양의 기존 확장성 포인트를 활용하므로 API 변경이나 새 리소스가 필요하지 않습니다. 이를 위해서는 경로 리소스 정의(Gateway API의 GRPCRoute 또는 HTTPRoute)를 확장하여 구체적으로는 서비스 메시용 Gateway API에 설명된 대로 경로 리소스를 서비스 리소스와 연결해 서비스 메시 사용 사례를 알립니다.

다음 예는 HTTPRoute를 사용하는 메시 사용 사례를 보여줍니다.

apiVersion:  gateway.networking.k8s.io
kind: HTTPRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80
      weight: 9
  - backendRefs:
    - name: echo-v2
      port: 80
      weight: 1

HTTPRoute 다이어그램

HTTPRoute는 Service를 parentRef로 참조하며, 이는 HTTPRoute 경로가 서비스 메시 사용 사례에 맞게 구성되었음을 나타냅니다. 이전 예시에서 echo-service 서비스는 parentRef로 지정되었습니다. 즉, HTTPRoute가 echo-service의 프런트엔드에 연결되어 있음을 의미합니다. 클라이언트가 echo-service로 전송하는 모든 트래픽은 HTTPRoute echo-route에 따라 라우팅됩니다.

GRPCRoute는 또 다른 Kubernetes Gateway API 리소스로 gRPC 트래픽을 Kubernetes 서비스로 라우팅하는 데 사용됩니다. 사용자는 특별히 gRPC 트래픽을 라우팅하고 gRPC 메서드 및 서비스 일치와 같이 gRPC에 맞춤화된 기능을 활용하려고 할 때 HTTPRoute 대신 GRPCRoute를 사용하도록 선택합니다.

다음 예시는 GRPCRoute 사용을 보여줍니다.

apiVersion:  gateway.networking.k8s.io
kind: GRPCRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
   - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: Echo
    backendRefs:
    - name: grpc-infra-backend-v1
      port: 8080
  - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: EchoTwo
    backendRefs:
    - name: grpc-infra-backend-v2
      port: 8080

GRPCRoute 다이어그램

HTTPRoute 예시와 마찬가지로 이 GRPCRoute는 서비스 메시 사용 사례에 맞게 구성됩니다. 프록시리스 gRPC 클라이언트가 xds:///echo-service.default.svc.cluster.local:8080으로 전송하는 모든 트래픽은 GRPCRoute echo-route에 따라 라우팅됩니다. 이 예시의 라우팅 규칙은 gRPC 메서드와 일치하고 트래픽을 특정 backendRef로 라우팅합니다. 또한 GRPCRoute를 사용하여 xds:/// 프리픽스가 삭제될 때 Envoy와 같은 사이드카 삽입으로 프록시 클라이언트의 요청을 라우팅할 수 있습니다.

단일 클러스터 메시 다이어그램

개요

메시용 Gateway API

다음 단계