Chapitre 9. Intégrations

9.1. Intégration de Service Mesh avec OpenShift Serverless

L'opérateur OpenShift Serverless fournit Kourier comme ingress par défaut pour Knative. Cependant, vous pouvez utiliser Service Mesh avec OpenShift Serverless, que Kourier soit activé ou non. L'intégration avec Kourier désactivé vous permet de configurer des options de réseau et de routage supplémentaires que l'ingress de Kourier ne prend pas en charge, telles que la fonctionnalité mTLS.

Important

OpenShift Serverless ne prend en charge que l'utilisation des fonctionnalités de Red Hat OpenShift Service Mesh qui sont explicitement documentées dans ce guide, et ne prend pas en charge d'autres fonctionnalités non documentées.

9.1.1. Conditions préalables

Les exemples des procédures suivantes utilisent le domaine example.com. Le certificat d'exemple pour ce domaine est utilisé comme autorité de certification (CA) qui signe le certificat du sous-domaine.
Pour effectuer et vérifier ces procédures dans le cadre de votre déploiement, vous devez disposer d'un certificat signé par une autorité de certification publique largement reconnue ou par une autorité de certification fournie par votre organisation. Les exemples de commandes doivent être adaptés en fonction du domaine, du sous-domaine et de l'autorité de certification.
Vous devez configurer le certificat wildcard pour qu'il corresponde au domaine de votre cluster OpenShift Container Platform. Par exemple, si l'adresse de votre console OpenShift Container Platform est https://console-openshift-console.apps.openshift.example.comvous devez configurer le certificat Wildcard pour que le domaine soit *.apps.openshift.example.com. Pour plus d'informations sur la configuration des certificats génériques, consultez la rubrique suivante à propos de Creating a certificate to encrypt incoming external traffic.
Si vous souhaitez utiliser n'importe quel nom de domaine, y compris ceux qui ne sont pas des sous-domaines du domaine de cluster OpenShift Container Platform par défaut, vous devez configurer le mappage de domaine pour ces domaines. Pour plus d'informations, voir la documentation OpenShift Serverless sur la création d'un mappage de domaine personnalisé.

9.1.2. Création d'un certificat pour crypter le trafic externe entrant

Par défaut, la fonctionnalité Service Mesh mTLS ne sécurise que le trafic à l'intérieur du Service Mesh lui-même, entre la passerelle d'entrée et les pods individuels qui ont des sidecars. Pour chiffrer le trafic lorsqu'il circule dans le cluster OpenShift Container Platform, vous devez générer un certificat avant d'activer l'intégration OpenShift Serverless et Service Mesh.

Conditions préalables

Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
Vous avez installé OpenShift Serverless Operator et Knative Serving.
Installez le CLI OpenShift (oc).
Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

Créez un certificat racine et une clé privée qui signent les certificats de vos services Knative :

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
    -subj '/O=Example Inc./CN=example.com' \
    -keyout root.key \
    -out root.crt

$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
    -subj '/O=Example Inc./CN=example.com' \
    -keyout root.key \
    -out root.crt

Copy to Clipboard

Créer un certificat de type "wildcard" :

openssl req -nodes -newkey rsa:2048 \
    -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
    -keyout wildcard.key \
    -out wildcard.csr

$ openssl req -nodes -newkey rsa:2048 \
    -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
    -keyout wildcard.key \
    -out wildcard.csr

Copy to Clipboard

Signer le certificat Wildcard :

openssl x509 -req -days 365 -set_serial 0 \
    -CA root.crt \
    -CAkey root.key \
    -in wildcard.csr \
    -out wildcard.crt

$ openssl x509 -req -days 365 -set_serial 0 \
    -CA root.crt \
    -CAkey root.key \
    -in wildcard.csr \
    -out wildcard.crt

Copy to Clipboard

Créez un secret en utilisant le certificat générique :
```
oc create -n istio-system secret tls wildcard-certs \
    --key=wildcard.key \
    --cert=wildcard.crt
```
```
$ oc create -n istio-system secret tls wildcard-certs \
    --key=wildcard.key \
    --cert=wildcard.crt
```
Copy to Clipboard
Ce certificat est récupéré par les passerelles créées lors de l'intégration d'OpenShift Serverless avec Service Mesh, afin que la passerelle d'entrée serve le trafic avec ce certificat.

9.1.3. Intégration de Service Mesh avec OpenShift Serverless

