1.18. 서비스 메시 연결


페더레이션 은 별도의 관리 도메인에서 관리하는 별도의 메시 간에 서비스 및 워크로드를 공유할 수 있는 배포 모델입니다.

1.18.1. 페더레이션 개요

페더레이션은 별도의 메시 간에 서비스를 연결할 수 있는 일련의 기능이며 여러 별도의 관리 도메인에서 인증, 권한 부여 및 트래픽 관리와 같은 서비스 메시 기능을 사용할 수 있습니다.

페더레이션 메시를 구현하면 여러 OpenShift 클러스터에서 실행되는 단일 서비스 메시를 실행, 관리 및 관찰할 수 있습니다. Red Hat OpenShift Service Mesh 페더레이션은 메시 간 최소 신뢰를 가정하는 Service Mesh의 다중 클러스터 구현에 대한 의견 접근 방식을 취합니다.

서비스 메시 페더레이션에서는 각 메시가 개별적으로 관리되고 자체 관리자가 있는 것으로 가정합니다. 기본 동작은 통신이 허용되지 않으며 메시 간에 정보가 공유되지 않는다는 것입니다. 메시 간 정보 공유는 명시적 옵트인(opt-in) 기반입니다. 공유를 위해 구성되지 않은 경우 페더레이션 메시에서 공유되지 않습니다. 인증서 생성, 메트릭 및 추적 수집과 같은 지원 기능은 각 메시에서 로컬로 유지됩니다.

각 서비스 메시에서 ServiceMeshControlPlane 을 구성하여 구체적으로 페더레이션을 위한 수신 및 송신 게이트웨이를 생성하고 메시에 대한 신뢰 도메인을 지정합니다.

페더레이션은 또한 추가 연합 파일을 생성하는 것과 관련이 있습니다. 다음 리소스는 둘 이상의 메시 간 연합을 구성하는 데 사용됩니다.

  • ServiceMeshPeriod 리소스 는 한 쌍의 서비스 메시 간 페더레이션을 선언합니다.
  • ExportedServiceSet 리소스는 피어 메시에서 하나 이상의 서비스를 사용할 수 있음을 선언합니다.
  • ImportedServiceSet 리소스는 피어 메시에서 내보낸 서비스를 메시로 가져올 서비스를 선언합니다.

1.18.2. 페더레이션 기능

메시에 가입하기 위한 Red Hat OpenShift Service Mesh 통합 접근법의 기능은 다음과 같습니다.

  • 각 메시에 대한 공통 루트 인증서를 지원합니다.
  • 각 메시에 대해 다양한 루트 인증서를 지원합니다.
  • 메시 관리자는 Federated 메시 외부의 메시에 대한 인증서 체인, 서비스 검색 끝점, 신뢰 도메인 등을 수동으로 구성해야 합니다.
  • 메시 간에 공유할 서비스만 내보내거나 가져옵니다.

    • 기본적으로 배포된 워크로드에 대한 정보는 통합의 다른 메시와 공유하지 않습니다. 서비스를 내보내 다른 메시에 표시하고 자체 메시 외부의 워크로드의 요청을 허용할 수 있습니다.
    • 내보낸 서비스를 다른 메시로 가져올 수 있으므로 해당 메시의 워크로드가 가져온 서비스에 요청을 보낼 수 있습니다.
  • 항상 메시 간 통신을 암호화합니다.
  • 로컬로 배포된 워크로드 및 다른 메시에 배포된 워크로드 간 로드 밸런싱 구성을 지원합니다.

메시가 다른 메시에 결합되면 다음을 수행할 수 있습니다.

  • 연합된 메시에 대한 신뢰 세부 정보를 제공합니다.
  • 연합된 메시에 대한 신뢰 세부 정보를 검색합니다.
  • 내보낸 자체 서비스에 대한 연합 메시에 정보를 제공합니다.
  • 연합 메시에서 내보낸 서비스에 대한 정보를 검색합니다.

1.18.3. 페더레이션 보안

Red Hat OpenShift Service Mesh 페더레이션은 메시 간 최소 신뢰를 가정하는 Service Mesh의 다중 클러스터 구현에 대한 의견 접근 방식을 취합니다. 데이터 보안은 연합 기능의 일부로 구축됩니다.

  • 각 메시는 고유한 관리를 통해 고유한 테넌트로 간주됩니다.
  • 페더레이션에서 각 메시에 대해 고유한 신뢰 도메인을 생성합니다.
  • 연합 메시 간 트래픽은 mTLS(mutual Transport Layer Security)을 사용하여 자동으로 암호화됩니다.
  • Kiali 그래프는 가져온 메시 및 서비스만 표시합니다. 메시로 가져오지 않은 다른 메시 또는 서비스는 볼 수 없습니다.

1.18.4. 페더레이션 제한

메시에 가입하기 위한 Red Hat OpenShift Service Mesh 통합 접근법에는 다음과 같은 제한 사항이 있습니다.

  • OpenShift Dedicated에서는 메시의 페더레이션이 지원되지 않습니다.

1.18.5. 페더레이션 사전 요구 사항

메시에 가입하기 위한 Red Hat OpenShift Service Mesh 통합 접근법에는 다음과 같은 사전 요구 사항이 있습니다.

  • 두 개 이상의 OpenShift Container Platform 4.6 이상의 클러스터.
  • 페더레이션은 Red Hat OpenShift Service Mesh 2.1 이상에서 도입되었습니다. 페더레이션할 각 메시에 Red Hat OpenShift Service Mesh 2.1 이상의 Operator가 설치되어 있어야 합니다.
  • 연결하려는 각 메시에 버전 2.1 이상 ServiceMeshControlPlane 이 배포되어야 합니다.
  • 원시 TLS 트래픽을 지원하려면 페더레이션 게이트웨이와 연결된 서비스를 지원하는 로드 밸런서를 구성해야 합니다. 페더레이션 트래픽은 서비스 트래픽을 위한 검색 및 원시 암호화된 TCP를 위한 HTTPS로 구성됩니다.
  • 다른 메시에 노출하려는 서비스를 내보내서 가져올 수 있기 전에 배포해야 합니다. 그러나 이것은 엄격한 요구 사항이 아닙니다. export/import에 대해 아직 존재하지 않는 서비스 이름을 지정할 수 있습니다. ExportedServiceSetImportedServiceSet 에서 이름이 지정된 서비스를 배포하면 내보내기/가져오기에 자동으로 사용할 수 있습니다.

1.18.6. 메시 통합 계획

