Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 26. Configuration des itinéraires

download PDF

26.1. Configuration des itinéraires

26.1.1. Création d'un itinéraire basé sur HTTP

Une route vous permet d'héberger votre application à une URL publique. Elle peut être sécurisée ou non, en fonction de la configuration de sécurité du réseau de votre application. Une route basée sur HTTP est une route non sécurisée qui utilise le protocole de routage HTTP de base et expose un service sur un port d'application non sécurisé.

La procédure suivante décrit comment créer une route simple basée sur le protocole HTTP vers une application web, en utilisant l'application hello-openshift comme exemple.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté en tant qu'administrateur.
  • Vous avez une application web qui expose un port et un point de terminaison TCP qui écoute le trafic sur le port.

Procédure

  1. Créez un projet appelé hello-openshift en exécutant la commande suivante : 

    $ oc new-project hello-openshift

  2. Créez un pod dans le projet en exécutant la commande suivante : 

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

  3. Créez un service appelé hello-openshift en exécutant la commande suivante : 

    $ oc expose pod/hello-openshift

  4. Créez une route non sécurisée vers l'application hello-openshift en exécutant la commande suivante : 

    $ oc expose svc hello-openshift

Vérification

  • Pour vérifier que la ressource route que vous avez créée fonctionne, exécutez la commande suivante : 

    $ oc get routes -o yaml <name of resource> 1
    1
    Dans cet exemple, la route est nommée hello-openshift.

Exemple de définition YAML de la route non sécurisée créée :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain> 1
  port:
    targetPort: 8080 2
  to:
    kind: Service
    name: hello-openshift

1
<Ingress_Domain> est le nom de domaine d'entrée par défaut. L'objet ingresses.config/cluster est créé lors de l'installation et ne peut pas être modifié. Si vous souhaitez spécifier un domaine différent, vous pouvez spécifier un autre domaine de cluster à l'aide de l'option appsDomain.
2
targetPort est le port cible sur les pods qui est sélectionné par le service vers lequel cette route pointe.
Note

Pour afficher votre domaine d'entrée par défaut, exécutez la commande suivante : 

$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}

26.1.2. Création d'une route pour le sharding du contrôleur d'entrée

Une route vous permet d'héberger votre application à une URL. Dans ce cas, le nom d'hôte n'est pas défini et la route utilise un sous-domaine à la place. Lorsque vous spécifiez un sous-domaine, vous utilisez automatiquement le domaine du contrôleur d'entrée qui expose l'itinéraire. Lorsqu'un itinéraire est exposé par plusieurs contrôleurs d'ingestion, l'itinéraire est hébergé sur plusieurs URL.

La procédure suivante décrit comment créer une route pour le sharding du contrôleur d'entrée, en utilisant l'application hello-openshift comme exemple.

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté en tant qu'administrateur de projet.
  • Vous avez une application web qui expose un port et un point d'extrémité HTTP ou TLS qui écoute le trafic sur le port.
  • Vous avez configuré le contrôleur d'entrée pour le partage.

Procédure

  1. Créez un projet appelé hello-openshift en exécutant la commande suivante : 

    $ oc new-project hello-openshift

  2. Créez un pod dans le projet en exécutant la commande suivante : 

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

  3. Créez un service appelé hello-openshift en exécutant la commande suivante : 

    $ oc expose pod/hello-openshift

  4. Créez une définition de route appelée hello-openshift-route.yaml:

    Définition YAML de la route créée pour le sharding :

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 1
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 2
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift

    1
    La clé d'étiquette et la valeur d'étiquette correspondante doivent toutes deux correspondre à celles spécifiées dans le contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée a la clé et la valeur d'étiquette type: sharded.
    2
    La route sera exposée en utilisant la valeur du champ subdomain. Lorsque vous spécifiez le champ subdomain, vous devez laisser le nom d'hôte non défini. Si vous spécifiez à la fois les champs host et subdomain, l'itinéraire utilisera la valeur du champ host et ignorera le champ subdomain.

  5. Utilisez hello-openshift-route.yaml pour créer une route vers l'application hello-openshift en exécutant la commande suivante : 

    $ oc -n hello-openshift create -f hello-openshift-route.yaml

Vérification

  • Obtenez l'état de la route à l'aide de la commande suivante : 

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

    La ressource Route qui en résulte devrait ressembler à ce qui suit :

    Exemple de sortie

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 1
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2
    routerName: sharded 3

    1
    Le nom d'hôte que le contrôleur d'entrée, ou le routeur, utilise pour exposer l'itinéraire. La valeur du champ host est automatiquement déterminée par le contrôleur d'entrée et utilise son domaine. Dans cet exemple, le domaine du contrôleur d'entrée est <apps-sharded.basedomain.example.net>.
    2
    Le nom d'hôte du contrôleur d'entrée.
    3
    Le nom du contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée porte le nom sharded.

26.1.3. Configuration des délais d'attente pour les itinéraires

Vous pouvez configurer les délais d'attente par défaut pour une route existante lorsque vous avez des services qui ont besoin d'un délai d'attente faible, qui est nécessaire pour la disponibilité du niveau de service (SLA), ou d'un délai d'attente élevé, pour les cas où le back-end est lent.

Conditions préalables

  • Vous avez besoin d'un contrôleur d'ingestion déployé sur un cluster en cours d'exécution.

