2.3. 서비스 메시 및 Istio 차이점
Red Hat OpenShift Service Mesh 설치는 여러 가지 면에서 업스트림 Istio 커뮤니티 설치와 다릅니다.
Red Hat OpenShift Service Mesh의 현재 릴리스는 다음과 같은 점에서 현재 업스트림 Istio 커뮤니티 릴리스와 다릅니다.
2.3.1. 다중 테넌트 설치
업스트림 Istio는 하나의 테넌트 접근법을 사용하지만 Red Hat OpenShift Service Mesh는 클러스터 내에서 여러 개의 독립적인 컨트롤 플레인을 지원합니다. Red Hat OpenShift Service Mesh는 다중 테넌트 연산자를 사용하여 컨트롤 플레인 라이프사이클을 관리합니다.
Red Hat OpenShift Service Mesh는 기본적으로 다중 테넌트 컨트롤 플레인을 설치합니다. 서비스 메시에 액세스할 수 있는 프로젝트를 지정하고 다른 컨트롤 플레인 인스턴스에서 서비스 메시를 분리합니다.
2.3.1.1. 멀티 테넌시 대 클러스터 전체 설치
구성 요소는 더 이상 클러스터 범위의 역할 기반 액세스 제어(RBAC) 리소스 ClusterRoleBinding
을 사용하지 않습니다.
ServiceMeshMemberRoll
members
목록에 있는 모든 프로젝트는 컨트롤 플레인 배포와 관련된 각 서비스 계정에 대해 RoleBinding
을 가지며, 각 컨트롤 플레인 배포는 해당하는 멤버 프로젝트만 감시합니다. 각 멤버 프로젝트에는 maistra.io/member-of
레이블이 추가됩니다. 여기서 member-of
값은 컨트롤 플레인 설치가 포함된 프로젝트입니다.
Red Hat OpenShift Service Mesh는 각 멤버 프로젝트를 구성하여 자체, 컨트롤 플레인 및 기타 멤버 프로젝트 간의 네트워크 액세스를 보장합니다. 자세한 내용은 OpenShift SDN 정보를 참조하십시오.
NetworkPolicy
: Red Hat OpenShift Service Mesh는 각 멤버 프로젝트에서NetworkPolicy
리소스를 생성하여 다른 멤버 및 컨트롤 플레인에서 모든 pod로 수신할 수 있습니다. 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
실행과 동일). - 서브넷: 추가 구성이 수행되지 않습니다.
2.3.1.2. 클러스터 범위 리소스
업스트림 Istio에는 의존하는 두 개의 클러스터 범위 리소스가 있습니다. MeshPolicy
및 ClusterRbacConfig
이는 다중 테넌트 클러스터와 호환되지 않으며 아래에 설명된 대로 교체되었습니다.
- ServiceMeshPolicy는 컨트롤 플레인 전체의 인증 정책 구성을 위해 MeshPolicy를 대체합니다. 이는 컨트롤 플레인과 동일한 프로젝트에서 생성되어야 합니다.
- ServicemeshRbacConfig는 컨트롤 플레인 전체 역할 기반 액세스 제어 구성을 위해 ClusterRbacConfig 를 대체합니다. 이는 컨트롤 플레인과 동일한 프로젝트에서 생성되어야 합니다.
2.3.2. Istio와 Red Hat OpenShift Service Mesh 간의 차이점
Red Hat OpenShift Service Mesh 설치는 여러 가지 면에서 Istio 설치와 다릅니다.
2.3.2.1. 명령줄 도구
Red Hat OpenShift Service Mesh의 명령줄 도구는 oc입니다. Red Hat OpenShift Service Mesh는 istioctl을 지원하지 않습니다.
2.3.2.2. 자동 삽입
업스트림 Istio 커뮤니티 설치는 레이블을 지정한 프로젝트 내의 pod에 사이드카를 자동으로 삽입합니다.
Red Hat OpenShift Service Mesh는 사이드카를 Pod에 자동으로 삽입하지 않지만 프로젝트에 레이블을 지정하지 않고 주석을 사용하여 삽입해야 합니다. 이 방법은 더 적은 권한이 필요하며, builder pod와 같은 다른 OpenShift 기능과 충돌하지 않습니다. 자동 삽입을 활성화하려면 자동 사이드카 삽입 섹션에 설명된 대로 sidecar.istio.io/inject
주석을 지정합니다.
2.3.2.3. Istio 역할 기반 액세스 제어 기능
역할 기반 액세스 제어(RBAC)는 서비스에 대한 액세스를 제어하는 데 사용할 수 있는 메커니즘을 제공합니다. 사용자 이름별로, 또는 속성 집합을 지정하여 제목을 식별하고 그에 따라 액세스 제어를 적용할 수 있습니다.
업스트림 Istio 커뮤니티 설치에는 정확한 헤더 일치를 수행하거나, 헤더에서 와일드카드를 일치시키거나, 특정 접두사 또는 접미사가 포함된 헤더를 확인하는 옵션이 포함되어 있습니다.
Red Hat OpenShift Service Mesh는 정규식을 사용하여 요청 헤더를 일치시키는 기능을 확장합니다. 정규식이 있는 request.regex.headers
의 속성 키를 지정합니다.
요청 헤더와 일치하는 업스트림 Istio 커뮤니티 예
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: httpbin-client-binding namespace: httpbin spec: subjects: - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" properties: request.headers[<header>]: "value"
정규식을 사용하여 요청 헤더를 일치시키는 Red Hat OpenShift Service Mesh
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: httpbin-client-binding namespace: httpbin spec: subjects: - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" properties: request.regex.headers[<header>]: "<regular expression>"
2.3.2.4. OpenSSL
Red Hat OpenShift Service Mesh는 BoringSSL을 OpenSSL로 대체합니다. OpenSSL은 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 프로토콜의 오픈 소스 구현이 포함된 소프트웨어 라이브러리입니다. Red Hat OpenShift Service Mesh 프록시 바이너리는 기본 Red Hat Enterprise Linux 운영 체제에서 OpenSSL 라이브러리(libssl 및 libcrypto)를 동적으로 연결합니다.
2.3.2.5. 구성 요소 수정
- maistra-version 레이블이 모든 리소스에 추가되었습니다.
- 모든 Ingress 리소스가 OpenShift Route 리소스로 변환되었습니다.
- Grafana, Tracing(Jaeger) 및 Kiali는 기본적으로 활성화되어 OpenShift 경로를 통해 노출됩니다.
- Godebug가 모든 템플릿에서 제거됨
-
istio-multi
ServiceAccount과 ClusterRoleBinding,istio-reader
ClusterRole이 제거되었습니다.
2.3.2.6. Envoy, Secret Discovery Service, 및 인증서
- Red Hat OpenShift Service Mesh는 QUIC 기반 서비스를 지원하지 않습니다.
- Istio의 SDS(Security Discovery Service) 기능을 사용한 TLS 인증서 배포는 현재 Red Hat OpenShift Service Mesh에서 지원되지 않습니다. Istio 구현은 hostPath 마운트를 사용하는 nodeagent 컨테이너에 따라 다릅니다.
2.3.2.7.
2.3.2.8. Istio 게이트웨이 경로
Istio 게이트웨이의 OpenShift 경로는 Red Hat OpenShift Service Mesh에서 자동으로 관리됩니다. Istio 게이트웨이가 서비스 메시 내부에서 생성, 업데이트 또는 삭제될 때마다 OpenShift 경로가 생성, 업데이트 또는 삭제됩니다.
IOR(Istio OpenShift Routing)이라는 Red Hat OpenShift Service Mesh Control Plane 구성 요소는 게이트웨이 경로를 동기화합니다. 자세한 내용은 자동 경로 생성을 참조하십시오.
2.3.2.8.1. catch-all 도메인
catch-all 도메인("*")은 지원되지 않습니다. 게이트웨이 정의에서 이 도메인이 발견되면 Red Hat OpenShift Service Mesh는 경로를 생성하지만 기본 호스트 이름을 만들기 위해 OpenShift에 의존합니다. 즉, 새로 생성된 경로는 catch-all ("*") 경로가 아니며, 대신 r<route-name>[-<project>].<suffix>
형식의 호스트 이름이 있습니다. 기본 호스트 이름이 작동하는 방법과 클러스터 관리자가 사용자 지정할 수 있는 방법에 대한 자세한 내용은 OpenShift 문서를 참조하십시오.
2.3.2.8.2. 하위 도메인
하위 도메인(예: "*.domain.com")이 지원됩니다.
2.3.2.8.3. TLS(Transport layer security)
TLS(Transport Layer Security)가 지원됩니다. 즉, 게이트웨이에 tls
섹션이 포함된 경우 OpenShift 경로는 TLS를 지원하도록 구성됩니다.
추가 리소스
2.3.3. Kiali 및 서비스 메시
- Kiali는 기본적으로 활성화되어 있습니다.
- Ingress는 기본적으로 활성화되어 있습니다.
- Kiali ConfigMap이 업데이트되었습니다.
- Kiali의 ClusterRole 설정이 업데이트되었습니다.
-
Operator 파일을 업데이트하려면
cluster-admin
권한이 있는 사용자로 제한해야 합니다.
2.3.4.
- Ingress는 기본적으로 서비스 메시에 대해 활성화되어 있습니다.
-
Zipkin 포트 이름의 이름이
jaeger-collector-zipkin(
으로 변경되었습니다.http
) -
Jaeger는
production
또는streaming
배포 옵션을 선택할 때 기본적으로 스토리지에 Elasticsearch를 사용합니다. - Istio 커뮤니티 버전은 일반적인 "tracing" 경로를 제공합니다.
- Red Hat OpenShift Service Mesh는 Envoy 프록시에 사이드카를 사용하며 Jaeger 또한 Jaeger 에이전트에 사이드카를 사용합니다. 이 두 가지 사이드카는 별도로 구성되어 있으며 서로 혼동해서는 안 됩니다. 프록시 사이드카는 Pod의 수신 및 송신 트래픽과 관련된 기간을 생성합니다. 에이전트 사이드카는 응용 프로그램에서 발송되는 기간을 수신하여 Jaeger 수집기로 보냅니다.