Spécification de l’API Passerelle d’application pour conteneurs pour Kubernetes

"application-cookie"

AffinityTypeApplicationCookie est un type d’affinité de session pour un cookie d’application

"managed-cookie"

AffinityTypeManagedCookie est un type d’affinité de session pour un cookie managé

"Accepted"

AlbReasonAccepted indique que la ressource Passerelle d’application pour conteneurs est acceptée par le contrôleur.

« Prêt »

AlbReasonDeploymentReady indique l’état du déploiement des ressources Passerelle d’application pour conteneurs.

"InProgress"

AlbReasonInProgress indique si la ressource Passerelle d’application pour conteneurs est en cours de création, de mise à jour ou de suppression.

"Accepted"

AlbConditionTypeAccepted indique si la ressource Passerelle d’application pour conteneurs est acceptée par le contrôleur.

"Deployment"

AlbConditionTypeDeployment indique l’état de déploiement de la ressource Passerelle d’application pour conteneurs.

Les associations sont des ID de ressource de sous-réseau auxquels la ressource Passerelle d’application pour conteneurs est associée.

Les types de conditions connues sont les suivants :

• “Accepté”
• “Prêt”

Métadonnées de l’objet.

Spec correspond aux spécifications de la ressource Passerelle d’application pour conteneurs.

Status définit l’état actuel de la ressource Passerelle d’application pour conteneurs.

Métadonnées de l’objet.

Spec est la spécification BackendTLSPolicy.

Status définit l’état actuel de BackendTLSPolicy.

"Accepted"

BackendTLSPolicyReasonAccepted est utilisé pour définir BackendTLSPolicyConditionReason sur Accepted lorsque la BackendTLSPolicy donnée est configurée correctement

"InvalidBackendTLSPolicy"

BackendTLSPolicyReasonInvalid est la raison pour laquelle backendTLSPolicy n’est pas Accepted

"InvalidCertificateRef"

BackendTLSPolicyReasonInvalidCertificateRef est utilisé lorsqu’un certificat non valide est référencé

"InvalidGroup"

BackendTLSPolicyReasonInvalidGroup est utilisé lorsque le groupe n’est pas valide

"InvalidKind"

BackendTLSPolicyReasonInvalidKind est utilisé lorsque le type/groupe n’est pas valide

"InvalidName"

BackendTLSPolicyReasonInvalidName est utilisé lorsque le nom n’est pas valide

"InvalidSecret"

BackendTLSPolicyReasonInvalidSecret est utilisé lorsque le secret n’est pas valide

"InvalidService"

BackendTLSPolicyReasonInvalidService est utilisé lorsque le service n’est pas valide

"NoTargetReference"

BackendTLSPolicyReasonNoTargetReference est utilisé lorsqu’il n’existe aucune référence cible

"OverrideNotSupported"

BackendTLSPolicyReasonOverrideNotSupported est utilisé lorsque le remplacement n’est pas pris en charge

"RefNotPermitted"

BackendTLSPolicyReasonRefNotPermitted est utilisé lorsque la référence n’est pas autorisée

"SectionNamesNotPermitted"

BackendTLSPolicyReasonSectionNamesNotPermitted est utilisé lorsque les noms de section ne sont pas autorisés

"Accepted"

BackendTLSPolicyConditionAccepted est utilisé pour définir BackendTLSPolicyConditionType sur Accepted

"ResolvedRefs"

BackendTLSPolicyConditionResolvedRefs est utilisé pour définir BackendTLSPolicyCondition sur ResolvedRefs

(Les membres de CommonTLSPolicy sont incorporés dans ce type.)

Sni est le nom du serveur à utiliser pour la connexion TLS au back-end.

Ports spécifie la liste des ports où la stratégie est appliquée.

ClientCertificateRef est la référence au certificat client à utiliser pour la connexion TLS au back-end.

Port est le port à utiliser pour la connexion TLS au back-end

TargetRef identifie un objet API auquel appliquer la stratégie.