Procédure

  1. À l'aide de la commande oc annotate, ajoutez le délai d'attente à l'itinéraire : 

    $ oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1
    1
    Les unités de temps prises en charge sont les microsecondes (us), les millisecondes (ms), les secondes (s), les minutes (m), les heures (h) ou les jours (d).

    L'exemple suivant définit un délai d'attente de deux secondes sur une route nommée myroute: 

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

26.1.4. Sécurité stricte du transport HTTP

La politique HTTP Strict Transport Security (HSTS) est une amélioration de la sécurité qui signale au client du navigateur que seul le trafic HTTPS est autorisé sur l'hôte de la route. HSTS optimise également le trafic web en signalant que le transport HTTPS est nécessaire, sans utiliser de redirections HTTP. HSTS est utile pour accélérer les interactions avec les sites web.

Lorsque la politique HSTS est appliquée, elle ajoute un en-tête Strict Transport Security aux réponses HTTP et HTTPS du site. Vous pouvez utiliser la valeur insecureEdgeTerminationPolicy dans une route pour rediriger HTTP vers HTTPS. Lorsque la politique HSTS est appliquée, le client modifie toutes les requêtes de l'URL HTTP en HTTPS avant l'envoi de la requête, ce qui élimine la nécessité d'une redirection.

Les administrateurs de clusters peuvent configurer HSTS de la manière suivante :

  • Activer HSTS par itinéraire
  • Désactiver HSTS par itinéraire
  • Appliquer HSTS par domaine, pour un ensemble de domaines, ou utiliser des étiquettes d'espace de noms en combinaison avec des domaines
Important

HSTS ne fonctionne qu'avec les routes sécurisées, qu'elles soient terminées en périphérie ou réencryptées. La configuration est inefficace sur les routes HTTP ou passthrough.

26.1.4.1. Activation de HTTP Strict Transport Security par itinéraire

HTTP strict transport security (HSTS) est mis en œuvre dans le modèle HAProxy et appliqué aux itinéraires de bordure et de recryptage qui ont l'annotation haproxy.router.openshift.io/hsts_header.

Conditions préalables

  • Vous êtes connecté au cluster avec un utilisateur disposant de privilèges d'administrateur pour le projet.
  • Vous avez installé le CLI oc.

Procédure

  • Pour activer HSTS sur une route, ajoutez la valeur haproxy.router.openshift.io/hsts_header à la route de terminaison ou de recryptage. Pour ce faire, vous pouvez utiliser l'outil oc annotate en exécutant la commande suivante : 

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ 1
includeSubDomains;preload"
    1
    Dans cet exemple, l'âge maximum est fixé à 31536000 ms, soit environ huit heures et demie.
    Note

    Dans cet exemple, le signe égal (=) est entre guillemets. Cela est nécessaire pour exécuter correctement la commande annoter.

    Exemple de route configurée avec une annotation

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 1 2 3
...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"

    1
    Requis. max-age mesure la durée, en secondes, pendant laquelle la politique HSTS est en vigueur. Si la valeur est 0, la politique est annulée.
    2
    Facultatif. Lorsqu'il est inclus, includeSubDomains indique au client que tous les sous-domaines de l'hôte doivent avoir la même politique HSTS que l'hôte.
    3
    Facultatif. Lorsque max-age est supérieur à 0, vous pouvez ajouter preload dans haproxy.router.openshift.io/hsts_header pour permettre aux services externes d'inclure ce site dans leurs listes de préchargement HSTS. Par exemple, des sites tels que Google peuvent établir une liste de sites pour lesquels preload est défini. Les navigateurs peuvent alors utiliser ces listes pour déterminer les sites avec lesquels ils peuvent communiquer via HTTPS, avant même d'avoir interagi avec le site. Sans preload, les navigateurs doivent avoir interagi avec le site via HTTPS, au moins une fois, pour obtenir l'en-tête.

26.1.4.2. Désactivation de HTTP Strict Transport Security par itinéraire

Pour désactiver HTTP strict transport security (HSTS) par itinéraire, vous pouvez définir la valeur max-age dans l'annotation de l'itinéraire sur 0.

Conditions préalables

  • Vous êtes connecté au cluster avec un utilisateur disposant de privilèges d'administrateur pour le projet.
  • Vous avez installé le CLI oc.

Procédure

  • Pour désactiver HSTS, définissez la valeur max-age dans l'annotation de l'itinéraire sur 0, en entrant la commande suivante : 

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
    Astuce

    Vous pouvez également appliquer le YAML suivant pour créer la carte de configuration :

    Exemple de désactivation de HSTS par itinéraire

    metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

  • Pour désactiver HSTS pour chaque route d'un espace de noms, entrez la commande suivante : 

    $ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

Vérification

  1. Pour demander l'annotation de tous les itinéraires, entrez la commande suivante : 

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

    Exemple de sortie

    Name: routename HSTS: max-age=0

26.1.4.3. Renforcer la sécurité stricte du transport HTTP par domaine

Pour appliquer HTTP Strict Transport Security (HSTS) par domaine pour les itinéraires sécurisés, ajoutez un enregistrement requiredHSTSPolicies à la spécification d'entrée pour capturer la configuration de la politique HSTS.

Si vous configurez un site requiredHSTSPolicy pour qu'il applique HSTS, tout itinéraire nouvellement créé doit être configuré avec une annotation de politique HSTS conforme.

