검색

2.14. 서비스 메시에서 트래픽 관리

download PDF

Red Hat OpenShift Service Mesh를 사용하면 서비스 간 트래픽 흐름과 API 호출을 제어할 수 있습니다. 서비스 메시의 일부 서비스는 메시 내에서 통신해야 하며 다른 서비스는 숨겨야 할 수 있습니다. 트래픽을 관리하여 특정 백엔드 서비스를 숨기거나, 서비스를 노출하거나, 테스트 또는 버전 관리 배포를 생성하거나 서비스 세트에 보안 계층을 추가할 수 있습니다.

2.14.1. 게이트웨이 사용

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

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

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

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

게이트웨이 예제

게이트웨이 리소스는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시의 에지에서 작동하는 로드 밸런서를 설명합니다. 사양은 노출해야 하는 포트 세트, 사용할 프로토콜 유형, 로드 밸런서에 대한 SNI 구성 등을 설명합니다.

다음 예제는 외부 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

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

2.14.1.1. 게이트웨이 삽입 활성화

게이트웨이 구성은 서비스 워크로드와 함께 실행되는 사이드카 Envoy 프록시 대신 메시 에지에서 실행되는 독립 실행형 Envoy 프록시에 적용됩니다. 게이트웨이는 Envoy 프록시이므로 사이드카를 삽입할 수 있는 방법과 유사하게 게이트웨이를 자동으로 삽입하도록 서비스 메시를 구성할 수 있습니다.

게이트웨이에 자동 삽입을 사용하면 ServiceMeshControlPlane 리소스와 독립적으로 게이트웨이를 배포 및 관리하고 사용자 애플리케이션으로 게이트웨이를 관리할 수 있습니다. 게이트웨이 배포에 자동 삽입을 사용하면 개발자가 게이트웨이 배포를 간소화하면서 작업을 완전히 제어할 수 있습니다. 새 업그레이드를 사용할 수 있거나 구성이 변경되면 게이트웨이 Pod를 다시 시작하여 업데이트합니다. 이렇게 하면 게이트웨이 배포 운영에 대한 경험이 사이드카 작동과 동일하게 됩니다.

참고

Cryostat는 ServiceMeshControlPlane 네임스페이스에 대해 기본적으로 비활성화되어 있습니다(예: istio-system 네임스페이스). 보안 모범 사례로 컨트롤 플레인에서 다른 네임스페이스에 게이트웨이를 배포합니다.

2.14.1.2. 자동 게이트웨이 삽입 배포

게이트웨이를 배포할 때 게이트웨이 deployment 오브젝트에 삽입 레이블 또는 주석을 추가하여 삽입을 선택해야 합니다. 다음 예제에서는 게이트웨이를 배포합니다.

사전 요구 사항

  • 네임스페이스는 ServiceMeshMemberRoll 에서 정의하거나 ServiceMeshMember 리소스를 생성하여 메시의 멤버여야 합니다.