메시 연합 구성을 시작하기 전에 일정 시간이 걸리므로 구현을 계획해야 합니다.

  • 얼마나 많은 메시가 연합에 참여할 계획입니까? 제한된 수의 메시 (두 개 또는 세 개)로 시작해야 할 수도 있습니다.
  • 각 메시에 사용할 이름 지정 규칙은 무엇입니까? 미리 정의된 이름 지정 규칙이 있으면 구성 및 문제 해결에 도움이 됩니다. 이 문서의 예제에서는 각 메시에 대해 다른 색상을 사용합니다. 각 메시와 다음 페더레이션 리소스를 누가 소유하고 관리하는지 결정하는 데 도움이 되는 이름 지정 규칙을 결정해야 합니다.

    • 클러스터 이름
    • 클러스터 네트워크 이름
    • 메시 이름 및 네임스페이스
    • 페더레이션 수신 게이트웨이
    • 페더레이션 송신 게이트웨이
    • 보안 신뢰 도메인

      참고

      페더레이션의 각 메시에는 고유한 신뢰 도메인이 있어야 합니다.

  • 각 메시의 어떤 서비스가 연합 메시로 내보낼 계획입니까? 각 서비스를 개별적으로 내보내거나 레이블을 지정하거나 와일드카드를 사용할 수 있습니다.

    • 서비스 네임스페이스에 별칭을 사용하고 싶으신가요?
    • 내보낸 서비스에 별칭을 사용하고 싶으신가요?
  • 각 메시에서 가져올 계획인 내보낸 서비스는 무엇입니까? 각 메시는 필요한 서비스만 가져옵니다.

    • 가져온 서비스에 별칭을 사용하고 싶으신가요?

1.18.7. 클러스터 전체에서 메시 통합

다른 클러스터에서 실행 중인 OpenShift Service Mesh의 인스턴스 하나를 연결하기 위해 동일한 클러스터에 배포된 두 메시를 연결할 때와 매우 다르지 않습니다. 그러나 하나의 메시의 수신 게이트웨이는 다른 메시에서 연결할 수 있어야합니다. 클러스터가 이러한 유형의 서비스를 지원하는 경우 게이트웨이 서비스를 LoadBalancer 서비스로 구성하는 것입니다.

OSI 모델의 계층4에서 작동하는 로드 밸런서를 통해 서비스를 노출해야 합니다.

1.18.7.1. 베어 메탈에서 실행되는 클러스터에 페더레이션 인그레스 노출

클러스터가 베어 메탈에서 실행되고 LoadBalancer 서비스를 완전히 지원하는 경우 수신 게이트웨이 서비스 오브젝트의 .status.loadBalancer.ingress.ip 필드에 있는 IP 주소는 ServiceMesh -02- 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

클러스터가 LoadBalancer 서비스를 지원하지 않는 경우 NodePort 서비스를 사용하면 다른 메시를 실행하는 클러스터에서 노드에 액세스할 수 있는 경우 옵션이 될 수 있습니다. ServiceMesh peer 개체에서 .spec.remote.addresses 필드에 노드의 IP 주소와 .spec.remote.discoveryPort.spec.remote.servicePort 필드에 서비스의 노드 포트를 지정합니다.

1.18.7.2. IBM Power 및 IBM Z에서 실행되는 클러스터에 페더레이션 수신 노출

클러스터가 IBM Power 또는 IBM Z 인프라에서 실행되고 LoadBalancer 서비스를 완전히 지원하는 경우 수신 게이트웨이 서비스 오브젝트의 .status.loadBalancer.ingress.ip 필드에 있는 IP 주소는 ServiceMesh Period 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

클러스터가 LoadBalancer 서비스를 지원하지 않는 경우 NodePort 서비스를 사용하면 다른 메시를 실행하는 클러스터에서 노드에 액세스할 수 있는 경우 옵션이 될 수 있습니다. ServiceMesh peer 개체에서 .spec.remote.addresses 필드에 노드의 IP 주소와 .spec.remote.discoveryPort.spec.remote.servicePort 필드에 서비스의 노드 포트를 지정합니다.

1.18.7.3. AWS(Amazon Web Services)에 페더레이션 수신 노출

기본적으로 AWS에서 실행되는 클러스터의 LoadBalancer 서비스는 L4 로드 밸런싱을 지원하지 않습니다. Red Hat OpenShift Service Mesh 통합이 올바르게 작동하려면 수신 게이트웨이 서비스에 다음 주석을 추가해야 합니다.

service.beta.kubernetes.io/aws-load-balancer-type: nlb

수신 게이트웨이 서비스 오브젝트의 .status.loadBalancer.ingress.hostname 필드에 있는 정규화된 도메인 이름은 ServiceMesh 피어 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

1.18.7.4. Azure에서 페더레이션 인그레스 노출

Microsoft Azure에서 메시 페더레이션이 제대로 작동하기 위해 서비스 유형을 LoadBalancer 로 설정하는 것만으로 충분합니다.

수신 게이트웨이 서비스 오브젝트의 .status.loadBalancer.ingress.ip 필드에 있는 IP 주소는 ServiceMesh Period 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

1.18.7.5. GCP(Google Cloud Platform)에 페더레이션 수신 노출

Google Cloud Platform에서 서비스 유형을 LoadBalancer 로 설정하는 것만으로 메시 통합이 올바르게 작동하기에 충분합니다.

수신 게이트웨이 서비스 오브젝트의 .status.loadBalancer.ingress.ip 필드에 있는 IP 주소는 ServiceMesh Period 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

1.18.8. 페더레이션 구현 체크리스트

서비스 메시에는 다음 활동이 포함됩니다.

  • ❏ 통합하려는 클러스터 간 네트워킹을 구성합니다.

    • ❏ 원시 TLS 트래픽을 지원하기 위해 페더레이션 게이트웨이와 연결된 서비스를 지원하는 로드 밸런서를 구성합니다.
  • dpdk 각 클러스터에 Red Hat OpenShift Service Mesh 버전 2.1 이상 Operator를 설치합니다.
  • jenkinsfile 버전 2.1 이상 ServiceMeshControlPlane 을 각 클러스터에 배포합니다.
  • 통합하려는 각 메시에 대해 SMCP를 구성합니다.

    • 연결하려는 각 메시에 대해 페더레이션 송신 게이트웨이를 만듭니다.
    • 연결하려는 각 메시에 대해 페더레이션 수신 게이트웨이를 만듭니다.
    • 고유한 트러스트 도메인을 구성합니다.Configure a unique trust domain.
  • ❏ 각 메시 쌍에 대해 ServiceMesh peer 리소스를 생성하여 두 개 이상의 메시를 통합합니다.
  • dpdk ExportedServiceSet 리소스를 생성하여 하나의 메시에서 피어 메시로 서비스를 사용할 수 있도록 하여 서비스를 내보냅니다.
  • dpdk는 메시 피어에서 공유하는 서비스를 가져오기 위해 ImportedServiceSet 리소스를 만들어 서비스를 가져옵니다.

1.18.9. 페더레이션을 위한 서비스 메시 컨트롤 플레인 구성

메시를 통합하기 전에 메시 통합을 위해 ServiceMeshControlPlane 을 구성해야 합니다. 연합의 멤버인 모든 메시가 동일하고 각 메시는 독립적으로 관리되므로 페더레이션에 참여할 메시마다 SMCP를 구성해야 합니다.

다음 예에서 red-mesh 의 관리자는 green-meshblue-mesh 와 함께 페더레이션에 대해 SMCP를 구성하고 있습니다.

red-mesh에 대한 샘플 SMCP

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  version: v2.4
  runtime:
    defaults:
      container:
        imagePullPolicy: Always
  gateways:
    additionalEgress:
      egress-green-mesh:
        enabled: true
        requestedNetworkView:
        - green-network
        routerMode: sni-dnat
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for: egress-green-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: http-discovery  #note HTTP here
      egress-blue-mesh:
        enabled: true
        requestedNetworkView:
        - blue-network
        routerMode: sni-dnat
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for: egress-blue-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: http-discovery  #note HTTP here
    additionalIngress:
      ingress-green-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: LoadBalancer
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-green-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: https-discovery  #note HTTPS here
      ingress-blue-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: LoadBalancer
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-blue-mesh
          ports:
          - port: 15443
            name: tls
          - port: 8188
            name: https-discovery  #note HTTPS here
  security:
    trust:
      domain: red-mesh.local

