지원콘솔개발자평가판 시작연락처

2.20. 서비스 메시 연결

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

2.20.1. 페더레이션 개요

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

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

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

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

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

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

2.20.2. 페더레이션 기능

메시를 결합하는 Red Hat OpenShift Service Mesh 페더레이션 접근 방식의 기능은 다음과 같습니다.

  • 각 메시에 대한 공통 루트 인증서를 지원합니다.
  • 각 메시에 대해 서로 다른 루트 인증서를 지원합니다.
  • 메시 관리자는 Federated 메시 외부의 메시에 대해 인증서 체인, 서비스 검색 끝점, 신뢰 도메인 등을 수동으로 구성해야 합니다.

  • 메시 간에 공유할 서비스만 내보내거나 가져옵니다.

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

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

  • 페더레이션 메시에 대한 신뢰 세부 정보를 자체적으로 제공합니다.
  • 페더레이션 메시에 대한 신뢰 세부 정보를 확인합니다.
  • 자체 내보낸 서비스에 대한 정보를 페더레이션 메시에 제공합니다.
  • 페더레이션 메시가 내보낸 서비스에 대한 정보를 검색합니다.

2.20.3. 페더레이션 보안

Red Hat OpenShift Service Mesh 페더레이션은 메시 간 신뢰가 최소화된다고 가정하는 서비스 메시의 다중 클러스터 구현에 대해 의견을 내포하고 있습니다. 데이터 보안은 페더레이션 기능의 일부로 구축됩니다.

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

2.20.4. 페더레이션 제한

메시에 대한 Red Hat OpenShift Service Mesh 페더레이션 접근 방식에는 다음과 같은 제한 사항이 있습니다.

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

2.20.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로 구성됩니다.
  • 다른 메시에 노출하려는 서비스는 내보내기 및 가져오기 전에 배포해야 합니다. 그러나 이는 엄격한 요구 사항은 아닙니다. 내보내기/가져오기 위해 아직 존재하지 않는 서비스 이름을 지정할 수 있습니다. ExportedServiceSet 및 ImportedServiceSet 에 라는 서비스를 배포하면 내보내기/가져오기에서 자동으로 사용할 수 있습니다.

2.20.6. 메시 페더레이션 계획

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

  • 얼마나 많은 메시가 페더레이션에 참여할 계획입니까? 제한된 수의 메시로, 2개 또는 세 개로 시작하려고 할 수 있습니다.

  • 각 메시에 사용할 이름 지정 규칙은 무엇입니까? 사전 정의된 이름 지정 규칙을 사용하면 구성 및 문제 해결에 도움이 됩니다. 이 문서의 예제에서는 각 메시에 대해 다른 색상을 사용합니다. 각 메시를 소유하고 관리하는 데 도움이 되는 이름 지정 규칙과 다음 페더레이션 리소스를 결정해야 합니다.

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

    • 보안 신뢰 도메인

      참고

      페더레이션의 각 메시는 고유한 신뢰 도메인을 보유해야 합니다.

  • 각 메시에서 페더레이션 메시로 내보낼 계획입니까? 각 서비스는 개별적으로 내보내거나 라벨을 지정하거나 와일드카드를 사용할 수 있습니다.

    • 서비스 네임스페이스에 별칭을 사용하시겠습니까?
    • 내보낸 서비스에 별칭을 사용하시겠습니까?

  • 각 메시에서 가져올 내보낸 서비스는 무엇입니까? 각 메시는 필요한 서비스만 가져옵니다.

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

2.20.7. 클러스터 전체에 메시 페더레이션

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

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

2.20.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 필드에 서비스의 노드 포트를 지정합니다.

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

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

클러스터에서 LoadBalancer 서비스를 지원하지 않는 경우, 다른 메시를 실행하는 클러스터에서 노드에 액세스할 수 있는 경우 NodePort 서비스를 사용하는 것이 옵션일 수 있습니다. ServiceMeshPeer 오브젝트에서 .spec.remote.addresses 필드에 있는 노드의 IP 주소와 .spec.remote.discoveryPort 및 .spec.remote.servicePort 필드에 서비스의 노드 포트를 지정합니다.

