2.7. 트래픽 관리

게이트웨이를 사용하여 메시에 대한 인바운드 및 아웃바운드 트래픽을 관리하여 메시에 들어가거나 나가려는 트래픽을 지정할 수 있습니다. 게이트웨이 구성은 서비스 워크로드와 함께 실행되는 사이드카 Envoy 프록시가 아닌, 메시의 에지에서 실행되는 독립 실행형 Envoy 프록시에 적용됩니다.

Kubernetes Ingress API와 같이 시스템으로 들어오는 트래픽을 제어하는 다른 메커니즘과 달리 Red Hat OpenShift Service Mesh 게이트웨이는 트래픽 라우팅의 모든 기능과 유연성을 사용합니다.

Red Hat OpenShift Service Mesh 게이트웨이 리소스는 Red Hat OpenShift Service Mesh TLS 설정을 노출하고 구성하기 위해 포트와 같은 계층 4-6 로드 밸런싱 속성을 사용할 수 있습니다. 애플리케이션 계층 트래픽 라우팅(L7)을 동일한 API 리소스에 추가하는 대신, 일반 Red Hat OpenShift Service Mesh 가상 서비스를 게이트웨이에 바인딩하고 서비스 메시의 다른 데이터 플레인 트래픽처럼 게이트웨이 트래픽을 관리할 수 있습니다.

게이트웨이는 주로 수신 트래픽을 관리하는 데 사용되지만 송신 게이트웨이를 구성할 수도 있습니다. 송신 게이트웨이를 사용하면 메시를 나가는 트래픽에 대해 전용 종료 노드를 구성할 수 있습니다. 이를 통해 외부 네트워크에 대한 액세스 권한이 있는 서비스를 제한하여 서비스 메시에 보안 제어를 추가할 수 있습니다. 게이트웨이를 사용하여 전적으로 내부 프록시를 구성할 수도 있습니다.

다음 예제는 외부 HTTPS 수신 트래픽에 대해 샘플 게이트웨이 구성을 보여줍니다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

이 게이트웨이 구성으로 ext-host.example.com의 HTTPS 트래픽을 포트 443의 메시로 허용할 수 있지만 트래픽에 라우팅을 지정하지 않습니다.

라우팅을 지정하고 게이트웨이가 의도한 대로 작동하려면 게이트웨이도 가상 서비스에 바인딩해야 합니다. 다음 예와 같이 가상 서비스의 게이트웨이 필드를 사용하여 이 작업을 수행합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

그러면 외부 트래픽에 대한 라우팅 규칙으로 가상 서비스를 구성할 수 있습니다.

Ingress 게이트웨이는 들어오는 HTTP/TCP 연결을 수신하는 메시의 에지에서 작동하는 로드 밸런서입니다. 노출된 포트와 프로토콜을 구성하지만 트래픽 라우팅 구성은 포함하지 않습니다. Ingress 트래픽의 트래픽 라우팅은 내부 서비스 요청과 동일한 방식으로 라우팅 규칙으로 구성됩니다.

다음 단계에서는 게이트웨이를 만들고 Bookinfo 샘플 애플리케이션에서 서비스를 /productpage 및 /login. 경로의 외부 트래픽에 노출하도록 VirtualService를 구성하는 방법을 보여줍니다.

Red Hat OpenShift Service Mesh에서 Ingress Gateway는 모니터링, 보안 및 라우팅 규칙과 같은 기능을 클러스터에 들어오는 트래픽에 적용할 수 있도록 합니다. 서비스 메시 게이트웨이를 사용하여 서비스 메시 외부에서 서비스를 노출합니다.

$ oc get svc istio-ingressgateway -n istio-system

$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Istio 게이트웨이의 OpenShift 경로는 Red Hat OpenShift Service Mesh에서 자동으로 관리됩니다. Istio 게이트웨이가 서비스 메시 내부에서 생성, 업데이트 또는 삭제될 때마다 OpenShift 경로가 생성, 업데이트 또는 삭제됩니다.

