This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.2.7. 트래픽 관리
Red Hat OpenShift Service Mesh의 서비스 간 트래픽 및 API 호출 흐름을 제어할 수 있습니다. 예를 들어, 서비스 메시의 일부 서비스는 메시 내에서 통신해야 하며 다른 서비스는 숨겨야 할 수 있습니다. 트래픽을 관리하여 특정 백엔드 서비스를 숨기고, 서비스를 노출하며, 테스트 또는 버전 관리 배포를 생성하거나 서비스 세트에 보안 계층을 추가합니다.
이 안내서는 Bookinfo 샘플 애플리케이션을 참조하여 예제 애플리케이션에 라우팅 예제를 제공합니다. Bookinfo 애플리케이션을 설치하여 이러한 라우팅 예제가 작동하는 방법을 알아봅니다.
2.7.1. 트래픽 라우팅 및 관리
YAML 파일에서 사용자 지정 리소스 정의를 사용하여 Red Hat OpenShift Service Mesh에 자체 트래픽 구성을 추가하여 서비스 메시를 구성합니다.
2.7.1.1. 가상 서비스의 트래픽 관리
가상 서비스가 있는 Red Hat OpenShift Service Mesh를 통해 여러 버전의 마이크로 서비스로 요청을 동적으로 라우팅할 수 있습니다. 가상 서비스를 사용하면 다음을 수행할 수 있습니다.
- 단일 가상 서비스를 통해 여러 애플리케이션 서비스를 처리합니다. 예를 들어 메시에서 Kubernetes를 사용하는 경우 특정 네임스페이스의 모든 서비스를 처리하도록 가상 서비스를 구성할 수 있습니다. 가상 서비스를 사용하면 모놀리식 애플리케이션을 원활한 소비자 환경을 통해 별도의 마이크로 서비스로 구성된 서비스로 전환할 수 있습니다.
- 게이트웨이와 결합하여 트래픽 규칙을 구성하고 수신 및 송신 트래픽을 제어합니다.
2.7.1.1.1. 가상 서비스 구성
요청은 가상 서비스를 통해 서비스 메시 내의 서비스로 라우팅됩니다. 각 가상 서비스는 순서대로 평가되는 라우팅 규칙 세트로 구성됩니다. Red Hat OpenShift Service Mesh는 가상 서비스에 대해 주어진 각 요청을 메시 내의 실제 특정 대상에 연결합니다.
가상 서비스가 없는 Red Hat OpenShift Service Mesh는 모든 서비스 인스턴스 간에 라운드 로빈 로드 밸런싱을 사용하여 트래픽을 배포합니다. 가상 서비스에서는 하나 이상의 호스트 이름에 대한 트래픽 동작을 지정할 수 있습니다. 가상 서비스의 라우팅 규칙은 가상 서비스에 대한 트래픽을 적절한 대상으로 전송하는 방법을 Red Hat OpenShift Service Mesh에 알립니다. 경로 대상은 동일한 서비스 또는 완전히 다른 서비스 버전일 수 있습니다.
절차
다음 예제를 사용하여 YAML 파일을 만들어 애플리케이션에 연결하는 사용자에 따라 Bookinfo 샘플 애플리케이션 서비스의 다른 버전으로 요청을 라우팅합니다.
예: VirtualService.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v3
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v3
다음 명령을 실행하여
VirtualService.yaml
을 적용합니다. 여기서VirtualService.yaml
은 파일 경로입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f VirtualService.yaml
$ oc apply -f VirtualService.yaml
2.7.1.2. 가상 호스트 구성
다음 섹션에서는 YAML 파일의 각 필드에 대해 설명하고 가상 서비스에서 가상 호스트를 생성하는 방법을 설명합니다.
2.7.1.2.1. 호스트
hosts
필드에는 라우팅 규칙이 적용되는 가상 서비스의 대상 주소가 나열됩니다. 이는 서비스에 요청을 보내는 데 사용되는 주소입니다.
가상 서비스 호스트 이름은 IP 주소, DNS 이름 또는 정규화된 도메인 이름으로 확인되는 짧은 이름일 수 있습니다.
spec: hosts: - reviews
spec:
hosts:
- reviews
2.7.1.2.2. 라우팅 규칙
http
섹션에는 호스트 필드에 지정된 대상으로 전송된 HTTP/1.1, HTTP2, gRPC 트래픽을 라우팅하기 위한 일치 조건 및 작업을 설명하는 가상 서비스의 라우팅 규칙이 포함됩니다. 라우팅 규칙은 트래픽을 이동할 대상과 지정된 일치 조건으로 구성됩니다.
일치 조건
예제의 첫 번째 라우팅 규칙에는 일치 필드로 시작하는 조건이 있습니다. 이 예제에서 이 라우팅은 사용자 jason
의 모든 요청에 적용됩니다. headers
, end-user
, exact
필드를 추가하여 적절한 요청을 선택합니다.
spec: hosts: - reviews http: - match: - headers: end-user: exact: jason
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
대상
경로 섹션의 destination
필드는 이 조건과 일치하는 트래픽에 대한 실제 대상을 지정합니다. 가상 서비스의 호스트와 달리 대상 호스트는 Red Hat OpenShift Service Mesh 서비스 레지스트리에 있는 실제 대상이어야 합니다. 프록시가 있는 메시 서비스 또는 서비스 항목을 사용하여 추가된 비 메시 서비스일 수 있습니다. 이 예에서 호스트 이름은 Kubernetes 서비스 이름입니다.
spec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
2.7.1.2.3. 대상 규칙
대상 규칙은 가상 서비스 라우팅 규칙이 평가된 후에 적용되므로 트래픽의 실제 대상에 적용됩니다. 가상 서비스는 트래픽을 대상으로 라우팅합니다. 대상 규칙은 해당 대상의 트래픽에 발생하는 요소를 설정합니다.
2.7.1.2.3.1. 로드 밸런싱 옵션
기본적으로 Red Hat OpenShift Service Mesh는 풀의 각 서비스 인스턴스에서 차례대로 요청을 수신하는 라운드 로빈 로드 밸런싱 정책을 사용합니다. 또한 Red Hat OpenShift Service Mesh는 특정 서비스 또는 서비스 하위 집합에 대한 요청의 대상 규칙에 지정할 수 있는 다음과 같은 모델을 지원합니다.
- Random: 요청은 풀의 인스턴스에 무작위로 전달됩니다.
- Weighted: 요청은 구체적인 비율에 따라 풀의 인스턴스로 전달됩니다.
- Least requests: 요청은 요청 수가 가장 적은 인스턴스로 전달됩니다.
대상 규칙 예
다음 예제 대상 규칙은 서로 다른 로드 밸런싱 정책을 사용하여 my-svc
대상 서비스에 대해 세 가지 다른 하위 집합을 구성합니다.
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
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
2.7.1.2.4. 게이트웨이
게이트웨이를 사용하여 메시에 대한 인바운드 및 아웃바운드 트래픽을 관리하여 메시에 들어가거나 나가려는 트래픽을 지정할 수 있습니다. 게이트웨이 구성은 서비스 워크로드와 함께 실행되는 사이드카 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
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
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: virtual-svc
spec:
hosts:
- ext-host.example.com
gateways:
- ext-host-gwy
그러면 외부 트래픽에 대한 라우팅 규칙으로 가상 서비스를 구성할 수 있습니다.
2.7.1.2.5. 서비스 항목
서비스 항목은 Red Hat OpenShift Service Mesh가 내부적으로 관리하는 서비스 레지스트리에 항목을 추가합니다. 서비스 항목을 추가한 후 Envoy 프록시는 메시의 서비스인 것처럼 서비스에 트래픽을 보냅니다. 서비스 항목을 사용하면 다음을 수행할 수 있습니다.
- 서비스 메시 외부에서 실행되는 서비스의 트래픽을 관리합니다.
- 웹에서 소비된 API 또는 레거시 인프라의 서비스에 대한 트래픽과 같은 외부 대상의 트래픽을 리디렉션 및 전달합니다.
- 외부 대상에 대한 재시도, 시간 초과 및 오류 삽입 정책을 정의합니다.
- VM(가상 머신)에서 메시에 VM을 추가하여 메시 서비스를 실행합니다.
Kubernetes에서 다중 클러스터 Red Hat OpenShift Service Mesh 메시를 구성하기 위해 다른 클러스터의 서비스를 메시에 추가합니다.
서비스 항목 예
다음 예제 mesh-external 서비스 항목은 ext-resource
외부 종속성을 Red Hat OpenShift Service Mesh 서비스 레지스트리에 추가합니다.
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
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
호스트 필드를 사용하여 외부 리소스를 지정합니다. 완전히 한정하거나 와일드카드 접두사 도메인 이름을 사용할 수 있습니다.
메시의 다른 서비스에 대한 트래픽을 구성하는 것과 동일한 방식으로 서비스 항목에 대한 트래픽을 제어하도록 가상 서비스 및 대상 규칙을 구성할 수 있습니다. 예를 들어 다음 대상 규칙은 서비스 항목을 사용하여 구성된 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
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