Vous pouvez intégrer Service Mesh avec OpenShift Serverless sans utiliser Kourier comme ingress par défaut. Pour ce faire, n'installez pas le composant Knative Serving avant d'avoir effectué la procédure suivante. Il y a des étapes supplémentaires requises lors de la création de la définition de ressource personnalisée (CRD) KnativeServing pour intégrer Knative Serving avec Service Mesh, qui ne sont pas couvertes dans la procédure générale d'installation de Knative Serving. Cette procédure peut être utile si vous souhaitez intégrer Service Mesh comme ingress par défaut et unique pour votre installation OpenShift Serverless.

Conditions préalables

Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
Installez Red Hat OpenShift Service Mesh Operator et créez une ressource ServiceMeshControlPlane dans l'espace de noms istio-system. Si vous souhaitez utiliser la fonctionnalité mTLS, vous devez également définir le champ spec.security.dataPlane.mtls de la ressource ServiceMeshControlPlane sur true.
Important
L'utilisation d'OpenShift Serverless avec Service Mesh n'est prise en charge qu'avec Red Hat OpenShift Service Mesh version 2.0.5 ou ultérieure.
Installer l'opérateur OpenShift Serverless.
Installez le CLI OpenShift (oc).

Procédure

Ajoutez à l'objet ServiceMeshMemberRoll, en tant que membres, les espaces de noms que vous souhaitez intégrer à Service Mesh :

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members: 
    - knative-serving
    - <namespace>

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:


    - knative-serving
    - <namespace>

Copy to Clipboard

1: Une liste d'espaces de noms à intégrer dans Service Mesh.

Important

Cette liste d'espaces de noms doit inclure l'espace de noms knative-serving.

Appliquer la ressource ServiceMeshMemberRoll:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

Créez les passerelles nécessaires pour que le Service Mesh puisse accepter le trafic :

Exemple knative-local-gateway objet en utilisant HTTP

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: knative-ingress-gateway
  namespace: knative-serving
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*"
      tls:
        mode: SIMPLE
        credentialName: <wildcard_certs> 
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: knative-local-gateway
 namespace: knative-serving
spec:
 selector:
   istio: ingressgateway
 servers:
   - port:
       number: 8081
       name: http
       protocol: HTTP 
     hosts:
       - "*"
---
apiVersion: v1
kind: Service
metadata:
 name: knative-local-gateway
 namespace: istio-system
 labels:
   experimental.istio.io/disable-gateway-port-translation: "true"
spec:
 type: ClusterIP
 selector:
   istio: ingressgateway
 ports:
   - name: http2
     port: 80
     targetPort: 8081

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: knative-ingress-gateway
  namespace: knative-serving
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*"
      tls:
        mode: SIMPLE
        credentialName: <wildcard_certs>


---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: knative-local-gateway
 namespace: knative-serving
spec:
 selector:
   istio: ingressgateway
 servers:
   - port:
       number: 8081
       name: http
       protocol: HTTP


     hosts:
       - "*"
---
apiVersion: v1
kind: Service
metadata:
 name: knative-local-gateway
 namespace: istio-system
 labels:
   experimental.istio.io/disable-gateway-port-translation: "true"
spec:
 type: ClusterIP
 selector:
   istio: ingressgateway
 ports:
   - name: http2
     port: 80
     targetPort: 8081

Copy to Clipboard

1: Ajoutez le nom du secret qui contient le certificat générique.
2: Le site knative-local-gateway sert le trafic HTTP. L'utilisation de HTTP signifie que le trafic provenant de l'extérieur de Service Mesh, mais utilisant un nom d'hôte interne, tel que example.default.svc.cluster.local, n'est pas crypté. Vous pouvez configurer le cryptage pour ce chemin en créant un autre certificat générique et une passerelle supplémentaire qui utilise une spécification protocol différente.

Exemple knative-local-gateway objet utilisant HTTPS

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: knative-local-gateway
  namespace: knative-serving
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*"
      tls:
        mode: SIMPLE
        credentialName: <wildcard_certs>

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: knative-local-gateway
  namespace: knative-serving
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*"
      tls:
        mode: SIMPLE
        credentialName: <wildcard_certs>

Copy to Clipboard

Appliquer les ressources du site Gateway:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

Installez Knative Serving en créant la définition de ressource personnalisée (CRD) suivante KnativeServing, qui permet également l'intégration d'Istio :

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true 
  deployments: 
  - name: activator
    annotations:
      "sidecar.istio.io/inject": "true"
      "sidecar.istio.io/rewriteAppHTTPProbers": "true"
  - name: autoscaler
    annotations:
      "sidecar.istio.io/inject": "true"
      "sidecar.istio.io/rewriteAppHTTPProbers": "true"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true


  deployments:


  - name: activator
    annotations:
      "sidecar.istio.io/inject": "true"
      "sidecar.istio.io/rewriteAppHTTPProbers": "true"
  - name: autoscaler
    annotations:
      "sidecar.istio.io/inject": "true"
      "sidecar.istio.io/rewriteAppHTTPProbers": "true"

