1.18. 서비스 메시 연결

Federation 은 별도의 관리 도메인에서 관리되는 개별 메시 간에 서비스와 워크로드를 공유할 수 있는 배포 모델입니다.

1.18.1. 페더레이션 개요

Federation은 별도의 메시 간에 서비스를 연결할 수 있는 기능 세트로, 여러 개의 개별 관리 도메인에서 인증, 권한 부여 및 트래픽 관리와 같은 서비스 메시 기능을 사용할 수 있습니다.

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

서비스 메시 페더레이션은 각 메시가 개별적으로 관리되고 자체 관리자를 유지한다고 가정합니다. 기본 동작은 통신이 허용되지 않으며 메시 간에 정보를 공유하지 않는다는 것입니다. 메시 간 정보 공유는 명시적인 옵트인 기반으로 합니다. 공유하도록 구성되지 않은 한, 페더레이션 메시에서 공유되지는 않습니다. 인증서 생성, 지표 및 추적 컬렉션과 같은 지원 기능은 해당 메시에서 로컬로 유지됩니다.

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

페더레이션에는 추가 페더레이션 파일 생성도 포함됩니다. 다음 리소스는 두 개 이상의 메시 간에 통합을 구성하는 데 사용됩니다.

  • ServiceMeshPeer 리소스는 서비스 메시 쌍 간 통합을 선언합니다.
  • ExportedServiceSet 리소스는 메시의 하나 이상의 서비스를 피어 메시에서 사용할 수 있다고 선언합니다.
  • ImportedServiceSet 리소스는 피어 메시에서 내보낸 서비스를 메시로 선언합니다.

1.18.2. 페더레이션 기능

메시 결합에 대한 Red Hat OpenShift Service Mesh 페더레이션 접근법의 기능은 다음과 같습니다.

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

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

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

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

1.18.3. 페더레이션 보안

Red Hat OpenShift Service Mesh 페더레이션은 메시 간에 최소의 신뢰성을 가정하는 서비스 메시의 다중 클러스터 구현에 관심이 있는 접근 방식을 취합니다. 데이터 보안은 페더레이션 기능의 일부로 에 빌드됩니다.

  • 각 메시는 고유 관리가 있는 고유한 테넌트로 간주됩니다.
  • 페더레이션에서 각 메시의 고유한 신뢰 도메인을 생성합니다.
  • 연결된 메시 간 트래픽은 mTLS(상호 전송 계층 보안)를 사용하여 자동으로 암호화됩니다.
  • 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 트래픽을 지원하려면 페더레이션 게이트웨이와 연결된 서비스를 지원하는 로드 밸런서를 구성해야 합니다. 페더레이션 트래픽은 검색용 HTTPS와 서비스 트래픽에 대해 원시 암호화된 TCP로 구성됩니다.
  • 다른 메시에 노출하려는 서비스는 내보내고 가져올 수 있어야 합니다. 그러나 이는 엄격한 요구 사항이 아닙니다. 내보내기/가져오기용으로 아직 존재하지 않는 서비스 이름을 지정할 수 있습니다. ExportedServiceSet 및 Imported ServiceSet 에 이름이 지정된 서비스를 배포하면 내보내기/가져오기에서 자동으로 사용할 수 있습니다.

1.18.6. 메시 페더레이션 계획

메시 페더레이션 구성을 시작하기 전에 구현을 계획하는 데 시간이 걸릴 수 있습니다.

  • 페더레이션에 참가할 계획인 메시 수는 몇 개입니까? 제한된 수의 메시, 즉 2~3개로 시작하는 것이 좋습니다.
  • 각 메시에 어떤 명명 규칙을 사용하시겠습니까? 사전 정의된 명명 규칙을 사용하면 구성 및 문제 해결에 도움이 됩니다. 이 문서의 예제에서는 각 메시에 대해 서로 다른 컬러를 사용합니다. 다음 페더레이션 리소스뿐만 아니라 각 메시를 소유하고 관리하는 데 도움이 되는 명명 규칙을 결정해야 합니다.

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

      참고

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

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

    • 서비스 네임스페이스에 별칭을 사용하시겠습니까?
    • 내보낸 서비스에 대해 별칭을 사용하시겠습니까?
  • 각 메시를 가져올 내보낸 서비스는 무엇입니까? 각 메시는 필요한 서비스만 가져옵니다.

    • 가져온 서비스에 별칭을 사용하시겠습니까?

