1.11.

이전 버전에서 사용하는 아키텍처 단위는 Istiod로 교체되었습니다.

Mixer는 더 이상 컨트롤 플레인 구성 요소로 지원되지 않지만, Mixer 정책 및 Telemetry 플러그인은 이제 Istiod의 WASM 확장을 통해 지원됩니다. 레거시 Mixer 플러그인을 통합해야 하는 경우 정책 및 Telemetry에 대해 Mixer를 활성화할 수 있습니다.

SDS(Secret Discovery Service)는 Istiod에서 직접 사이드카에 인증서와 키를 배포하는 데 사용됩니다. Red Hat OpenShift Service Mesh 버전 1.1에서는 Citadel에 의해 시크릿이 생성되었으며, 이는 프록시가 클라이언트 인증서와 키를 검색하는 데 사용되었습니다.

v2.0에서는 다음과 같은 주석이 더 이상 지원되지 않습니다.

Red Hat OpenShift Service Mesh 2.0의 일부 기능은 이전 버전과 다르게 작동합니다.

RbacConfig 동작을 모방하려면 RbacConfig에 지정된 spec.mode에 따라 설정이 달라지는 기본 AuthorizationPolicy를 작성해야 합니다.

AuthorizationPolicy에는 ServiceRoleBinding이 제공하는 기능과 유사한 구성이 적용되는 선택기와 ServiceRole이 제공하는 기능과 유사하며 적용되어야 하는 규칙에 대한 구성이 모두 포함됩니다.

Mixer 구성 요소는 버전 2.0에서 기본적으로 비활성화되어 있습니다. 워크로드에 Mixer 플러그인을 사용하는 경우 Mixer 구성 요소를 포함하도록 버전 2.0 ServiceMeshControlPlane을 구성해야 합니다.

Mixer 정책 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다.

spec:
  policy:
    type: Mixer

Mixer telemetry 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다.

spec:
  telemetry:
    type: Mixer

또한 레거시 mixer 플러그인은 WASM으로 마이그레이션하고 새로운 ServiceMeshExtension(maistra.io/v1alpha1) 사용자 정의 리소스를 사용하여 통합할 수 있습니다.

업스트림 Istio 배포에 포함된 내장 WASM 필터는 Red Hat OpenShift Service Mesh 2.0에서 사용할 수 없습니다.

워크로드별 PeerAuthentication 정책과 함께 mTLS를 사용할 때 워크로드 정책이 네임스페이스/글로벌 정책과 다를 경우 트래픽을 허용하려면 상응하는 DestinationRule이 필요합니다.

자동 mTLS는 기본적으로 활성화되어 있지만 ServiceMeshControlPlane 리소스에서 spec.security.dataPlane.automtls를 false로 설정하여 비활성화할 수 있습니다. 자동 mTLS를 비활성화할 때 서비스 간 적절한 통신을 위해 DestinationRules가 필요할 수 있습니다. 예를 들어, 하나의 네임스페이스에 대해 PeerAuthentication을 STRICT으로 설정하면 DestinationRule이 네임스페이스의 서비스에 TLS 모드를 구성하지 않는 한 다른 네임스페이스의 서비스에 액세스하지 못할 수 있습니다.

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

데이터 플레인 통신에 대한 상호 TLS는 ServiceMeshControlPlane 리소스의 spec.security.dataPlane.mtls를 통해 구성되며, 기본적으로 false입니다.

Istiod는 서비스 프록시에서 사용하는 클라이언트 인증서 및 개인 키를 관리합니다. 기본적으로 Istiod는 서명에 자체 서명된 인증서를 사용하지만 사용자 정의 인증서와 개인 키를 구성할 수 있습니다.

추적 기능은 spec.tracing에서 구성됩니다. 현재 지원되는 유일한 추적기 유형은 Jaeger입니다. 샘플링은 0.01% 증분을 나타내는 스케일링된 정수입니다(예: 1은 0.01%, 10000은 100%). 추적 구현 및 샘플링 비율을 지정할 수 있습니다.

spec:
  tracing:
    sampling: 100 # 1%
    type: Jaeger

spec:
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch for production mode
          memory:
            maxTraces: 100000
          elasticsearch: # the following values only apply if storage:type:=Elasticsearch
            storage: # specific storageclass configuration for the Jaeger Elasticsearch (optional)
              size: "100G"
              storageClassName: "storageclass"
            nodeCount: 3
            redundancyPolicy: SingleRedundancy
  runtime:
    components:
      tracing.jaeger: {} # general Jaeger specific runtime configuration (optional)
      tracing.jaeger.elasticsearch: #runtime configuration for Jaeger Elasticsearch deployment (optional)
        container:
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"

Jaeger 설치는 install 필드로 사용자 지정할 수 있습니다. 리소스 제한과 같은 컨테이너 구성은 spec.runtime.components.jaeger 관련 필드에 구성됩니다. 기존 Jaeger 리소스를 사용하여 Jaeger 설치를 완전히 사용자 지정할 수 있습니다.

spec:
  addons:
    grafana:
      enabled: true
      install: {} # customize install
    kiali:
      enabled: true
      name: kiali
      install: {} # customize install

Grafana 및 Kiali 설치는 각각의 install 필드를 통해 사용자 지정할 수 있습니다. 리소스 제한과 같은 컨테이너 사용자 정의는 spec.runtime.components.kiali 및 spec.runtime.components.grafana에서 구성됩니다. Kiali 리소스의 일부 필드(예: accessible_namespaces 목록과 Grafana, Prometheus, 추적에 대한 끝점)는 재정의됩니다. 기존 리소스를 사용하여 Kiali 설치를 완전히 사용자 지정할 수 있습니다.

리소스는 spec.runtime.<component>에서 구성됩니다. 다음과 같은 구성 요소 이름이 지원됩니다.

일부 구성 요소는 리소스 제한 및 스케줄링을 지원합니다.