1.5. 서비스 메시 및 Istio 차이점

Red Hat OpenShift Service Mesh의 명령줄 도구는 oc입니다.  Red Hat OpenShift Service Mesh는 istioctl을 지원하지 않습니다.

Red Hat OpenShift Service Mesh는 Istio 설치 프로필을 지원하지 않습니다.

Red Hat OpenShift Service Mesh는 서비스 메시의 카나리아 업그레이드를 지원하지 않습니다.

업스트림 Istio 커뮤니티 설치는 레이블을 지정한 프로젝트 내의 pod에 사이드카를 자동으로 삽입합니다.

Red Hat OpenShift Service Mesh는 사이드카를 Pod에 자동으로 삽입하지 않지만 프로젝트에 레이블을 지정하지 않고 주석을 사용하여 삽입해야 합니다. 이 방법은 더 적은 권한이 필요하며 빌더 Pod와 같은 다른 OpenShift Container Platform 기능과 충돌하지 않습니다. 자동 삽입을 활성화하려면 자동 사이드카 삽입 섹션에 설명된 대로 sidecar.istio.io/inject 레이블 또는 주석을 지정합니다.

역할 기반 액세스 제어(RBAC)는 서비스에 대한 액세스를 제어하는 데 사용할 수 있는 메커니즘을 제공합니다. 사용자 이름별로, 또는 속성 집합을 지정하여 제목을 식별하고 그에 따라 액세스 제어를 적용할 수 있습니다.

업스트림 Istio 커뮤니티 설치에는 정확한 헤더 일치를 수행하거나, 헤더에서 와일드카드를 일치시키거나, 특정 접두사 또는 접미사가 포함된 헤더를 확인하는 옵션이 포함되어 있습니다.

Red Hat OpenShift Service Mesh는 정규식을 사용하여 요청 헤더를 일치시키는 기능을 확장합니다. 정규식이 있는 request.regex.headers의 속성 키를 지정합니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

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)를 동적으로 연결합니다.

Red Hat OpenShift Service Mesh는 베어 메탈 서버에서 OpenShift 외부에서 실행되는 가상 머신과 같은 외부 워크로드를 지원하지 않습니다.

OpenShift Virtualization을 사용하여 OpenShift에 가상 머신을 배포할 수 있습니다. 그런 다음 mTLS 또는 AuthorizationPolicy와 같은 메시 정책을 메시의 일부인 다른 Pod와 마찬가지로 이러한 가상 머신에 적용할 수 있습니다.

Red Hat OpenShift Service Mesh는 명시적으로 문서화된 경우를 제외하고 EnvoyFilter 구성을 지원하지 않습니다. 기본 Envoy API와의 긴밀한 결합으로 인해 이전 버전과의 호환성을 유지할 수 없습니다. EnvoyFilter 패치는 Istio에서 생성한 Envoy 구성의 형식에 매우 민감합니다. Istio에서 생성한 구성이 변경되면 EnvoyFilter 의 애플리케이션을 중단할 수 있습니다.

Red Hat OpenShift Service Mesh는 QUIC 기반 서비스를 지원하지 않습니다.

Red Hat OpenShift Service Mesh에는 CNI 플러그인이 포함되어 있으며, 이를 통해 애플리케이션 Pod 네트워킹을 구성할 수 있는 대체 방법을 제공합니다. CNI 플러그인은 승격된 권한으로 SCC(보안 컨텍스트 제약 조건)에 서비스 계정 및 프로젝트 액세스 권한을 부여할 필요가 없도록 init-container 네트워크 구성을 대체합니다.

Red Hat OpenShift Service Mesh는 메시 내에서 상호 TLS 인증(mTLS)을 활성화 또는 비활성화하는 PeerAuthentication 리소스를 생성합니다.

Red Hat OpenShift Service Mesh는 기본적으로 수신 및 송신 게이트웨이를 설치합니다. 다음 설정을 사용하여 ServiceMeshControlPlane (SMCP) 리소스에서 게이트웨이 설치를 비활성화할 수 있습니다.

멀티 클러스터 구성에 대한 Red Hat OpenShift Service Mesh 지원은 여러 클러스터에서 서비스 메시 통합으로 제한됩니다.

Kubernetes CA(인증 기관)를 통해 CSR을 처리하도록 Red Hat OpenShift Service Mesh를 구성할 수 없습니다.

Istio 게이트웨이의 OpenShift 경로는 Red Hat OpenShift Service Mesh에서 자동으로 관리됩니다. Istio 게이트웨이가 서비스 메시 내부에서 생성, 업데이트 또는 삭제될 때마다 OpenShift 경로가 생성, 업데이트 또는 삭제됩니다.

IOR(Istio OpenShift Routing)이라는 Red Hat OpenShift Service Mesh Control Plane 구성 요소는 게이트웨이 경로를 동기화합니다. 자세한 내용은 자동 경로 생성을 참조하십시오.

다중 테넌트 설치와 클러스터 전체 설치의 주요 차이점은 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 플러그인을 사용하도록 구성된 경우:

업스트림 Istio에는 의존하는 두 개의 클러스터 범위 리소스가 있습니다. MeshPolicy 및 ClusterRbacConfig 이는 다중 테넌트 클러스터와 호환되지 않으며 아래에 설명된 대로 교체되었습니다.