표 1.6. ServiceMeshControlPlane 페더레이션 구성 매개변수
매개변수설명기본값
spec:
  cluster:
    name:

클러스터의 이름입니다. 클러스터 이름을 지정할 필요는 없지만 문제 해결에 유용합니다.

문자열

해당 없음

spec:
  cluster:
    network:

클러스터 네트워크의 이름입니다. 네트워크 이름을 지정할 필요는 없지만 구성 및 문제 해결에 유용합니다.

문자열

해당 없음

1.18.9.1. 페더레이션 게이트웨이 이해

게이트웨이를 사용하여 메시에 대한 인바운드 및 아웃바운드 트래픽을 관리하여 메시에 들어가거나 나가려는 트래픽을 지정할 수 있습니다.

수신 및 송신 게이트웨이를 사용하여 서비스 메시(North-South 트래픽)를 입력하고 나가는 트래픽을 관리합니다. 연합 메시를 생성할 때 추가적인 수신/egress 게이트웨이를 생성하여 연합 메시 간 서비스 검색, 통합 메시 간 통신, 서비스 메시 간 트래픽 흐름(동부 트래픽)을 관리합니다.

메시 간 충돌 이름 지정을 방지하려면 각 메시에 대해 별도의 송신 및 수신 게이트웨이를 생성해야 합니다. 예를 들어 red-mesh 에는 green-meshblue-mesh 로 이동하는 트래픽에 대해 별도의 송신 게이트웨이가 있습니다.

표 1.7. 페더레이션 게이트웨이 매개변수
매개변수설명기본값
spec:
  gateways:
    additionalEgress:
      <egressName>:

페더레이션에서 메시 피어에 대한 추가 송신 게이트웨이를 정의합니다.

  
spec:
  gateways:
    additionalEgress:
      <egressName>:
        enabled:

이 매개변수는 페더레이션 송신을 활성화 또는 비활성화합니다.

true/false

true

spec:
  gateways:
    additionalEgress:
      <egressName>:
        requestedNetworkView:

내보낸 서비스와 연결된 네트워크입니다.

메시의 SMCP에서 spec.cluster.network 값으로 설정합니다. 그렇지 않으면 <ServiceMeshpeer-name>-network를 사용합니다. 예를 들어, 해당 메시 의 ServiceMesh peer 리소스의 이름이 west 인 경우 네트워크 이름은 west-network 입니다.

 
spec:
  gateways:
    additionalEgress:
      <egressName>:
        routerMode:

게이트웨이에서 사용할 라우터 모드입니다.

sni-dnat

 
spec:
  gateways:
    additionalEgress:
      <egressName>:
        service:
          metadata:
            labels:
              federation.maistra.io/egress-for:

연결된 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 않도록 게이트웨이에 대한 고유 레이블을 지정합니다.

  
spec:
  gateways:
    additionalEgress:
      <egressName>:
        service:
          ports:

포트: 및 name: 를 지정하는 데 사용되는 TLS 및 서비스 검색에 사용됩니다. 페더레이션 트래픽은 서비스 트래픽을 위해 원시 암호화된 TCP로 구성됩니다.

포트 15443 은 연합 내의 다른 메시에 TLS 서비스 요청을 보내는 데 필요합니다. 포트 8188 은 페더레이션의 다른 메시에 서비스 검색 요청을 보내는 데 필요합니다.

 
spec:
  gateways:
    additionalIngress:

페더레이션에서 메시 피어에 대한 추가 수신 게이트웨이 게이트웨이를 정의합니다.

  
spec:
  gateways:
    additionalIgress:
      <ingressName>:
        enabled:

이 매개변수는 페더레이션 인그레스를 활성화 또는 비활성화합니다.

true/false

true

spec:
  gateways:
    additionalIngress:
      <ingressName>:
        routerMode:

게이트웨이에서 사용할 라우터 모드입니다.

sni-dnat

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          type:

수신 게이트웨이 서비스는 OSI 모델의 계층 4에서 작동하고 공개적으로 사용 가능한 로드 밸런서를 통해 노출되어야 합니다.

LoadBalancer

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          type:

클러스터가 LoadBalancer 서비스를 지원하지 않으면 NodePort 서비스를 통해 수신 게이트웨이 서비스가 노출될 수 있습니다.

NodePort

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          metadata:
            labels:
              federation.maistra.io/ingress-for:

연결된 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 않도록 게이트웨이에 대한 고유 레이블을 지정합니다.

  
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          ports:

포트: 및 name: 를 지정하는 데 사용되는 TLS 및 서비스 검색에 사용됩니다. 페더레이션 트래픽은 서비스 트래픽을 위해 원시 암호화된 TCP로 구성됩니다. 페더레이션 트래픽은 검색을 위한 HTTPS로 구성됩니다.

포트 15443 은 다른 메시에 대한 TLS 서비스 요청을 수신하는 데 필요합니다. 포트 8188 은 페더레이션의 다른 메시에 대한 서비스 검색 요청을 수신하는 데 필요합니다.

 
spec:
  gateways:
    additionalIngress:
      <ingressName>:
        service:
          ports:
            nodePort:

nodePort: 클러스터가 LoadBalancer 서비스를 지원하지 않는 경우

지정된 경우 TLS 및 서비스 검색에는 포트 : 및 name 외에도 필요합니다. NodePort: 30000-32767 범위에 있어야 합니다.

 

다음 예에서 관리자는 NodePort 서비스를 사용하여 green-mesh 로 통합에 SMCP를 구성하고 있습니다.

NodePort의 샘플 SMCP

  gateways:
     additionalIngress:
      ingress-green-mesh:
        enabled: true
        routerMode: sni-dnat
        service:
          type: NodePort
          metadata:
            labels:
              federation.maistra.io/ingress-for: ingress-green-mesh
          ports:
          - port: 15443
            nodePort: 30510
            name: tls
          - port: 8188
            nodePort: 32359
            name: https-discovery

1.18.9.2. 페더레이션 신뢰 도메인 매개변수 이해

페더레이션의 각 메시에는 고유한 신뢰 도메인이 있어야 합니다. 이 값은 ServiceMeshPeer 리소스에서 메시 통합을 구성할 때 사용됩니다.

kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  security:
    trust:
      domain: red-mesh.local
표 1.8. 페더레이션 보안 매개변수
매개변수설명기본값
spec:
  security:
    trust:
      domain:

메시에 대한 신뢰 도메인의 고유 이름을 지정하는 데 사용됩니다. 도메인은 연합 내의 모든 메시에 대해 고유해야 합니다.

<mesh-name>.local

해당 없음

콘솔의 프로세스