Note

Pour gérer les clusters mis à niveau avec des routes HSTS non conformes, vous pouvez mettre à jour les manifestes à la source et appliquer les mises à jour.

Note

Vous ne pouvez pas utiliser les commandes oc expose route ou oc create route pour ajouter un itinéraire dans un domaine qui applique HSTS, car l'API de ces commandes n'accepte pas les annotations.

Important

HSTS ne peut pas être appliqué aux routes non sécurisées ou non TLS, même si HSTS est demandé pour toutes les routes au niveau mondial.

Conditions préalables

  • Vous êtes connecté au cluster avec un utilisateur disposant de privilèges d'administrateur pour le projet.
  • Vous avez installé le CLI oc.

Procédure

  1. Modifiez le fichier de configuration de l'entrée : 

    $ oc edit ingresses.config.openshift.io/cluster

    Exemple de politique HSTS

    apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: 'hello-openshift-default.apps.username.devcluster.openshift.com'
  requiredHSTSPolicies: 1
  - domainPatterns: 2
    - '*hello-openshift-default.apps.username.devcluster.openshift.com'
    - '*hello-openshift-default2.apps.username.devcluster.openshift.com'
    namespaceSelector: 3
      matchLabels:
        myPolicy: strict
    maxAge: 4
      smallestMaxAge: 1
      largestMaxAge: 31536000
    preloadPolicy: RequirePreload 5
    includeSubDomainsPolicy: RequireIncludeSubDomains 6
  - domainPatterns: 7
    - 'abc.example.com'
    - '*xyz.example.com'
    namespaceSelector:
      matchLabels: {}
    maxAge: {}
    preloadPolicy: NoOpinion
    includeSubDomainsPolicy: RequireNoIncludeSubDomains

    1
    Obligatoire. requiredHSTSPolicies est validé dans l'ordre et le premier domainPatterns correspondant s'applique.
    2 7
    Obligatoire. Vous devez indiquer au moins un nom d'hôte domainPatterns. Un nombre quelconque de domaines peut être listé. Vous pouvez inclure plusieurs sections d'options d'application pour différentes domainPatterns.
    3
    Facultatif. Si vous incluez namespaceSelector, il doit correspondre aux étiquettes du projet où résident les itinéraires, afin d'appliquer la politique HSTS sur les itinéraires. Les itinéraires qui ne correspondent qu'à namespaceSelector et non à domainPatterns ne sont pas validés.
    4
    Requis. max-age mesure la durée, en secondes, pendant laquelle la politique HSTS est en vigueur. Ce paramètre de la politique permet d'appliquer une valeur minimale et une valeur maximale à max-age.
    • La valeur de largestMaxAge doit être comprise entre 0 et 2147483647. Elle peut ne pas être spécifiée, ce qui signifie qu'aucune limite supérieure n'est imposée.
    • La valeur smallestMaxAge doit être comprise entre 0 et 2147483647. Entrez 0 pour désactiver HSTS pour le dépannage, sinon entrez 1 si vous ne voulez jamais que HSTS soit désactivé. Il est possible de ne pas spécifier de valeur, ce qui signifie qu'aucune limite inférieure n'est appliquée.
    5
    Facultatif. L'inclusion de preload dans haproxy.router.openshift.io/hsts_header permet aux services externes d'inclure ce site dans leurs listes de préchargement HSTS. Les navigateurs peuvent alors utiliser ces listes pour déterminer les sites avec lesquels ils peuvent communiquer via HTTPS, avant même d'avoir interagi avec le site. Si preload n'est pas défini, les navigateurs doivent interagir au moins une fois avec le site pour obtenir l'en-tête. preload peut être défini avec l'une des options suivantes :
    • RequirePreloadle site preload est requis par le site RequiredHSTSPolicy.
    • RequireNoPreloadle site preload est interdit par le site RequiredHSTSPolicy.
    • NoOpinionl'article 2 de la loi sur la protection de l'environnement prévoit que : preload n'a pas d'importance pour RequiredHSTSPolicy.
    6
    Facultatif. includeSubDomainsPolicy peut être défini avec l'une des options suivantes :
    • RequireIncludeSubDomainsle site includeSubDomains est requis par le site RequiredHSTSPolicy.
    • RequireNoIncludeSubDomainsle site includeSubDomains est interdit par le site RequiredHSTSPolicy.
    • NoOpinionl'article 2 de la loi sur la protection de l'environnement prévoit que : includeSubDomains n'a pas d'importance pour RequiredHSTSPolicy.

  2. Vous pouvez appliquer HSTS à toutes les routes du cluster ou d'un espace de noms particulier en entrant l'adresse oc annotate command.

    • Pour appliquer HSTS à toutes les routes de la grappe, entrez l'adresse oc annotate command. Par exemple : 

      $ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"

    • Pour appliquer HSTS à toutes les routes d'un espace de noms particulier, entrez l'adresse oc annotate command. Par exemple : 

      $ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"

Vérification

Vous pouvez revoir la politique HSTS que vous avez configurée. Par exemple :

  • Pour vérifier l'ensemble maxAge pour les politiques HSTS requises, entrez la commande suivante : 

    $ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'

  • Pour examiner les annotations HSTS sur tous les itinéraires, entrez la commande suivante : 

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

    Exemple de sortie

    Nom : <_routename_> HSTS : max-age=31536000;preload;includeSubDomains

