Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

1.21. Utilisation de l'adaptateur 3scale Istio

download PDF

L'adaptateur 3scale Istio est un adaptateur optionnel qui vous permet d'étiqueter un service fonctionnant dans Red Hat OpenShift Service Mesh et d'intégrer ce service avec la solution 3scale API Management. Il n'est pas requis pour Red Hat OpenShift Service Mesh.

Important

Vous ne pouvez utiliser l'adaptateur 3scale Istio qu'avec Red Hat OpenShift Service Mesh versions 2.0 et inférieures. Le composant Mixer a été déprécié dans la version 2.0 et supprimé dans la version 2.1. Pour Red Hat OpenShift Service Mesh versions 2.1.0 et ultérieures, vous devez utiliser le module 3scale WebAssembly.

Si vous souhaitez activer le cache backend 3scale avec l'adaptateur Istio 3scale, vous devez également activer la politique Mixer et la télémétrie Mixer. Voir Déployer le plan de contrôle Red Hat OpenShift Service Mesh.

1.21.1. Intégrer l'adaptateur 3scale avec Red Hat OpenShift Service Mesh

Vous pouvez utiliser ces exemples pour configurer les requêtes vers vos services en utilisant l'adaptateur Istio 3scale.

Prérequis :

  • Red Hat OpenShift Service Mesh version 2.x
  • Un compte 3scale fonctionnel(SaaS ou 3scale 2.9 On-Premises)
  • L'activation du backend cache nécessite 3scale 2.9 ou plus
  • Prérequis de Red Hat OpenShift Service Mesh
  • Assurez-vous que l'application de la politique Mixer est activée. La section Mise à jour de l'application de la politique Mixer fournit des instructions pour vérifier l'état actuel de l'application de la politique Mixer et activer l'application de la politique.

  • La politique de mixage et la télémétrie doivent être activées si vous utilisez un plugin de mixage.

    • Vous devrez configurer correctement le plan de contrôle Service Mesh (SMCP) lors de la mise à niveau.
Note

Pour configurer l'adaptateur 3scale Istio, reportez-vous aux ressources personnalisées Red Hat OpenShift Service Mesh pour obtenir des instructions sur l'ajout de paramètres d'adaptateur au fichier de ressources personnalisées.

Note

Portez une attention particulière à la ressource kind: handler. Vous devez la mettre à jour avec les informations d'identification de votre compte 3scale. Vous pouvez optionnellement ajouter une ressource service_id à un handler, mais ceci n'est conservé que pour la compatibilité ascendante, puisque cela rendrait le handler utile uniquement pour un seul service dans votre compte 3scale. Si vous ajoutez service_id à un handler, l'activation de 3scale pour d'autres services nécessite la création d'autres handlers avec des service_ids différents.

Utilisez un seul gestionnaire par compte 3scale en suivant les étapes ci-dessous :

Procédure

  1. Créez un gestionnaire pour votre compte 3scale et indiquez les informations d'identification de votre compte. N'indiquez pas d'identifiant de service. 

      apiVersion: "config.istio.io/v1alpha2"
  kind: handler
  metadata:
   name: threescale
  spec:
   adapter: threescale
   params:
     system_url: "https://<organization>-admin.3scale.net/"
     access_token: "<ACCESS_TOKEN>"
   connection:
     address: "threescale-istio-adapter:3333"

    En option, vous pouvez fournir un champ backend_url dans la section params pour remplacer l'URL fournie par la configuration 3scale. Cela peut être utile si l'adaptateur fonctionne sur le même cluster que l'instance 3scale sur site, et que vous souhaitez utiliser le DNS interne du cluster.

  2. Modifiez ou corrigez la ressource Déploiement de tous les services appartenant à votre compte 3scale comme suit :

    1. Ajouter l'étiquette "service-mesh.3scale.net/service-id" avec une valeur correspondant à une service_id valide.
    2. Ajoutez l'étiquette "service-mesh.3scale.net/credentials" dont la valeur est celle de name of the handler resource de l'étape 1.
  3. Faites l'étape 2 pour le lier à vos identifiants de compte 3scale et à son identifiant de service, lorsque vous avez l'intention d'ajouter d'autres services.

  4. Modifiez la configuration de la règle avec votre configuration 3scale pour envoyer la règle au gestionnaire 3scale.

    Exemple de configuration d'une règle

      apiVersion: "config.istio.io/v1alpha2"
  kind: rule
  metadata:
    name: threescale
  spec:
    match: destination.labels["service-mesh.3scale.net"] == "true"
    actions:
      - handler: threescale.handler
        instances:
          - threescale-authorization.instance