Copy to Clipboard

1: Active l'intégration d'Istio.
2: Active l'injection de sidecar pour les pods du plan de données Knative Serving.

Appliquer la ressource KnativeServing:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

Créez un service Knative pour lequel l'injection de sidecar est activée et qui utilise une route pass-through :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: <service_name>
  namespace: <namespace> 
  annotations:
    serving.knative.openshift.io/enablePassthrough: "true" 
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true" 
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - image: <image_url>

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: <service_name>
  namespace: <namespace>


  annotations:
    serving.knative.openshift.io/enablePassthrough: "true"


spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"


        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - image: <image_url>

Copy to Clipboard

1: Un espace de noms qui fait partie du rouleau de membres du Service Mesh.
2: Indique à Knative Serving de générer une route OpenShift Container Platform pass-through enabled, de sorte que les certificats que vous avez générés sont servis par la passerelle d'entrée directement.
3: Injecte des sidecars Service Mesh dans les pods de service Knative.

Appliquer la ressource Service:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

Vérification

Accédez à votre application sans serveur en utilisant une connexion sécurisée qui est maintenant approuvée par l'autorité de certification :

curl --cacert root.crt <service_url>

curl --cacert root.crt <service_url>

Copy to Clipboard

Example command

curl --cacert root.crt https://hello-default.apps.openshift.example.com

$ curl --cacert root.crt https://hello-default.apps.openshift.example.com

Copy to Clipboard

Exemple de sortie

Hello Openshift!

Hello Openshift!

Copy to Clipboard

9.1.4. Activation des métriques Knative Serving lors de l'utilisation de Service Mesh avec mTLS

Si Service Mesh est activé avec mTLS, les métriques pour Knative Serving sont désactivées par défaut, car Service Mesh empêche Prometheus de récupérer les métriques. Cette section explique comment activer les métriques Knative Serving lors de l'utilisation de Service Mesh et de mTLS.

Conditions préalables

Vous avez installé OpenShift Serverless Operator et Knative Serving sur votre cluster.
Vous avez installé Red Hat OpenShift Service Mesh avec la fonctionnalité mTLS activée.
Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
Installez le CLI OpenShift (oc).
Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

Spécifier prometheus comme metrics.backend-destination dans la spécification observability de la ressource personnalisée (CR) Knative Serving :

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    observability:
      metrics.backend-destination: "prometheus"
...

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    observability:
      metrics.backend-destination: "prometheus"
...

Copy to Clipboard

Cette étape permet d'éviter que les métriques soient désactivées par défaut.

Appliquez la stratégie réseau suivante pour autoriser le trafic en provenance de l'espace de noms Prometheus :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring-ns
  namespace: knative-serving
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: "openshift-monitoring"
  podSelector: {}
...

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring-ns
  namespace: knative-serving
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: "openshift-monitoring"
  podSelector: {}
...

Copy to Clipboard

Modifier et réappliquer le plan de contrôle Service Mesh par défaut dans l'espace de noms istio-system, de manière à ce qu'il inclue la spécification suivante :

...
spec:
  proxy:
    networking:
      trafficControl:
        inbound:
          excludedPorts:
          - 8444
...

...
spec:
  proxy:
    networking:
      trafficControl:
        inbound:
          excludedPorts:
          - 8444
...

Copy to Clipboard

9.1.5. Intégration de Service Mesh avec OpenShift Serverless lorsque Kourier est activé

Vous pouvez utiliser Service Mesh avec OpenShift Serverless même si Kourier est déjà activé. Cette procédure peut être utile si vous avez déjà installé Knative Serving avec Kourier activé, mais que vous décidez d'ajouter une intégration Service Mesh plus tard.

Conditions préalables

Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
Installez le CLI OpenShift (oc).
Installez OpenShift Serverless Operator et Knative Serving sur votre cluster.
Installer Red Hat OpenShift Service Mesh. OpenShift Serverless avec Service Mesh et Kourier est pris en charge pour une utilisation avec les versions 1.x et 2.x de Red Hat OpenShift Service Mesh.

Procédure

Ajoutez à l'objet ServiceMeshMemberRoll, en tant que membres, les espaces de noms que vous souhaitez intégrer à Service Mesh :

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
    - <namespace> 
...

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
    - <namespace>

...

Copy to Clipboard

