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에 대해 아직 존재하지 않는 서비스 이름을 지정할 수 있습니다.
ExportedServiceSet
및ImportedServiceSet
에서 이름이 지정된 서비스를 배포하면 내보내기/가져오기에 자동으로 사용할 수 있습니다.
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-mesh
및 blue-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
매개변수 | 설명 | 값 | 기본값 |
---|---|---|---|
spec: cluster: name: | 클러스터의 이름입니다. 클러스터 이름을 지정할 필요는 없지만 문제 해결에 유용합니다. | 문자열 | 해당 없음 |
spec: cluster: network: | 클러스터 네트워크의 이름입니다. 네트워크 이름을 지정할 필요는 없지만 구성 및 문제 해결에 유용합니다. | 문자열 | 해당 없음 |
1.18.9.1. 페더레이션 게이트웨이 이해
게이트웨이를 사용하여 메시에 대한 인바운드 및 아웃바운드 트래픽을 관리하여 메시에 들어가거나 나가려는 트래픽을 지정할 수 있습니다.
수신 및 송신 게이트웨이를 사용하여 서비스 메시(North-South 트래픽)를 입력하고 나가는 트래픽을 관리합니다. 연합 메시를 생성할 때 추가적인 수신/egress 게이트웨이를 생성하여 연합 메시 간 서비스 검색, 통합 메시 간 통신, 서비스 메시 간 트래픽 흐름(동부 트래픽)을 관리합니다.
메시 간 충돌 이름 지정을 방지하려면 각 메시에 대해 별도의 송신 및 수신 게이트웨이를 생성해야 합니다. 예를 들어 red-mesh
에는 green-mesh
및 blue-mesh
로 이동하는 트래픽에 대해 별도의 송신 게이트웨이가 있습니다.
매개변수 | 설명 | 값 | 기본값 |
---|---|---|---|
spec: gateways: additionalEgress: <egressName>: | 페더레이션에서 각 메시 피어에 대한 추가 송신 게이트웨이를 정의합니다. | ||
spec: gateways: additionalEgress: <egressName>: enabled: | 이 매개변수는 페더레이션 송신을 활성화 또는 비활성화합니다. |
|
|
spec: gateways: additionalEgress: <egressName>: requestedNetworkView: | 내보낸 서비스와 연결된 네트워크입니다. |
메시의 SMCP에서 | |
spec: gateways: additionalEgress: <egressName>: routerMode: | 게이트웨이에서 사용할 라우터 모드입니다. |
| |
spec: gateways: additionalEgress: <egressName>: service: metadata: labels: federation.maistra.io/egress-for: | 연결된 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 않도록 게이트웨이에 대한 고유 레이블을 지정합니다. | ||
spec: gateways: additionalEgress: <egressName>: service: ports: |
|
포트 | |
spec: gateways: additionalIngress: | 페더레이션에서 각 메시 피어에 대한 추가 수신 게이트웨이 게이트웨이를 정의합니다. | ||
spec: gateways: additionalIgress: <ingressName>: enabled: | 이 매개변수는 페더레이션 인그레스를 활성화 또는 비활성화합니다. |
|
|
spec: gateways: additionalIngress: <ingressName>: routerMode: | 게이트웨이에서 사용할 라우터 모드입니다. |
| |
spec: gateways: additionalIngress: <ingressName>: service: type: | 수신 게이트웨이 서비스는 OSI 모델의 계층 4에서 작동하고 공개적으로 사용 가능한 로드 밸런서를 통해 노출되어야 합니다. |
| |
spec: gateways: additionalIngress: <ingressName>: service: type: |
클러스터가 |
| |
spec: gateways: additionalIngress: <ingressName>: service: metadata: labels: federation.maistra.io/ingress-for: | 연결된 트래픽이 클러스터의 기본 시스템 게이트웨이를 통과하지 않도록 게이트웨이에 대한 고유 레이블을 지정합니다. | ||
spec: gateways: additionalIngress: <ingressName>: service: ports: |
|
포트 | |
spec: gateways: additionalIngress: <ingressName>: service: ports: nodePort: |
|
지정된 경우 TLS 및 서비스 검색에는 |
다음 예에서 관리자는 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
매개변수 | 설명 | 값 | 기본값 |
---|---|---|---|
spec: security: trust: domain: | 메시에 대한 신뢰 도메인의 고유 이름을 지정하는 데 사용됩니다. 도메인은 연합 내의 모든 메시에 대해 고유해야 합니다. |
| 해당 없음 |
콘솔의 프로세스
OpenShift Container Platform 웹 콘솔을 사용하여 ServiceMeshControlPlane
을 편집하려면 다음 절차를 따르십시오. 이 예에서는 red-mesh
를 예제로 사용합니다.
- cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
설치된 Operator로 이동합니다. -
프로젝트 메뉴를 클릭하고 Service Mesh Control Plane을 설치한 프로젝트를 선택합니다. 예를 들면
red-mesh-system
입니다. - Red Hat OpenShift Service Mesh Operator를 클릭합니다.
-
Istio Service Mesh Control Plane 탭에서
ServiceMeshControlPlane
의 이름을 클릭합니다(예:red-mesh
). -
ServiceMeshControlPlane 세부 정보 만들기 페이지에서
YAML
을 클릭하여 구성을 수정합니다. -
ServiceMeshControlPlane
을 수정하여 페더레이션 인그레스 및 송신 게이트웨이를 추가하고 신뢰 도메인을 지정합니다. - 저장을 클릭합니다.
CLI의 프로세스
다음 절차에 따라 명령줄로 ServiceMeshControlPlane
을 생성하거나 편집합니다. 이 예에서는 red-mesh
를 예제로 사용합니다.
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
Service Mesh Control Plane을 설치한 프로젝트로 변경합니다(예: red-mesh-system).
$ oc project red-mesh-system
-
ServiceMeshControlPlane
파일을 편집하여 페더레이션 인그레스 및 송신 게이트웨이를 추가하고 신뢰 도메인을 지정합니다. 다음 명령을 실행하여 Service Mesh Control Plane을 편집합니다. 여기서
red-mesh-system
은 시스템 네임스페이스이고red-mesh
는ServiceMeshControlPlane
오브젝트의 이름입니다.$ oc edit -n red-mesh-system smcp red-mesh
다음 명령을 입력합니다. 여기서
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 리소스 쌍이 필요합니다. 예를 들어 red
와 green
이라는 두 개의 메시를 통합하려면 ServiceMeshPeer
파일이 필요합니다.
-
red-mesh-system에서 녹색 메시에 대한
ServiceMesh
peer를 만듭니다. -
green-mesh-system에서 빨간색 메시에 대한
ServiceMesh
peer를 만듭니다.
빨간색
,블루
, 녹색
이라는 세 개의 메시를 태그하려면 6개의 ServiceMeshPeriod 파일이
필요합니다.
-
red-mesh-system에서 녹색 메시에 대한
ServiceMesh
peer를 만듭니다. -
red-mesh-system에서 Blue 메시에 대한
ServiceMesh
peer를 만듭니다. -
green-mesh-system에서 빨간색 메시에 대한
ServiceMesh
peer를 만듭니다. -
green-mesh-system에서 Blue 메시에 대한
ServiceMesh
peer를 만듭니다. -
blue-mesh-system에서 빨간색 메시에 대한
ServiceMesh
peer를 만듭니다. -
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
매개변수 | 설명 | 값 |
---|---|---|
metadata: name: | 이 리소스가 페더레이션을 구성하는 피어 메시의 이름입니다. | 문자열 |
metadata: namespace: | Service Mesh Control Plane이 설치된 이 메시의 시스템 네임스페이스입니다. | 문자열 |
spec: remote: addresses: | 이 메시에서 요청을 처리하는 피어 메시의 수신 게이트웨이의 공용 주소 목록입니다. | |
spec: remote: discoveryPort: | 검색 요청을 처리하는 주소가 있는 포트입니다. | 기본값은 8188입니다. |
spec: remote: servicePort: | 주소가 서비스 요청을 처리하는 포트입니다. | 기본값은 15443입니다. |
spec: gateways: ingress: name: |
피어 메시에서 수신한 요청을 서비스하는 이 메시의 수신 수신 이름입니다. 예: | |
spec: gateways: egress: name: |
피어 메시로 전송되는 요청을 서비스하는 이 메시의 송신 이름입니다. 예를 들어 | |
spec: security: trustDomain: | 피어 메시에서 사용하는 신뢰 도메인입니다. | <peerMeshName>.local |
spec: security: clientID: | 이 메시로 호출할 때 피어 메시에서 사용하는 클라이언트 ID입니다. | <peerMeshTrustDomain>/ns/<peerMeshSystem>/sa/<peerMeshEgressGatewayName>-service-account |
spec: security: certificateChain: kind: ConfigMap name: |
피어 메시에 의해 제공되는 클라이언트 및 서버 인증서의 유효성을 검사하는 데 사용되는 루트 인증서가 포함된 종류의(예: ConfigMap) 및 리소스 이름입니다. 인증서가 포함된 구성 맵 항목의 키는 | 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
에 대한 피어 리소스를 생성하는 방법을 보여줍니다.
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
컨트롤 플레인을 설치한 프로젝트(예:
red-mesh-system
)로 변경합니다.$ oc project red-mesh-system
통합하려는 두 메시에 대해 다음 예제를 기반으로
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
다음 명령을 실행하여 리소스를 배포합니다. 여기서
red-mesh-system
은 시스템 네임스페이스이고servicemeshpeer.yaml
에는 편집한 파일에 대한 전체 경로가 포함됩니다.$ oc create -n red-mesh-system -f servicemeshpeer.yaml
빨간색 메시와 녹색 메시 간 연결이 설정되었는지 확인하려면 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-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
매개변수 | 설명 | 값 |
---|---|---|
metadata: name: | 이 서비스를 노출하는 ServiceMeshpeer의 이름입니다. |
|
metadata: namespace: | 이 리소스를 포함하는 프로젝트/네임스페이스의 이름(슬래쉬의 시스템 네임스페이스여야 함) . | |
spec: exportRules: - type: | 이 서비스의 내보내기를 관리할 규칙 유형입니다. 서비스에 대해 발견된 첫 번째 일치 규칙은 내보내기에 사용됩니다. |
|
spec: exportRules: - type: NameSelector nameSelector: namespace: name: |
| |
spec: exportRules: - type: NameSelector nameSelector: alias: namespace: name: |
서비스에 대한 | |
spec: exportRules: - type: LabelSelector labelSelector: namespace: <exportingMesh> selector: matchLabels: <labelKey>: <labelValue> |
| |
spec: exportRules: - type: LabelSelector labelSelector: namespace: <exportingMesh> selector: matchLabels: <labelKey>: <labelValue> aliases: - namespace: name: alias: namespace: name: |
서비스에 별칭을 사용하는 |
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
을 만듭니다.
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
Service Mesh Control Plane을 설치한 프로젝트(예:
red-mesh-system
)로 변경합니다.$ oc project red-mesh-system
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
다음 명령을 실행하여 red-mesh-system 네임스페이스에
ExportedServiceSet
리소스를 업로드하고 만듭니다.$ oc create -n <ControlPlaneNamespace> -f <ExportedServiceSet.yaml>
예를 들어 다음과 같습니다.
$ oc create -n red-mesh-system -f export-to-green-mesh.yaml
-
페더레이션 메시의 각 메시 피어에 필요한 추가
ExportedServiceSets
를 만듭니다. red-mesh
에서 내보낸 서비스를 검증하여green-mesh
와 공유하려면 다음 명령을 실행합니다.$ oc get exportedserviceset <PeerMeshExportedTo> -o yaml
예를 들어 다음과 같습니다.
$ oc get exportedserviceset green-mesh -o yaml
다음 명령을 실행하여 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
매개변수 | 설명 | 값 |
---|---|---|
metadata: name: | 연결된 메시에 서비스를 내보낸 ServiceMeshPeriod의 이름입니다. | |
metadata: namespace: | ServiceMeshpeer 리소스( mesh 시스템 네임스페이스)가 포함된 네임스페이스의 이름입니다. | |
spec: importRules: - type: | 서비스의 가져오기를 제어하는 규칙 유형입니다. 서비스에 대해 발견된 첫 번째 일치 규칙이 가져오기에 사용됩니다. |
|
spec: importRules: - type: NameSelector nameSelector: namespace: name: |
| |
spec: importRules: - type: NameSelector importAsLocal: |
로컬 서비스를 사용하여 원격 엔드포인트를 집계하려면 |
|
spec: importRules: - type: NameSelector nameSelector: namespace: name: alias: namespace: name: |
서비스에 대한 |
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
로 가져와서 송신 게이트웨이 네임스페이스 내에서만 표시되고 내보낸 서비스의 호스트 이름과 연결됩니다. 이 서비스는 importAsLocal
가 true
으로 설정되어 있는 경우(domainSuffix
이 svc.cluster.local
인 경우)가 아니면 기본적으로 domainSuffix
이 svc.<ServiceMeshPeer.name>-imports.local
인 <export-name>.<export-namespace>.<domainSuffix>
로 로컬에서 사용할 수 있습니다. importAsLocal
이 false
로 설정되면 가져오기 규칙의 도메인 접미사가 적용됩니다. 로컬 가져오기를 메시의 다른 서비스와 마찬가지로 처리할 수 있습니다. 내보낸 서비스의 원격 이름으로 리디렉션되는 송신 게이트웨이를 통해 자동으로 라우팅됩니다.
사전 요구 사항
-
클러스터와
ServiceMeshControlPlane
은 메시 통합에 대해 구성되어 있습니다. -
cluster-admin
역할이 있는 계정.
아직 내보내지 않은 경우에도 가져오기 위해 서비스를 구성할 수 있습니다. ImportedServiceSet에 지정된 값과 일치하는 서비스가 배포되고 내보내면 자동으로 가져옵니다.
CLI의 프로세스
다음 절차에 따라 명령줄에서 ImportedServiceSet
을 생성합니다.
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
Service Mesh Control Plane을 설치한 프로젝트(예:
green-mesh-system
)로 변경합니다.$ oc project green-mesh-system
다음 예제를 기반으로
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
다음 명령을 실행하여 green-mesh-system 네임스페이스에
ImportedServiceSet
리소스를 업로드하고 만듭니다.$ oc create -n <ControlPlaneNamespace> -f <ImportedServiceSet.yaml>
예를 들어 다음과 같습니다.
$ oc create -n green-mesh-system -f import-from-red-mesh.yaml
-
페더레이션 메시의 각 메시 피어에 필요한 대로 추가로
ImportedServiceSet
리소스를 만듭니다. green-mesh
에 가져온 서비스를 확인하려면 다음 명령을 실행합니다.$ oc get importedserviceset <PeerMeshImportedInto> -o yaml
예를 들어 다음과 같습니다.
$ oc get importedserviceset green-mesh -o yaml
다음 명령을 실행하여 메시로 가져온 서비스의 유효성을 검사합니다.
$ 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
리소스에서 importAsLocal
및 locality
설정을 설정한 다음 ImportedServiceSet
에 지정된 지역으로 서비스에 대한 장애 조치를 구성하는 DestinationRule
을 구성하여 페일오버를 구성합니다.
사전 요구 사항
- 두 개 이상의 OpenShift Container Platform 4.6 이상의 클러스터가 이미 네트워크 연결 및 통합되었습니다.
-
페더레이션 메시의 각 메시 피어에 대해 이미 생성된
ExportedServiceSet
리소스입니다. -
통합 메시의 각 메시 피어에 대해 이미
ImportedServiceSet
리소스가 생성되었습니다. -
cluster-admin
역할이 있는 계정.
1.18.13.1. 장애 조치(failover)를 위해 ImportedServiceSet 구성
관리자는 현지화된 부하 분산을 통해 트래픽이 시작된 위치와 종료될 위치를 기준으로 엔드포인트의 트래픽 배포를 제어할 수 있습니다. 이러한 지역에는 {region}/{zone}/{sub-zone} 형식의 지역 계층을 지정하는 임의의 레이블을 사용하여 지정됩니다.
이 섹션의 예제에서 green-mesh
는 us-east
지역에 있으며 red-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
이름 | 설명 | 유형 |
---|---|---|
지역: | 가져온 서비스가 있는 리전입니다. | string |
서브 존: | 가져온 서비스가 있는 하위 영역입니다. I Subzone은 지정되며 영역도 지정해야 합니다. | string |
영역: | 가져온 서비스가 있는 영역입니다. Zone을 지정하는 경우 지역도 지정해야 합니다. | string |
절차
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인하고 다음 명령을 입력합니다.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
Service Mesh Control Plane을 설치한 프로젝트로 변경하고 다음 명령을 입력합니다.
$ oc project <smcp-system>
예를 들면
green-mesh-system
입니다.$ oc project green-mesh-system
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
파일을 수정합니다.
-
spec.importRules.importAsLocal
을true
로 설정합니다. -
spec.locality
를 지역 ,영역
하위 영역으로
설정합니다. - 변경 사항을 저장하십시오.
-
1.18.13.2. 장애 조치(failover)를 위해 DestinationRule 구성
다음을 구성하는 DestinationRule
리소스를 만듭니다.
- 서비스에 대한 이상값 탐지입니다. 장애 조치가 제대로 작동하려면 이 작업이 필요합니다. 특히, 서비스 엔드포인트가 비정상인 시기를 확인하도록 사이드카 프록시를 구성하여 결국 다음 로컬에 장애 조치를 트리거합니다.
- 리전 간 페일오버 정책. 이렇게 하면 영역 경계 이외의 장애 조치(failover)가 예측될 수 있습니다.This ensures that failover beyond a region boundary will behave predictably.
절차
cluster-admin
역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다. 다음 명령을 입력합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다.$ oc login --username=<NAMEOFUSER> <API token> https://<HOSTNAME>:6443
Service Mesh Control Plane을 설치한 프로젝트로 변경합니다.
$ oc project <smcp-system>
예를 들면
green-mesh-system
입니다.$ oc project green-mesh-system
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
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. 연합된 메시에서 메시 제거
페더레이션에서 메시를 제거해야 하는 경우 그렇게 할 수 있습니다.
-
삭제된 메시의
ServiceMeshControlPlane
리소스를 편집하여 피어 메시에 대한 모든 연합 수신 게이트웨이를 제거합니다. 제거된 메시가 연결된 각 메시 피어에 대해:
-
두 메시를 연결하는
ServiceMesh
peer 리소스를 제거합니다. -
피어 메시의
ServiceMeshControlPlane
리소스를 편집하여 제거된 메시를 제공하는 송신 게이트웨이를 제거합니다.
-
두 메시를 연결하는