2.5. 서비스 메시 배포 모델
Red Hat OpenShift Service Mesh는 비즈니스 요구 사항에 가장 적합한 다양한 방식으로 결합할 수 있는 여러 가지 배포 모델을 지원합니다.
Istio에서 테넌트는 배포된 워크로드 세트에 대한 공통 액세스 및 권한을 공유하는 사용자 그룹입니다. 테넌트를 사용하여 다른 팀 간에 격리 수준을 제공할 수 있습니다. NetworkPolicies
,AuthorizationPolicies
, istio.io 또는 서비스 리소스에서 exportTo
주석을 사용하여 다양한 테넌트에 대한 액세스를 분리할 수 있습니다.
2.5.1. cluster-Wide (Single Tenant) 메시 배포 모델
클러스터 전체 배포에는 전체 클러스터의 리소스를 모니터링하는 Service Mesh Control Plane이 포함되어 있습니다. 컨트롤 플레인이 모든 네임스페이스에서 단일 쿼리를 사용하여 Istio 및 Kubernetes 리소스를 모니터링한다는 점에서 전체 클러스터의 모니터링 리소스는 Istio 기능과 유사합니다. 결과적으로 클러스터 전체 배포는 API 서버로 전송되는 요청 수를 줄입니다.
Istio와 유사하게 클러스터 전체 메시에는 기본적으로 istio-injection=enabled
namespace 라벨이 있는 네임스페이스가 포함됩니다. ServiceMeshMemberRoll
리소스의 spec.labelSelectors
필드를 수정하여 이 레이블을 변경할 수 있습니다.
2.5.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 클러스터에 여러 메시를 설치할 수 있습니다.
일반적인 서비스 메시 배포는 단일 Service Mesh Control Plane을 사용하여 메시의 서비스 간 통신을 구성합니다. Red Hat OpenShift Service Mesh는 "소유 멀티 테넌시"를 지원합니다. 여기서 컨트롤 플레인과 테넌트당 하나의 메시가 있으며 클러스터 내에 여러 개의 독립적인 컨트롤 플레인이 있을 수 있습니다. 다중 테넌트 배포는 서비스 메시에 액세스하고 다른 컨트롤 플레인 인스턴스에서 서비스 메시를 격리할 수 있는 프로젝트를 지정합니다.
클러스터 관리자는 모든 Istio 컨트롤 플레인에서 제어 및 가시성을 가져오는 반면 테넌트 관리자는 특정 서비스 메시, Kiali 및 Jaeger 인스턴스만 제어합니다.
지정된 네임스페이스 또는 네임스페이스 세트에만 워크로드를 배포할 수 있는 팀에 권한을 부여할 수 있습니다. 서비스 메시 관리자가 mesh-user
역할을 부여하는 경우 사용자는 ServiceMeshMember
리소스를 생성하여 ServiceMeshMemberRoll
에 네임스페이스를 추가할 수 있습니다.
2.5.2.1. 클러스터 전체 메시로 마이그레이션 정보
클러스터 전체 메시에서 하나의 SMCP( ServiceMeshControlPlane
)는 전체 클러스터의 모든 네임스페이스를 감시합니다. Red Hat OpenShift Service Mesh 버전 2.5 이상을 사용하여 기존 클러스터를 다중 테넌트 메시에서 클러스터 전체 메시로 마이그레이션할 수 있습니다.
클러스터에 두 개 이상의 SMCP가 있어야 하는 경우 클러스터 전체 메시로 마이그레이션할 수 없습니다.
기본적으로 클러스터 전체 메시는 클러스터를 구성하는 모든 네임스페이스를 검색합니다. 그러나 제한된 네임스페이스 세트에 액세스하도록 메시를 구성할 수 있습니다. 네임스페이스는 기본적으로 사이드카 삽입을 수신하지 않습니다. 사이드카 삽입을 수신하는 네임스페이스를 지정해야 합니다.
마찬가지로 사이드카 삽입을 수신하는 Pod를 지정해야 합니다. 사이드카 삽입을 수신하는 네임스페이스에 존재하는 Pod는 사이드카 삽입을 상속하지 않습니다. 네임스페이스 및 Pod에 사이드카 삽입을 적용하는 작업은 별도의 작업입니다.
클러스터 전체 메시로 마이그레이션할 때 Istio 버전을 변경하는 경우 애플리케이션을 다시 시작해야 합니다. 동일한 Istio 버전을 사용하는 경우 애플리케이션 프록시는 클러스터 전체 메시의 새 SMCP에 연결하고 다중 테넌트 메시에 대해 동일한 방식으로 작동합니다.
2.5.2.1.1. 웹 콘솔을 사용하여 클러스터 전체 메시에서 네임스페이스 포함 및 제외
OpenShift Container Platform 웹 콘솔을 사용하여 클러스터 전체 메시의 ServiceMeshControlPlane
리소스에 검색 선택기를 추가할 수 있습니다. 검색 선택기는 컨트롤 플레인에서 검색할 수 있는 네임스페이스를 정의합니다. 컨트롤 플레인은 검색 선택기 중 하나와 일치하지 않는 네임스페이스를 무시하고 메시에서 네임스페이스를 제외합니다.
컨트롤 플레인 네임스페이스에 수신 또는 송신 게이트웨이를 설치하는 경우 검색 선택기에 컨트롤 플레인 네임스페이스를 포함해야 합니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
ServiceMeshControlPlane
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
설치된 Operator로 이동합니다. - Red Hat OpenShift Service Mesh Operator를 클릭합니다.
- Istio Service Mesh Control Plane 을 클릭합니다.
- 컨트롤 플레인의 이름을 클릭합니다.
- YAML 을 클릭합니다.
ServiceMeshControlPlane
리소스의spec.meshConfig
필드에 검색 선택기가 포함되도록 YAML 파일을 수정합니다.참고Istiod
서비스에서 검색할 수 있는 네임스페이스를 구성할 때 나머지 메시에 노출해서는 안 되는 중요한 서비스가 포함될 수 있는 네임스페이스를 제외합니다.다음 예에서
Istiod
서비스는istio-discovery: enabled
또는 nameinfo
,httpbin
또는istio-system
라벨이 지정된 네임스페이스를 검색합니다.apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: mode: ClusterWide meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled 1 - matchExpressions: - key: kubernetes.io/metadata.name 2 operator: In values: - info - httpbin - istio-system
네임스페이스가 검색 선택기와 일치하는 경우 메시에서 네임스페이스를 검색합니다. 메시는 검색 선택기와 일치하지 않는 네임스페이스를 제외합니다.
- 파일을 저장합니다.
2.5.2.1.2. CLI를 사용하여 클러스터 전체 메시에서 네임스페이스 포함 및 제외
OpenShift Container Platform CLI를 사용하여 클러스터 전체 메시의 ServiceMeshControlPlane
리소스에 검색 선택기를 추가할 수 있습니다. 검색 선택기는 컨트롤 플레인에서 검색할 수 있는 네임스페이스를 정의합니다. 컨트롤 플레인은 검색 선택기 중 하나와 일치하지 않는 네임스페이스를 무시하고 메시에서 네임스페이스를 제외합니다.
컨트롤 플레인 네임스페이스에 수신 또는 송신 게이트웨이를 설치하는 경우 검색 선택기에 컨트롤 플레인 네임스페이스를 포함해야 합니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
ServiceMeshControlPlane
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform CLI에 로그인합니다.
다음 명령을 실행하여
ServiceMeshControlPlane
리소스를 YAML 파일로 엽니다.$ oc -n istio-system edit smcp <name> 1
- 1
<name
>은ServiceMeshControlPlane
리소스의 이름을 나타냅니다.
ServiceMeshControlPlane
리소스의spec.meshConfig
필드에 검색 선택기가 포함되도록 YAML 파일을 수정합니다.참고Istiod
서비스에서 검색할 수 있는 네임스페이스를 구성할 때 나머지 메시에 노출해서는 안 되는 중요한 서비스가 포함될 수 있는 네임스페이스를 제외합니다.다음 예에서
Istiod
서비스는istio-discovery: enabled
또는 nameinfo
,httpbin
또는istio-system
라벨이 지정된 네임스페이스를 검색합니다.apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: mode: ClusterWide meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled 1 - matchExpressions: - key: kubernetes.io/metadata.name 2 operator: In values: - info - httpbin - istio-system
네임스페이스가 검색 선택기와 일치하는 경우 메시에서 네임스페이스를 검색합니다. 메시는 검색 선택기와 일치하지 않는 네임스페이스를 제외합니다.
- 파일을 저장하고 편집기를 종료합니다.
2.5.2.1.3. 웹 콘솔을 사용하여 클러스터 전체 메시에서 사이드카 삽입을 수신하는 네임스페이스 정의
기본적으로 Red Hat OpenShift Service Mesh Operator는 멤버 선택기를 사용하여 사이드카 삽입을 수신하는 네임스페이스를 식별합니다. ServiceMeshMemberRoll
리소스에 정의된 대로 istio-injection=enabled
레이블과 일치하지 않는 네임스페이스는 사이드카 삽입을 수신하지 않습니다.
검색 선택기를 사용하여 메시에서 검색할 수 있는 네임스페이스를 결정해도 사이드카 삽입에는 영향을 미치지 않습니다. 네임스페이스를 검색하고 사이드카 삽입을 구성하는 작업은 별도의 작업입니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
mode: ClusterWide
주석을 사용하여ServiceMeshControlPlanae
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
설치된 Operator로 이동합니다. - Red Hat OpenShift Service Mesh Operator를 클릭합니다.
- Istio Service Mesh 멤버 롤 을 클릭합니다.
-
ServiceMeshMemberRoll
리소스를 클릭합니다. - YAML 을 클릭합니다.
inject
레이블과 일치하는 멤버 선택기를 추가하여ServiceMeshMemberRoll
리소스에서spec.memberSelectors
필드를 수정합니다. 다음 예제에서는istio-injection: enabled
를 사용합니다.apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: memberSelectors: - matchLabels: istio-injection: enabled 1
- 1
- 네임스페이스에서 사이드카 삽입을 수신하는지 확인합니다.
- 파일을 저장합니다.
2.5.2.1.4. CLI를 사용하여 클러스터 전체 메시에서 사이드카 삽입을 수신하는 네임스페이스 정의
기본적으로 Red Hat OpenShift Service Mesh Operator는 멤버 선택기를 사용하여 사이드카 삽입을 수신하는 네임스페이스를 식별합니다. ServiceMeshMemberRoll
리소스에 정의된 대로 istio-injection=enabled
레이블과 일치하지 않는 네임스페이스는 사이드카 삽입을 수신하지 않습니다.
검색 선택기를 사용하여 메시에서 검색할 수 있는 네임스페이스를 결정해도 사이드카 삽입에는 영향을 미치지 않습니다. 네임스페이스를 검색하고 사이드카 삽입을 구성하는 작업은 별도의 작업입니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
mode: ClusterWide
주석을 사용하여ServiceMeshControlPlanae
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform CLI에 로그인합니다.
ServiceMeshMemberRoll
리소스를 편집합니다.$ oc edit smmr -n <controlplane-namespace>
inject
레이블과 일치하는 멤버 선택기를 추가하여ServiceMeshMemberRoll
리소스에서spec.memberSelectors
필드를 수정합니다. 다음 예제에서는istio-injection: enabled
를 사용합니다.apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: memberSelectors: - matchLabels: istio-injection: enabled 1
- 1
- 네임스페이스에서 사이드카 삽입을 수신하는지 확인합니다.
- 파일을 저장하고 편집기를 종료합니다.
2.5.2.1.5. 웹 콘솔을 사용하여 클러스터 전체 메시에서 개별 Pod 제외
Pod에 sidecar.istio.io/inject: true
주석이 적용되고 Pod는 라벨 선택기 또는 ServiceMeshMemberRoll
리소스에 정의된 멤버 목록과 일치하는 네임스페이스에 있는 경우 사이드카 삽입을 수신합니다.
Pod에 sidecar.istio.io/inject
주석이 적용된 경우 사이드카 삽입을 수신할 수 없습니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
mode: ClusterWide
주석을 사용하여ServiceMeshControlPlane
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
워크로드
배포로 이동합니다. - 배포 이름을 클릭합니다.
- YAML 을 클릭합니다.
다음 예와 같이 YAML 파일을 수정하여 사이드카 삽입을 수신하는 하나의 애플리케이션과 그렇지 않은 애플리케이션을 배포합니다.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: annotations: sidecar.istio.io/inject: 'true' 1 labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-without-sidecar spec: selector: matchLabels: app: nginx-without-sidecar template: metadata: labels: app: nginx-without-sidecar 2 spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
- 파일을 저장합니다.
2.5.2.1.6. CLI를 사용하여 클러스터 전체 메시에서 개별 Pod 제외
Pod에 sidecar.istio.io/inject: true
주석이 적용되고 Pod는 라벨 선택기 또는 ServiceMeshMemberRoll
리소스에 정의된 멤버 목록과 일치하는 네임스페이스에 있는 경우 사이드카 삽입을 수신합니다.
Pod에 sidecar.istio.io/inject
주석이 적용된 경우 사이드카 삽입을 수신할 수 없습니다.
사전 요구 사항
- Red Hat OpenShift Service Mesh Operator가 설치되어 있습니다.
-
mode: ClusterWide
주석을 사용하여ServiceMeshControlPlane
리소스를 배포했습니다. -
cluster-admin
역할의 사용자로 로그인되어 있습니다. Red Hat OpenShift Dedicated를 사용하는 경우dedicated-admin
역할의 사용자로 로그인되어 있습니다.
프로세스
- OpenShift Container Platform CLI에 로그인합니다.
다음 명령을 실행하여 배포를 편집합니다.
$ oc edit deployment -n <namespace> <deploymentName>
다음 예와 같이 YAML 파일을 수정하여 사이드카 삽입을 수신하는 하나의 애플리케이션과 그렇지 않은 애플리케이션을 배포합니다.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: annotations: sidecar.istio.io/inject: 'true' 1 labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-without-sidecar spec: selector: matchLabels: app: nginx-without-sidecar template: metadata: labels: app: nginx-without-sidecar 2 spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
- 파일을 저장합니다.
2.5.3. Multimesh 또는 페더레이션 배포 모델
페더레이션 은 별도의 관리 도메인에서 관리되는 별도의 메시 간에 서비스와 워크로드를 공유할 수 있는 배포 모델입니다.
Istio 다중 클러스터 모델에는 개별 메시가 있는 모든 Kubernetes API 서버에 대한 메시와 원격 액세스 간의 높은 수준의 신뢰가 필요합니다. Red Hat OpenShift Service Mesh 페더레이션은 메시 간 신뢰가 최소화 된다고 가정하는 서비스 메시의 다중 클러스터 구현에 대해 의견을 내포하고 있습니다.
페더레이션 메시는 단일 메시로 작동하는 메시 그룹입니다. 각 메시의 서비스는 고유한 서비스일 수 있습니다. 예를 들어 메시에서 다른 메시에서 서비스를 가져와서 서비스를 추가하고, 메시 전체에서 동일한 서비스에 대한 추가 워크로드를 제공하여 고가용성 또는 두 가지의 조합을 제공할 수 있습니다. 페더레이션 메시에 결합된 모든 메시는 개별적으로 관리되며, 페더레이션의 다른 메시로 내보내거나 가져오는 서비스를 명시적으로 구성해야 합니다. 인증서 생성, 메트릭 및 추적 컬렉션과 같은 지원 기능은 각 메시에서 로컬로 유지됩니다.