OpenShift Container Platform 웹 콘솔을 사용하여 ServiceMeshControlPlane을 편집하려면 다음 절차를 따르십시오. 이 예에서는 red-mesh 를 예제로 사용합니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators 설치된 Operator로 이동합니다.
  3. 프로젝트 메뉴를 클릭하고 Service Mesh Control Plane을 설치한 프로젝트를 선택합니다. 예를 들면 red-mesh-system 입니다.
  4. Red Hat OpenShift Service Mesh Operator를 클릭합니다.
  5. Istio Service Mesh Control Plane 탭에서 ServiceMeshControlPlane 의 이름을 클릭합니다(예: red-mesh ).
  6. ServiceMeshControlPlane 세부 정보 만들기 페이지에서 YAML을 클릭하여 구성을 수정합니다.
  7. ServiceMeshControlPlane 을 수정하여 페더레이션 인그레스 및 송신 게이트웨이를 추가하고 신뢰 도메인을 지정합니다.
  8. 저장을 클릭합니다.

CLI의 프로세스

다음 절차에 따라 명령줄로 ServiceMeshControlPlane을 생성하거나 편집합니다. 이 예에서는 red-mesh 를 예제로 사용합니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. Service Mesh Control Plane을 설치한 프로젝트로 변경합니다(예: red-mesh-system).

    $ oc project red-mesh-system
  3. ServiceMeshControlPlane 파일을 편집하여 페더레이션 인그레스 및 송신 게이트웨이를 추가하고 신뢰 도메인을 지정합니다.
  4. 다음 명령을 실행하여 Service Mesh Control Plane을 편집합니다. 여기서 red-mesh-system 은 시스템 네임스페이스이고 red-meshServiceMeshControlPlane 오브젝트의 이름입니다.

    $ oc edit -n red-mesh-system smcp red-mesh
  5. 다음 명령을 입력합니다. 여기서 red-mesh-system 은 시스템 네임스페이스이며, Service Mesh Control Plane 설치 상태를 확인합니다.

    $ oc get smcp -n red-mesh-system

    READY 열에 모든 구성 요소가 준비되었음을 나타내는 설치가 성공적으로 완료되었습니다.

    NAME       READY   STATUS            PROFILES      VERSION   AGE
    red-mesh   10/10   ComponentsReady   ["default"]   2.1.0     4m25s

1.18.10. 페더레이션 메시 결합

ServiceMeshPeer 리소스를 생성하여 두 메시 간 페더레이션을 선언합니다. ServiceMeshPeer 리소스는 두 메시 간의 페더레이션을 정의하고, 이를 사용하여 피어 메시에 대한 검색, 피어 메시에 대한 액세스, 다른 메시의 클라이언트의 유효성을 확인하는 데 사용되는 인증서를 구성합니다.

서비스 메시 통합 메시 피어 예시

메시는 일대일로 통합되므로 각 피어 쌍에는 다른 서비스 메시에 대한 통합 연결을 지정하는 ServiceMesh peer 리소스 쌍이 필요합니다. 예를 들어 redgreen 이라는 두 개의 메시를 통합하려면 ServiceMeshPeer 파일이 필요합니다.

  1. red-mesh-system에서 녹색 메시에 대한 ServiceMesh peer를 만듭니다.
  2. green-mesh-system에서 빨간색 메시에 대한 ServiceMesh peer를 만듭니다.

빨간색,블루, 녹색 이라는 세 개의 메시를 태그하려면 6개의 ServiceMeshPeriod 파일이 필요합니다.

  1. red-mesh-system에서 녹색 메시에 대한 ServiceMesh peer를 만듭니다.
  2. red-mesh-system에서 Blue 메시에 대한 ServiceMesh peer를 만듭니다.
  3. green-mesh-system에서 빨간색 메시에 대한 ServiceMesh peer를 만듭니다.
  4. green-mesh-system에서 Blue 메시에 대한 ServiceMesh peer를 만듭니다.
  5. blue-mesh-system에서 빨간색 메시에 대한 ServiceMesh peer를 만듭니다.
  6. blue-mesh-system에서 녹색 메시에 대한 ServiceMesh peer를 만듭니다.

ServiceMeshPeriod 리소스의 구성은 다음과 같습니다.

  • 검색 및 서비스 요청에 사용되는 다른 메시의 수신 게이트웨이의 주소입니다.
  • 지정된 피어 메시와 상호 작용하는 데 사용되는 로컬 수신 및 송신 게이트웨이의 이름입니다.
  • 이 메시에 요청을 보낼 때 다른 메시에서 사용하는 클라이언트 ID입니다.
  • 다른 메시에서 사용하는 신뢰 도메인입니다.
  • 다른 메시에서 사용하는 신뢰 도메인에서 클라이언트 인증서의 유효성을 확인하는 데 사용되는 루트 인증서가 포함된 ConfigMap 의 이름입니다.

다음 예에서 red-mesh 의 관리자는 green-mesh 로 페더레이션을 구성하고 있습니다.

red-mesh에 대한 ServiceMeshpeer 리소스의 예

kind: ServiceMeshPeer
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  remote:
    addresses:
    - ingress-red-mesh.green-mesh-system.apps.domain.com
  gateways:
    ingress:
      name: ingress-green-mesh
    egress:
      name: egress-green-mesh
  security:
    trustDomain: green-mesh.local
    clientID: green-mesh.local/ns/green-mesh-system/sa/egress-red-mesh-service-account
    certificateChain:
      kind: ConfigMap
      name: green-mesh-ca-root-cert

표 1.9. ServiceMeshPeriod 구성 매개변수
매개변수설명
metadata:
  name:

이 리소스가 페더레이션을 구성하는 피어 메시의 이름입니다.

문자열

metadata:
  namespace:

Service Mesh Control Plane이 설치된 이 메시의 시스템 네임스페이스입니다.

문자열

spec:
  remote:
    addresses:

이 메시에서 요청을 처리하는 피어 메시의 수신 게이트웨이의 공용 주소 목록입니다.

 
spec:
  remote:
    discoveryPort:

검색 요청을 처리하는 주소가 있는 포트입니다.

기본값은 8188입니다.

spec:
  remote:
    servicePort:

주소가 서비스 요청을 처리하는 포트입니다.

기본값은 15443입니다.

spec:
  gateways:
    ingress:
      name:

피어 메시에서 수신한 요청을 서비스하는 이 메시의 수신 수신 이름입니다. 예: ingress-green-mesh.

 
spec:
  gateways:
    egress:
      name:

피어 메시로 전송되는 요청을 서비스하는 이 메시의 송신 이름입니다. 예를 들어 egress-green-mesh.

 
spec:
  security:
    trustDomain:

피어 메시에서 사용하는 신뢰 도메인입니다.

<peerMeshName>.local

spec:
  security:
    clientID:

이 메시로 호출할 때 피어 메시에서 사용하는 클라이언트 ID입니다.

<peerMeshTrustDomain>/ns/<peerMeshSystem>/sa/<peerMeshEgressGatewayName>-service-account

spec:
  security:
    certificateChain:
      kind: ConfigMap
      name:

피어 메시에 의해 제공되는 클라이언트 및 서버 인증서의 유효성을 검사하는 데 사용되는 루트 인증서가 포함된 종류의(예: ConfigMap) 및 리소스 이름입니다. 인증서가 포함된 구성 맵 항목의 키는 root-cert.pem 이어야 합니다.

kind: ConfigMap 이름: <peerMesh>-ca-root-cert

1.18.10.1. ServiceMeshpeer 리소스 생성

