Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 9. Intégrations

9.1. Intégration de Service Mesh avec OpenShift Serverless
Copier lien

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
Copier lien

  • 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é.

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

  1. 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

  2. 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

  3. Signer le certificat Wildcard : 

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

  4. 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

    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
Copier lien

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

  1. 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:
    1 
    
    - knative-serving
    - <namespace>
    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.

  2. Appliquer la ressource ServiceMeshMemberRoll: 

    $ oc apply -f <filename>

  3. 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>
    1 
    
---
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
    2 
    
     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

    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>

  4. Appliquer les ressources du site Gateway: 

    $ oc apply -f <filename>

  5. 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
    1 
    
  deployments:
    2 
    
  - 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"
    1
    Active l'intégration d'Istio.
    2
    Active l'injection de sidecar pour les pods du plan de données Knative Serving.

  6. Appliquer la ressource KnativeServing: 

    $ oc apply -f <filename>

  7. 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>
    1 
    
  annotations:
    serving.knative.openshift.io/enablePassthrough: "true"
    2 
    
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
    3 
    
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - image: <image_url>
    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.

  8. Appliquer la ressource Service: 

    $ oc apply -f <filename>

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>

    Example command

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

    Exemple de sortie

    Hello Openshift!

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

  1. 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"
...

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

  2. 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: {}
...

  3. 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
...

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

  1. 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>
    1 
    
...
    1
    Une liste d'espaces de noms à intégrer dans Service Mesh.

  2. Appliquer la ressource ServiceMeshMemberRoll: 

    $ oc apply -f <filename>

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

    1. 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>
      1 
      
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          knative.openshift.io/part-of: "openshift-serverless"
  podSelector: {}
  policyTypes:
  - Ingress
...
      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

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

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

    2. Appliquer la ressource NetworkPolicy: 

      $ oc apply -f <filename>

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"
    1 
    
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

    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.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début