프로세스

  1. Istio 수신 게이트웨이의 고유한 레이블을 설정합니다. 게이트웨이에서 워크로드를 선택할 수 있도록 하려면 이 설정이 필요합니다. 이 예에서는 ingressgateway 를 게이트웨이 이름으로 사용합니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: istio-ingress
    spec:
      type: ClusterIP
      selector:
        istio: ingressgateway
      ports:
      - name: http2
        port: 80
        targetPort: 8080
      - name: https
        port: 443
        targetPort: 8443
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: istio-ingressgateway
      namespace: istio-ingress
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      template:
        metadata:
          annotations:
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            sidecar.istio.io/inject: "true" 1
        spec:
          containers:
          - name: istio-proxy
            image: auto 2
    1
    sidecar.istio.io/inject 필드를 "true" 로 설정하여 게이트웨이 삽입을 활성화합니다.
    2
    Pod가 시작될 때마다 image가 자동으로 업데이트되도록 image 필드를 auto 로 설정합니다.
  2. TLS에 대한 자격 증명을 읽을 수 있도록 역할을 설정합니다.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: istio-ingress
    rules:
      - apiGroups: [""]
        resources: ["secrets"]
        verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: istio-ingress
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
  3. spec.security.manageNetworkPolicytrue 로 설정될 때마다 클러스터 외부에서 새 게이트웨이에 대한 액세스 권한을 부여합니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: gatewayingress
      namespace: istio-ingress
    spec:
      podSelector:
        matchLabels:
          istio: ingressgateway
      ingress:
        - {}
      policyTypes:
      - Ingress
  4. Ingress 트래픽이 증가하면 Pod를 자동으로 스케일링합니다. 이 예에서는 최소 복제본을 2 로 설정하고 최대 복제본을 5 로 설정합니다. 또한 사용률이 80%에 도달하면 다른 복제본도 생성합니다.

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      labels:
        istio: ingressgateway
        release: istio
      name: ingressgatewayhpa
      namespace: istio-ingress
    spec:
      maxReplicas: 5
      metrics:
      - resource:
          name: cpu
          target:
            averageUtilization: 80
            type: Utilization
        type: Resource
      minReplicas: 2
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: istio-ingressgateway
  5. 노드에서 실행해야 하는 최소 Pod 수를 지정합니다. 이 예에서는 새 노드에서 Pod가 다시 시작되면 하나의 복제본이 실행 중인지 확인합니다.

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      labels:
        istio: ingressgateway
        release: istio
      name: ingressgatewaypdb
      namespace: istio-ingress
    spec:
      minAvailable: 1
      selector:
        matchLabels:
          istio: ingressgateway

2.14.1.3. Ingress 트래픽 관리

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

2.14.1.3.1. Ingress IP 및 포트 확인

Ingress 구성은 환경에서 외부 로드 밸런서를 지원하는지 여부에 따라 달라집니다. 외부 로드 밸런서는 클러스터의 Ingress IP 및 포트에 설정됩니다. 클러스터의 IP 및 포트가 외부 로드 밸런서에 구성되어 있는지 확인하려면 다음 명령을 실행합니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

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

해당 명령은 네임스페이스에 있는 각 항목의 NAME, TYPE, CLUSTER-IP, EXTERNAL-IP, PORT(S), AGE를 반환합니다.

EXTERNAL-IP 값이 설정되면 해당 환경에 Ingress 게이트웨이에 사용할 수 있는 외부 로드 밸런서가 있습니다.

EXTERNAL-IP 값이 <none> 또는 영구적으로 <pending>인 경우, 해당 환경은 Ingress 게이트웨이에 외부 로드 밸런서를 제공하지 않습니다.

2.14.1.3.1.1. 로드 밸런서를 사용하여 Ingress 포트 확인

환경에 외부 로드 밸런서가 있는 경우 다음 지침을 따릅니다.

프로세스

  1. 다음 명령을 실행하여 Ingress IP 및 포트를 설정합니다. 이 명령은 터미널에서 변수를 설정합니다.

    $ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  2. 다음 명령을 실행하여 Ingress 포트를 설정합니다.

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
  3. 다음 명령을 실행하여 보안 Ingress 포트를 설정합니다.

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
  4. 다음 명령을 실행하여 TCP Ingress 포트를 설정합니다.

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].port}')
참고

일부 환경에서는 IP 주소 대신 호스트 이름을 사용하여 로드 밸런서가 노출될 수 있습니다. 이 경우 Ingress 게이트웨이의 EXTERNAL-IP 값은 IP 주소가 아닙니다. 대신 호스트 이름이며 이전 명령이 INGRESS_HOST 환경 변수를 설정하지 못합니다.

이 경우 다음 명령을 사용하여 INGRESS_HOST 값을 수정합니다.

