1.5.2. 다중 테넌트 설치

업스트림 Istio는 하나의 테넌트 접근법을 사용하지만 Red Hat OpenShift Service Mesh는 클러스터 내에서 여러 개의 독립적인 컨트롤 플레인을 지원합니다. Red Hat OpenShift Service Mesh는 다중 테넌트 연산자를 사용하여 컨트롤 플레인 라이프사이클을 관리합니다.

Red Hat OpenShift Service Mesh는 기본적으로 다중 테넌트 컨트롤 플레인을 설치합니다. 서비스 메시에 액세스할 수 있는 프로젝트를 지정하고 다른 컨트롤 플레인 인스턴스에서 서비스 메시를 분리합니다.

1.5.2.1. 멀티 테넌시 대 클러스터 전체 설치

다중 테넌트 설치와 클러스터 전체 설치의 주요 차이점은 istod에서 사용하는 권한 범위입니다. 구성 요소는 더 이상 클러스터 범위의 역할 기반 액세스 제어(RBAC) 리소스 ClusterRoleBinding을 사용하지 않습니다.

ServiceMeshMemberRoll members 목록에 있는 모든 프로젝트는 컨트롤 플레인 배포와 관련된 각 서비스 계정에 대해 RoleBinding을 가지며, 각 컨트롤 플레인 배포는 해당하는 멤버 프로젝트만 감시합니다. 각 멤버 프로젝트에는 maistra.io/member-of 레이블이 추가됩니다. 여기서 member-of 값은 컨트롤 플레인 설치가 포함된 프로젝트입니다.

Red Hat OpenShift Service Mesh는 각 멤버 프로젝트를 구성하여 자체, 컨트롤 플레인 및 기타 멤버 프로젝트 간의 네트워크 액세스를 보장합니다. 정확한 구성은 OpenShift Container Platform 소프트웨어 정의 네트워킹(SDN)이 구성된 방법에 따라 다릅니다. 자세한 내용은 OpenShift SDN 정보를 참조하십시오.

OpenShift Container Platform 클러스터가 SDN 플러그인을 사용하도록 구성된 경우:

  • NetworkPolicy: Red Hat OpenShift Service Mesh는 각 멤버 프로젝트에서 NetworkPolicy 리소스를 생성하여 다른 멤버 및 컨트롤 플레인에서 모든 포드로 수신할 수 있습니다. Service Mesh에서 멤버를 제거하면 이 NetworkPolicy 리소스는 프로젝트에서 삭제됩니다.

    참고

    또한 멤버 프로젝트 전용 수신으로 제한합니다. 멤버 외 프로젝트에서 수신이 필요한 경우 해당 트래픽을 허용하기 위해 NetworkPolicy를 생성해야 합니다.

  • 다중 테넌트: Red Hat OpenShift Service Mesh는 각 멤버 프로젝트의 NetNamespace 를 컨트롤 플레인 프로젝트의 NetNamespace 에 결합합니다(oc adm pod-network join-projects --to control-plane-project member-project). 서비스 메시에서 멤버를 제거하면 해당 NetNamespace가 컨트롤 플레인과 분리됩니다(oc adm pod-network isolate-projects member-project 실행과 동일).
  • 서브넷: 추가 구성이 수행되지 않습니다.