1.21.1.1. Générer des ressources personnalisées à 3 échelles

L'adaptateur comprend un outil qui vous permet de générer les ressources personnalisées handler, instance et rule.

Tableau 1.29. Utilisation
OptionDescriptionExigéeValeur par défaut

-h, --help

Produit une sortie d'aide pour les options disponibles

Non

 

--name

Nom unique pour cet URL, paire de jetons

Oui

 

-n, --namespace

Espace de noms pour générer des modèles

Non

istio-system

-t, --token

jeton d'accès 3scale

Oui

 

-u, --url

uRL du portail administratif 3scale

Oui

 

--backend-url

uRL du backend 3scale. Si elle est définie, elle remplace la valeur lue dans la configuration du système

Non

 

-s, --service

iD API/Service 3scale

Non

 

--auth

modèle d'authentification à 3 niveaux à spécifier (1=clé API, 2=identification de l'application/clé de l'application, 3=OIDC)

Non

Hybride

-o, --output

Fichier dans lequel enregistrer les manifestes produits

Non

Sortie standard

--version

Affiche la version de l'interface de programmation et quitte immédiatement

Non

 
1.21.1.1.1. Générer des modèles à partir d'exemples d'URL
Note
  • Exécutez les commandes suivantes via oc exec à partir de l'image du conteneur de l'adaptateur 3scale dans Générer des manifestes à partir d'un adaptateur déployé.
  • Utilisez la commande 3scale-config-gen pour éviter les erreurs de syntaxe et d'indentation de YAML.
  • Vous pouvez omettre le site --service si vous utilisez les annotations.
  • Cette commande doit être invoquée à partir de l'image du conteneur via oc exec.

Procédure

  • Utilisez la commande 3scale-config-gen pour autogénérer des fichiers modèles permettant à la paire token, URL d'être partagée par plusieurs services en tant que gestionnaire unique : 

    $ 3scale-config-gen --name=admin-credentials --url="https://<organization>-admin.3scale.net:443" --token="[redacted]"

  • L'exemple suivant génère les modèles avec l'identifiant du service intégré dans le gestionnaire : 

    $ 3scale-config-gen --url="https://<organization>-admin.3scale.net" --name="my-unique-id" --service="123456789" --token="[redacted]"

Ressources supplémentaires

1.21.1.2. Générer des manifestes à partir d'un adaptateur déployé

Note
  • NAME est un identifiant que vous utilisez pour vous identifier auprès du service que vous gérez avec 3scale.
  • La référence CREDENTIALS_NAME est un identifiant qui correspond à la section match dans la configuration de la règle. Si vous utilisez l'outil CLI, l'identifiant NAME est automatiquement utilisé.
  • Sa valeur n'a pas besoin d'être spécifique : la valeur de l'étiquette doit simplement correspondre au contenu de la règle. Voir Routage du trafic de service à travers l'adaptateur pour plus d'informations.

  1. Exécutez cette commande pour générer des manifestes à partir d'un adaptateur déployé dans l'espace de noms istio-system: 

    $ export NS="istio-system" URL="https://replaceme-admin.3scale.net:443" NAME="name" TOKEN="token"
oc exec -n ${NS} $(oc get po -n ${NS} -o jsonpath='{.items[?(@.metadata.labels.app=="3scale-istio-adapter")].metadata.name}') \
-it -- ./3scale-config-gen \
--url ${URL} --name ${NAME} --token ${TOKEN} -n ${NS}
  2. Cela produira des exemples de sortie dans le terminal. Modifiez ces exemples si nécessaire et créez les objets à l'aide de la commande oc create.

  3. Lorsque la requête atteint l'adaptateur, ce dernier doit savoir comment le service correspond à une API sur 3scale. Vous pouvez fournir cette information de deux façons :

    1. Étiqueter la charge de travail (recommandé)
    2. Le code dur du gestionnaire est le suivant service_id

  4. Mettre à jour la charge de travail avec les annotations requises :

    Note

    Il suffit de mettre à jour l'identifiant de service fourni dans cet exemple s'il n'est pas déjà intégré dans le gestionnaire. The setting in the handler takes precedence. 

    $ export CREDENTIALS_NAME="replace-me"