$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
2.14.1.3.1.2. 로드 밸런서 없이 Ingress 포트 확인

환경에 외부 로드 밸런서가 없는 경우 Ingress 포트를 확인하고 대신 노드 포트를 사용합니다.

프로세스

  1. Ingress 포트를 설정합니다.

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
  2. 다음 명령을 실행하여 보안 Ingress 포트를 설정합니다.

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
  3. 다음 명령을 실행하여 TCP Ingress 포트를 설정합니다.

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].nodePort}')

2.14.1.4. 수신 게이트웨이 구성

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

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

프로세스

  1. 트래픽을 수락하기 위해 게이트웨이를 만듭니다.

    1. YAML 파일을 생성한 후 다음 YAML을 이 파일에 복사합니다.

      게이트웨이 예제 gateway.yaml

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: info-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"

    2. YAML 파일을 적용합니다.

      $ oc apply -f gateway.yaml
  2. VirtualService 오브젝트를 생성하여 호스트 헤더를 다시 작성합니다.

    1. YAML 파일을 생성한 후 다음 YAML을 이 파일에 복사합니다.

      가상 서비스 예

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: info
      spec:
        hosts:
        - "*"
        gateways:
        - info-gateway
        http:
        - match:
          - uri:
              exact: /productpage
          - uri:
              prefix: /static
          - uri:
              exact: /login
          - uri:
              exact: /logout
          - uri:
              prefix: /api/v1/products
          route:
          - destination:
              host: productpage
              port:
                number: 9080

    2. YAML 파일을 적용합니다.

      $ oc apply -f vs.yaml
  3. 게이트웨이 및 VirtualService가 올바르게 설정되었는지 확인합니다.

    1. 게이트웨이 URL을 설정합니다.

      export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
    2. 포트 번호를 설정합니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

      export TARGET_PORT=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.port.targetPort}')
    3. 명시적으로 노출된 페이지를 테스트합니다.

      curl -s -I "$GATEWAY_URL/productpage"

      예상 결과는 200입니다.

2.14.2. 자동 경로 이해

중요

Istio OpenShift Routing (IOR)은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

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

참고

Service Mesh 2.5부터 ServiceMeshControlPlane 리소스의 새 인스턴스에 대해 자동 경로가 기본적으로 비활성화됩니다.

2.14.2.1. 하위 도메인이 있는 경로

Red Hat OpenShift Service Mesh 는 하위 도메인으로 경로를 생성하지만 이를 활성화하려면 OpenShift Container Platform을 구성해야 합니다. 하위 도메인(예: *.domain.com )은 지원되지만 기본적으로 지원되지 않습니다. 와일드카드 호스트 게이트웨이를 구성하기 전에 OpenShift Container Platform 와일드카드 정책을 구성합니다.

자세한 내용은 와일드카드 경로 사용을 참조하십시오.

2.14.2.2. 하위 도메인 경로 생성

다음 예제에서는 Bookinfo 샘플 애플리케이션에 게이트웨이를 생성하여 하위 도메인 경로를 생성합니다.

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

Gateway 리소스는 다음 OpenShift 경로를 생성합니다. 다음 명령을 사용하여 경로가 생성되었는지 확인할 수 있습니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

$ oc -n istio-system 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가 경로를 삭제합니다. 그러나 수동으로 생성한 경로는 Red Hat OpenShift Service Mesh에 의해 수정되지 않습니다.

2.14.2.3. 경로 레이블 및 주석

OpenShift 경로에 특정 레이블 또는 주석이 필요한 경우가 있습니다. 예를 들어 OpenShift 경로의 일부 고급 기능은 특수 주석을 사용하여 관리됩니다. 다음 "추가 리소스" 섹션의 "Route-specific annotations"을 참조하십시오.

이 사용 사례 및 기타 사용 사례의 경우 Red Hat OpenShift Service Mesh는 Istio 게이트웨이 리소스에 있는 모든 레이블 및 주석( kubectl.kubernetes.io부터 시작하는 주석을 관리형 OpenShift 경로 리소스에 제외)에 복사합니다.

