1.11. Mise à niveau du maillage de services

Les unités architecturales utilisées par les versions précédentes ont été remplacées par Istiod. Dans la version 2.0, les composants du plan de contrôle Service Mesh - Mixer, Pilot, Citadel, Galley - et la fonctionnalité de l'injecteur sidecar ont été combinés en un seul composant, Istiod.

Bien que Mixer ne soit plus supporté en tant que composant du plan de contrôle, les plugins de politique et de télémétrie Mixer sont maintenant supportés par des extensions WASM dans Istiod. Mixer peut être activé pour la politique et la télémétrie si vous avez besoin d'intégrer des plugins Mixer hérités.

Secret Discovery Service (SDS) est utilisé pour distribuer des certificats et des clés aux sidecars directement depuis Istiod. Dans Red Hat OpenShift Service Mesh version 1.1, des secrets ont été générés par Citadel, qui ont été utilisés par les proxys pour récupérer les certificats et les clés de leurs clients.

Les annotations suivantes ne sont plus prises en charge dans la version 2.0. Si vous utilisez l'une de ces annotations, vous devez mettre à jour votre charge de travail avant de la transférer vers un plan de contrôle Service Mesh v2.0.

Certaines fonctionnalités de Red Hat OpenShift Service Mesh 2.0 fonctionnent différemment de celles des versions précédentes.

Pour imiter le comportement de RbacConfig, il faut écrire une AuthorizationPolicy par défaut dont les paramètres dépendent du spec.mode spécifié dans RbacConfig.

AuthorizationPolicy comprend la configuration à la fois du sélecteur auquel la configuration s'applique, qui est similaire à la fonction ServiceRoleBinding, et des règles qui doivent être appliquées, qui sont similaires à la fonction ServiceRole.

Les composants Mixer sont désactivés par défaut dans la version 2.0. Si votre charge de travail repose sur des plugins Mixer, vous devez configurer votre version 2.0 ServiceMeshControlPlane pour inclure les composants Mixer.

Pour activer les composants de la politique Mixer, ajoutez l'extrait suivant à votre site ServiceMeshControlPlane.

spec:
  policy:
    type: Mixer

Pour activer les composants de télémétrie de Mixer, ajoutez l'extrait suivant à votre site ServiceMeshControlPlane.

spec:
  telemetry:
    type: Mixer

Les anciens plugins de mélangeur peuvent également être migrés vers WASM et intégrés à l'aide de la nouvelle ressource personnalisée ServiceMeshExtension (maistra.io/v1alpha1).

Les filtres WASM intégrés inclus dans la distribution Istio en amont ne sont pas disponibles dans Red Hat OpenShift Service Mesh 2.0.

Lors de l'utilisation de mTLS avec des stratégies PeerAuthentication spécifiques à la charge de travail, une DestinationRule correspondante est nécessaire pour autoriser le trafic si la stratégie de la charge de travail diffère de la stratégie globale/de l'espace de noms.

La fonction Auto mTLS est activée par défaut, mais peut être désactivée en attribuant la valeur false à spec.security.dataPlane.automtls dans la ressource ServiceMeshControlPlane. Lors de la désactivation de mTLS auto, les règles de destination peuvent être nécessaires pour assurer une communication correcte entre les services. Par exemple, le fait de définir PeerAuthentication sur STRICT pour un espace de noms peut empêcher les services d'autres espaces de noms d'y accéder, à moins qu'une règle de destination ne configure le mode TLS pour les services de l'espace de noms.

Pour plus d'informations sur mTLS, voir Activation de la sécurité mutuelle de la couche transport (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

TLS mutuel pour la communication du plan de données est configuré via spec.security.dataPlane.mtls dans la ressource ServiceMeshControlPlane, qui est false par défaut.

Istiod gère les certificats clients et les clés privées utilisés par les proxys de services. Par défaut, Istiod utilise un certificat auto-signé pour la signature, mais vous pouvez configurer un certificat et une clé privée personnalisés. Pour plus d'informations sur la configuration des clés de signature, voir Ajout d'une clé et d'un certificat d'autorité de certification externe

Le traçage est configuré à l'adresse spec.tracing. Actuellement, le seul type de traceur pris en charge est Jaeger. L'échantillonnage est un nombre entier échelonné représentant des incréments de 0,01 %, par exemple, 1 est 0,01 et 10000 est 100 %. La mise en œuvre du traçage et le taux d'échantillonnage peuvent être spécifiés :

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

Jaeger est configuré dans la section addons de la ressource ServiceMeshControlPlane.

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"

L'installation de Jaeger peut être personnalisée à l'aide du champ install. La configuration des conteneurs, comme les limites des ressources, est configurée dans les champs liés à spec.runtime.components.jaeger. Si une ressource Jaeger correspondant à la valeur de spec.addons.jaeger.name existe, le plan de contrôle Service Mesh sera configuré pour utiliser l'installation existante. Utilisez une ressource Jaeger existante pour personnaliser entièrement votre installation Jaeger.

Kiali et Grafana sont configurés dans la section addons de la ressource ServiceMeshControlPlane.

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

Les installations Grafana et Kiali peuvent être personnalisées via leurs champs install respectifs. La personnalisation des conteneurs, comme les limites de ressources, est configurée dans spec.runtime.components.kiali et spec.runtime.components.grafana. Si une ressource Kiali existante correspondant à la valeur du nom existe, le plan de contrôle Service Mesh configure la ressource Kiali pour l'utiliser avec le plan de contrôle. Certains champs de la ressource Kiali sont remplacés, comme la liste accessible_namespaces, ainsi que les points de terminaison pour Grafana, Prometheus et le traçage. Utilisez une ressource existante pour personnaliser entièrement votre installation Kiali.

Les ressources sont configurées sous spec.runtime.<component>. Les noms de composants suivants sont pris en charge.

Certains composants prennent en charge la limitation des ressources et la planification. Pour plus d'informations, voir Performances et évolutivité.