26.1.5. Méthodes de résolution des problèmes de débit

Parfois, les applications déployées à l'aide d'OpenShift Container Platform peuvent causer des problèmes de débit réseau, tels qu'une latence anormalement élevée entre des services spécifiques.

Si les fichiers journaux ne révèlent aucune cause du problème, utilisez les méthodes suivantes pour analyser les problèmes de performance :

  • Utilisez un analyseur de paquets, tel que ping ou tcpdump, pour analyser le trafic entre un pod et son nœud.

    Par exemple, exécutez l'outil tcpdump sur chaque module tout en reproduisant le comportement à l'origine du problème. Examinez les captures des deux côtés pour comparer les horodatages d'envoi et de réception afin d'analyser la latence du trafic vers et depuis un module. La latence peut se produire dans OpenShift Container Platform si l'interface d'un nœud est surchargée par le trafic provenant d'autres pods, de périphériques de stockage ou du plan de données. 

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 1
    1
    podip est l'adresse IP du module. Exécutez la commande oc get pod <pod_name> -o wide pour obtenir l'adresse IP d'un module.

    La commande tcpdump génère un fichier à l'adresse /tmp/dump.pcap contenant tout le trafic entre ces deux pods. Vous pouvez lancer l'analyseur peu avant que le problème ne se reproduise et l'arrêter peu après la fin de la reproduction du problème pour minimiser la taille du fichier. Vous pouvez également exécuter un analyseur de paquets entre les nœuds (en éliminant le SDN de l'équation) avec : 

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789

  • Utilisez un outil de mesure de la bande passante, tel que iperfpour mesurer le débit de streaming et le débit UDP. Localisez les éventuels goulets d'étranglement en exécutant l'outil d'abord à partir des pods, puis à partir des nœuds.

    • Pour plus d'informations sur l'installation et l'utilisation de iperf, consultez cette solution Red Hat.
  • Dans certains cas, la grappe peut marquer le nœud avec le pod de routeur comme malsain en raison de problèmes de latence. Utilisez les profils de latence des travailleurs pour ajuster la fréquence à laquelle la grappe attend une mise à jour de l'état du nœud avant d'agir.
  • Si votre cluster comporte des nœuds à faible et à forte latence, configurez le champ spec.nodePlacement dans le contrôleur d'entrée pour contrôler l'emplacement du module de routeur.

Ressources supplémentaires

26.1.6. Utilisation de cookies pour conserver l'état des routes

OpenShift Container Platform fournit des sessions collantes, qui permettent un trafic d'application avec état en s'assurant que tout le trafic atteint le même point de terminaison. Cependant, si le pod d'extrémité se termine, que ce soit à la suite d'un redémarrage, d'une mise à l'échelle ou d'un changement de configuration, cet état peut disparaître.

OpenShift Container Platform peut utiliser des cookies pour configurer la persistance de la session. Le contrôleur Ingress sélectionne un point de terminaison pour traiter les demandes des utilisateurs et crée un cookie pour la session. Le cookie est renvoyé dans la réponse à la demande et l'utilisateur renvoie le cookie lors de la prochaine demande de la session. Le cookie indique au contrôleur d'entrée quel point d'accès gère la session, ce qui garantit que les demandes des clients utilisent le cookie et qu'elles sont acheminées vers le même module.

Note

Les cookies ne peuvent pas être installés sur les routes passthrough, car le trafic HTTP ne peut pas être vu. Au lieu de cela, un nombre est calculé sur la base de l'adresse IP source, qui détermine le backend.

Si les backends changent, le trafic peut être dirigé vers le mauvais serveur, ce qui le rend moins collant. Si vous utilisez un équilibreur de charge, qui masque l'IP source, le même numéro est défini pour toutes les connexions et le trafic est envoyé au même pod.

26.1.7. Routes basées sur le chemin

Les itinéraires basés sur un chemin d'accès spécifient un composant de chemin d'accès qui peut être comparé à une URL, ce qui exige que le trafic de l'itinéraire soit basé sur HTTP. Ainsi, plusieurs itinéraires peuvent être servis en utilisant le même nom d'hôte, chacun avec un chemin d'accès différent. Les routeurs doivent faire correspondre les itinéraires en fonction du chemin le plus spécifique au moins spécifique. Cependant, cela dépend de l'implémentation du routeur.

Le tableau suivant présente des exemples d'itinéraires et leur accessibilité :

Tableau 26.1. Disponibilité des itinéraires
ItinérairePar rapport àAccessible

www.example.com/test

www.example.com/test

Oui

www.example.com

Non

www.example.com/test et www.example.com

www.example.com/test

Oui

www.example.com

Oui

www.example.com

www.example.com/text

Oui (Correspondance avec l'hôte, pas avec l'itinéraire)

www.example.com

Oui

Un itinéraire non sécurisé avec un chemin

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" 1
  to:
    kind: Service
    name: service-name

1
Le chemin est le seul attribut ajouté pour un itinéraire basé sur le chemin.
Note

Le routage basé sur le chemin n'est pas disponible lors de l'utilisation de TLS passthrough, car le routeur ne termine pas TLS dans ce cas et ne peut pas lire le contenu de la requête.

26.1.8. Annotations spécifiques à l'itinéraire

