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.10. 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 이름: <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