Service Mesh에서 생성한 OpenShift 경로에 특정 레이블 또는 주석이 필요한 경우 Istio 게이트웨이 리소스에서 생성하고 Service Mesh에서 관리하는 OpenShift 경로 리소스로 복사됩니다.

추가 리소스

2.14.2.4. 자동 경로 생성 비활성화

기본적으로 ServiceMeshControlPlane 리소스는 Istio 게이트웨이 리소스를 OpenShift 경로와 자동으로 동기화합니다. 자동 경로 생성을 비활성화하면 특별한 경우가 있거나 경로를 수동으로 제어하려는 경우 보다 유연하게 경로를 제어할 수 있습니다.

2.14.2.4.1. 특정 사례에 대한 자동 경로 생성 비활성화

특정 Istio 게이트웨이에 대한 OpenShift 경로의 자동 관리를 비활성화하려면 주석 maistra.io/manageRoute: false 를 게이트웨이 메타데이터 정의에 추가해야 합니다. Red Hat OpenShift Service Mesh는 다른 Istio 게이트웨이의 자동 관리를 유지하면서 이 주석이 포함된 Istio 게이트웨이를 무시합니다.

2.14.2.4.2. 모든 사례에 대한 자동 경로 생성 비활성화

메시의 모든 게이트웨이에 대해 OpenShift 경로의 자동 관리를 비활성화할 수 있습니다.

ServiceMeshControlPlane 필드 gateways.openshiftRoute.enabledfalse 로 설정하여 Istio 게이트웨이와 OpenShift 경로 간의 통합을 비활성화합니다. 예를 들어, 다음 리소스 스니펫을 참조하십시오.

apiVersion: maistra.io/v1alpha1
kind: ServiceMeshControlPlane
metadata:
  namespace: istio-system
spec:
  gateways:
    openshiftRoute:
      enabled: false

2.14.3. 서비스 항목 이해

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

  • 서비스 메시 외부에서 실행되는 서비스의 트래픽을 관리합니다.
  • 웹에서 소비된 API 또는 레거시 인프라의 서비스에 대한 트래픽과 같은 외부 대상의 트래픽을 리디렉션 및 전달합니다.
  • 외부 대상에 대한 재시도, 시간 초과 및 오류 삽입 정책을 정의합니다.
  • VM(가상 머신)에서 메시에 VM을 추가하여 메시 서비스를 실행합니다.
참고

Kubernetes에서 다중 클러스터 Red Hat OpenShift Service Mesh 메시를 구성하기 위해 다른 클러스터의 서비스를 메시에 추가합니다.

서비스 항목 예

다음 예제는 ext-resource 외부 종속성을 Red Hat OpenShift Service Mesh 서비스 레지스트리에 추가하는 mesh-external 서비스 항목입니다.

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

2.14.4. VirtualServices 사용

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

  • 단일 가상 서비스를 통해 여러 애플리케이션 서비스를 처리합니다. 예를 들어 메시에서 Kubernetes를 사용하는 경우 특정 네임스페이스의 모든 서비스를 처리하도록 가상 서비스를 구성할 수 있습니다. 가상 서비스를 사용하면 모놀리식 애플리케이션을 원활한 소비자 환경을 통해 별도의 마이크로 서비스로 구성된 서비스로 전환할 수 있습니다.
  • 게이트웨이와 결합하여 트래픽 규칙을 구성하고 수신 및 송신 트래픽을 제어합니다.

2.14.4.1. VirtualServices 구성

요청은 가상 서비스를 통해 서비스 메시 내의 서비스로 라우팅됩니다. 각 가상 서비스는 순서대로 평가되는 라우팅 규칙 세트로 구성됩니다. Red Hat OpenShift Service Mesh는 가상 서비스에 대해 주어진 각 요청을 메시 내의 실제 특정 대상에 연결합니다.