Le contrôleur d'entrée peut définir les options par défaut pour toutes les routes qu'il expose. Un itinéraire individuel peut remplacer certaines de ces options par défaut en fournissant des configurations spécifiques dans ses annotations. Red Hat ne prend pas en charge l'ajout d'une annotation d'itinéraire à un itinéraire géré par un opérateur.

Important

Pour créer une liste blanche avec plusieurs IP ou sous-réseaux sources, utilisez une liste délimitée par des espaces. Tout autre type de délimiteur entraîne l'ignorance de la liste sans message d'avertissement ou d'erreur.

Tableau 26.2. Annotations d'itinéraires
VariableDescriptionVariable d'environnement utilisée par défaut

haproxy.router.openshift.io/balance

Définit l'algorithme d'équilibrage de la charge. Les options disponibles sont random, source, roundrobin et leastconn. La valeur par défaut est random.

ROUTER_TCP_BALANCE_SCHEME pour les itinéraires de transit. Sinon, utilisez ROUTER_LOAD_BALANCE_ALGORITHM.

haproxy.router.openshift.io/disable_cookies

Désactive l'utilisation de cookies pour suivre les connexions liées. Si la valeur est 'true' ou 'TRUE', l'algorithme d'équilibre est utilisé pour choisir le back-end qui servira les connexions pour chaque requête HTTP entrante.

 

router.openshift.io/cookie_name

Spécifie un cookie facultatif à utiliser pour cet itinéraire. Le nom doit être composé d'une combinaison de lettres majuscules et minuscules, de chiffres, de "_" et de "-". La valeur par défaut est le nom de la clé interne hachée de l'itinéraire.

 

haproxy.router.openshift.io/pod-concurrent-connections

Définit le nombre maximum de connexions autorisées vers un pod de soutien à partir d'un routeur.
Note : S'il y a plusieurs pods, chacun peut avoir ce nombre de connexions. Si vous avez plusieurs routeurs, il n'y a pas de coordination entre eux, chacun peut se connecter autant de fois. Si cette valeur n'est pas définie ou si elle est fixée à 0, il n'y a pas de limite.

 

haproxy.router.openshift.io/rate-limit-connections

Le réglage de 'true' ou 'TRUE' permet d'activer la fonctionnalité de limitation de débit qui est mise en œuvre par le biais de tables de stick sur le backend spécifique par route.
Remarque : l'utilisation de cette annotation offre une protection de base contre les attaques par déni de service distribué (DDoS).

 

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

Limite le nombre de connexions TCP simultanées établies à partir de la même adresse IP source. Il accepte une valeur numérique.
Remarque : l'utilisation de cette annotation offre une protection de base contre les attaques par déni de service distribué (DDoS).

 

haproxy.router.openshift.io/rate-limit-connections.rate-http

Limite la vitesse à laquelle un client ayant la même adresse IP source peut effectuer des requêtes HTTP. Elle accepte une valeur numérique.
Remarque : l'utilisation de cette annotation offre une protection de base contre les attaques par déni de service distribué (DDoS).

 

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

Limite la vitesse à laquelle un client ayant la même adresse IP source peut établir des connexions TCP. Il accepte une valeur numérique.
Remarque : l'utilisation de cette annotation offre une protection de base contre les attaques par déni de service distribué (DDoS).

 

haproxy.router.openshift.io/timeout

Définit un délai d'attente côté serveur pour la route. (Unités de temps)

ROUTER_DEFAULT_SERVER_TIMEOUT

haproxy.router.openshift.io/timeout-tunnel

Ce délai s'applique à une connexion tunnel, par exemple, WebSocket sur des routes en texte clair, en bordure, réencryptées ou passthrough. Avec les types d'itinéraires cleartext, edge ou reencrypt, cette annotation est appliquée en tant que tunnel timeout avec la valeur timeout existante. Pour les types de routes passthrough, l'annotation est prioritaire sur toute valeur de timeout existante.

ROUTER_DEFAULT_TUNNEL_TIMEOUT

ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after

Vous pouvez définir un IngressController ou la configuration ingress . Cette annotation redéploie le routeur et configure le proxy HA pour qu'il émette l'option globale haproxy hard-stop-after, qui définit le temps maximum autorisé pour effectuer un arrêt progressif propre.

ROUTER_HARD_STOP_AFTER

router.openshift.io/haproxy.health.check.interval

Définit l'intervalle pour les contrôles de santé du back-end. (Unités de temps)

ROUTER_BACKEND_CHECK_INTERVAL

haproxy.router.openshift.io/ip_whitelist

Définit une liste blanche pour l'itinéraire. La liste blanche est une liste d'adresses IP et de plages CIDR séparées par des espaces pour les adresses sources approuvées. Les demandes provenant d'adresses IP qui ne figurent pas dans la liste blanche sont rejetées.

Le nombre maximum d'adresses IP et de plages CIDR autorisées dans une liste blanche est de 61.

 

haproxy.router.openshift.io/hsts_header

Définit un en-tête Strict-Transport-Security pour la route terminée ou recryptée.

 

haproxy.router.openshift.io/log-send-hostname

Définit le champ hostname dans l'en-tête Syslog. Utilise le nom d'hôte du système. log-send-hostname est activé par défaut si une méthode de journalisation Ingress API, telle que sidecar ou Syslog facility, est activée pour le routeur.

 

haproxy.router.openshift.io/rewrite-target