Override définit la configuration de stratégie qui doit remplacer la configuration de stratégie attachée sous la ressource ciblée dans la hiérarchie.

Remarque : le remplacement n’est actuellement pas pris en charge et génère une erreur de validation. La prise en charge du remplacement sera ajoutée dans une version ultérieure.

Default définit la configuration de stratégie par défaut pour la ressource ciblée.

conditions décrit les conditions actuelles de BackendTLSPolicy.

Les implémentations doivent préférer exprimer des conditions BackendTLSPolicy à l’aide des constantes BackendTLSPolicyConditionType et BackendTLSPolicyConditionReason, afin que les opérateurs et les outils puissent converger sur un vocabulaire commun pour décrire l’état BackendTLSPolicy.

Les types de conditions connues sont les suivants :

• “Accepté”

Verify fournit les options permettant de vérifier le certificat du pair.

CaCertificateRef est le certificat d’autorité de certification utilisé pour vérifier le certificat du pair.

SubjectAltName est l’autre nom de l’objet utilisé pour vérifier le certificat du pair.

(Les membres de NamespacedPolicyTargetReference sont incorporés dans ce type.)

SectionNames est le nom de la section dans la ressource cible. Lorsqu’il n’est pas spécifié, ce targetRef cible l’ensemble de la ressource. Dans les ressources suivantes, SectionNames est interprété de la manière suivante :

• Passerelle : nom de l’écouteur
• Service : nom du port

Si SectionNames est spécifié, mais qu’il n’existe pas sur l’objet ciblé, l’attachement de la stratégie échoue et l’implémentation de la stratégie enregistre une ResolvedRefs ou une condition similaire dans l’état de la stratégie.

Métadonnées de l’objet.

Spec est la spécification FrontendTLSPolicy.

Status définit l’état actuel de FrontendTLSPolicy.

"Accepted"

FrontendTLSPolicyReasonAccepted est utilisé pour définir FrontendTLSPolicyConditionReason sur Accepted lorsque la FrontendTLSPolicy donnée est configurée correctement

"InvalidFrontendTLSPolicy"

FrontendTLSPolicyReasonInvalid est la raison pour laquelle FrontendTLSPolicy n’est pas Accepted

"InvalidCertificateRef"

FrontendTLSPolicyReasonInvalidCertificateRef est utilisé quand un certificat non valide est référencé.

« InvalidDefault »

FrontendTLSPolicyReasonInvalidDefault est utilisé quand le nom est non valide.

"InvalidGateway"

FrontendTLSPolicyReasonInvalidGateway est utilisé lorsque la passerelle n’est pas valide

"InvalidGroup"

FrontendTLSPolicyReasonInvalidGroup est utilisé lorsque le groupe n’est pas valide

"InvalidKind"

FrontendTLSPolicyReasonInvalidKind est utilisé lorsque le type/groupe n’est pas valide

"InvalidName"

FrontendTLSPolicyReasonInvalidName est utilisé lorsque le nom n’est pas valide

"InvalidPolicyName"

FrontendTLSPolicyReasonInvalidPolicyName est utilisé lorsque le nom de la stratégie n’est pas valide

"InvalidPolicyType"

FrontendTLSPolicyReasonInvalidPolicyType est utilisé lorsque le type de stratégie n’est pas valide

« InvalidTargetReference »

FrontendTLSPolicyReasonInvalidTargetReference est utilisé quand la référence cible est non valide.

"NoTargetReference"

FrontendTLSPolicyReasonNoTargetReference est utilisé lorsqu’il n’existe aucune référence cible

"OverrideNotSupported"

FrontendTLSPolicyReasonOverrideNotSupported est utilisé lorsque le remplacement n’est pas pris en charge

"RefNotPermitted"

FrontendTLSPolicyReasonRefNotPermitted est utilisé lorsque la référence n’est pas autorisée

"SectionNamesNotPermitted"

FrontendTLSPolicyReasonSectionNamesNotPermitted est utilisé lorsque les noms de section ne sont pas autorisés