가상 서비스가 없으면 Red Hat OpenShift Service Mesh는 모든 서비스 인스턴스 간에 최소 로드 밸런싱을 사용하여 트래픽을 배포합니다. 가상 서비스에서는 하나 이상의 호스트 이름에 대한 트래픽 동작을 지정할 수 있습니다. 가상 서비스의 라우팅 규칙은 가상 서비스에 대한 트래픽을 적절한 대상으로 전송하는 방법을 Red Hat OpenShift Service Mesh에 알립니다. 경로 대상은 동일한 서비스 또는 완전히 다른 서비스 버전일 수 있습니다.

프로세스

  1. 다음 예제를 사용하여 YAML 파일을 생성하여 애플리케이션에 연결하는 사용자에 따라 다른 버전의 Bookinfo 샘플 애플리케이션 서비스로 요청을 라우팅합니다.

    예: VirtualService.yaml

    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

  2. 다음 명령을 실행하여 VirtualService.yaml을 적용합니다. 여기서 VirtualService.yaml은 파일 경로입니다.

    $ oc apply -f <VirtualService.yaml>

2.14.4.2. VirtualService 구성 참조

매개변수설명
spec:
  hosts:

hosts 필드에는 라우팅 규칙이 적용되는 가상 서비스의 대상 주소가 나열됩니다. 이는 서비스에 요청을 보내는 데 사용되는 주소입니다. 가상 서비스 호스트 이름은 IP 주소, DNS 이름 또는 정규화된 도메인 이름으로 확인되는 짧은 이름일 수 있습니다.

spec:
  http:
  - match:

http 섹션에는 호스트 필드에 지정된 대상으로 전송된 HTTP/1.1, HTTP2, gRPC 트래픽을 라우팅하기 위한 일치 조건 및 작업을 설명하는 가상 서비스의 라우팅 규칙이 포함됩니다. 라우팅 규칙은 트래픽을 이동할 대상과 지정된 일치 조건으로 구성됩니다. 예제의 첫 번째 라우팅 규칙에는 일치 필드로 시작하는 조건이 있습니다. 이 예제에서 이 라우팅은 사용자 jason의 모든 요청에 적용됩니다. headers, end-user, exact 필드를 추가하여 적절한 요청을 선택합니다.

spec:
  http:
  - match:
    - destination:

경로 섹션의 destination 필드는 이 조건과 일치하는 트래픽에 대한 실제 대상을 지정합니다. 가상 서비스의 호스트와 달리 대상 호스트는 Red Hat OpenShift Service Mesh 서비스 레지스트리에 있는 실제 대상이어야 합니다. 프록시가 있는 메시 서비스 또는 서비스 항목을 사용하여 추가된 비 메시 서비스일 수 있습니다. 이 예에서 호스트 이름은 Kubernetes 서비스 이름입니다.

2.14.5. 대상 규칙 이해

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

기본적으로 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

2.14.6. 네트워크 정책 이해

Red Hat OpenShift Service Mesh는 Service Mesh Control Plane 및 애플리케이션 네임스페이스에서 여러 NetworkPolicies 리소스를 자동으로 생성하고 관리합니다. 이는 애플리케이션과 컨트롤 플레인이 서로 통신할 수 있도록 하기 위한 것입니다.

예를 들어 SDN 플러그인을 사용하도록 OpenShift Container Platform 클러스터를 구성한 경우 Red Hat OpenShift Service Mesh는 각 멤버 프로젝트에서 NetworkPolicy 리소스를 생성합니다. 이를 통해 다른 메시 멤버 및 컨트롤 플레인에서 메시의 모든 Pod에 수신할 수 있습니다. 또한 멤버 프로젝트 전용 수신으로 제한합니다. 멤버 외 프로젝트에서 수신이 필요한 경우 해당 트래픽을 허용하기 위해 NetworkPolicy를 생성해야 합니다. Service Mesh에서 네임스페이스를 제거하면 이 NetworkPolicy 리소스는 프로젝트에서 삭제됩니다.