1.18.7. 클러스터의 메시 페더레이션

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

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

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

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

클러스터가 LoadBalancer 서비스를 지원하지 않는 경우 다른 메시를 실행하는 클러스터에서 노드에 액세스할 수 있는 경우 NodePort 서비스를 사용하는 옵션이 될 수 있습니다. ServiceMeshPeer 오브젝트에서.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 서비스를 사용하는 옵션이 될 수 있습니다. ServiceMeshPeer 오브젝트에서.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

수신 게이트웨이 Service 오브젝트의 .status.loadBalancer.ingress.hostname 필드에 있는 전체 도메인 이름은 ServiceMeshPeer 오브젝트의 .spec.remote.addresses 필드에 있는 항목 중 하나로 지정해야 합니다.

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

Microsoft Azure에서 메시 페더레이션이 올바르게 작동하도록 서비스 유형을 LoadBalancer 접미사로만 설정하면 됩니다.

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

1.18.7.5. GCP(Google Cloud Platform)에서 페더레이션 인그레스 노출

Google 클라우드 플랫폼에서는 서비스 유형을 LoadBalancer 접미사로만 설정하여 메시 페더레이션이 올바르게 작동합니다.

수신 게이트웨이 Service 오브젝트의 .status.loadBalancer.ingress.ip 필드에 있는 IP 주소는 ServiceMeshPeer 오브젝트의 .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.
  • ❏ 각 메시 쌍에 ServiceMeshPeer 리소스를 생성하여 두 개 이상의 메시를 통합합니다.
  • 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.3
  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. 페더레이션 게이트웨이 이해

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

수신 및 송신 게이트웨이를 사용하여 서비스 메시(북-남 트래픽)로 들어오고 나가는 트래픽을 관리합니다. 페더레이션 메시를 만들 때 추가 수신/ 송신 게이트웨이를 생성하여 페더레이션 메시 간 서비스 검색, 페더레이션 메시 간 통신 및 서비스 메시 간 트래픽(동-서 트래픽)을 관리합니다.

메시 간 이름 지정 충돌을 방지하려면 각 메시에 대해 별도의 송신 및 수신 게이트웨이를 생성해야 합니다. 예를 들어 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를 사용합니다. 예를 들어 해당 메시의 ServiceMeshPeer 리소스의 이름이 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:

포트(및 이름 ): 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:

포트(및 이름 ): 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 리소스는 두 메시 간 통합을 정의하고, 이를 사용하여 피어 메시에 대한 검색, 피어 메시 액세스 및 다른 메시의 클라이언트의 유효성을 검사하는 데 사용되는 인증서를 구성합니다.

서비스 메시 페더레이션 메시 피어 그림

메시는 일대일 기준으로 통합되므로 각 피어 쌍에는 다른 서비스 메시에 대한 페더 연결을 지정하는 ServiceMeshPeer 리소스 쌍이 필요합니다. 예를 들어 빨간색과 녹색 이라는 두 개의 메시를 연결하려면 두 개의 ServiceMeshPeer 파일이 필요합니다.

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

빨간색,파란색, 녹색 이라는 세 개의 메시를 통합하려면 6개의 ServiceMeshPeer 파일이 필요합니다.

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

ServiceMeshPeer 리소스의 구성에는 다음이 포함됩니다.

  • 검색 및 서비스 요청에 사용되는 다른 메시의 수신 게이트웨이 주소입니다.
  • 지정된 피어 메시와의 상호 작용에 사용되는 로컬 수신 및 송신 게이트웨이의 이름입니다.
  • 이 메시에 요청을 보낼 때 다른 메시에서 사용하는 클라이언트 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. ServiceMeshPeer 구성 매개변수

매개변수설명
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 name: <peerMesh>-ca-root-cert