"Accepted"

FrontendTLSPolicyConditionAccepted est utilisé pour définir FrontendTLSPolicyCondition sur Accepted

"ResolvedRefs"

FrontendTLSPolicyConditionResolvedRefs est utilisé pour définir FrontendTLSPolicyCondition sur ResolvedRefs

Verify fournit les options permettant de vérifier le certificat du pair.

Type est le type de la stratégie.

TargetRef identifie un objet API auquel appliquer la stratégie.

Default définit la configuration de stratégie par défaut pour la ressource ciblée.

Override définit la configuration de stratégie qui doit remplacer la configuration de stratégie attachée sous la ressource ciblée dans la hiérarchie.

Remarque : le remplacement n’est actuellement pas pris en charge et génère une erreur de validation. La prise en charge du remplacement sera ajoutée dans une version ultérieure.

conditions décrit les conditions actuelles de FrontendTLSPolicy.

Les implémentations doivent préférer exprimer des conditions FrontendTLSPolicy à l’aide des constantes FrontendTLSPolicyConditionType et FrontendTLSPolicyConditionReason, afin que les opérateurs et les outils puissent converger sur un vocabulaire commun pour décrire l’état FrontendTLSPolicy.

Les types de conditions connues sont les suivants :

• “Accepté”

"predefined"

PredefinedFrontendTLSPolicyType est le type de la stratégie TLS front-end prédéfinie.

"2023-06"

PredefinedPolicy202306 est le nom de la stratégie TLS front-end prédéfinie pour la stratégie “2023-06”.

"2023-06-S"

PredefinedPolicy202306Strict est le nom de la stratégie TLS front-end prédéfinie pour la stratégie “2023-06-S”. Il s’agit d’une version stricte de la stratégie “2023-06”.

Si elle est présente, l’autorité est utilisée comme valeur de l’en-tête Authority dans le contrôle d’intégrité.

Le service autorise la configuration d’un contrôle d’intégrité inscrit sous un autre nom de service.