export SERVICE_ID="replace-me"
export DEPLOYMENT="replace-me"
patch="$(oc get deployment "${DEPLOYMENT}"
patch="$(oc get deployment "${DEPLOYMENT}" --template='{"spec":{"template":{"metadata":{"labels":{ {{ range $k,$v := .spec.template.metadata.labels }}"{{ $k }}":"{{ $v }}",{{ end }}"service-mesh.3scale.net/service-id":"'"${SERVICE_ID}"'","service-mesh.3scale.net/credentials":"'"${CREDENTIALS_NAME}"'"}}}}}' )"
oc patch deployment "${DEPLOYMENT}" --patch ''"${patch}"''

1.21.1.3. Acheminement du trafic de service via l'adaptateur

Suivez les étapes suivantes pour générer du trafic pour votre service grâce à l'adaptateur 3scale.

Conditions préalables

  • Les informations d'identification et l'identifiant de service de votre administrateur 3scale.

Procédure

  1. Correspondre à la règle destination.labels["service-mesh.3scale.net/credentials"] == "threescale" que vous avez précédemment créée dans la configuration, dans la ressource kind: rule.
  2. Ajoutez l'étiquette ci-dessus à PodTemplateSpec sur le Déploiement de la charge de travail cible pour intégrer un service. la valeur, threescale, fait référence au nom du gestionnaire généré. Ce gestionnaire stocke le jeton d'accès requis pour appeler 3scale.
  3. Ajoutez l'étiquette destination.labels["service-mesh.3scale.net/service-id"] == "replace-me" à la charge de travail pour transmettre l'identifiant du service à l'adaptateur via l'instance au moment de la demande.

1.21.2. Configurer les paramètres d'intégration dans 3scale

Suivez cette procédure pour configurer les paramètres d'intégration de 3scale.

Note

Pour les clients SaaS de 3scale, Red Hat OpenShift Service Mesh est activé dans le cadre du programme Early Access.

Procédure

  1. Naviguez vers [your_API_name] Integration
  2. Cliquez sur Settings.

  3. Sélectionnez l'option Istio sous Deployment.

    • L'option API Key (user_key) sous Authentication est sélectionnée par défaut.
  4. Cliquez sur Update Product pour enregistrer votre sélection.
  5. Cliquez sur Configuration.
  6. Cliquez sur Update Configuration.

1.21.3. Comportement de mise en cache

Les réponses des API du système 3scale sont mises en cache par défaut dans l'adaptateur. Les entrées sont supprimées du cache lorsqu'elles sont plus anciennes que la valeur cacheTTLSeconds. Par défaut également, le rafraîchissement automatique des entrées mises en cache sera tenté quelques secondes avant leur expiration, sur la base de la valeur cacheRefreshSeconds. Vous pouvez désactiver le rafraîchissement automatique en définissant cette valeur à un niveau supérieur à la valeur cacheTTLSeconds.

La mise en cache peut être entièrement désactivée en donnant à cacheEntriesMax une valeur non positive.

En utilisant le processus de rafraîchissement, les valeurs mises en cache dont les hôtes deviennent inaccessibles seront réessayées avant d'être finalement purgées lorsqu'elles auront dépassé leur date d'expiration.

1.21.4. Authentification des demandes

Cette version prend en charge les méthodes d'authentification suivantes :

  • Standard API Keysles systèmes d'authentification sont des chaînes ou des hachages aléatoires uniques qui servent d'identificateur et de jeton secret.
  • Application identifier and key pairsles chaînes d'identification immuables et les chaînes de clés secrètes mutables.
  • OpenID authentication methodchaîne d'identification du client analysée à partir du jeton Web JSON.

1.21.4.1. Application de modèles d'authentification

Modifiez la ressource personnalisée instance, comme illustré dans les exemples de méthodes d'authentification suivants, pour configurer le comportement d'authentification. Vous pouvez accepter les informations d'authentification de :

  • En-têtes de la demande
  • Paramètres de la demande
  • Les en-têtes et les paramètres de la requête
Note

Lorsque vous spécifiez des valeurs à partir d'en-têtes, elles doivent être en minuscules. Par exemple, si vous souhaitez envoyer un en-tête sous la forme User-Key, il doit être référencé dans la configuration sous la forme request.headers["user-key"].

1.21.4.1.1. Méthode d'authentification de la clé API