1: Une liste d'espaces de noms à intégrer dans Service Mesh.

Appliquer la ressource ServiceMeshMemberRoll:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

Créer une stratégie de réseau qui autorise le flux de trafic des pods du système Knative vers les services Knative :

Pour chaque espace de noms que vous souhaitez intégrer à Service Mesh, créez une ressource NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-serving-system-namespace
  namespace: <namespace> 
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          knative.openshift.io/part-of: "openshift-serverless"
  podSelector: {}
  policyTypes:
  - Ingress
...

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-serving-system-namespace
  namespace: <namespace>


spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          knative.openshift.io/part-of: "openshift-serverless"
  podSelector: {}
  policyTypes:
  - Ingress
...

Copy to Clipboard

1: Ajoutez l'espace de noms que vous souhaitez intégrer à Service Mesh.

Note

Le label knative.openshift.io/part-of: "openshift-serverless" a été ajouté dans OpenShift Serverless 1.22.0. Si vous utilisez OpenShift Serverless 1.21.1 ou une version antérieure, ajoutez le label knative.openshift.io/part-of aux espaces de noms knative-serving et knative-serving-ingress.

Ajouter l'étiquette à l'espace de noms knative-serving:

oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless

$ oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless

Copy to Clipboard

Ajouter l'étiquette à l'espace de noms knative-serving-ingress:

oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless

$ oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless

Copy to Clipboard

Appliquer la ressource NetworkPolicy:
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard

9.1.6. Améliorer l'utilisation de la mémoire de net-istio en utilisant le filtrage secret pour Service Mesh

Par défaut, l'implémentation des informateurs pour la bibliothèque Kubernetes client-go récupère toutes les ressources d'un type particulier. Cela peut entraîner une surcharge substantielle lorsque de nombreuses ressources sont disponibles, ce qui peut faire échouer le contrôleur d'entrée Knative net-istio sur les grands clusters en raison de fuites de mémoire. Cependant, un mécanisme de filtrage est disponible pour le contrôleur d'entrée Knative net-istio, ce qui permet au contrôleur de ne récupérer que les secrets liés à Knative. Vous pouvez activer ce mécanisme en ajoutant une annotation à la ressource personnalisée (CR) KnativeServing.

Important

Si vous activez le filtrage des secrets, tous vos secrets doivent être étiquetés avec networking.internal.knative.dev/certificate-uid: "<id>". Sinon, Knative Serving ne les détecte pas, ce qui entraîne des échecs. Vous devez étiqueter à la fois les nouveaux secrets et les secrets existants.

Conditions préalables

Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
Installez Red Hat OpenShift Service Mesh. OpenShift Serverless with Service Mesh only est pris en charge pour une utilisation avec Red Hat OpenShift Service Mesh version 2.0.5 ou ultérieure.
Installez OpenShift Serverless Operator et Knative Serving.
Installez le CLI OpenShift (oc).

Procédure

Ajouter l'annotation serverless.openshift.io/enable-secret-informer-filtering à la CR KnativeServing:

Exemple KnativeServing CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
  annotations:
    serverless.openshift.io/enable-secret-informer-filtering: "true" 
spec:
  ingress:
    istio:
      enabled: true
  deployments:
    - annotations:
        sidecar.istio.io/inject: "true"
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
      name: activator
    - annotations:
        sidecar.istio.io/inject: "true"
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
      name: autoscaler

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
  annotations:
    serverless.openshift.io/enable-secret-informer-filtering: "true"


spec:
  ingress:
    istio:
      enabled: true
  deployments:
    - annotations:
        sidecar.istio.io/inject: "true"
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
      name: activator
    - annotations:
        sidecar.istio.io/inject: "true"
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
      name: autoscaler

Copy to Clipboard

1: L'ajout de cette annotation injecte une variable d'environnement, ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true, dans le pod contrôleur net-istio.

Note

Cette annotation est ignorée si vous définissez une valeur différente en remplaçant les déploiements.

Retour au début

Chapitre 9. Intégrations

9.1. Intégration de Service Mesh avec OpenShift Serverless

9.1.1. Conditions préalables

9.1.2. Création d'un certificat pour crypter le trafic externe entrant

9.1.3. Intégration de Service Mesh avec OpenShift Serverless

9.1.4. Activation des métriques Knative Serving lors de l'utilisation de Service Mesh avec mTLS

9.1.5. Intégration de Service Mesh avec OpenShift Serverless lorsque Kourier est activé

9.1.6. Améliorer l'utilisation de la mémoire de net-istio en utilisant le filtrage secret pour Service Mesh

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links