1.11. 升级 Service Mesh

之前的版本使用的架构单元已被 Istiod 替代。在 2.0 中，Service Mesh control plane 组件 Mixer、Pilot、Citadel、Galley 和 sidecar 注入程序功能已合并为一个组件 Istiod。

虽然 Mixer 不再作为 control plane 组件支持，但 Mixer 策略和遥测插件现在可以通过 Istiodi 中的 WASM 扩展支持。如果您需要集成旧的 Mixer 插件，则可为策略和遥测启用混合程序。

安全发现服务 Service（SDS）用于直接从 Istiod 向 sidecar 分发证书和密钥。在 Red Hat OpenShift Service Mesh 1.1 中，secret 由 Citadel 生成，代理使用它来检索其客户端证书和密钥。

v2.0 不再支持以下注解。如果使用其中一个注解，则必须更新工作负载，然后将其移至 v2.0 Service Mesh control plane。

Red Hat OpenShift Service Mesh 2.0 中的一些功能与之前的版本不同。

模拟 RbacConfig 行为需要编写默认的 AuthorizationPolicy，其设置取决于 RbacConfig 中指定的 spec.mode。

AuthorizationPolicy 包括配置适用的选择器的配置，它类似于 ServiceRoleBinding 提供的函数 ServiceRoleBinding，这与所提供函数 ServiceRole 相似。

在版本 2.0 中默认禁用 Mixer 组件。如果您的工作负载依赖 Mixer 插件，必须将 2.0 ServiceMeshControlPlane 版本配置为包含 Mixer 组件。

要启用 Mixer 策略组件，在 ServiceMeshControlPlane 中添加以下片断。

spec:
  policy:
    type: Mixer

要启用 Mixer 遥测组件，在 ServiceMeshControlPlane 中添加以下片断。

spec:
  telemetry:
    type: Mixer

旧版混合程序插件也可以迁移到 WASM，并使用新的 ServiceMeshExtension（maistra.io/v1alpha1）自定义资源进行集成。

Red Hat OpenShift Service Mesh 2.0 不提供上游 Istio 发行本中的内置 WASM 过滤器。

当使用带有特定工作负载 PeerAuthentication 策略的 mTLS 时，如果工作负载策略与命名空间/全局策略不同，则需要一个对应的 DestinationRule 来允许流量。

auto mTLS 默认启用，但可以通过将 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.automtls 设置为 false 来禁用。禁用自动 mTLS 时，可能需要 DestinationRules 进行服务间的正常通信。例如，将一个命名空间的 PeerAuthentication 设置为 STRICT 可能会阻止其他命名空间中的服务访问它们，除非 DestinationRule 为命名空间中的服务配置 TLS 模式。

有关 mTLS 的详情请参考 启用 mutual Transport Layer Security（mTLS）

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

通过 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.mtls 为 data plane 通信配置双向 TLS，默认为 false。

Istiod 管理服务代理使用的客户端证书和私钥。默认情况下， Istiod 使用自签名证书作为签名，但您可以配置自定义证书和私钥。有关如何配置签名密钥的更多信息，请参阅 添加外部证书颁发机构密钥和证书

Tracing 在 spec.tracing 中配置。目前，Jaeger 是唯一支持的 tracer 类型。sampling 是一个缩放整数，代表 0.01% 增长，例如： 1 为 0.01%，10000 为 100%。可以指定追踪实施和抽样率：

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

Jaeger 在 ServiceMeshControlPlane 资源的 addons 部分进行配置。

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"

您可以使用 install 字段自定义 Jaeger 安装。容器配置，如资源限值是在 spec.runtime.components.jaeger 相关字段中配置的。如果存在与 spec.addons.jaeger.name 值匹配的 Jaeger 资源，Service Mesh control plane 将配置为使用现有安装。使用现有的 Jaeger 资源来完全自定义 Jaeger 安装。

Kiali 和 Grafana 在 ServiceMeshControlPlane 资源的 addons 部分进行配置。

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 资源，Service Mesh control plane 会配置用于 control plane 的 Kiali 资源。Kiali 资源中的一些字段会被覆盖，如 access_namespaces 列表，以及 Grafana、Prometheus 和追踪的端点。使用现有资源来完全自定义 Kiali 安装。

资源在 spec.runtime.<component> 下配置。支持以下组件名称。

一些组件支持资源限制和调度。如需更多信息，请参阅性能和可扩展性。