1.4. 서비스 메시 배포 모델
Red Hat OpenShift Service Mesh는 비즈니스 요구 사항에 가장 적합하도록 다양한 방식으로 결합할 수 있는 여러 가지 배포 모델을 지원합니다.
Istio에서 테넌트는 배포된 워크로드 집합에 대한 공통 액세스 및 권한을 공유하는 사용자 그룹입니다. 테넌트를 사용하여 서로 다른 팀 간에 격리 수준을 제공할 수 있습니다. NetworkPolicies
,AuthorizationPolicies
, istio.io 또는 서비스 리소스에서 exportTo
주석을 사용하여 다른 테넌트에 대한 액세스를 분리할 수 있습니다.
1.4.1. cluster-Wide (Single Tenant) 메시 배포 모델
클러스터 전체 배포에는 전체 클러스터의 리소스를 모니터링하는 Service Mesh Control Plane이 포함되어 있습니다. 컨트롤 플레인이 모든 네임스페이스에서 단일 쿼리를 사용하여 Istio 및 Kubernetes 리소스를 모니터링한다는 점에서 전체 클러스터의 모니터링 리소스는 Istio 기능과 유사합니다. 결과적으로 클러스터 전체 배포는 API 서버로 전송되는 요청 수를 줄입니다.
Istio와 유사하게 클러스터 전체 메시에는 기본적으로 istio-injection=enabled
namespace 라벨이 있는 네임스페이스가 포함됩니다. ServiceMeshMemberRoll
리소스의 spec.labelSelectors
필드를 수정하여 이 레이블을 변경할 수 있습니다.
1.4.2. 다중 테넌트 배포 모델
Red Hat OpenShift Service Mesh는 기본적으로 멀티 테넌시용으로 구성된 ServiceMeshControlPlane
을 설치합니다. Red Hat OpenShift Service Mesh는 다중 테넌트 Operator를 사용하여 Service Mesh Control Plane 라이프사이클을 관리합니다. 메시 내에서 네임스페이스는 테넌시에 사용됩니다.
Red Hat OpenShift Service Mesh는 ServiceMeshControlPlane
리소스를 사용하여 기본적으로 리소스가 포함된 네임스페이스로 범위가 제한된 메시 설치를 관리합니다. ServiceMeshMemberRoll
및 ServiceMeshMember
리소스를 사용하여 추가 네임스페이스를 메시에 포함합니다. 네임스페이스는 단일 메시에만 포함될 수 있으며 단일 OpenShift 클러스터에 여러 메시를 설치할 수 있습니다.
일반적인 서비스 메시 배포에서는 단일 서비스 메시 컨트롤 플레인을 사용하여 메시의 서비스 간 통신을 구성합니다. Red Hat OpenShift Service Mesh는 테넌트당 하나의 컨트롤 플레인과 하나의 메시가 있고 클러스터 내에 여러 개의 독립적인 컨트롤 플레인이 있는 "소프트 멀티 테넌시"를 지원합니다. 다중 테넌트 배포는 서비스 메시에 액세스하고 다른 컨트롤 플레인 인스턴스에서 서비스 메시를 격리할 수 있는 프로젝트를 지정합니다.
클러스터 관리자는 모든 Istio 컨트롤 플레인에서 제어 및 가시성을 가져오고, 테넌트 관리자는 특정 서비스 메시, Kiali, Jaeger 인스턴스만 제어합니다.
팀에 지정된 네임스페이스 또는 네임스페이스 집합에만 워크로드를 배포할 수 있는 권한을 부여할 수 있습니다. 서비스 메시 관리자가 mesh-user
역할을 부여하는 경우 사용자는 ServiceMeshMember
리소스를 생성하여 ServiceMeshMemberRoll
에 네임스페이스를 추가할 수 있습니다.
1.4.3. Multimesh 또는 연합 배포 모델
페더레이션 은 별도의 관리 도메인에서 관리하는 별도의 메시 간에 서비스 및 워크로드를 공유할 수 있는 배포 모델입니다.
Istio 다중 클러스터 모델을 사용하려면 개별 메시가 상주하는 모든 Kubernetes API 서버에 대한 메시와 원격 액세스 간에 높은 수준의 신뢰가 필요합니다. Red Hat OpenShift Service Mesh 페더레이션은 메시 간 최소 신뢰를 가정하는 Service Mesh의 다중 클러스터 구현에 대한 의견 접근 방식을 취합니다.
통합 메시 는 단일 메시로 작동하는 메시 그룹입니다. 각 메시의 서비스는 고유한 서비스(예: 다른 메시에서 서비스를 가져와 서비스 추가)가 될 수 있으며, 메시 전체에 동일한 서비스에 추가 워크로드를 제공하여 고가용성을 제공하거나 두 가지의 조합을 제공할 수 있습니다. 페더레이션 메시에 가입된 모든 메시는 개별적으로 관리되며, 페더레이션으로 내보내지 않고 다른 메시에서 가져온 서비스를 명시적으로 구성해야 합니다. 인증서 생성, 메트릭 및 추적 수집과 같은 지원 기능은 각 메시에서 로컬로 유지됩니다.