Définit le chemin de réécriture de la requête sur le backend.

 

router.openshift.io/cookie-same-site

Définit une valeur pour restreindre les cookies. Les valeurs possibles sont les suivantes :

Laxles cookies sont transférés entre le site visité et les sites tiers.

Strict: les cookies sont limités au site visité.

None: les cookies sont limités au site visité.

Cette valeur ne s'applique qu'aux itinéraires de recryptage et aux itinéraires de périphérie. Pour plus d'informations, voir la documentation sur les cookies SameSite.

 

haproxy.router.openshift.io/set-forwarded-headers

Définit la politique de traitement des en-têtes HTTP Forwarded et X-Forwarded-For par route. Les valeurs sont les suivantes :

append: ajoute l'en-tête, en préservant tout en-tête existant. C'est la valeur par défaut.

replace: définit l'en-tête, en supprimant tout en-tête existant.

never: ne définit jamais l'en-tête, mais préserve tout en-tête existant.

if-none: définit l'en-tête s'il n'est pas déjà défini.

ROUTER_SET_FORWARDED_HEADERS

Note

Les variables d'environnement ne peuvent pas être modifiées.

Variables de délai d'attente du routeur

TimeUnits sont représentés par un nombre suivi de l'unité : us *(microsecondes), ms (millisecondes, par défaut), s (secondes), m (minutes), h *(heures), d (jours).

L'expression régulière est : [1-9][0-9]*(us\|ms\|s\|m\|h\|d).

VariableDéfautDescription

ROUTER_BACKEND_CHECK_INTERVAL

5000ms

Temps écoulé entre les vérifications ultérieures de l'état de conservation sur les extrémités arrière.

ROUTER_CLIENT_FIN_TIMEOUT

1s

Contrôle le délai d'attente TCP FIN pour le client qui se connecte à la route. Si le FIN envoyé pour fermer la connexion ne répond pas dans le délai imparti, HAProxy ferme la connexion. Ce délai est inoffensif s'il est fixé à une valeur faible et utilise moins de ressources sur le routeur.

ROUTER_DEFAULT_CLIENT_TIMEOUT

30s

Durée pendant laquelle un client doit accuser réception ou envoyer des données.

ROUTER_DEFAULT_CONNECT_TIMEOUT

5s

Le temps de connexion maximum.

ROUTER_DEFAULT_SERVER_FIN_TIMEOUT

1s

Contrôle le délai TCP FIN entre le routeur et le pod qui soutient la route.

ROUTER_DEFAULT_SERVER_TIMEOUT

30s

Durée pendant laquelle un serveur doit accuser réception ou envoyer des données.

ROUTER_DEFAULT_TUNNEL_TIMEOUT

1h

Durée pendant laquelle les connexions TCP ou WebSocket restent ouvertes. Ce délai est réinitialisé à chaque rechargement de HAProxy.

ROUTER_SLOWLORIS_HTTP_KEEPALIVE

300s

Définit le temps d'attente maximum pour l'apparition d'une nouvelle requête HTTP. Si ce délai est trop court, il peut causer des problèmes avec les navigateurs et les applications qui ne s'attendent pas à une petite valeur keepalive.

Certaines valeurs de délai d'attente effectif peuvent correspondre à la somme de certaines variables, plutôt qu'au délai d'attente spécifique prévu. Par exemple, ROUTER_SLOWLORIS_HTTP_KEEPALIVE ajuste timeout http-keep-alive. Il est défini sur 300s par défaut, mais HAProxy attend également tcp-request inspect-delay, qui est défini sur 5s. Dans ce cas, le délai global serait 300s plus 5s.

ROUTER_SLOWLORIS_TIMEOUT

10s

Durée de la transmission d'une requête HTTP.

RELOAD_INTERVAL

5s

Indique la fréquence minimale à laquelle le routeur doit se recharger et accepter de nouvelles modifications.

ROUTER_METRICS_HAPROXY_TIMEOUT

5s

Délai d'attente pour la collecte des données métriques de HAProxy.

Un itinéraire définissant un délai d'attente personnalisé

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 1
...

1
Spécifie le nouveau délai d'attente avec les unités supportées par HAProxy (us, ms, s, m, h, d). Si l'unité n'est pas fournie, ms est l'unité par défaut.
Note

Si la valeur du délai d'attente côté serveur pour les routes passthrough est trop faible, les connexions WebSocket risquent d'expirer fréquemment sur cette route.

Un itinéraire qui n'autorise qu'une seule adresse IP spécifique

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10

Une route qui autorise plusieurs adresses IP

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12

Une route qui permet à une adresse IP d'accéder à un réseau CIDR

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24

Une route qui autorise à la fois une adresse IP et des réseaux CIDR d'adresses IP

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

Une route spécifiant une cible de réécriture

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 1
...

1
Définit / comme chemin de réécriture de la requête sur le backend.

La définition de l'annotation haproxy.router.openshift.io/rewrite-target sur un itinéraire spécifie que le contrôleur d'entrée doit réécrire les chemins dans les requêtes HTTP utilisant cet itinéraire avant de transmettre les requêtes à l'application dorsale. La partie du chemin de la requête qui correspond au chemin spécifié dans spec.path est remplacée par la cible de réécriture spécifiée dans l'annotation.

Le tableau suivant donne des exemples du comportement de réécriture du chemin pour diverses combinaisons de spec.path, de chemin de requête et de cible de réécriture.