2.20.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 필드 중 하나로 지정해야 합니다.

2.20.7.4. Azure에 페더레이션 수신 노출

Microsoft Azure에서 메시 페더레이션이 올바르게 작동하는 데 필요한 서비스 유형을 LoadBalancer 로 설정하기만 하면 됩니다.

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

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

Google Cloud Platform에서 메시 페더레이션이 올바르게 작동하는 데 필요한 서비스 유형을 LoadBalancer 로 설정하기만 하면 됩니다.

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

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

서비스 메시를 플러시하려면 다음과 같은 활동이 포함됩니다.

  • 통합할 클러스터 간에 네트워킹을 구성합니다.

    • 원시 TLS 트래픽을 지원하도록 페더레이션 게이트웨이와 관련된 서비스를 지원하는 로드 밸런서를 구성합니다.
  • 각 클러스터에 Red Hat OpenShift Service Mesh 버전 2.1 이상 Operator를 설치합니다.
  • 버전 2.1 이상 ServiceMeshControlPlane 을 각 클러스터에 배포합니다.

  • 통합할 각 메시에 대해 SMCP를 구성합니다.

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

2.20.9. 페더레이션을 위한 Service Mesh Control Plane 구성

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

다음 예에서 red-mesh 관리자는 green-mesh 및 blue-mesh를 둘 다 사용하여 페더레이션에 대해 SMCP를 구성하고 있습니다.

red-mesh용 샘플 SMCP

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  version: v2.6
  runtime:
    defaults:
      container:
        imagePullPolicy: Always
  gateways:
    additionalEgress:
      egress-green-mesh:
        enabled: true
        requestedNetworkView:
        - green-network
        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
        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
        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
        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

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

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

문자열

해당 없음 

spec:
  cluster:
    network:

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

문자열

해당 없음

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

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

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

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

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

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

  
spec:
  gateways:
    additionalEgress:
      <egress_name>:
        enabled:

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

true/false

true 

spec:
  gateways:
    additionalEgress:
      <egress_name>:
        requestedNetworkView:

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

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

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

페더레이션 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 못하도록 게이트웨이의 고유한 레이블을 지정합니다.

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

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

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

 
spec:
  gateways:
    additionalIngress:

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

  
spec:
  gateways:
    additionalIgress:
      <ingress_name>:
        enabled:

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

true/false

true 

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

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

LoadBalancer

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

클러스터에서 LoadBalancer 서비스를 지원하지 않는 경우 NodePort 서비스를 통해 수신 게이트웨이 서비스를 노출할 수 있습니다.

NodePort

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

페더레이션 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 못하도록 게이트웨이의 고유한 레이블을 지정합니다.

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

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

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

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

클러스터에서 LoadBalancer 서비스를 지원하지 않는 경우 nodePort: 를 지정하는 데 사용됩니다.

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

 

다음 예에서 관리자는 NodePort 서비스를 사용하여 green-mesh 로 페더레이션을 위해 SMCP를 구성하고 있습니다.

NodePort용 샘플 SMCP

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: green-mesh
  namespace: green-mesh-system
spec:
# ...
  gateways:
     additionalIngress:
      ingress-green-mesh:
        enabled: true
        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

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

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

kind: ServiceMeshControlPlane
metadata:
  name: red-mesh
  namespace: red-mesh-system
spec:
  security:
    trust:
      domain: red-mesh.local
표 2.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. 다음 명령을 실행하여 red-mesh-system 이 시스템 네임스페이스이고 red-mesh 가 ServiceMeshControlPlane 오브젝트의 이름입니다. 

    $ oc edit -n red-mesh-system smcp red-mesh

  5. 다음 명령을 입력합니다. 여기서 red-mesh-system 은 시스템 네임스페이스로 서비스 메시 컨트롤 플레인 설치 상태를 확인합니다. 

    $ oc get smcp -n red-mesh-system

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

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

2.20.10. 페더레이션 메시 결합

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

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

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

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

red, blue, green 이라는 세 개의 메시를 페더레이션하려면 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