사전 요구 사항

  • 두 개 이상의 OpenShift Container Platform 4.6 이상의 클러스터.
  • 클러스터가 이미 네트워크되어 있어야 합니다.
  • 페더레이션 게이트웨이와 연결된 서비스를 지원하는 로드 밸런서는 원시 TLS 트래픽을 지원하도록 구성해야 합니다.
  • 각 클러스터에는 배포된 페더레이션을 지원하도록 버전 2.1 이상의 ServiceMeshControlPlane 이 구성되어 있어야 합니다.
  • cluster-admin 역할이 있는 계정.

CLI의 프로세스

다음 절차에 따라 명령줄에서 ServiceMesh peer 리소스를 만듭니다. 이 예에서는 red-mesh 에서 green-mesh 에 대한 피어 리소스를 생성하는 방법을 보여줍니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.

    $ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
  2. 컨트롤 플레인을 설치한 프로젝트(예: red-mesh-system )로 변경합니다.

    $ oc project red-mesh-system
  3. 통합하려는 두 메시에 대해 다음 예제를 기반으로 ServiceMesh Period 파일을 만듭니다.

    red-mesh에 대한 ServiceMeshPeer 리소스 예 - green-mesh

    kind: ServiceMeshPeer
    apiVersion: federation.maistra.io/v1
    metadata:
      name: green-mesh
      namespace: red-mesh-system
    spec:
      remote:
        addresses:
        - ingress-red-mesh.green-mesh-system.apps.domain.com
      gateways:
        ingress:
          name: ingress-green-mesh
        egress:
          name: egress-green-mesh
      security:
        trustDomain: green-mesh.local
        clientID: green-mesh.local/ns/green-mesh-system/sa/egress-red-mesh-service-account
        certificateChain:
          kind: ConfigMap
          name: green-mesh-ca-root-cert

  4. 다음 명령을 실행하여 리소스를 배포합니다. 여기서 red-mesh-system 은 시스템 네임스페이스이고 servicemeshpeer.yaml 에는 편집한 파일에 대한 전체 경로가 포함됩니다.

    $ oc create -n red-mesh-system -f servicemeshpeer.yaml
  5. 빨간색 메시와 녹색 메시 간 연결이 설정되었는지 확인하려면 red-mesh-system 네임스페이스에서 green-mesh ServiceMesh peer의 상태를 검사합니다.

    $ oc -n red-mesh-system get servicemeshpeer green-mesh -o yaml

    red-mesh와 green-mesh 간의 ServiceMeshpeer 연결 예

    status:
      discoveryStatus:
        active:
        - pod: istiod-red-mesh-b65457658-9wq5j
          remotes:
          - connected: true
            lastConnected: "2021-10-05T13:02:25Z"
            lastFullSync: "2021-10-05T13:02:25Z"
            source: 10.128.2.149
          watch:
            connected: true
            lastConnected: "2021-10-05T13:02:55Z"
            lastDisconnectStatus: 503 Service Unavailable
            lastFullSync: "2021-10-05T13:05:43Z"

    status.discoveryStatus.active.remotes 필드에는 피어 메시의 istiod(이 예에서는 녹색 메시)가 현재 메시(이 예에서는 빨간색 메시)에서 istiod에 연결되어 있음을 보여줍니다.

    status.discoveryStatus.active.watch 필드에는 현재 메시의 istiod가 피어 메시의 istiod에 연결되어 있는 것으로 표시됩니다.

    green-mesh-system 에서 red-mesh 피어라는 servicemeshpeer 를 선택하면 녹색 메시의 관점에서 동일한 두 연결에 대한 정보를 확인할 수 있습니다.

    두 메시 간 연결이 설정되지 않으면 ServiceMeshPeriod 상태는 status.discoveryStatus.inactive 필드에 이를 나타냅니다.

    연결 시도가 실패한 이유에 대한 자세한 내용은 Istiod 로그, 피어에 대한 송신 트래픽을 처리하는 송신 게이트웨이의 액세스 로그 및 피어 메시의 현재 메시에 대한 수신 트래픽을 처리하는 수신 게이트웨이를 검사합니다.

    예를 들어 빨간색 메시가 녹색 메시에 연결할 수 없는 경우 다음 로그를 확인합니다.

    • red-mesh-system의 Istiod-red-mesh
    • red-mesh-system의 egress-Green-mesh
    • green-mesh-system의 ingress-red-mesh

1.18.11. 연합된 메시에서 서비스 내보내기

서비스를 내보내면 메시에서 하나 이상의 해당 서비스를 연합 메시의 다른 멤버와 공유할 수 있습니다.

서비스 메시 통합 내보내기 서비스 설명

ExportedServiceSet 리소스를 사용하여 페더레이션 메시에서 다른 피어에 사용할 수 있도록 하는 하나의 메시에서 서비스를 선언합니다. 각 서비스를 피어와 공유할 수 있도록 명시적으로 선언해야 합니다.

  • 네임스페이스 또는 이름으로 서비스를 선택할 수 있습니다.
  • 와일드카드를 사용하여 서비스를 선택할 수 있습니다. 예를 들어 네임스페이스의 모든 서비스를 내보낼 수 있습니다.
  • 별칭을 사용하여 서비스를 내보낼 수 있습니다. 예를 들어 foo/bar 서비스를 custom-ns/bar 로 내보낼 수 있습니다.
  • 메시의 시스템 네임스페이스에 표시되는 서비스만 내보낼 수 있습니다. 예를 들어 networking.istio.io/exportTo 레이블이 '.'로 설정된 다른 네임스페이스의 서비스는 내보내기 후보가 아닙니다.
  • 내보낸 서비스의 경우 대상 서비스는 원래 요청자가 아닌 수신 게이트웨이의 트래픽만 확인합니다(즉, 다른 메시의 송신 게이트웨이 또는 워크로드 또는 요청 발생)의 클라이언트 ID를 볼 수 없습니다.

다음 예제는 red-meshgreen-mesh 로 내보내는 서비스의 예입니다.

ExportedServiceSet 리소스의 예

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  # export ratings.mesh-x-info as ratings.bookinfo
  - type: NameSelector
    nameSelector:
      namespace: red-mesh-info
      name: red-ratings
      alias:
        namespace: info
        name: ratings
  # export any service in red-mesh-info namespace with label export-service=true
  - type: LabelSelector
    labelSelector:
      namespace: red-mesh-info
      selector:
        matchLabels:
          export-service: "true"
      aliases: # export all matching services as if they were in the info namespace
      - namespace: "*"
        name: "*"
        alias:
          namespace: info

표 1.10. ExportedServiceSet 매개변수
매개변수설명
metadata:
  name:

이 서비스를 노출하는 ServiceMeshpeer의 이름입니다.

ServiceMeshPeer 리소스의 메시 이름 값과 일치해야 합니다.

metadata:
  namespace:

이 리소스를 포함하는 프로젝트/네임스페이스의 이름(슬래쉬의 시스템 네임스페이스여야 함) .

 
spec:
  exportRules:
  - type:

이 서비스의 내보내기를 관리할 규칙 유형입니다. 서비스에 대해 발견된 첫 번째 일치 규칙은 내보내기에 사용됩니다.

NameSelector, LabelSelector

spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace:
      name:

NameSelector 규칙을 만들려면 서비스의 네임스페이스Service 리소스에 정의된 서비스 이름을 지정합니다.

 
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      alias:
        namespace:
        name:

