2.10. Ressources personnalisées
You are viewing documentation for a Red Hat OpenShift Service Mesh release that is no longer supported.
Les plans de contrôle Service Mesh version 1.0 et 1.1 ne sont plus pris en charge. Pour plus d'informations sur la mise à niveau de votre plan de contrôle Service Mesh, voir Mise à niveau de Service Mesh.
Pour plus d'informations sur l'état de l'assistance d'une version particulière de Red Hat OpenShift Service Mesh, consultez la page Cycle de vie du produit.
Vous pouvez personnaliser votre Red Hat OpenShift Service Mesh en modifiant la ressource personnalisée Service Mesh par défaut ou en créant une nouvelle ressource personnalisée.
2.10.1. Conditions préalables
-
Un compte avec le rôle
cluster-admin. - Vous avez terminé le processus de préparation à l'installation de Red Hat OpenShift Service Mesh.
- Les opérateurs ont été installés.
2.10.2. Ressources personnalisées Red Hat OpenShift Service Mesh
Le projet istio-system est utilisé comme exemple dans toute la documentation Service Mesh, mais vous pouvez utiliser d'autres projets si nécessaire.
Un custom resource vous permet d'étendre l'API dans un projet ou un cluster Red Hat OpenShift Service Mesh. Lorsque vous déployez Service Mesh, il crée un site ServiceMeshControlPlane par défaut que vous pouvez modifier pour changer les paramètres du projet.
L'opérateur Service Mesh étend l'API en ajoutant le type de ressource ServiceMeshControlPlane, qui vous permet de créer des objets ServiceMeshControlPlane dans les projets. En créant un objet ServiceMeshControlPlane, vous demandez à l'opérateur d'installer un plan de contrôle Service Mesh dans le projet, configuré avec les paramètres que vous avez définis dans l'objet ServiceMeshControlPlane.
Cet exemple de définition ServiceMeshControlPlane contient tous les paramètres pris en charge et déploie les images Red Hat OpenShift Service Mesh 1.1.18.2 basées sur Red Hat Enterprise Linux (RHEL).
L'adaptateur 3scale Istio est déployé et configuré dans le fichier de ressources personnalisé. Il nécessite également un compte 3scale fonctionnel(SaaS ou On-Premises).
Exemple istio-installation.yaml
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
metadata:
name: basic-install
spec:
istio:
global:
proxy:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 128Mi
gateways:
istio-egressgateway:
autoscaleEnabled: false
istio-ingressgateway:
autoscaleEnabled: false
ior_enabled: false
mixer:
policy:
autoscaleEnabled: false
telemetry:
autoscaleEnabled: false
resources:
requests:
cpu: 100m
memory: 1G
limits:
cpu: 500m
memory: 4G
pilot:
autoscaleEnabled: false
traceSampling: 100
kiali:
enabled: true
grafana:
enabled: true
tracing:
enabled: true
jaeger:
template: all-in-one
2.10.3. Paramètres du plan de contrôle ServiceMesh
Les exemples suivants illustrent l'utilisation des paramètres ServiceMeshControlPlane et les tableaux fournissent des informations supplémentaires sur les paramètres pris en charge.
Les ressources que vous configurez pour Red Hat OpenShift Service Mesh avec ces paramètres, y compris les CPU, la mémoire et le nombre de pods, sont basées sur la configuration de votre cluster OpenShift Container Platform. Configurez ces paramètres en fonction des ressources disponibles dans la configuration actuelle de votre cluster.
2.10.3.1. Exemple global d'Istio
Voici un exemple qui illustre les paramètres globaux d'Istio pour ServiceMeshControlPlane et une description des paramètres disponibles avec les valeurs appropriées.
Pour que l'adaptateur 3scale Istio fonctionne, disablePolicyChecks doit être false.
Exemple de paramètres globaux
istio:
global:
tag: 1.1.0
hub: registry.redhat.io/openshift-service-mesh/
proxy:
resources:
requests:
cpu: 10m
memory: 128Mi
limits:
mtls:
enabled: false
disablePolicyChecks: true
policyCheckFailOpen: false
imagePullSecrets:
- MyPullSecret
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
|
| Ce paramètre permet d'activer ou de désactiver les contrôles de politique. |
|
|
|
| Ce paramètre indique si le trafic est autorisé à passer par le sidecar Envoy lorsque le service de stratégie Mixer ne peut être atteint. |
|
|
|
| La balise que l'opérateur utilise pour extraire les images Istio. | Une balise d'image conteneur valide. |
|
|
| Le hub que l'opérateur utilise pour extraire les images Istio. | Un référentiel d'images valide. |
|
|
| Ce paramètre permet d'activer/désactiver la sécurité mutuelle de la couche transport (mTLS) entre les services par défaut. |
|
|
|
| Si l'accès au registre fournissant les images Istio est sécurisé, listez une imagePullSecret ici. | redhat-registry-pullsecret OR quay-pullsecret | Aucun |
Ces paramètres sont spécifiques au sous-ensemble de paramètres globaux du proxy.
| Type | Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|---|
|
|
| La quantité de ressources CPU demandées pour le proxy Envoy. | Ressources CPU, spécifiées en cœurs ou en millicores (par exemple, 200m, 0,5, 1) en fonction de la configuration de votre environnement. |
|
|
| La quantité de mémoire demandée pour le proxy Envoy | Mémoire disponible en octets (par exemple, 200Ki, 50Mi, 5Gi) en fonction de la configuration de votre environnement. |
| |
|
|
| Quantité maximale de ressources CPU demandée pour le proxy Envoy. | Ressources CPU, spécifiées en cœurs ou en millicores (par exemple, 200m, 0,5, 1) en fonction de la configuration de votre environnement. |
|
|
| Quantité maximale de mémoire que le proxy Envoy est autorisé à utiliser. | Mémoire disponible en octets (par exemple, 200Ki, 50Mi, 5Gi) en fonction de la configuration de votre environnement. |
|
2.10.3.2. Configuration de la passerelle Istio
Voici un exemple qui illustre les paramètres de la passerelle Istio pour le site ServiceMeshControlPlane et une description des paramètres disponibles avec les valeurs appropriées.
Exemple de paramètres de passerelle
gateways:
egress:
enabled: true
runtime:
deployment:
autoScaling:
enabled: true
maxReplicas: 5
minReplicas: 1
enabled: true
ingress:
enabled: true
runtime:
deployment:
autoScaling:
enabled: true
maxReplicas: 5
minReplicas: 1
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
|
| Ce paramètre active/désactive la mise à l'échelle automatique. |
|
|
|
|
Nombre minimum de modules à déployer pour la passerelle de sortie en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
|
|
Nombre maximal de modules à déployer pour la passerelle de sortie en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
|
| Ce paramètre active/désactive la mise à l'échelle automatique. |
|
|
|
|
Le nombre minimum de pods à déployer pour la passerelle d'entrée en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
|
|
Nombre maximal de modules à déployer pour la passerelle d'entrée en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
Les administrateurs de clusters peuvent se référer à la section Utilisation d'itinéraires génériques pour obtenir des instructions sur la manière d'activer les sous-domaines.
2.10.3.3. Configuration d'Istio Mixer
Voici un exemple qui illustre les paramètres du mixeur pour le site ServiceMeshControlPlane et une description des paramètres disponibles avec les valeurs appropriées.
Exemple de paramètres du mélangeur
mixer:
enabled: true
policy:
autoscaleEnabled: false
telemetry:
autoscaleEnabled: false
resources:
requests:
cpu: 10m
memory: 128Mi
limits:
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
|
| Ce paramètre permet d'activer/désactiver le mixeur. |
|
|
|
| Ce paramètre active/désactive la mise à l'échelle automatique. Désactivez ce paramètre pour les environnements de petite taille. |
|
|
|
|
Le nombre minimum de pods à déployer en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
|
|
Le nombre maximum de pods à déployer en fonction du paramètre | Un nombre valide de pods allouables en fonction de la configuration de votre environnement. |
|
| Type | Paramètres | Description | Valeurs | Défaut |
|---|---|---|---|---|
|
|
| Le pourcentage de ressources CPU demandées pour la télémétrie Mixer. | Ressources CPU en millicores en fonction de la configuration de votre environnement. |
|
|
| La quantité de mémoire requise pour la télémétrie du mélangeur. | Mémoire disponible en octets (par exemple, 200Ki, 50Mi, 5Gi) en fonction de la configuration de votre environnement. |
| |
|
|
| Pourcentage maximum de ressources CPU que la télémétrie Mixer est autorisée à utiliser. | Ressources CPU en millicores en fonction de la configuration de votre environnement. |
|
|
| Quantité maximale de mémoire que la télémétrie du mélangeur est autorisée à utiliser. | Mémoire disponible en octets (par exemple, 200Ki, 50Mi, 5Gi) en fonction de la configuration de votre environnement. |
|
2.10.3.4. Configuration d'Istio Pilot
Vous pouvez configurer Pilot pour planifier ou fixer des limites à l'allocation des ressources. L'exemple suivant illustre les paramètres de Pilot pour le site ServiceMeshControlPlane et une description des paramètres disponibles avec les valeurs appropriées.
Exemple de paramètres de pilotage
spec:
runtime:
components:
pilot:
deployment:
autoScaling:
enabled: true
minReplicas: 1
maxReplicas: 5
targetCPUUtilizationPercentage: 85
pod:
tolerations:
- key: node.kubernetes.io/unreachable
operator: Exists
effect: NoExecute
tolerationSeconds: 60
affinity:
podAntiAffinity:
requiredDuringScheduling:
- key: istio
topologyKey: kubernetes.io/hostname
operator: In
values:
- pilot
container:
resources:
limits:
cpu: 100m
memory: 128M
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
|
| Le pourcentage de ressources CPU demandées pour Pilot. | Ressources CPU en millicores en fonction de la configuration de votre environnement. |
|
|
| La quantité de mémoire demandée pour Pilot. | Mémoire disponible en octets (par exemple, 200Ki, 50Mi, 5Gi) en fonction de la configuration de votre environnement. |
|
|
| Ce paramètre active/désactive la mise à l'échelle automatique. Désactivez ce paramètre pour les environnements de petite taille. |
|
|
|
| Cette valeur détermine la fréquence de l'échantillonnage aléatoire. Note: Augmenter pour le développement ou les tests. | Un pourcentage valable. |
|
2.10.4. Configuration de Kiali
Lorsque le Service Mesh Operator crée le site ServiceMeshControlPlane, il traite également la ressource Kiali. L'opérateur Kiali utilise ensuite cet objet lors de la création d'instances Kiali.
Les paramètres par défaut de Kiali spécifiés dans le site ServiceMeshControlPlane sont les suivants :
Exemple de paramètres Kiali
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
kiali:
enabled: true
dashboard:
viewOnlyMode: false
ingress:
enabled: true
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
activée | Ce paramètre permet d'activer ou de désactiver Kiali. Kiali est activé par défaut. |
|
|
dashboard viewOnlyMode | Ce paramètre active/désactive le mode vue seule pour la console Kiali. Lorsque ce mode est activé, les utilisateurs ne peuvent pas utiliser la console pour apporter des modifications au Service Mesh. |
|
|
ingress enabled | Ce paramètre permet d'activer ou de désactiver l'entrée pour Kiali. |
|
|
2.10.4.1. Configuration de Kiali pour Grafana
Lorsque vous installez Kiali et Grafana dans le cadre de Red Hat OpenShift Service Mesh, l'opérateur configure les éléments suivants par défaut :
- Grafana est activé en tant que service externe pour Kiali
- Autorisation de Grafana pour la console Kiali
- URL Grafana pour la console Kiali
Kiali peut détecter automatiquement l'URL de Grafana. Cependant, si vous avez une installation personnalisée de Grafana qui n'est pas facilement détectable par Kiali, vous devez mettre à jour la valeur de l'URL dans la ressource ServiceMeshControlPlane.
Paramètres supplémentaires de Grafana
spec:
kiali:
enabled: true
dashboard:
viewOnlyMode: false
grafanaURL: "https://grafana-istio-system.127.0.0.1.nip.io"
ingress:
enabled: true
2.10.4.2. Configuration de Kiali pour Jaeger
Lorsque vous installez Kiali et Jaeger dans le cadre de Red Hat OpenShift Service Mesh, l'opérateur configure les éléments suivants par défaut :
- Jaeger est activé en tant que service externe pour Kiali
- Autorisation Jaeger pour la console Kiali
- URL Jaeger pour la console Kiali
Kiali peut détecter automatiquement l'URL de Jaeger. Cependant, si vous avez une installation Jaeger personnalisée qui n'est pas facilement détectable par Kiali, vous devez mettre à jour la valeur de l'URL dans la ressource ServiceMeshControlPlane.
Paramètres supplémentaires de Jaeger
spec:
kiali:
enabled: true
dashboard:
viewOnlyMode: false
jaegerURL: "http://jaeger-query-istio-system.127.0.0.1.nip.io"
ingress:
enabled: true
2.10.5. Configuration de Jaeger
Lorsque l'opérateur de Service Mesh crée la ressource ServiceMeshControlPlane, il peut également créer les ressources pour le traçage distribué. Service Mesh utilise Jaeger pour le traçage distribué.
Vous pouvez spécifier votre configuration Jaeger de deux façons :
-
Configurer Jaeger dans la ressource
ServiceMeshControlPlane. Cette approche présente certaines limites. -
Configurer Jaeger dans une ressource personnalisée
Jaeger, puis référencer cette instance de Jaeger dans la ressourceServiceMeshControlPlane. S'il existe une ressource Jaeger correspondant à la valeur dename, le plan de contrôle utilisera l'installation existante. Cette approche vous permet de personnaliser entièrement votre configuration Jaeger.
Les paramètres Jaeger par défaut spécifiés dans le site ServiceMeshControlPlane sont les suivants :
Paramètres par défaut de all-in-one Jaeger
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
version: v1.1
istio:
tracing:
enabled: true
jaeger:
template: all-in-one
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
tracing: enabled: |
Ce paramètre permet d'activer/désactiver l'installation et le déploiement du traçage par l'opérateur du maillage de services. L'installation de Jaeger est activée par défaut. Pour utiliser un déploiement Jaeger existant, définissez cette valeur sur |
|
|
jaeger: template: | Ce paramètre indique la stratégie de déploiement Jaeger à utiliser. |
|
|
Le modèle par défaut dans la ressource ServiceMeshControlPlane est la stratégie de déploiement all-in-one qui utilise le stockage en mémoire. Pour la production, la seule option de stockage prise en charge est Elasticsearch. Vous devez donc configurer la ressource ServiceMeshControlPlane pour qu'elle demande le modèle production-elasticsearch lorsque vous déployez Service Mesh dans un environnement de production.
2.10.5.1. Configuration d'Elasticsearch
La stratégie de déploiement par défaut de Jaeger utilise le modèle all-in-one afin que l'installation puisse être réalisée avec un minimum de ressources. Cependant, comme le modèle all-in-one utilise un stockage en mémoire, il n'est recommandé qu'à des fins de développement, de démonstration ou de test et ne doit PAS être utilisé dans des environnements de production.
Si vous déployez Service Mesh et Jaeger dans un environnement de production, vous devez remplacer le modèle par le modèle production-elasticsearch, qui utilise Elasticsearch pour les besoins de stockage de Jaeger.
Elasticsearch est une application gourmande en mémoire. L'ensemble initial de nœuds spécifié dans l'installation par défaut d'OpenShift Container Platform peut ne pas être suffisant pour supporter le cluster Elasticsearch. Vous devez modifier la configuration par défaut d'Elasticsearch pour qu'elle corresponde à votre cas d'utilisation et aux ressources que vous avez demandées pour votre installation d'OpenShift Container Platform. Vous pouvez ajuster les limites de CPU et de mémoire pour chaque composant en modifiant le bloc de ressources avec des valeurs de CPU et de mémoire valides. Des nœuds supplémentaires doivent être ajoutés au cluster si vous souhaitez fonctionner avec la quantité de mémoire recommandée (ou plus). Veillez à ne pas dépasser les ressources requises pour votre installation d'OpenShift Container Platform.
Paramètres de Jaeger par défaut avec Elasticsearch
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
tracing:
enabled: true
ingress:
enabled: true
jaeger:
template: production-elasticsearch
elasticsearch:
nodeCount: 3
redundancyPolicy:
resources:
requests:
cpu: "1"
memory: "16Gi"
limits:
cpu: "1"
memory: "16Gi"
| Paramètres | Description | Valeurs | Valeur par défaut | Examples |
|---|---|---|---|---|
tracing: enabled: | Ce paramètre permet d'activer ou de désactiver le traçage dans Service Mesh. Jaeger est installé par défaut. |
|
| |
ingress: enabled: | Ce paramètre permet d'activer ou de désactiver l'entrée pour Jaeger. |
|
| |
jaeger: template: | Ce paramètre indique la stratégie de déploiement Jaeger à utiliser. |
|
| |
elasticsearch: nodeCount: | Nombre de nœuds Elasticsearch à créer. | Valeur entière. | 1 | Preuve de concept = 1, Déploiement minimal =3 |
requests: cpu: | Nombre d'unités centrales de traitement pour les requêtes, en fonction de la configuration de votre environnement. | Spécifié en carottes ou en millicores (par exemple, 200m, 0,5, 1). | 1Gi | Preuve du concept = 500m, déploiement minimum =1 |
requests: memory: | Mémoire disponible pour les requêtes, en fonction de la configuration de votre environnement. | Spécifié en octets (par exemple, 200Ki, 50Mi, 5Gi). | 500m | Preuve de concept = 1Gi, déploiement minimum = 16Gi* |
limits: cpu: | Limitation du nombre d'unités centrales de traitement, en fonction de la configuration de votre environnement. | Spécifié en carottes ou en millicores (par exemple, 200m, 0,5, 1). | Preuve du concept = 500m, déploiement minimum =1 | |
limits: memory: | Limite de mémoire disponible en fonction de la configuration de votre environnement. | Spécifié en octets (par exemple, 200Ki, 50Mi, 5Gi). | Preuve de concept = 1Gi, déploiement minimum = 16Gi* | |
| * Chaque nœud Elasticsearch peut fonctionner avec un paramètre de mémoire inférieur, bien que cela soit recommandé pour les déploiements en production ( not ). Pour une utilisation en production, vous ne devriez pas avoir moins de 16Gi alloués à chaque pod par défaut, mais il est préférable d'en allouer autant que possible, jusqu'à 64Gi par pod. | ||||
Procédure
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin. -
Naviguez jusqu'à Operators
Installed Operators. - Cliquez sur l'opérateur Red Hat OpenShift Service Mesh.
- Cliquez sur l'onglet Istio Service Mesh Control Plane.
-
Cliquez sur le nom du fichier du plan de contrôle, par exemple
basic-install. - Cliquez sur l'onglet YAML.
-
Modifiez les paramètres Jaeger, en remplaçant le modèle par défaut
all-in-onepar les paramètres du modèleproduction-elasticsearch, modifiés en fonction de votre cas d'utilisation. Assurez-vous que l'indentation est correcte. - Cliquez sur Save.
- Cliquez sur Reload. OpenShift Container Platform redéploie Jaeger et crée les ressources Elasticsearch en fonction des paramètres spécifiés.
2.10.5.2. Connexion à une instance Jaeger existante
Pour que le SMCP puisse se connecter à une instance Jaeger existante, les conditions suivantes doivent être remplies :
-
L'instance Jaeger est déployée dans le même espace de noms que le plan de contrôle, par exemple dans l'espace de noms
istio-system. - Pour permettre une communication sécurisée entre les services, vous devez activer le proxy oauth, qui sécurise la communication avec votre instance Jaeger, et vous assurer que le secret est monté dans votre instance Jaeger pour que Kiali puisse communiquer avec elle.
-
Pour utiliser une instance Jaeger personnalisée ou déjà existante, définissez
spec.istio.tracing.enabledà "false" pour désactiver le déploiement d'une instance Jaeger. -
Fournissez le bon point de terminaison jaeger-collector à Mixer en définissant
spec.istio.global.tracer.zipkin.addressavec le nom d'hôte et le port de votre service jaeger-collector. Le nom d'hôte du service est généralement<jaeger-instance-name>-collector.<namespace>.svc.cluster.local. -
Fournissez à Kiali le bon point de terminaison jaeger-query pour la collecte des traces en définissant
spec.istio.kiali.jaegerInClusterURLavec le nom d'hôte de votre service jaeger-query - le port n'est normalement pas nécessaire, car il utilise 443 par défaut. Le nom d'hôte du service est généralement<jaeger-instance-name>-query.<namespace>.svc.cluster.local. Fournissez l'URL du tableau de bord de votre instance Jaeger à Kiali pour permettre l'accès à Jaeger via la console Kiali. Vous pouvez récupérer l'URL à partir de la route OpenShift créée par l'opérateur Jaeger. Si votre ressource Jaeger s'appelle
external-jaegeret réside dans le projetistio-system, vous pouvez récupérer la route à l'aide de la commande suivante :$ oc get route -n istio-system external-jaeger
Exemple de sortie
NAME HOST/PORT PATH SERVICES [...] external-jaeger external-jaeger-istio-system.apps.test external-jaeger-query [...]
La valeur sous
HOST/PORTest l'URL accessible de l'extérieur du tableau de bord Jaeger.
Exemple de ressource Jaeger
apiVersion: jaegertracing.io/v1
kind: "Jaeger"
metadata:
name: "external-jaeger"
# Deploy to the Control Plane Namespace
namespace: istio-system
spec:
# Set Up Authentication
ingress:
enabled: true
security: oauth-proxy
openshift:
# This limits user access to the Jaeger instance to users who have access
# to the control plane namespace. Make sure to set the correct namespace here
sar: '{"namespace": "istio-system", "resource": "pods", "verb": "get"}'
htpasswdFile: /etc/proxy/htpasswd/auth
volumeMounts:
- name: secret-htpasswd
mountPath: /etc/proxy/htpasswd
volumes:
- name: secret-htpasswd
secret:
secretName: htpasswd
L'exemple suivant ServiceMeshControlPlane suppose que vous avez déployé Jaeger à l'aide de l'opérateur Jaeger et de la ressource Jaeger d'exemple.
Exemple ServiceMeshControlPlane avec Jaeger externe
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
metadata:
name: external-jaeger
namespace: istio-system
spec:
version: v1.1
istio:
tracing:
# Disable Jaeger deployment by service mesh operator
enabled: false
global:
tracer:
zipkin:
# Set Endpoint for Trace Collection
address: external-jaeger-collector.istio-system.svc.cluster.local:9411
kiali:
# Set Jaeger dashboard URL
dashboard:
jaegerURL: https://external-jaeger-istio-system.apps.test
# Set Endpoint for Trace Querying
jaegerInClusterURL: external-jaeger-query.istio-system.svc.cluster.local
2.10.5.3. Configuration d'Elasticsearch
La stratégie de déploiement par défaut de Jaeger utilise le modèle all-in-one afin que l'installation puisse être réalisée avec un minimum de ressources. Cependant, comme le modèle all-in-one utilise un stockage en mémoire, il n'est recommandé qu'à des fins de développement, de démonstration ou de test et ne doit PAS être utilisé dans des environnements de production.
Si vous déployez Service Mesh et Jaeger dans un environnement de production, vous devez remplacer le modèle par le modèle production-elasticsearch, qui utilise Elasticsearch pour les besoins de stockage de Jaeger.
Elasticsearch est une application gourmande en mémoire. L'ensemble initial de nœuds spécifié dans l'installation par défaut d'OpenShift Container Platform peut ne pas être suffisant pour supporter le cluster Elasticsearch. Vous devez modifier la configuration par défaut d'Elasticsearch pour qu'elle corresponde à votre cas d'utilisation et aux ressources que vous avez demandées pour votre installation d'OpenShift Container Platform. Vous pouvez ajuster les limites de CPU et de mémoire pour chaque composant en modifiant le bloc de ressources avec des valeurs de CPU et de mémoire valides. Des nœuds supplémentaires doivent être ajoutés au cluster si vous souhaitez fonctionner avec la quantité de mémoire recommandée (ou plus). Veillez à ne pas dépasser les ressources requises pour votre installation d'OpenShift Container Platform.
Paramètres de Jaeger par défaut avec Elasticsearch
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
tracing:
enabled: true
ingress:
enabled: true
jaeger:
template: production-elasticsearch
elasticsearch:
nodeCount: 3
redundancyPolicy:
resources:
requests:
cpu: "1"
memory: "16Gi"
limits:
cpu: "1"
memory: "16Gi"
| Paramètres | Description | Valeurs | Valeur par défaut | Examples |
|---|---|---|---|---|
tracing: enabled: | Ce paramètre permet d'activer ou de désactiver le traçage dans Service Mesh. Jaeger est installé par défaut. |
|
| |
ingress: enabled: | Ce paramètre permet d'activer ou de désactiver l'entrée pour Jaeger. |
|
| |
jaeger: template: | Ce paramètre indique la stratégie de déploiement Jaeger à utiliser. |
|
| |
elasticsearch: nodeCount: | Nombre de nœuds Elasticsearch à créer. | Valeur entière. | 1 | Preuve de concept = 1, Déploiement minimal =3 |
requests: cpu: | Nombre d'unités centrales de traitement pour les requêtes, en fonction de la configuration de votre environnement. | Spécifié en carottes ou en millicores (par exemple, 200m, 0,5, 1). | 1Gi | Preuve du concept = 500m, déploiement minimum =1 |
requests: memory: | Mémoire disponible pour les requêtes, en fonction de la configuration de votre environnement. | Spécifié en octets (par exemple, 200Ki, 50Mi, 5Gi). | 500m | Preuve de concept = 1Gi, déploiement minimum = 16Gi* |
limits: cpu: | Limitation du nombre d'unités centrales de traitement, en fonction de la configuration de votre environnement. | Spécifié en carottes ou en millicores (par exemple, 200m, 0,5, 1). | Preuve du concept = 500m, déploiement minimum =1 | |
limits: memory: | Limite de mémoire disponible en fonction de la configuration de votre environnement. | Spécifié en octets (par exemple, 200Ki, 50Mi, 5Gi). | Preuve de concept = 1Gi, déploiement minimum = 16Gi* | |
| * Chaque nœud Elasticsearch peut fonctionner avec un paramètre de mémoire inférieur, bien que cela soit recommandé pour les déploiements en production ( not ). Pour une utilisation en production, vous ne devriez pas avoir moins de 16Gi alloués à chaque pod par défaut, mais il est préférable d'en allouer autant que possible, jusqu'à 64Gi par pod. | ||||
Procédure
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin. -
Naviguez jusqu'à Operators
Installed Operators. - Cliquez sur l'opérateur Red Hat OpenShift Service Mesh.
- Cliquez sur l'onglet Istio Service Mesh Control Plane.
-
Cliquez sur le nom du fichier du plan de contrôle, par exemple
basic-install. - Cliquez sur l'onglet YAML.
-
Modifiez les paramètres Jaeger, en remplaçant le modèle par défaut
all-in-onepar les paramètres du modèleproduction-elasticsearch, modifiés en fonction de votre cas d'utilisation. Assurez-vous que l'indentation est correcte. - Cliquez sur Save.
- Cliquez sur Reload. OpenShift Container Platform redéploie Jaeger et crée les ressources Elasticsearch en fonction des paramètres spécifiés.
2.10.5.4. Configuration de la tâche de nettoyage de l'index Elasticsearch
Lorsque l'opérateur du Service Mesh crée le site ServiceMeshControlPlane, il crée également la ressource personnalisée (CR) pour Jaeger. L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift utilise ensuite cette CR lors de la création d'instances Jaeger.
Lors de l'utilisation du stockage Elasticsearch, une tâche est créée par défaut pour nettoyer les anciennes traces. Pour configurer les options de cette tâche, vous devez éditer la ressource personnalisée (CR) Jaeger, afin de l'adapter à votre cas d'utilisation. Les options pertinentes sont énumérées ci-dessous.
apiVersion: jaegertracing.io/v1
kind: Jaeger
spec:
strategy: production
storage:
type: elasticsearch
esIndexCleaner:
enabled: false
numberOfDays: 7
schedule: "55 23 * * *"| Paramètres | Valeurs | Description |
|---|---|---|
| a permis : | vrai/ faux | Activer ou désactiver la tâche de nettoyage de l'index. |
| nombre de jours : | valeur entière | Nombre de jours à attendre avant de supprimer un index. |
| calendrier : | "55 23 * * *" | Expression Cron pour l'exécution du travail |
Pour plus d'informations sur la configuration d'Elasticsearch avec OpenShift Container Platform, voir Configuration du magasin de logs.
2.10.6. configuration 3scale
Le tableau suivant explique les paramètres de l'adaptateur Istio 3scale dans la ressource ServiceMeshControlPlane.
Exemple de paramètres 3scale
spec:
addons:
3Scale:
enabled: false
PARAM_THREESCALE_LISTEN_ADDR: 3333
PARAM_THREESCALE_LOG_LEVEL: info
PARAM_THREESCALE_LOG_JSON: true
PARAM_THREESCALE_LOG_GRPC: false
PARAM_THREESCALE_REPORT_METRICS: true
PARAM_THREESCALE_METRICS_PORT: 8080
PARAM_THREESCALE_CACHE_TTL_SECONDS: 300
PARAM_THREESCALE_CACHE_REFRESH_SECONDS: 180
PARAM_THREESCALE_CACHE_ENTRIES_MAX: 1000
PARAM_THREESCALE_CACHE_REFRESH_RETRIES: 1
PARAM_THREESCALE_ALLOW_INSECURE_CONN: false
PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS: 10
PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS: 60
PARAM_USE_CACHED_BACKEND: false
PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS: 15
PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED: true
| Paramètres | Description | Valeurs | Valeur par défaut |
|---|---|---|---|
|
| Utilisation ou non de l'adaptateur 3scale |
|
|
|
| Définit l'adresse d'écoute du serveur gRPC | Numéro de port valide |
|
|
| Définit le niveau minimum de sortie du journal. |
|
|
|
| Contrôle si le journal est formaté en JSON |
|
|
|
| Contrôle si le journal contient des informations gRPC |
|
|
|
| Contrôle si les métriques du système 3scale et du backend sont collectées et rapportées à Prometheus |
|
|
|
|
Définit le port à partir duquel le point d'extrémité 3scale | Numéro de port valide |
|
|
| Délai, en secondes, à attendre avant de purger les éléments expirés de la mémoire cache | Période de temps en secondes |
|
|
| Période de temps avant l'expiration au cours de laquelle les éléments du cache sont tentés d'être rafraîchis | Période de temps en secondes |
|
|
|
Nombre maximal d'éléments pouvant être stockés dans le cache à tout moment. La valeur | Numéro valide |
|
|
| Le nombre de fois où les hôtes inaccessibles sont réessayés pendant une boucle de mise à jour du cache | Numéro valide |
|
|
|
Permet d'ignorer la vérification des certificats lors de l'appel des API |
|
|
|
| Définit le nombre de secondes à attendre avant de terminer les requêtes vers le système 3scale et le backend | Période de temps en secondes |
|
|
| Définit le nombre maximum de secondes ( /-10% de gigue) qu'une connexion peut durer avant d'être fermée | Période de temps en secondes | 60 |
|
| Si true, tentative de création d'un cache d'apisonator en mémoire pour les demandes d'autorisation |
|
|
|
| Si le cache du backend est activé, ceci définit l'intervalle en secondes pour vider le cache par rapport à 3scale | Période de temps en secondes | 15 |
|
| Lorsque le cache du backend ne peut pas récupérer les données d'autorisation, il convient de refuser (fermé) ou d'autoriser (ouvert) les demandes |
|
|