표 2.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

2.20.10.1. ServiceMeshPeer 리소스 생성

사전 요구 사항

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

CLI의 프로세스

명령줄에서 ServiceMeshPeer 리소스를 생성하려면 다음 절차를 따르십시오. 이 예에서는 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 to 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에 연결되어 있음을 보여줍니다.

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

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

    두 메시 간의 연결이 설정되지 않은 경우 ServiceMeshPeer 상태는 status.discoveryStatus.inactive 필드에 이를 나타냅니다.

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

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

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

2.20.11. 페더레이션 메시에서 서비스 내보내기

서비스 내보내기를 통해 메시는 하나 이상의 서비스를 페더레이션 메시의 다른 멤버와 공유할 수 있습니다.

서비스 메시 페더레이션에서 서비스 예시

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

  • 네임스페이스 또는 이름별로 서비스를 선택할 수 있습니다.
  • 와일드카드를 사용하여 서비스를 선택할 수 있습니다(예: 네임스페이스의 모든 서비스를 내보내려면).
  • 별칭을 사용하여 서비스를 내보낼 수 있습니다. 예를 들어 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

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

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

ServiceMeshPeer 리소스에서 메시의 name 값과 일치해야 합니다. 

metadata:
  namespace:

이 리소스가 포함된 프로젝트/네임스페이스의 이름(메쉬의 시스템 네임스페이스여야 함)

 
spec:
  exportRules:
  - type:

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

NameSelector, LabelSelector 

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

NameSelector 규칙을 생성하려면 Service 리소스에 정의된 대로 서비스의 namespace 와 서비스 name을 지정합니다.

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

서비스에 대한 별칭을 사용하는 NameSelector 규칙을 생성하려면 서비스에 대한 namespace 와 name을 지정한 후 namespace 의 별칭과 서비스 name에 사용할 별칭을 지정합니다.

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

LabelSelector 규칙을 생성하려면 서비스의 namespace를 지정하고 Service 리소스에 정의된 label 을 지정합니다. 위의 예에서 레이블은 export-service 입니다.

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

서비스에 대한 별칭을 사용하는 LabelSelector 규칙을 생성하려면 selector를 지정한 후 서비스의 name 또는 namespace에 사용할 별칭을 지정합니다. 위의 예에서 네임스페이스 별칭은 일치하는 모든 서비스에 대한 info 입니다.

 

이름이 "ratings"인 서비스를 빨간색-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: "*"

2.20.11.1. ExportedServiceSet 생성

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

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

참고

로컬 서비스와 함께 원격 끝점을 집계하려면 importAsLocal 매개변수를 true 로 설정하면 서비스에 대한 별칭을 사용해야 합니다. 매개변수를 false 로 설정하면 별칭이 필요하지 않습니다.

사전 요구 사항

  • 메시 페더레이션을 위해 클러스터 및 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 를 생성합니다.

검증

  • 다음 명령을 실행하여 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 오브젝트를 사용하여 서비스 메시의 멤버로 구성되어 있는지 확인합니다.

2.20.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

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

서비스를 페더레이션 메시로 내보낸 ServiceMeshPeer의 이름입니다.

 
metadata:
  namespace:

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

 
spec:
  importRules:
  - type:

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

NameSelector 

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

NameSelector 규칙을 생성하려면 내보낸 서비스의 namespace 와 name을 지정합니다.

 
spec:
  importRules:
  - type: NameSelector
    importAsLocal:

로컬 서비스와 함께 원격 끝점을 집계하려면 true 로 설정합니다. true 서비스를 < name>.<namespace>.svc.cluster.local 로 가져오는 경우 true 인 경우 별칭이 필요합니다. false 인 경우 별칭이 필요하지 않습니다.

true/false 

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

서비스에 대한 별칭을 사용하는 NameSelector 규칙을 생성하려면 서비스에 대한 namespace 와 name을 지정한 후 namespace 의 별칭과 서비스 name에 사용할 별칭을 지정합니다.

 

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

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: "*"

2.20.12.1. ImportedServiceSet 생성

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

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