서비스에 대한 네임스페이스이름을 지정한 후 서비스의 별칭을 사용하는 NameSelector 규칙을 만들려면 네임스페이스 및 서비스 이름에 사용할 별칭을 지정합니다.

 
spec:
  exportRules:
  - type: LabelSelector
    labelSelector:
      namespace: <exportingMesh>
      selector:
        matchLabels:
          <labelKey>: <labelValue>

LabelSelector 규칙을 만들려면 서비스의 네임스페이스 를 지정하고 Service 리소스에 정의된 라벨 을 지정합니다. 위의 예에서 레이블은 export-service 입니다.

 
spec:
  exportRules:
  - type: LabelSelector
    labelSelector:
      namespace: <exportingMesh>
      selector:
        matchLabels:
          <labelKey>: <labelValue>
      aliases:
      - namespace:
        name:
        alias:
          namespace:
          name:

서비스에 별칭을 사용하는 LabelSelector 규칙을 만들려면 선택기 를 지정한 후 서비스의 이름 또는 네임스페이스에 사용할 별칭을 지정합니다. 위의 예에서 네임스페이스 별칭은 일치하는 모든 서비스에 대한 info 입니다.

 

red-mesh에 있는 모든 네임스페이스에서 blue-mesh로 이름이 "ratings"인 서비스를 내보냅니다.

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: blue-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace: "*"
      name: ratings

west-data-center 네임스페이스에서 green-mesh로 모든 서비스를 내보냅니다.

kind: ExportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: green-mesh
  namespace: red-mesh-system
spec:
  exportRules:
  - type: NameSelector
    nameSelector:
      namespace: west-data-center
      name: "*"

1.18.11.1. ExportedServiceSet 생성

메시 피어에 사용할 수 있는 서비스를 명시적으로 선언하기 위해 ExportedServiceSet 리소스를 생성합니다.

서비스는 <export-name>.<export-namespace>.svc.<ServiceMeshPeer.name>-exports.local 로 내보내지 고 대상 서비스로 자동으로 라우팅됩니다. 내보낸 서비스가 메시에서 알려진 이름입니다. 수신 게이트웨이가 이 이름으로 향하는 요청을 수신하면 내보낸 실제 서비스로 라우팅됩니다. 예를 들어, 이름이 ratings.red-mesh-info 라는 서비스가 ratings.bookinfo.bookinfo로 green-mesh -info로 내보낸 경우, 서비스는 이름 ratings.bookinfo.svc.green-mesh-exports.local 로 내보내지고 해당 호스트 이름에 대한 수신 게이트웨이에서 수신하는 트래픽은 ratings.red-mesh-bookinfo 서비스로 라우팅됩니다.

사전 요구 사항

  • 클러스터와 ServiceMeshControlPlane 은 메시 통합에 대해 구성되어 있습니다.
  • cluster-admin 역할이 있는 계정.
참고

아직 존재하지 않는 경우에도 내보내기를 위해 서비스를 구성할 수 있습니다. ExportedServiceSet에 지정된 값과 일치하는 서비스가 배포되면 자동으로 내보내집니다.

CLI의 프로세스

다음 절차에 따라 명령줄에서 ExportedServiceSet 을 만듭니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.

    $ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
  2. Service Mesh Control Plane을 설치한 프로젝트(예: red-mesh-system )로 변경합니다.

    $ oc project red-mesh-system
  3. red-mesh 가 서비스를 green-mesh 로 내보내는 다음 예제를 기반으로 ExportedServiceSet 파일을 만듭니다.

    red-mesh에서 green-mesh로 ExportedServiceSet 리소스의 예

    apiVersion: federation.maistra.io/v1
    kind: ExportedServiceSet
    metadata:
      name: green-mesh
      namespace: red-mesh-system
    spec:
      exportRules:
      - type: NameSelector
        nameSelector:
          namespace: red-mesh-info
          name: ratings
          alias:
            namespace: info
            name: red-ratings
      - type: NameSelector
        nameSelector:
          namespace: red-mesh-info
          name: reviews

  4. 다음 명령을 실행하여 red-mesh-system 네임스페이스에 ExportedServiceSet 리소스를 업로드하고 만듭니다.

    $ oc create -n <ControlPlaneNamespace> -f <ExportedServiceSet.yaml>

    예를 들어 다음과 같습니다.

    $ oc create -n red-mesh-system -f export-to-green-mesh.yaml
  5. 페더레이션 메시의 각 메시 피어에 필요한 추가 ExportedServiceSets 를 만듭니다.
  6. red-mesh 에서 내보낸 서비스를 검증하여 green-mesh 와 공유하려면 다음 명령을 실행합니다.

    $ oc get exportedserviceset <PeerMeshExportedTo> -o yaml

    예를 들어 다음과 같습니다.

    $ oc get exportedserviceset green-mesh -o yaml
  7. 다음 명령을 실행하여 green-mesh와 공유할 red-mesh 내보내기를 서비스의 유효성을 검사합니다.

    $ oc get exportedserviceset <PeerMeshExportedTo> -o yaml

    예를 들어 다음과 같습니다.

    $ oc -n red-mesh-system get exportedserviceset green-mesh -o yaml

    녹색 메시와 공유되는 빨간색 메시에서 내보낸 서비스의 유효성을 검사하는 예입니다.

      status:
        exportedServices:
        - exportedName: red-ratings.info.svc.green-mesh-exports.local
          localService:
            hostname: ratings.red-mesh-info.svc.cluster.local
            name: ratings
            namespace: red-mesh-info
        - exportedName: reviews.red-mesh-info.svc.green-mesh-exports.local
          localService:
            hostname: reviews.red-mesh-info.svc.cluster.local
            name: reviews
            namespace: red-mesh-info

    status.exportedServices 어레이는 현재 내보낸 서비스를 나열합니다(해당 서비스는 ExportedServiceSet 오브젝트의 내보내기 규칙과 일치함). 배열의 각 항목은 내보낸 서비스의 이름과 내보낸 로컬 서비스에 대한 세부 정보를 나타냅니다.

    내보낼 것으로 예상되는 서비스가 누락된 경우 Service 오브젝트가 있는지, 해당 이름 또는 레이블이 ExportedServiceSet 오브젝트에 정의된 exportRules 와 일치하고 Service 오브젝트의 네임스페이스가 ServiceMeshMemberRoll 또는 ServiceMeshMember 오브젝트를 사용하여 서비스 메시의 멤버로 구성되어 있는지 확인합니다.

1.18.12. 통합 메시로 서비스 가져오기

서비스를 가져오면 서비스 메시 내에서 다른 메시에서 내보낸 서비스를 명시적으로 지정할 수 있습니다.

서비스 메시 페더레이션 서비스 설명