Service Mesh recherche la clé API dans les paramètres de requête et les en-têtes de demande spécifiés dans l'option user du paramètre de ressource personnalisée subject. Il vérifie les valeurs dans l'ordre indiqué dans le fichier de ressources personnalisées. Vous pouvez limiter la recherche de la clé API aux paramètres de requête ou aux en-têtes de requête en omettant l'option indésirable.

Dans cet exemple, Service Mesh recherche la clé API dans le paramètre de requête user_key. Si la clé API ne figure pas dans le paramètre de la requête, Service Mesh vérifie alors l'en-tête user-key.

Exemple de méthode d'authentification par clé API

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

Si vous souhaitez que l'adaptateur examine un paramètre de requête ou un en-tête de requête différent, modifiez le nom en conséquence. Par exemple, pour vérifier la clé API dans un paramètre de requête nommé "key", remplacez request.query_params["user_key"] par request.query_params["key"].

1.21.4.1.2. Méthode d'authentification de l'ID de l'application et de la paire de clés de l'application

Service Mesh recherche l'identifiant et la clé de l'application dans les paramètres de la requête et les en-têtes de la demande, comme spécifié dans l'option properties du paramètre de ressource personnalisée subject. La clé d'application est facultative. Il vérifie les valeurs dans l'ordre indiqué dans le fichier de ressources personnalisées. Vous pouvez limiter la recherche des informations d'identification aux paramètres de requête ou aux en-têtes de requête en n'incluant pas l'option "unwanted".

Dans cet exemple, Service Mesh recherche d'abord l'identifiant et la clé de l'application dans les paramètres de la requête, puis passe aux en-têtes de la requête si nécessaire.

Exemple de méthode d'authentification par ID d'application et paire de clés d'application

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

Si vous souhaitez que l'adaptateur examine un paramètre de requête ou un en-tête de requête différent, modifiez le nom en conséquence. Par exemple, pour vérifier l'ID de l'application dans un paramètre de requête nommé identification, remplacez request.query_params["app_id"] par request.query_params["identification"].

1.21.4.1.3. Méthode d'authentification OpenID

Pour utiliser le champ OpenID Connect (OIDC) authentication method, utilisez la valeur properties sur le champ subject pour définir client_id, et éventuellement app_key.

Vous pouvez manipuler cet objet à l'aide des méthodes décrites précédemment. Dans l'exemple de configuration ci-dessous, l'identifiant du client (ID de l'application) est extrait du jeton Web JSON (JWT) sous l'étiquette azp. Vous pouvez le modifier si nécessaire.

Exemple de méthode d'authentification OpenID

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: threescale-authorization
  params:
    subject:
      properties:
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
      action:
        path: request.url_path
        method: request.method | "get"
        service: destination.labels["service-mesh.3scale.net/service-id"] | ""

Pour que cette intégration fonctionne correctement, l'OIDC doit toujours être effectué dans 3scale pour que le client soit créé dans le fournisseur d'identité (IdP). Vous devez créer une autorisation de demande pour le service que vous voulez protéger dans le même espace de noms que ce service. Le JWT est transmis dans l'en-tête Authorization de la requête.

Dans l'exemple RequestAuthentication défini ci-dessous, remplacez issuer, jwksUri, et selector comme il convient.

Exemple de politique OpenID

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: info
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak
    jwksUri: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs

1.21.4.1.4. Méthode d'authentification hybride

Vous pouvez choisir de ne pas appliquer une méthode d'authentification particulière et d'accepter toutes les informations d'identification valides pour l'une ou l'autre méthode. Si une clé API et une paire ID d'application/clé d'application sont fournies, Service Mesh utilise la clé API.

Dans cet exemple, Service Mesh vérifie la présence d'une clé API dans les paramètres de la requête, puis dans les en-têtes de la requête. S'il n'y a pas de clé API, il recherche alors un identifiant et une clé d'application dans les paramètres de la requête, puis dans les en-têtes de la requête.

Exemple de méthode d'authentification hybride

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] |
      properties:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
    action:
      path: request.url_path
      method: request.method | "get"
      service: destination.labels["service-mesh.3scale.net/service-id"] | ""

1.21.5. 3scale Adapter metrics

L'adaptateur, par défaut, rapporte diverses mesures Prometheus qui sont exposées sur le port 8080 au point de terminaison /metrics. Ces métriques donnent un aperçu de la façon dont les interactions entre l'adaptateur et 3scale se déroulent. Le service est étiqueté pour être automatiquement découvert et scrappé par Prometheus.