사전 요구 사항

  • 메시 페더레이션을 위해 클러스터 및 ServiceMeshControlPlane 이 구성되어 있습니다.
  • cluster-admin 역할이 있는 계정.
참고

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

프로세스

명령줄에서 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. green-mesh 가 이전에 red-mesh 에서 내보낸 서비스를 가져오는 다음 예제를 기반으로 ImportedServiceSet 파일을 만듭니다.

    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 리소스를 생성합니다.

검증

  • 다음 명령을 실행하여 서비스가 green-mesh 로 가져왔는지 확인합니다. 

    $ 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 와 일치하지 않기 때문에 현재 가져온 것은 아닙니다.

2.20.13. 페일오버를 위한 페더레이션 메시 구성

장애 조치(failover)는 다른 서버와 같이 자동으로 원활하게 안정적인 백업 시스템으로 전환할 수 있는 기능입니다. 페더레이션 메시의 경우 한 메시에서 서비스를 구성하여 다른 메시의 서비스로 페일오버할 수 있습니다.

ImportAsLocal 및 locality 설정을 ImportedServiceSet 리소스에서 설정한 다음 ImportedServiceSet 에 지정된 지역으로 서비스에 대한 장애 조치를 구성하는 DestinationRule 을 구성하여 장애 조치(failover)를 구성합니다.

사전 요구 사항

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

2.20.13.1. 페일오버를 위한 ImportedServiceSet 구성

로컬리티 가중치 로드 밸런싱을 사용하면 관리자가 트래픽이 시작되는 위치와 트래픽이 종료되는 위치를 기반으로 엔드포인트에 대한 트래픽 배포를 제어할 수 있습니다. 이러한 현지 위치는 {region}/{zone}/{sub-zone} 양식에서 현지인 계층 구조를 지정하는 임의의 레이블을 사용하여 지정됩니다.

이 섹션의 예제에서 green-mesh 는 us-east 리전에 있으며 빨간색-mesh 는 us-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

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

region:

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

string

하위 영역:

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

string

zone:

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

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 예제와 같이 red-mesh-system에서 green-mesh-system으로 가져오는 파일을 수정하려면 다음을 수행합니다. 

    $ oc edit -n green-mesh-system -f import-from-red-mesh.yaml

  4. 파일을 수정합니다.

    1. spec.importRules.importAsLocal 를 true 로 설정합니다.
    2. spec.locality 를 region,zone 또는 subzone으로 설정합니다.
    3. 변경 사항을 저장하십시오.

2.20.13.2. 페일오버를 위한 DestinationRule 구성

다음을 구성하는 DestinationRule 리소스를 생성합니다.

  • 서비스에 대한 outlier 탐지 장애 조치(failover)가 제대로 작동하려면 이 작업이 필요합니다. 특히 서비스 엔드 포인트가 비정상인 시기를 알 수 있도록 사이드카 프록시를 구성하여 결국 다음 위치로 장애 조치(failover)를 트리거합니다.
  • 지역 간 페일오버 정책. 이렇게 하면 영역 경계를 넘어 장애 조치(failover)가 예측 가능한 방식으로 작동합니다.

프로세스

  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를 사용할 수 없는 경우 us-east 리전의 green-mesh에서 us-west 의 빨간색-mesh로 트래픽을 라우팅해야 하는 다음 예제를 기반으로 DestinationRule 파일을 만듭니다.

    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

2.20.14. 페더레이션 메시에서 서비스 제거

페더레이션 메시에서 서비스를 제거해야하는 경우, 예를 들어 사용되지 않거나 다른 서비스로 교체된 경우 그렇게 할 수 있습니다.

2.20.14.1. 단일 메시에서 서비스 제거

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

2.20.14.2. 전체 페더레이션 메시에서 서비스 제거

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

2.20.15. 페더레이션 메시에서 메시 제거

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

  1. 제거된 메시의 ServiceMeshControlPlane 리소스를 편집하여 피어 메시의 모든 페더레이션 수신 게이트웨이를 제거합니다.

  2. 제거된 메시가 다음과 연계된 각 메시 피어에 대해 다음을 수행합니다.

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.