ImportedServiceSet 리소스를 사용하여 가져올 서비스를 선택합니다. 메시 피어 및 명시적으로 가져온 서비스만 메시에서 사용할 수 있습니다. 명시적으로 가져오지 않은 서비스는 메시 내에서 사용할 수 없습니다.

  • 네임스페이스 또는 이름으로 서비스를 선택할 수 있습니다.
  • 예를 들어 와일드카드를 사용하여 서비스를 선택하여 네임스페이스로 내보낸 모든 서비스를 가져올 수 있습니다.
  • 메시에 글로벌할 수 있는 라벨 선택기를 사용하여 내보내기 서비스를 선택하거나 특정 멤버 네임스페이스로 범위를 지정할 수 있습니다.
  • 별칭을 사용하여 서비스를 가져올 수 있습니다. 예를 들어 custom-ns/bar 서비스를 other-mesh/bar 로 가져올 수 있습니다.
  • 정규화된 도메인 이름에 대해 가져온 서비스의 name.namespace 에 추가할 사용자 지정 도메인 접미사를 지정할 수 있습니다(예: bar.other-mesh.imported.local ).

다음 예제는 green-mesh 에서 red-mesh 에 의해 내보낸 서비스를 가져오는 데 사용됩니다.

ImportedServiceSet의 예

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh #name of mesh that exported the service
  namespace: green-mesh-system #mesh namespace that service is being imported into
spec:
  importRules: # first matching rule is used
  # import ratings.info as ratings.bookinfo
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: info
      name: ratings
      alias:
        # service will be imported as ratings.info.svc.red-mesh-imports.local
        namespace: info
        name: ratings

표 1.11. ImportedServiceSet 매개변수
매개변수설명
metadata:
  name:

연결된 메시에 서비스를 내보낸 ServiceMeshPeriod의 이름입니다.

 
metadata:
  namespace:

ServiceMeshpeer 리소스( mesh 시스템 네임스페이스)가 포함된 네임스페이스의 이름입니다.

 
spec:
  importRules:
  - type:

서비스의 가져오기를 제어하는 규칙 유형입니다. 서비스에 대해 발견된 첫 번째 일치 규칙이 가져오기에 사용됩니다.

NameSelector

spec:
  importRules:
  - type: NameSelector
    nameSelector:
      namespace:
      name:

NameSelector 규칙을 만들려면 네임스페이스 와 내보낸 서비스의 이름을 지정합니다.

 
spec:
  importRules:
  - type: NameSelector
    importAsLocal:

로컬 서비스를 사용하여 원격 엔드포인트를 집계하려면 true 로 설정합니다. true 인 경우 서비스는 < name>.<namespace>.svc.cluster.local로 가져옵니다.

true/false

spec:
  importRules:
  - type: NameSelector
    nameSelector:
      namespace:
      name:
      alias:
        namespace:
        name:

서비스에 대한 네임스페이스이름을 지정한 후 서비스의 별칭을 사용하는 NameSelector 규칙을 만들려면 네임스페이스 및 서비스 이름에 사용할 별칭을 지정합니다.

 

red-mesh에서 "info/ratings" 서비스를 blue-mesh로 가져옵니다.

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh
  namespace: blue-mesh-system
spec:
  importRules:
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: info
      name: ratings

red-mesh의 west-data-center 네임스페이스에서 green-mesh로 모든 서비스를 가져옵니다. 이러한 서비스는 <name>.west-data-center.svc.red-mesh-imports.local로 액세스할 수 있습니다.

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh
  namespace: green-mesh-system
spec:
  importRules:
  - type: NameSelector
    importAsLocal: false
    nameSelector:
      namespace: west-data-center
      name: "*"

1.18.12.1. ImportedServiceSet 생성

ImportedServiceSet 리소스를 생성하여 메시로 가져올 서비스를 명시적으로 선언합니다.

서비스는 이름이 <exported-name>. .<exported-namespace> svc.<ServiceMeshPeer.name>.remote 로 가져와서 송신 게이트웨이 네임스페이스 내에서만 표시되고 내보낸 서비스의 호스트 이름과 연결됩니다. 이 서비스는 importAsLocaltrue으로 설정되어 있는 경우(domainSuffixsvc.cluster.local인 경우)가 아니면 기본적으로 domainSuffixsvc.<ServiceMeshPeer.name>-imports.local<export-name>.<export-namespace>.<domainSuffix>로 로컬에서 사용할 수 있습니다. importAsLocalfalse 로 설정되면 가져오기 규칙의 도메인 접미사가 적용됩니다. 로컬 가져오기를 메시의 다른 서비스와 마찬가지로 처리할 수 있습니다. 내보낸 서비스의 원격 이름으로 리디렉션되는 송신 게이트웨이를 통해 자동으로 라우팅됩니다.

사전 요구 사항

  • 클러스터와 ServiceMeshControlPlane 은 메시 통합에 대해 구성되어 있습니다.
  • cluster-admin 역할이 있는 계정.
참고

아직 내보내지 않은 경우에도 가져오기 위해 서비스를 구성할 수 있습니다. ImportedServiceSet에 지정된 값과 일치하는 서비스가 배포되고 내보내면 자동으로 가져옵니다.

CLI의 프로세스

다음 절차에 따라 명령줄에서 ImportedServiceSet 을 생성합니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.

    $ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
  2. Service Mesh Control Plane을 설치한 프로젝트(예: green-mesh-system )로 변경합니다.

    $ oc project green-mesh-system
  3. 다음 예제를 기반으로 ImportedServiceSet 파일을 만듭니다. 여기서 green-mesh 가 이전에 red-mesh 에서 내보낸 서비스를 가져옵니다.

    red-mesh에서 green-mesh로 ImportedServiceSet 리소스의 예

    kind: ImportedServiceSet
    apiVersion: federation.maistra.io/v1
    metadata:
      name: red-mesh
      namespace: green-mesh-system
    spec:
      importRules:
      - type: NameSelector
        importAsLocal: false
        nameSelector:
          namespace: info
          name: red-ratings
          alias:
            namespace: info
            name: ratings

  4. 다음 명령을 실행하여 green-mesh-system 네임스페이스에 ImportedServiceSet 리소스를 업로드하고 만듭니다.

    $ oc create -n <ControlPlaneNamespace> -f <ImportedServiceSet.yaml>

    예를 들어 다음과 같습니다.

    $ oc create -n green-mesh-system -f import-from-red-mesh.yaml
  5. 페더레이션 메시의 각 메시 피어에 필요한 대로 추가로 ImportedServiceSet 리소스를 만듭니다.
  6. green-mesh 에 가져온 서비스를 확인하려면 다음 명령을 실행합니다.

    $ oc get importedserviceset <PeerMeshImportedInto> -o yaml

    예를 들어 다음과 같습니다.

    $ oc get importedserviceset green-mesh -o yaml
  7. 다음 명령을 실행하여 메시로 가져온 서비스의 유효성을 검사합니다.

    $ oc get importedserviceset <PeerMeshImportedInto> -o yaml

    예를 들어, 빨간색 메시에서 내보낸 서비스가 'green-mesh- system 네임스페이스에서 가져온serviceset/red-mesh' 오브젝트의 status 섹션을 사용하여 녹색 메시로 가져왔는지 확인합니다.

    $ oc -n green-mesh-system get importedserviceset/red-mesh -o yaml

    status:
      importedServices:
      - exportedName: red-ratings.info.svc.green-mesh-exports.local
        localService:
          hostname: ratings.info.svc.red-mesh-imports.local
          name: ratings
          namespace: info
      - exportedName: reviews.red-mesh-info.svc.green-mesh-exports.local
        localService:
          hostname: ""
          name: ""
          namespace: ""

    위 예제에서는 localService 아래에 있는 채워진 필드에 표시된 대로 ratings 서비스만 가져옵니다. reviews 서비스는 가져오기용으로 사용할 수 있지만 ImportedServiceSet 오브젝트의 importRules 와 일치하지 않기 때문에 현재 가져온 것은 아닙니다.