1.18.10.1. ServiceMeshPeer 리소스 생성

사전 요구 사항

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

CLI의 프로세스

다음 절차에 따라 명령줄에서 ServiceMeshPeer 리소스를 생성합니다. 이 예에서는 red-mesh가 green-mesh 에 대한 피어 리소스를 생성하는 red -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. 통합하려는 두 메시에 대해 다음 예제를 기반으로 ServiceMeshPeer 파일을 생성합니다.

    red-mesh에서 green-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

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

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

    $ 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(이 예에서 빨간색 메시)의 istiod에 연결되어 있음을 보여줍니다.

    status.discoveryStatus.active.watch 필드는 현재 메시의 istiod가 피어 메시의 istiod에 연결되어 있음을 보여줍니다.

    green- mesh-system에서 red-mesh- system이라는 servicemesh peer 를 확인하는 경우 녹색 메시의 관점에서 동일한 두 연결에 대한 정보를 확인할 수 있습니다.

    두 메시 간의 연결이 설정되지 않은 경우 ServiceMeshPeer 상태는 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. 연결된 메시에서 서비스 내보내기

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

서비스 메시 페더레이션 내보내기 서비스 그림

Exported ServiceSet 리소스를 사용하여 연결된 메시의 다른 피어에 사용할 수 있는 메시의 서비스를 선언합니다. 피어와 공유할 각 서비스를 명시적으로 선언해야 합니다.

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

다음 예제는 red-mesh가 green-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 리소스의 메시의 name 값과 일치해야 합니다.

metadata:
  namespace:

이 리소스를 포함하는 프로젝트/네임스페이스 이름(메서드의 시스템 네임스페이스여야 함)입니다.

 
spec:
  exportRules:
  - type:

이 서비스의 내보내기를 제어하는 규칙 유형입니다. 서비스에 대해 첫 번째로 일치하는 규칙이 내보내기에 사용됩니다.

NameSelector, LabelSelector

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

NameSelector 규칙을 생성하려면 서비스 리소스에 정의된 대로 서비스의 네임스페이스 와 서비스 이름을 지정합니다.

 
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 입니다.

 

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

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 생성

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

서비스는 <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. 다음 명령을 실행하여 red-mesh 내보내기를 사용하여 green-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 배열에는 현재 내보낸 서비스가 나열됩니다(이러한 서비스는 Exported ServiceSet 오브젝트의 내보내기규칙과 일치함). 배열의 각 항목은 내보낸 서비스의 이름과 내보낸 로컬 서비스에 대한 세부 정보를 나타냅니다.

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

1.18.12. 페더레이션 메시로 서비스 가져오기

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

서비스 메시 페더레이션 가져오기 서비스 그림

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

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

다음 예는 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: 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:

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

 
metadata:
  namespace:

ServiceMeshPeer 리소스(메서드 시스템 네임스페이스)가 포함된 네임스페이스의 이름입니다.

 
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 로 가져옵니다. 이 서비스는 송신 게이트웨이 네임스페이스 내에만 표시되며 내보낸 서비스의 호스트 이름과 연결됩니다. 서비스는 <export-name>.<export-namespace>.<domainSuffix> 로 로컬에서 사용할 수 있습니다. 여기서 domainSuffix 는 기본적으로 svc.<ServiceMeshPeer.name>-imports.local 입니다. importAsLocaltrue 로 설정하지 않는 한 domainSuffixsvc.cluster.local 입니다. 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. 가져온 서비스를 녹색 메시로 확인하려면 다음 명령을 실행합니다.

    $ oc get importedserviceset <PeerMeshImportedInto> -o yaml

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

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

    $ oc get importedserviceset <PeerMeshImportedInto> -o yaml

    'green-mesh-system 네임스페이스에서 importserviceset/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 서비스만 가져옵니다. Review 서비스는 가져오기에 사용할 수 있지만 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. 두 메시를 연결하는 ServiceMeshPeer 리소스를 제거합니다.
    2. 피어 메시의 ServiceMeshControlPlane 리소스를 편집하여 제거된 메시를 제공하는 송신 게이트웨이를 제거합니다.