spec:
  istio:
    gateways:
     istio-egressgateway:
       autoscaleEnabled: false
       autoscaleMin: 1
       autoscaleMax: 5
     istio-ingressgateway:
       autoscaleEnabled: false
       autoscaleMin: 1
       autoscaleMax: 5
       ior_enabled: true

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway1
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.info.com
    - info.example.com

$ oc -n <control_plane_namespace> get routes

NAME           HOST/PORT             PATH  SERVICES               PORT  TERMINATION   WILDCARD
gateway1-lvlfn info.example.com        istio-ingressgateway   <all>               None
gateway1-scqhv www.info.com            istio-ingressgateway   <all>               None

서비스 항목은 Red Hat OpenShift Service Mesh가 내부적으로 관리하는 서비스 레지스트리에 항목을 추가합니다. 서비스 항목을 추가한 후 Envoy 프록시는 메시의 서비스인 것처럼 서비스에 트래픽을 보냅니다. 서비스 항목을 사용하면 다음을 수행할 수 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

hosts 필드를 사용하여 외부 리소스를 지정합니다. 완전히 한정하거나 와일드카드 접두사 도메인 이름을 사용할 수 있습니다.

메시의 다른 서비스에 대한 트래픽을 구성하는 것과 동일한 방식으로 서비스 항목에 대한 트래픽을 제어하도록 가상 서비스 및 대상 규칙을 구성할 수 있습니다. 예를 들어 다음 대상 규칙은 서비스 항목을 사용하여 구성된 ext-svc.example.com 외부 서비스에 대한 연결을 보호하기 위해 상호 TLS를 사용하도록 트래픽 경로를 구성합니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

가상 서비스가 있는 Red Hat OpenShift Service Mesh를 통해 여러 버전의 마이크로 서비스로 요청을 동적으로 라우팅할 수 있습니다. 가상 서비스를 사용하면 다음을 수행할 수 있습니다.

spec:
  hosts:

spec:
  http:
  - match:

spec:
  http:
  - match:
    - destination:

대상 규칙은 가상 서비스 라우팅 규칙이 평가된 후에 적용되므로 트래픽의 실제 대상에 적용됩니다. 가상 서비스는 트래픽을 대상으로 라우팅합니다. 대상 규칙은 해당 대상의 트래픽에 발생하는 요소를 설정합니다.

기본적으로 Red Hat OpenShift Service Mesh는 최소 요청 부하 분산 정책을 사용합니다. 여기서 활성 연결 수가 가장 적은 풀의 서비스 인스턴스에서 요청을 수신합니다. 또한 Red Hat OpenShift Service Mesh는 특정 서비스 또는 서비스 하위 집합에 대한 요청의 대상 규칙에 지정할 수 있는 다음과 같은 모델을 지원합니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

이 안내서는 Bookinfo 샘플 애플리케이션을 참조하여 예제 애플리케이션에 라우팅 예제를 제공합니다. Bookinfo 애플리케이션을 설치하여 이러한 라우팅 예제가 작동하는 방법을 확인합니다.

Service Mesh Bookinfo 샘플 애플리케이션은 각각 여러 가지 버전이 있는 네 개의 마이크로 서비스로 구성됩니다. Bookinfo 샘플 애플리케이션을 설치한 후에는 reviews 마이크로 서비스의 세 가지 버전이 동시에 실행됩니다.

브라우저에서 Bookinfo 앱 /product 페이지에 액세스하여 여러 번 새로 고침하면 북 리뷰 출력에 별점이 포함된 경우도 있고 그렇지 않은 경우도 있습니다. 라우팅할 명시적인 기본 서비스 버전이 없으면 서비스 메시는 사용 가능한 모든 버전으로 차례대로 요청을 라우팅합니다.

이 튜토리얼은 모든 트래픽을 마이크로 서비스의 v1(버전 1)으로 라우팅하는 규칙을 적용하는 데 도움이 됩니다. 나중에 HTTP 요청 헤더의 값을 기반으로 트래픽을 라우팅하는 규칙을 적용할 수 있습니다.