Note

Il y a des changements incompatibles dans les métriques 3scale Istio Adapter depuis les versions précédentes de Service Mesh 1.x.

Dans Prometheus, les métriques ont été renommées avec un ajout pour le cache du backend, de sorte que les métriques suivantes existent depuis Service Mesh 2.0 :

Tableau 1.30. Métriques de Prométhée
MétriqueTypeDescription

threescale_latency

Histogramme

Temps de latence entre l'adaptateur et 3scale.

threescale_http_total

Compteur

Codes de réponse HTTP pour les requêtes adressées au backend 3scale.

threescale_system_cache_hits

Compteur

Nombre total de demandes adressées au système 3scale à partir du cache de configuration.

threescale_backend_cache_hits

Compteur

Nombre total de requêtes adressées à 3scale backend et récupérées dans le cache du backend.

1.21.6. 3scale backend cache

Le cache backend 3scale fournit un cache d'autorisation et de rapport pour les clients de l'API de gestion des services 3scale. Ce cache est intégré dans l'adaptateur pour permettre des temps de latence plus faibles dans les réponses dans certaines situations, à condition que l'administrateur soit prêt à accepter les compromis.

Note

le cache backend 3scale est désactivé par défaut. la fonctionnalité 3scale backend cache troque l'imprécision dans la limitation du taux et la perte potentielle d'occurrences depuis la dernière vidange pour une faible latence et une consommation plus élevée de ressources dans le processeur et la mémoire.

1.21.6.1. Avantages de l'activation de la mémoire cache

Les avantages de l'activation de la mémoire cache sont les suivants :

  • Activez le cache backend lorsque vous constatez que les latences sont élevées lors de l'accès aux services gérés par l'adaptateur Istio 3scale.

  • L'activation du backend cache empêchera l'adaptateur de vérifier continuellement avec le gestionnaire d'API 3scale les autorisations de demande, ce qui réduira la latence.

    • Cela crée un cache en mémoire des autorisations 3scale pour l'adaptateur Istio 3scale à stocker et à réutiliser avant de tenter de contacter le gestionnaire d'API 3scale pour les autorisations. Les autorisations prendront alors beaucoup moins de temps pour être accordées ou refusées.

  • La mise en cache du backend est utile dans les cas où vous hébergez le gestionnaire d'API 3scale dans un autre emplacement géographique que le maillage de service exécutant l'adaptateur Istio 3scale.

    • C'est généralement le cas avec la plateforme 3scale Hosted (SaaS), mais aussi si un utilisateur héberge son 3scale API manager dans un autre cluster situé dans un emplacement géographique différent, dans une zone de disponibilité différente, ou dans tous les cas où la surcharge du réseau pour atteindre le 3scale API manager est perceptible.

1.21.6.2. Compromis pour des temps de latence plus faibles

Les points suivants sont des compromis pour obtenir des temps de latence plus faibles :

  • L'état d'autorisation de chaque adaptateur 3scale est mis à jour à chaque fois qu'une vidange a lieu.

    • Cela signifie que deux instances ou plus de l'adaptateur introduiront plus d'imprécision entre les périodes de rinçage.
    • Il y a plus de risques qu'un trop grand nombre de demandes soient accordées, dépassant les limites et introduisant un comportement erratique, ce qui conduit à ce que certaines demandes soient acceptées et d'autres non, en fonction de l'adaptateur qui traite chaque demande.
  • Un cache d'adaptateur qui ne peut pas purger ses données et mettre à jour ses informations d'autorisation risque de s'arrêter ou de s'écraser sans signaler ses informations au gestionnaire d'API.
  • Une politique d'échec ouvert ou d'échec fermé sera appliquée lorsqu'un cache d'adaptateur ne peut pas déterminer si une demande doit être accordée ou refusée, éventuellement en raison de problèmes de connectivité réseau lors de la prise de contact avec le gestionnaire d'API.
  • En cas d'absence de cache, généralement juste après le démarrage de l'adaptateur ou après une longue période d'absence de connectivité, les temps de latence augmentent pour interroger le gestionnaire d'API.
  • Un cache d'adaptateur doit effectuer beaucoup plus de travail pour calculer les autorisations qu'il ne le ferait en l'absence d'un cache activé, ce qui sollicite les ressources du processeur.
  • Les besoins en mémoire augmenteront proportionnellement à la combinaison de la quantité de limites, d'applications et de services gérés par le cache.