Tableau 26.3. exemples de cibles de réécriture :
Route.spec.pathChemin de la demandeRéécriture de l'objectifChemin de la demande transmise

/foo

/foo

/

/

/foo

/foo/

/

/

/foo

/foo/bar

/

/bar

/foo

/foo/bar/

/

/bar/

/foo

/foo

/bar

/bar

/foo

/foo/

/bar

/bar/

/foo

/foo/bar

/baz

/baz/bar

/foo

/foo/bar/

/baz

/baz/bar/

/foo/

/foo

/

N/A (le chemin de la demande ne correspond pas au chemin de l'itinéraire)

/foo/

/foo/

/

/

/foo/

/foo/bar

/

/bar

26.1.9. Configuration de la politique d'admission des routes

Les administrateurs et les développeurs d'applications peuvent exécuter des applications dans plusieurs espaces de noms avec le même nom de domaine. Cela s'adresse aux organisations où plusieurs équipes développent des microservices qui sont exposés sur le même nom d'hôte.

Avertissement

L'autorisation des revendications à travers les espaces de noms ne devrait être activée que pour les clusters avec confiance entre les espaces de noms, sinon un utilisateur malveillant pourrait prendre le contrôle d'un nom d'hôte. Pour cette raison, la politique d'admission par défaut interdit les demandes de noms d'hôtes entre espaces de noms.

Conditions préalables

  • Privilèges d'administrateur de cluster.

Procédure

  • Modifiez le champ .spec.routeAdmission de la variable de ressource ingresscontroller à l'aide de la commande suivante : 

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

    Exemple de configuration du contrôleur d'entrée

    spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

    Astuce

    Vous pouvez également appliquer le langage YAML suivant pour configurer la politique d'admission des routes : 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

26.1.10. Création d'un itinéraire à travers un objet d'entrée

Certains composants de l'écosystème ont une intégration avec les ressources Ingress mais pas avec les ressources route. Pour couvrir ce cas, OpenShift Container Platform crée automatiquement des objets route gérés lorsqu'un objet Ingress est créé. Ces objets route sont supprimés lorsque les objets Ingress correspondants sont supprimés.

Procédure

  1. Définir un objet Ingress dans la console OpenShift Container Platform ou en entrant la commande oc create:

    Définition YAML d'une entrée

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt" 1
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 2
spec:
  rules:
  - host: www.example.com 3
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 443
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - www.example.com
    secretName: example-com-tls-certificate

    1
    L'annotation route.openshift.io/termination peut être utilisée pour configurer le champ spec.tls.termination de Route, car Ingress n'a pas de champ pour cela. Les valeurs acceptées sont edge, passthrough et reencrypt. Toutes les autres valeurs sont ignorées. Lorsque la valeur de l'annotation n'est pas définie, edge est l'itinéraire par défaut. Les détails du certificat TLS doivent être définis dans le fichier modèle pour mettre en œuvre l'itinéraire périphérique par défaut.
    3
    Lorsque vous travaillez avec un objet Ingress, vous devez spécifier un nom d'hôte explicite, contrairement à ce qui se passe avec les routes. Vous pouvez utiliser la syntaxe <host_name>.<cluster_ingress_domain>, par exemple apps.openshiftdemos.com, pour tirer parti de l'enregistrement DNS générique *.<cluster_ingress_domain> et du certificat de service pour le cluster. Sinon, vous devez vous assurer qu'il existe un enregistrement DNS pour le nom d'hôte choisi.

    1. Si vous spécifiez la valeur passthrough dans l'annotation route.openshift.io/termination, définissez path à '' et pathType à ImplementationSpecific dans la spécification : 

        spec:
    rules:
    - host: www.example.com
      http:
        paths:
        - path: ''
          pathType: ImplementationSpecific
          backend:
            service:
              name: frontend
              port:
                number: 443
      $ oc apply -f ingress.yaml
    2
    L'adresse route.openshift.io/destination-ca-certificate-secret peut être utilisée sur un objet Ingress pour définir un itinéraire avec un certificat de destination (CA) personnalisé. L'annotation fait référence à un secret kubernetes, secret-ca-cert, qui sera inséré dans l'itinéraire généré.
    1. Pour spécifier un objet route avec une autorité de certification de destination à partir d'un objet d'entrée, vous devez créer un secret de type kubernetes.io/tls ou Opaque avec un certificat au format PEM dans le spécificateur data.tls.crt du secret.

  2. Dressez la liste de vos itinéraires : 

    $ oc get routes

    Le résultat comprend une route autogénérée dont le nom commence par frontend-: 

    NAME             HOST/PORT         PATH    SERVICES    PORT    TERMINATION          WILDCARD
frontend-gnztq   www.example.com           frontend    443     reencrypt/Redirect   None

    Si vous inspectez cet itinéraire, il se présente comme suit :

    YAML Définition d'un itinéraire autogénéré

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend-gnztq
  ownerReferences:
  - apiVersion: networking.k8s.io/v1
    controller: true
    kind: Ingress
    name: frontend
    uid: 4e6c59cc-704d-4f44-b390-617d879033b6
spec:
  host: www.example.com
  path: /
  port:
    targetPort: https
  tls:
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    insecureEdgeTerminationPolicy: Redirect
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      [...]
      -----END RSA PRIVATE KEY-----
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
  to:
    kind: Service
    name: frontend

26.1.11. Création d'une route à l'aide du certificat par défaut par le biais d'un objet d'entrée

Si vous créez un objet Ingress sans spécifier de configuration TLS, OpenShift Container Platform génère une route non sécurisée. Pour créer un objet Ingress qui génère un itinéraire sécurisé à terminaison périphérique à l'aide du certificat d'entrée par défaut, vous pouvez spécifier une configuration TLS vide comme suit.

Conditions préalables

  • Vous avez un service que vous voulez exposer.
  • Vous avez accès au CLI OpenShift (oc).

Procédure

  1. Créez un fichier YAML pour l'objet Ingress. Dans cet exemple, le fichier s'appelle example-ingress.yaml:

    Définition YAML d'un objet Ingress

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  ...
spec:
  rules:
    ...
  tls:
  - {} 1

    1
    Utilisez cette syntaxe exacte pour spécifier TLS sans spécifier de certificat personnalisé.

  2. Créez l'objet Ingress en exécutant la commande suivante : 

    $ oc create -f example-ingress.yaml

Vérification

  • Vérifiez que OpenShift Container Platform a créé la route attendue pour l'objet Ingress en exécutant la commande suivante : 

    $ oc get routes -o yaml

    Exemple de sortie

    apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd 1
    ...
  spec:
  ...
    tls: 2
      insecureEdgeTerminationPolicy: Redirect
      termination: edge 3
  ...

    1
    Le nom de la route comprend le nom de l'objet Ingress suivi d'un suffixe aléatoire.
    2
    Pour utiliser le certificat par défaut, la route ne doit pas spécifier spec.certificate.
    3
    La route doit spécifier la politique de terminaison de edge.

26.1.12. Création d'un itinéraire à l'aide du certificat de l'autorité de certification de destination dans l'annotation Ingress

L'annotation route.openshift.io/destination-ca-certificate-secret peut être utilisée sur un objet Ingress pour définir un itinéraire avec un certificat CA de destination personnalisé.

Conditions préalables

  • Vous pouvez disposer d'une paire certificat/clé dans des fichiers codés PEM, où le certificat est valable pour l'hôte de la route.
  • Il se peut que vous disposiez d'un certificat d'autorité de certification distinct dans un fichier codé PEM qui complète la chaîne de certificats.
  • Vous devez disposer d'un certificat d'autorité de certification de destination distinct dans un fichier codé en PEM.
  • Vous devez avoir un service que vous souhaitez exposer.

Procédure

  1. Ajouter le site route.openshift.io/destination-ca-certificate-secret aux annotations d'entrée : 

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt"
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 1
...
    1
    L'annotation fait référence à un secret kubernetes.

  2. Le secret référencé dans cette annotation sera inséré dans l'itinéraire généré.

    Exemple de sortie

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: reencrypt
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
spec:
...
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
...

26.1.13. Configurer le contrôleur d'entrée de la plateforme OpenShift Container pour un réseau à double pile

Si votre cluster OpenShift Container Platform est configuré pour un réseau à double pile IPv4 et IPv6, votre cluster est accessible de l'extérieur par les routes OpenShift Container Platform.

Le contrôleur d'entrée dessert automatiquement les services qui ont des points d'extrémité IPv4 et IPv6, mais vous pouvez configurer le contrôleur d'entrée pour des services à pile unique ou à double pile.

Conditions préalables

  • Vous avez déployé un cluster OpenShift Container Platform sur du métal nu.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Pour que le contrôleur d'entrée serve le trafic sur IPv4/IPv6 à une charge de travail, vous pouvez créer un fichier YAML de service ou modifier un fichier YAML de service existant en définissant les champs ipFamilies et ipFamilyPolicy. Par exemple :

    Exemple de fichier YAML de service

    apiVersion: v1
kind: Service
metadata:
  creationTimestamp: yyyy-mm-ddT00:00:00Z
  labels:
    name: <service_name>
    manager: kubectl-create
    operation: Update
    time: yyyy-mm-ddT00:00:00Z
  name: <service_name>
  namespace: <namespace_name>
  resourceVersion: "<resource_version_number>"
  selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
  uid: <uid_number>
spec:
  clusterIP: 172.30.0.0/16
  clusterIPs: 1
  - 172.30.0.0/16
  - <second_IP_address>
  ipFamilies: 2
  - IPv4
  - IPv6
  ipFamilyPolicy: RequireDualStack 3
  ports:
  - port: 8080
    protocol: TCP
    targetport: 8080
  selector:
    name: <namespace_name>
  sessionAffinity: None
  type: ClusterIP
status:
  loadbalancer: {}

    1
    Dans une instance à double pile, deux sites différents sont fournis : clusterIPs.
    2
    Pour une instance à pile unique, entrez IPv4 ou IPv6. Pour une instance à double pile, entrez à la fois IPv4 et IPv6.
    3
    Pour une instance à pile unique, entrez SingleStack. Pour une instance à double pile, entrez RequireDualStack.

    Ces ressources génèrent des endpoints correspondants. Le contrôleur d'entrée surveille maintenant endpointslices.

  2. Pour afficher endpoints, entrez la commande suivante : 

    $ oc get endpoints

  3. Pour afficher endpointslices, entrez la commande suivante : 

    $ oc get endpointslices

Ressources supplémentaires

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.