Name est le nom de l’en-tête HTTP à mettre en correspondance. La mise en correspondance de noms NE DOIT PAS respecter la casse. (Voir https://tools.ietf.org/html/rfc7230#section-3.2.)

Si plusieurs entrées spécifient des noms d’en-tête équivalents, la première entrée avec un nom équivalent DOIT être prise en compte pour une correspondance. Les entrées suivantes avec un nom d’en-tête équivalent DOIVENT être ignorées. En raison du non-respect de la casse des noms d’en-tête, “foo” et “Foo” sont considérés comme équivalents.

Value est la valeur de l’en-tête HTTP à mettre en correspondance.

Body définit les correspondances de corps HTTP à utiliser pour les vérifications HealthCheck.

StatusCodes définit les correspondances de code d’état HTTP à utiliser pour les vérifications HealthCheck.

Type définit le type de modificateur de chemin d’accès. Davantage de types pourront être ajoutés dans une prochaine version de l’API.

Des valeurs peuvent être ajoutées à cette énumération ; les implémentations doivent s’assurer que les valeurs inconnues ne provoqueront pas d’incident.

Les valeurs inconnues ici doivent entraîner la définition, par l’implémentation, de la condition Accepted pour que la règle soit false

ReplaceFullPath spécifie la valeur par laquelle remplacer le chemin d’accès complet d’une requête lors d’une réécriture ou d’une redirection.

ReplacePrefixMatch spécifie la valeur par laquelle remplacer la correspondance de préfixe d’une requête lors d’une réécriture ou d’une redirection. Par exemple, une requête à “/foo/bar” avec une correspondance de préfixe “/foo” et un ReplacePrefixMatch de “/xyz” sera remplacée par “/xyz/bar”.

Cela correspond au comportement du type de correspondance PathPrefix. Cela correspond aux éléments de chemin d’accès complets. Un élément de chemin d’accès fait référence à la liste des étiquettes dans le chemin d’accès divisé par le séparateur /. S’il est spécifié, un / de fin est ignoré. Par exemple, les chemins d’accès /abc, /abc/ et /abc/def correspondent tous au préfixe /abc, contrairement au chemin d’accès /abcd.

ReplacePrefixMatch n’est compatible qu’avec un httpRouteMatch PathPrefix. Si vous utilisez un autre type de HTTPRouteMatch sur le même HTTPRouteRule, l’implémentation définit la condition Accepté pour la route sur status: False.

"ReplaceFullPath"

FullPathHTTPPathModifier remplace le chemin d’accès complet par la valeur spécifiée.

"ReplacePrefixMatch"

PrefixMatchHTTPPathModifier remplace tout chemin de préfixe par la valeur de substitution. Par exemple, un chemin d’accès avec une correspondance de préfixe de “/foo” et une substitution ReplacePrefixMatch de “/bar” remplace “/foo” par “/bar” dans les requêtes correspondantes.

Cela correspond au comportement du type de correspondance PathPrefix. Cela correspond aux éléments de chemin d’accès complets. Un élément de chemin d’accès fait référence à la liste des étiquettes dans le chemin d’accès divisé par le séparateur /. S’il est spécifié, un / de fin est ignoré. Par exemple, les chemins d’accès /abc, /abc/ et /abc/def correspondent tous au préfixe /abc, contrairement au chemin d’accès /abcd.

Host est la valeur d’en-tête de l’hôte à utiliser pour les vérifications HealthCheck.

Path est le chemin d’accès à utiliser pour les vérifications HealthCheck.

Match définit les correspondances HTTP à utiliser pour les vérifications HealthCheck.

Set remplace la requête par l’en-tête donné (nom, valeur) avant l’action.

Entrée : GET /foo HTTP/1.1 my-header: foo

Config : set: - name: “my-header” value: “bar”

Sortie : GET /foo HTTP/1.1 my-header: bar

Add ajoute le ou les en-têtes donnés (nom, valeur) à la requête avant l’action. Il ajoute à toutes les valeurs existantes associées au nom d’en-tête.

Entrée : GET /foo HTTP/1.1 my-header: foo

Config : add: - name “my-header” value: “bar,baz”

Sortie : GET /foo HTTP/1.1 my-header: foo,bar,baz

Remove supprime le ou les en-têtes donnés de la requête HTTP avant l’action. La valeur de Remove est une liste de noms d’en-tête HTTP. Les noms d’en-tête ne respectent pas la casse (consultez https://datatracker.ietf.org/doc/html/rfc2616#section-4.2).

Entrée : GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

Config : remove: [“my-header1”, “my-header3”]

Sortie : GET /foo HTTP/1.1 my-header2: bar

Métadonnées de l’objet.

Spec est la spécification HealthCheckPolicy.

Status définit l’état actuel de HealthCheckPolicy.

« BackendTLSPolicyNotFound »

BackendTLSPolicyConditionNotFound est utilisé quand BackendTLSPolicy est introuvable pour le service.

"Accepted"

HealthCheckPolicyReasonAccepted est utilisé pour définir HealthCheckPolicyConditionReason sur Accepted. Quand la HealthCheckPolicy donnée est configurée correctement.

"InvalidHealthCheckPolicy"

HealthCheckPolicyReasonInvalid est la raison quand la HealthCheckPolicy n’est pas acceptée (Accepted).

"InvalidGroup"

HealthCheckPolicyReasonInvalidGroup est utilisé quand le groupe est non valide.

"InvalidKind"

HealthCheckPolicyReasonInvalidKind est utilisé quand le type/groupe est non valide.

"InvalidName"

HealthCheckPolicyReasonInvalidName est utilisé quand le nom est non valide.

"InvalidPort"

HealthCheckPolicyReasonInvalidPort est utilisé quand le port est non valide.

"InvalidService"

HealthCheckPolicyReasonInvalidService est utilisé quand le service est non valide.

"NoTargetReference"

HealthCheckPolicyReasonNoTargetReference est utilisé quand il n’existe pas de référence cible.

"OverrideNotSupported"

HealthCheckPolicyReasonOverrideNotSupported est utilisé quand le remplacement n’est pas pris en charge.

"RefNotPermitted"

HealthCheckPolicyReasonRefNotPermitted est utilisé quand la référence n’est pas autorisée.

"SectionNamesNotPermitted"

HealthCheckPolicyReasonSectionNamesNotPermitted est utilisé quand les noms de section ne sont pas autorisés.

"Accepted"

HealthCheckPolicyConditionAccepted est utilisé pour définir HealthCheckPolicyConditionType sur Accepted.

"ResolvedRefs"

HealthCheckPolicyConditionResolvedRefs est utilisé pour définir HealthCheckPolicyCondition sur ResolvedRefs.

Interval est le nombre de secondes entre les vérifications HealthCheck.

HealthCheck est le nombre de secondes après lesquelles la vérification HealthCheck est considérée comme ayant échoué.

Port est le port à utiliser pour les vérifications HealthCheck.

UnhealthyThreshold est le nombre de contrôles HealthCheck consécutifs ayant échoué.

HealthyThreshold est le nombre de contrôles HealthCheck consécutifs ayant réussi.

UseTLS indique si le contrôle d’intégrité doit appliquer le protocole TLS. Par défaut, le contrôle d’intégrité va utiliser le même protocole que le service si le même port est utilisé pour le contrôle d’intégrité. Si le port est différent, le contrôle d’intégrité sera en texte en clair.

HTTP définit la spécification de contrainte HTTP pour la vérification HealthCheck d’une ressource cible.

GRPC configure un contrôle d’intégrité gRPC v1 (https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto) sur la ressource cible.

TargetRef identifie un objet API auquel appliquer la stratégie.

Override définit la configuration de stratégie qui doit remplacer la configuration de stratégie attachée sous la ressource ciblée dans la hiérarchie.

Remarque : le remplacement n’est actuellement pas pris en charge et génère une erreur de validation. La prise en charge du remplacement sera ajoutée dans une version ultérieure.

Default définit la configuration de stratégie par défaut pour la ressource ciblée.

conditions décrit les conditions actuelles de HealthCheckPolicy.

Les implémentations doivent préférer exprimer des conditions HealthCheckPolicy à l’aide des constantes HealthCheckPolicyConditionType et HealthCheckPolicyConditionReason, afin que les opérateurs et les outils puissent converger sur un vocabulaire commun pour décrire l’état HealthCheckPolicy.

Les types de conditions connues sont les suivants :

• “Accepté”

Port indique le port sur le service back-end

Name doit faire référence à un nom sur un port sur le service back-end

Le protocole doit être “HTTP”, “HTTPS”

Service identifie le BackendSetting décrit par cet état

Les erreurs sont une liste d’erreurs relatives à ce paramètre

Valid indique qu’aucune erreur de validation n’est présente sur ce BackendSetting

Service est le nom d’un service back-end auquel cette configuration s’applique

Port peut être utilisé pour indiquer si le service back-end écoute sur HTTP ou HTTPS

TrustedRootCertificate peut être utilisé pour fournir un certificat pouvant être approuvé par la passerelle lors de la communication avec le back-end sur un port spécifié en tant que https

SessionAffinity permet aux requêtes clientes d’être données de manière cohérente au même back-end

Timeouts définit un ensemble de paramètres de délai d’expiration à appliquer à une entrée

Métadonnées de l’objet.

Spec est la spécification IngressExtension.

"Accepted"

IngressExtensionReasonAccepted est utilisé pour définir IngressExtensionConditionAccepted sur Accepted

"HasValidationErrors"

IngressExtensionReasonHasErrors indique qu’il existe des erreurs de validation

"NoValidationErrors"

IngressExtensionReasonNoErrors indique qu’il n’existe aucune erreur de validation

"PartiallyAcceptedWithErrors"

IngressExtensionReasonPartiallyAccepted est utilisé pour définir IngressExtensionConditionAccepted sur Accepté, mais avec des erreurs de validation non irrécupérables

"Accepted"

IngressExtensionConditionAccepted indique si le ingressExtension est accepté (réconciliée) par le contrôleur

"Errors"

IngressExtensionConditionErrors indique s’il existe des erreurs de validation ou de build sur l’extension

Les règles définissent les règles par hôte

BackendSettings définit un ensemble d’options de configuration pour les back-ends du service d’entrée

Les règles contiennent des informations détaillées sur l’état de chaque règle

BackendSettings contient des informations détaillées sur l’état de chaque BackendSettings

conditions décri les conditions actuelles de l’IngressExtension. Les types de conditions connues sont les suivants :

• “Accepté”
• “Erreurs”

Type identifie le type de réécriture

RequestHeaderModifier définit un schéma qui modifie des en-têtes de requête.

RequestHeaderModifier définit un schéma qui modifie des en-têtes de réponse.

URLRewrite définit un schéma qui modifie une requête pendant le transfert.

Host est utilisé pour la mise en correspondance avec les règles d’entrée ayant le même nom d’hôte, afin d’identifier quelles règles sont affectées par ces paramètres

AdditionalHostnames spécifie des noms d’hôte supplémentaires sur lesquels écouter

Rewrites définit les réécritures pour la règle

RequestRedirect définit le comportement de redirection pour la règle

Host identifie la règle décrite par cet état

Les erreurs sont une liste d’erreurs relatives à ce paramètre

Valid indique qu’aucune erreur de validation n’est présente sur cette règle

RequestTimeout définit le délai d’expiration utilisé par l’équilibreur de charge lors du transfert de requêtes vers un service back-end

CaCertificateRef est le certificat d’autorité de certification utilisé pour vérifier le certificat du pair.

SubjectAltNames est la liste des autres noms de l’objet utilisés pour vérifier le certificat du pair.

Name est le nom de la stratégie.

PredefinedFrontendTLSPolicyType est le type de la stratégie TLS front-end prédéfinie.

"HTTP"

ProtocolHTTP implique que le service utilise HTTP.

« HTTPS »

ProtocolHTTPS implique que le service utilise HTTPS.

"TCP"

ProtocolTCP implique que le service utilise le protocole TCP en clair.

Scheme est le schéma à utiliser dans la valeur de l’en-tête Location dans la réponse. S’il est vide, le schéma de la requête est utilisé.

Hostname est le nom d’hôte à utiliser dans la valeur de l’en-tête Location dans la réponse. S’il est vide, le nom d’hôte dans l’en-tête Host de la requête est utilisé.

Path définit les paramètres utilisés pour modifier le chemin d’accès de la requête entrante. Le chemin d’accès modifié est ensuite utilisé pour construire l’en-tête Location. Lorsqu’il est vide, le chemin d’accès de la requête est utilisé tel quel.

Port est le port à utiliser dans la valeur de l’en-tête Location dans la réponse.

Si aucun port n’est spécifié, le port de redirection DOIT être dérivé à l’aide des règles suivantes :

• Si le schéma de redirection n’est pas vide, le port de redirection DOIT être le port connu associé au schéma de redirection. Plus précisément, “http” vers le port 80 et “https” vers le port 443. Si le schéma de redirection n’a pas de port connu, le port d’écouteur de la passerelle DOIT être utilisé.
• Si le schéma de redirection est vide, le port de redirection DOIT être le port de l’écouteur de passerelle.

Les implémentations NE DOIVENT PAS ajouter le numéro de port dans l’en-tête ‘Location’ dans les cas suivants :

• Un en-tête d’emplacement qui utilise HTTP (que ce soit déterminé via le protocole d’écouteur ou le champ de schéma) et qui utilise le port 80.
• Un en-tête d’emplacement qui utilise HTTPS (que ce soit déterminé via le protocole d’écouteur ou le champ de schéma) et qui utilise le port 443.

StatusCode est le code d’état HTTP à utiliser dans la réponse.

Des valeurs peuvent être ajoutées à cette énumération. Les implémentations doivent s’assurer que les valeurs inconnues ne provoqueront pas d’incident.

"RequestHeaderModifier"

RequestHeaderModifier peut être utilisé pour ajouter ou supprimer un en-tête HTTP d’une requête HTTP avant son envoi à la cible en amont.

"ResponseHeaderModifier"

ResponseHeaderModifier peut être utilisé pour ajouter ou supprimer un en-tête HTTP d’une réponse HTTP avant son envoi au client.

"URLRewrite"

URLRewrite peut être utilisé pour modifier une requête pendant le transfert.

Métadonnées de l’objet.

Spec est la spécification RoutePolicy.

Status définit l’état actuel de RoutePolicy.

"Accepted"

RoutePolicyReasonAccepted est utilisé pour définir RoutePolicyConditionReason sur Accepted lorsque la RoutePolicy donnée est configurée correctement

"InvalidRoutePolicy"

RoutePolicyReasonInvalid est la raison pour laquelle RoutePolicy n’est pas Accepted

« InvalidGRPCRoute »

RoutePolicyReasonInvalidGRPCRoute est utilisé quand GRPCRoute est non valide.

"InvalidGroup"

RoutePolicyReasonInvalidGroup est utilisé lorsque le groupe n’est pas valide

"InvalidHTTPRoute"

RoutePolicyReasonInvalidHTTPRoute est utilisé lorsque HTTPRoute n’est pas valide

"InvalidKind"

RoutePolicyReasonInvalidKind est utilisé lorsque le type/groupe n’est pas valide

"InvalidName"

RoutePolicyReasonInvalidName est utilisé lorsque le nom n’est pas valide

"NoTargetReference"

RoutePolicyReasonNoTargetReference est utilisé lorsqu’il n’existe aucune référence cible

"OverrideNotSupported"

RoutePolicyReasonOverrideNotSupported est utilisé lorsque le remplacement n’est pas pris en charge

"RefNotPermitted"

RoutePolicyReasonRefNotPermitted est utilisé lorsque la référence n’est pas autorisée

"SectionNamesNotPermitted"

RoutePolicyReasonSectionNamesNotPermitted est utilisé lorsque les noms de section ne sont pas autorisés

"Accepted"

RoutePolicyConditionAccepted est utilisé pour définir RoutePolicyConditionType sur Accepted

"ResolvedRefs"

RoutePolicyConditionResolvedRefs est utilisé pour définir RoutePolicyCondition sur ResolvedRefs

Délais d’expiration personnalisés pour la ressource cible.

SessionAffinity définit le schéma pour la spécification Session Affinity

TargetRef identifie un objet API auquel appliquer la stratégie.

Override définit la configuration de stratégie qui doit remplacer la configuration de stratégie attachée sous la ressource ciblée dans la hiérarchie.

Remarque : le remplacement n’est actuellement pas pris en charge et génère une erreur de validation. La prise en charge du remplacement sera ajoutée dans une version ultérieure.

Default définit la configuration de stratégie par défaut pour la ressource ciblée.

conditions décrit les conditions actuelles de RoutePolicy.

Les implémentations doivent préférer exprimer des conditions RoutePolicy à l’aide des constantes RoutePolicyConditionType et RoutePolicyConditionReason, afin que les opérateurs et les outils puissent converger sur un vocabulaire commun pour décrire l’état RoutePolicy.

Les types de conditions connues sont les suivants :

• “Accepté”

RouteTimeout est le délai d’expiration pour la route.

Start définit le début de la plage de codes d’état à utiliser pour les vérifications HealthCheck. Ceci est inclusif.

End définit la fin de la plage de codes d’état à utiliser pour les vérifications HealthCheck. Ceci est inclusif.

Hostname est la valeur à utiliser pour remplacer la valeur d’en-tête de l’hôte pendant le transfert.

Path définit une réécriture de chemin d’accès.