2.14.6.1. 자동 NetworkPolicy 생성 비활성화

예를 들어 회사 보안 정책을 적용하거나 메시의 Pod에 직접 액세스할 수 있도록 NetworkPolicy 리소스의 자동 생성 및 관리를 비활성화하려면 그렇게 할 수 있습니다. ServiceMeshControlPlane 을 편집하고 spec.security.manageNetworkPolicyfalse 로 설정할 수 있습니다.

참고

spec.security.manageNetworkPolicy Red Hat OpenShift Service Mesh를 비활성화하면 NetworkPolicy 오브젝트가 생성되지 않습니다. 시스템 관리자는 네트워크를 관리하고 이로 인해 발생할 수 있는 문제를 해결할 책임이 있습니다.

사전 요구 사항

  • Red Hat OpenShift Service Mesh Operator 버전 2.1.1 이상이 설치되어 있어야 합니다.
  • ServiceMeshControlPlane 리소스가 버전 2.1 이상으로 업데이트되었습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator 설치된 Operator를 클릭합니다.
  2. 프로젝트 메뉴에서 Service Mesh Control Plane을 설치한 프로젝트(예: istio-system )를 선택합니다.
  3. Red Hat OpenShift Service Mesh Operator를 클릭합니다. Istio Service Mesh Control Plane 열에서 ServiceMeshControlPlane의 이름을 클릭합니다(예: basic-install).
  4. ServiceMeshControlPlane 세부 정보 만들기 페이지에서 YAML을 클릭하여 구성을 수정합니다.
  5. 이 예와 같이 ServiceMeshControlPlane 필드 spec.security.manageNetworkPolicyfalse 로 설정합니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          manageNetworkPolicy: false
  6. 저장을 클릭합니다.

2.14.7. 트래픽 관리를 위한 사이드카 구성

기본적으로 Red Hat OpenShift Service Mesh는 연결된 워크로드의 모든 포트에서 트래픽을 허용하고 트래픽을 전달할 때 메시의 모든 워크로드에 도달할 수 있도록 모든 Envoy 프록시를 구성합니다. 사이드카 구성을 사용하여 다음을 수행할 수 있습니다.

  • Envoy 프록시가 수락하는 포트와 프로토콜 집합을 미세 조정합니다.
  • Envoy 프록시가 도달할 수 있는 서비스 집합을 제한합니다.
참고

서비스 메시의 성능을 최적화하려면 Envoy 프록시 구성을 제한하는 것이 좋습니다.

Bookinfo 샘플 애플리케이션에서 모든 서비스가 동일한 네임스페이스 및 컨트롤 플레인에서 실행되는 다른 서비스에 도달할 수 있도록 사이드카를 구성합니다. 이 사이드카 구성은 Red Hat OpenShift Service Mesh 정책 및 원격 분석 기능을 사용하는 데 필요합니다.

프로세스

  1. 다음 예제를 사용하여 YAML 파일을 생성하여 특정 네임스페이스의 모든 워크로드에 사이드카 구성을 적용하도록 지정합니다. 그렇지 않으면 workloadSelector를 사용하여 특정 워크로드를 선택합니다.

    예제 sidecar.yaml

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: info
    spec:
      egress:
      - hosts:
        - "./*"
        - "istio-system/*"

  2. 다음 명령을 실행하여 sidecar.yaml을 적용합니다. 여기서 sidecar.yaml은 파일의 경로입니다.

    $ oc apply -f sidecar.yaml
  3. 다음 명령을 실행하여 사이드카가 성공적으로 생성되었는지 확인합니다.

    $ oc get sidecar

2.14.8. 라우팅 튜토리얼

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