1.18.13. 장애 조치를 위한 페더레이션 메시 구성

장애 조치(failover)는 자동 및 원활하게 안정적인 백업 시스템(예: 다른 서버)으로 전환할 수 있습니다. 페더레이션 메시의 경우 다른 메시의 서비스에 장애 조치하도록 하나의 메시에서 서비스를 구성할 수 있습니다.

ImportedServiceSet 리소스에서 importAsLocallocality 설정을 설정한 다음 ImportedServiceSet 에 지정된 지역으로 서비스에 대한 장애 조치를 구성하는 DestinationRule 을 구성하여 페일오버를 구성합니다.

사전 요구 사항

  • 두 개 이상의 OpenShift Container Platform 4.6 이상의 클러스터가 이미 네트워크 연결 및 통합되었습니다.
  • 페더레이션 메시의 각 메시 피어에 대해 이미 생성된 ExportedServiceSet 리소스입니다.
  • 통합 메시의 각 메시 피어에 대해 이미 ImportedServiceSet 리소스가 생성되었습니다.
  • cluster-admin 역할이 있는 계정.

1.18.13.1. 장애 조치(failover)를 위해 ImportedServiceSet 구성

관리자는 현지화된 부하 분산을 통해 트래픽이 시작된 위치와 종료될 위치를 기준으로 엔드포인트의 트래픽 배포를 제어할 수 있습니다. 이러한 지역에는 {region}/{zone}/{sub-zone} 형식의 지역 계층을 지정하는 임의의 레이블을 사용하여 지정됩니다.

이 섹션의 예제에서 green-meshus-east 지역에 있으며 red-meshus-west 지역에 있습니다.

red-mesh에서 green-mesh로 ImportedServiceSet 리소스의 예

kind: ImportedServiceSet
apiVersion: federation.maistra.io/v1
metadata:
  name: red-mesh #name of mesh that exported the service
  namespace: green-mesh-system #mesh namespace that service is being imported into
spec:
  importRules: # first matching rule is used
  # import ratings.info as ratings.bookinfo
  - type: NameSelector
    importAsLocal: true
    nameSelector:
      namespace: info
      name: ratings
      alias:
        # service will be imported as ratings.info.svc.red-mesh-imports.local
        namespace: info
        name: ratings
  #Locality within which imported services should be associated.
  locality:
    region: us-west

표 1.12. ImportedServiceLocality 필드 테이블
이름설명유형

지역:

가져온 서비스가 있는 리전입니다.

string

서브 존:

가져온 서비스가 있는 하위 영역입니다. I Subzone은 지정되며 영역도 지정해야 합니다.

string

영역:

가져온 서비스가 있는 영역입니다. Zone을 지정하는 경우 지역도 지정해야 합니다.

string

절차

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인하고 다음 명령을 입력합니다.

    $ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
  2. Service Mesh Control Plane을 설치한 프로젝트로 변경하고 다음 명령을 입력합니다.

    $ oc project <smcp-system>

    예를 들면 green-mesh-system 입니다.

    $ oc project green-mesh-system
  3. ImportedServiceSet 파일을 편집합니다. 여기서 < ImportedServiceSet.yaml >에는 편집하려는 파일에 대한 전체 경로가 포함되어 있으며 다음 명령을 입력합니다.

    $ oc edit -n <smcp-system> -f <ImportedServiceSet.yaml>

    예를 들어 이전 ImportedServiceSet 예제에 표시된 대로 빨간색-mesh-system에서 green-mesh-system으로 가져오는 파일을 수정하려면 다음을 수행합니다.

    $ oc edit -n green-mesh-system -f import-from-red-mesh.yaml
  4. 파일을 수정합니다.

    1. spec.importRules.importAsLocaltrue 로 설정합니다.
    2. spec.locality 를 지역 , 영역 또는 하위 영역으로 설정합니다.
    3. 변경 사항을 저장하십시오.

1.18.13.2. 장애 조치(failover)를 위해 DestinationRule 구성

다음을 구성하는 DestinationRule 리소스를 만듭니다.

  • 서비스에 대한 이상값 탐지입니다. 장애 조치가 제대로 작동하려면 이 작업이 필요합니다. 특히, 서비스 엔드포인트가 비정상인 시기를 확인하도록 사이드카 프록시를 구성하여 결국 다음 로컬에 장애 조치를 트리거합니다.
  • 리전 간 페일오버 정책. 이렇게 하면 영역 경계 이외의 장애 조치(failover)가 예측될 수 있습니다.This ensures that failover beyond a region boundary will behave predictably.

절차

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.

    $ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
  2. Service Mesh Control Plane을 설치한 프로젝트로 변경합니다.

    $ oc project <smcp-system>

    예를 들면 green-mesh-system 입니다.

    $ oc project green-mesh-system
  3. green-mesh가 사용할 수 없는 다음 예제를 기반으로 DestinationRule 파일을 만듭니다. 이 파일은 us-east 리전의 green-mesh에서 us-west 으로 트래픽을 라우팅해야 합니다.

    DestinationRule

    apiVersion: networking.istio.io/v1beta1
    kind: DestinationRule
    metadata:
      name: default-failover
      namespace: info
    spec:
      host: "ratings.info.svc.cluster.local"
      trafficPolicy:
        loadBalancer:
          localityLbSetting:
            enabled: true
            failover:
              - from: us-east
                to: us-west
        outlierDetection:
          consecutive5xxErrors: 3
          interval: 10s
          baseEjectionTime: 1m

  4. DestinationRule 을 배포합니다. 여기서 < DestinationRule >에는 파일의 전체 경로가 포함되어 다음 명령을 입력합니다.

    $ oc create -n <application namespace> -f <DestinationRule.yaml>

    예를 들어 다음과 같습니다.

    $ oc create -n info -f green-mesh-us-west-DestinationRule.yaml

1.18.14. 연합 메시에서 서비스 제거

연합 메시에서 서비스를 제거해야 하는 경우(예: 사용되지 않거나 다른 서비스로 교체된 경우).

1.18.14.1. 단일 메시에서 서비스를 제거하려면 다음을 수행합니다.

더 이상 서비스에 액세스할 필요가 없는 메시 피어의 ImportedServiceSet 리소스에서 서비스 항목을 제거합니다.

1.18.14.2. 전체 연합 메시에서 서비스를 제거하려면

서비스를 소유한 메시의 ExportedServiceSet 리소스에서 서비스 항목을 제거합니다.

1.18.15. 연합된 메시에서 메시 제거

페더레이션에서 메시를 제거해야 하는 경우 그렇게 할 수 있습니다.

  1. 삭제된 메시의 ServiceMeshControlPlane 리소스를 편집하여 피어 메시에 대한 모든 연합 수신 게이트웨이를 제거합니다.
  2. 제거된 메시가 연결된 각 메시 피어에 대해:

    1. 두 메시를 연결하는 ServiceMesh peer 리소스를 제거합니다.
    2. 피어 메시의 ServiceMeshControlPlane 리소스를 편집하여 제거된 메시를 제공하는 송신 게이트웨이를 제거합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.