1.21.6.3. Paramètres de configuration du cache du backend

Les points suivants expliquent les paramètres de configuration du cache du backend :

  • Vous trouverez les paramètres pour configurer le cache backend dans les options de configuration de 3scale.

  • Les trois derniers paramètres contrôlent l'activation du cache en arrière-plan :

    • PARAM_USE_CACHE_BACKEND - est fixé à true pour activer le backend cache.
    • PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS - définit le temps en secondes entre les tentatives consécutives de vidage des données du cache au gestionnaire de l'API.
    • PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED - définir s'il faut ou non autoriser/ouvrir ou refuser/fermer les demandes aux services lorsqu'il n'y a pas assez de données mises en cache et que le gestionnaire d'API 3scale ne peut pas être atteint.

1.21.7. 3scale Istio Adapter Émulation APIcast

L'adaptateur 3scale Istio fonctionne comme APIcast lorsque les conditions suivantes se produisent :

  • Lorsqu'une requête ne peut correspondre à aucune règle de correspondance définie, le code HTTP renvoyé est 404 Not Found. Ce code était auparavant 403 Forbidden.
  • Lorsqu'une demande est refusée parce qu'elle dépasse les limites fixées, le code HTTP renvoyé est 429 Too Many Requests (trop de demandes). Ce code était auparavant 403 Forbidden.
  • Lors de la génération de modèles par défaut via l'interface de programmation, des traits de soulignement seront utilisés à la place des tirets pour les en-têtes, par exemple : user_key au lieu de user-key.

1.21.8. vérification de l'adaptateur Istio 3scale

Vous voudrez peut-être vérifier si l'adaptateur 3scale Istio fonctionne comme prévu. Si votre adaptateur ne fonctionne pas, suivez les étapes suivantes pour résoudre le problème.

Procédure

  1. Assurez-vous que le pod 3scale-adapter fonctionne dans l'espace de noms du plan de contrôle Service Mesh : 

    oc get pods -n <istio-system>

  2. Vérifiez que le pod 3scale-adapter a imprimé des informations sur son démarrage, telles que sa version : 

    oc logs <istio-system>
  3. Lors de l'exécution de requêtes vers les services protégés par l'intégration de l'adaptateur 3scale, essayez toujours les requêtes qui n'ont pas les bonnes informations d'identification et assurez-vous qu'elles échouent. Vérifiez les journaux de l'adaptateur 3scale pour recueillir des informations supplémentaires.

Ressources supplémentaires

1.21.9. liste de contrôle de dépannage de l'adaptateur Istio 3scale

En tant qu'administrateur installant l'adaptateur 3scale Istio, il y a un certain nombre de scénarios qui peuvent faire que votre intégration ne fonctionne pas correctement. Utilisez la liste suivante pour dépanner votre installation :

  • Indentation YAML incorrecte.
  • Sections YAML manquantes.
  • J'ai oublié d'appliquer les changements dans le YAML au cluster.
  • Oublié d'étiqueter les charges de travail de service avec la clé service-mesh.3scale.net/credentials.
  • Oublié d'étiqueter les charges de travail de service avec service-mesh.3scale.net/service-id lorsque l'on utilise des gestionnaires qui ne contiennent pas de service_id afin qu'ils soient réutilisables par compte.
  • La ressource personnalisée Rule pointe vers le mauvais gestionnaire ou les mauvaises ressources personnalisées d'instance, ou les références n'ont pas le suffixe de l'espace de noms correspondant.
  • La section Rule custom resource match ne peut pas correspondre au service que vous configurez, ou elle pointe vers une charge de travail de destination qui n'est pas en cours d'exécution ou qui n'existe pas.
  • Mauvais jeton d'accès ou URL pour le portail d'administration 3scale dans le gestionnaire.
  • La section params/subject/properties de la ressource personnalisée Instance ne répertorie pas les bons paramètres pour app_id, app_key ou client_id, soit parce qu'ils spécifient le mauvais emplacement, comme les paramètres de requête, les en-têtes et les demandes d'autorisation, soit parce que les noms des paramètres ne correspondent pas aux requêtes utilisées pour les tests.
  • Ne pas utiliser le générateur de configuration sans se rendre compte qu'il se trouve dans l'image du conteneur de l'adaptateur et qu'il a besoin de oc exec pour l'invoquer.
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.

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

© 2024 Red Hat, Inc.