2.14.8.1. Bookinfo 라우팅 튜토리얼

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

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

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

사전 요구 사항

  • 다음 예제에서 작동하도록 Bookinfo 샘플 애플리케이션을 배포하십시오.

2.14.8.2. 가상 서비스 적용

다음 절차에서 가상 서비스는 마이크로 서비스의 기본 버전을 설정하는 가상 서비스를 적용하여 모든 트래픽을 각 마이크로 서비스의 v1로 라우팅합니다.

프로세스

  1. 가상 서비스를 적용합니다.

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.6/samples/info/networking/virtual-service-all-v1.yaml
  2. 가상 서비스를 적용했는지 확인하려면 다음 명령을 사용하여 정의된 경로를 표시합니다.

    $ oc get virtualservices -o yaml

    이 명령은 kind: VirtualService의 리소스를 YAML 형식으로 반환합니다.

reviews 서비스 버전 1을 포함하여 서비스 메시를 Bookinfo 마이크로 서비스 v1 버전으로 라우팅하도록 구성했습니다.

2.14.8.3. 새 경로 구성 테스트

Bookinfo 앱의 /productpage를 다시 새로 고침하여 새 구성을 테스트합니다.

프로세스

  1. GATEWAY_URL 매개변수 값을 설정합니다. 이 변수를 사용하여 나중에 Bookinfo 제품 페이지의 URL을 찾을 수 있습니다. 이 예제에서 컨트롤 플레인 프로젝트는 istio-system입니다.

    export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
  2. 다음 명령을 실행하여 제품 페이지의 URL을 검색합니다.

    echo "http://$GATEWAY_URL/productpage"
  3. 브라우저에서 Bookinfo 사이트를 엽니다.

페이지의 리뷰 부분은 새로 고침 횟수와 관계없이 별점 없이 표시됩니다. 이는 리뷰 서비스의 모든 트래픽을 reviews:v1 버전으로 라우팅하도록 서비스 메시를 구성했기 때문이며, 이 서비스 버전은 별점 서비스에 액세스할 수 없습니다.

이제 서비스 메시가 트래픽을 하나의 서비스 버전으로 라우팅합니다.

2.14.8.4. 사용자 ID 기반 경로

특정 사용자의 모든 트래픽이 특정 서비스 버전으로 라우팅되도록 경로 구성을 변경합니다. 이 경우 jason이라는 사용자의 모든 트래픽은 서비스 reviews:v2로 라우팅됩니다.

서비스 메시에는 사용자 ID에 대한 특별한 기본 이해가 없습니다. 이 예제는 productpage 서비스가 모든 아웃바운드 HTTP 요청에 대한 사용자 정의 end-user 헤더를 검토 서비스에 추가한다는 사실에 의해 활성화됩니다.

프로세스

  1. 다음 명령을 실행하여 Bookinfo 샘플 애플리케이션에서 사용자 기반 라우팅을 활성화하도록 설정합니다.

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.6/samples/info/networking/virtual-service-reviews-test-v2.yaml
  2. 다음 명령을 실행하여 규칙이 생성되었는지 확인합니다. 이 명령은 kind: VirtualService의 모든 리소스를 YAML 형식으로 반환합니다.

    $ oc get virtualservice reviews -o yaml
  3. Bookinfo 앱의 /productpage에서 암호없이 jason으로 로그인합니다.
  4. 브라우저를 새로 고침합니다. 별점은 각 리뷰 옆에 표시됩니다.
  5. 다른 사용자로 로그인합니다(원하는 이름 선택). 브라우저를 새로 고침합니다. 이제 별이 사라졌습니다. Jason을 제외한 모든 사용자에 대해 트래픽이 reviews:v1으로 라우팅됩니다.

사용자 ID를 기반으로 트래픽을 라우팅하도록 Bookinfo 샘플 애플리케이션을 성공적으로 구성했습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.