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ée”
• “Prête”

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

L’état définit l’état actuel de BackendLoadBalancingPolicy.

"Accepted"

BackendLoadBalancingPolicyReasonAccepted est utilisé pour définir BackendLoadBalancingPolicyConditionReason sur Accepté lorsque le BackendLoadBalancingPolicy fourni est correctement configuré

« En conflit »

BackendLoadBalancingPolicyReasonConflicted est utilisé lorsque la référence cible entre en conflit avec une cible de politique existante.

« InvalidBackendLoadBalancingPolicy »

BackendLoadBalancingPolicyReasonInvalid est la raison pour laquelle BackendLoadBalancingPolicy n’est’pas accepté

"InvalidGroup"

BackendLoadBalancingPolicyReasonInvalidGroup est utilisé lorsque le groupe est invalide

"InvalidKind"

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

"InvalidName"

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

"InvalidService"

BackendLoadBalancingPolicyReasonInvalidService est utilisé lorsque le Service n’est pas valide

"NoTargetReference"

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

"RefNotPermitted"

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

"ResolvedRefs"

BackendLoadBalancingPolicyReasonResolvedRefs est utilisé pour définir le BackendLoadBalancingPolicyConditionReason sur ResolvedRefs lorsque le BackendLoadBalancingPolicy a des références correctes

"Accepted"

BackendLoadBalancingPolicyConditionAccepted est utilisé pour définir BackendLoadBalancingPolicyConditionType sur Accept

"ResolvedRefs"

BackendLoadBalancingPolicyConditionResolvedRefs est utilisé pour définir BackendLoadBalancingPolicyCondition sur ResolvedRefs

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

TargetRefs identifie une liste d’objets API auxquels appliquer la stratégie.

LoadBalancing définit le schéma pour la configuration des options d’équilibrage de charge

Métadonnées de l’objet ’.

Spec est la spécification BackendTLSPolicy.

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

(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ée”
• “ResolvedRefs”

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.

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ée”

"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

Configuration : ajouter : - nom : “my-header” valeur : “bar,baz”

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

Supprimez 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

Configuration : supprimer : [“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.

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

« BackendTLSPolicyNotFound »

BackendTLSPolicyConditionNotFound est utilisé lorsque backendTLSPolicy est introuvable pour le service.

"Accepted"

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

"InvalidHealthCheckPolicy"

HealthCheckPolicyReasonInvalid est la raison pour laquelle la HealthCheckPolicy n’est’pas acceptée.

"InvalidGroup"

HealthCheckPolicyReasonInvalidGroup est utilisé lorsque le groupe n’est pas valide.

"InvalidKind"

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

"InvalidName"

HealthCheckPolicyReasonInvalidName est utilisé lorsque le nom n’est pas valide.

« InvalidPort »

HealthCheckPolicyReasonInvalidPort est utilisé lorsque le port n’est pas valide.

"InvalidService"

HealthCheckPolicyReasonInvalidService est utilisé lorsque le service n’est pas valide.

"NoTargetReference"

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

« OverrideNotSupported »

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

"RefNotPermitted"

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

"ResolvedRefs"

HealthCheckPolicyReasonResolvedRefs est utilisé lorsque le targetRef a été résolu avec succès.

"SectionNamesNotPermitted"

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

« UnsupportedStatusCodes »

HealthCheckPolicyReasonUnsupportedStatusCodes est utilisé lorsque HealthCheckPolicy correspondant à StatusCodes ne sont pas pris en charge.

"Accepted"

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

"ResolvedRefs"

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

L’intervalle est le nombre de secondes entre les vérifications HealthCheck.

Le délai d’expiration 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" réussis consécutifs.

UseTLS indique si la vérification d’intégrité doit appliquer TLS. Par défaut, la vérification d’intégrité utilise 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, la vérification de l'état sera en texte clair.

HTTP définit la spécification de contrainte HTTP pour 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.

Les conditions décrivent 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ée”

Le port désigne celui utilisé par le service back-end.

Le nom doit faire référence à un nom sur un port sur le service principal

Le protocole doit être l’un des “protocoles HTTP”, “HTTPS”

Le service identifie le BackendSetting auquel cet état correspond.

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

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

Le service est le nom d’un service principal auquel cette configuration s’applique

Les ports peuvent être utilisés pour indiquer si le service principal écoute sur HTTP ou HTTPS

TrustedRootCertificate peut être utilisé pour fournir un certificat de confiance pour la passerelle lors de la communication avec le back-end sur le port spécifié en HTTPS.

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

Les délais d’expiration définissent un ensemble de paramètres d'expiration à appliquer à une Ingress.

LoadBalancing définit la stratégie d’équilibrage de charge pour le service principal

Métadonnées de l’objet ’.

Spec est la spécification IngressExtension.

"Accepted"

IngressExtensionReasonAccepted est utilisé pour définir IngressExtensionConditionAccepted sur Accept

"HasValidationErrors"

IngressExtensionReasonHasErrors indique qu’il existe des erreurs de validation

AucuneErreurDeValidation

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

« Accepté partiellement avec erreurs »

IngressExtensionReasonPartiallyAccepted est utilisé pour définir IngressExtensionConditionAccepted sur Accepté, mais avec des erreurs de validation non-fatales.

"Accepted"

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

« Erreurs »

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 Ingress

Les règles ont des informations d’état détaillées sur chaque règle

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

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

• “Acceptée”
• “Erreurs”

Type identifie le type de réécriture

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

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

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

L’hôte est utilisé pour correspondre aux règles Ingress avec le même nom d’hôte afin d’identifier les règles qui influencent ces paramètres.

AdditionalHostnames spécifie d’autres noms d’hôte sur lesquels écouter.

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

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

L’hôte identifie la règle que décrit ce statut

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

Valide 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

La stratégie définit la stratégie à utiliser lors de l’équilibrage de charge du trafic vers le service principal. La valeur par défaut est le round-robin.

SlowStart définit le schéma pour la spécification Slow Start

« moins de requêtes »

LoadBalancingLeastRequest est utilisé pour définir LoadBalancingStrategy sur least-request

« ring-hash »

LoadBalancingRingHash est utilisé pour définir LoadBalancingStrategy sur ring-hash

« round-robin »

LoadBalancingRoundRobin est utilisé pour définir LoadBalancingStrategy sur round-robin

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

SubjectAltNames est la liste des noms alternatifs de l'objet utilisés pour vérifier le certificat homologue.

"Accepted"

« En conflit »

« Déployé »

« ÉchecDuDéploiement »

« Non valide »

"InvalidCertificateRef"

"InvalidGroup"

"InvalidKind"

"InvalidName"

"InvalidService"

« InvalidTargetReference »

« Pas de déploiement »

"NoTargetReference"

« OpérationÉchouée »

« OverrideNotSupported »

« En attente »

« Programmé »

Échec de programmation

"RefNotPermitted"

"ResolvedRefs"

"SectionNamesNotPermitted"

"Accepted"

"Deployment"

« Programmé »

"ResolvedRefs"

TargetRef est la référence à l’objet cible auquel cette stratégie est appliquée

Les conditions décrivent les conditions actuelles des règles d’accès IP d’Application Gateway pour conteneurs, car elles concernent un targetRef particulier.

Name est le nom de la stratégie.

FrontendTLSPolicyType spécifie le type de stratégie TLS frontend

« 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 brut.

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

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

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

Le port à utiliser est celui indiqué 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 obligatoirement ê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.
• En-tête de localisation qui utilise HTTPS (que cela soit déterminé via le protocole Listener ou le champ Schéma) et utilise le port 443.

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

Les valeurs peuvent être ajoutées à cette énumération, les implémentations doivent s’assurer que les valeurs inconnues ne provoquent’pas de blocage.

« RequestHeaderModifier »

RequestHeaderModifier peut être utilisé pour ajouter ou supprimer un en-tête HTTP d’une requête HTTP avant d’être’envoyé à 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 »

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

Métadonnées de l’objet ’.

La spécification Spec est celle de RoutePolicy.

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

"Accepted"

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

« AcceptedWithTimeoutConflict »

RoutePolicyReasonAcceptedWithTimeoutConflict est utilisé pour définir RoutePolicyConditionReason sur AcceptedWithTimeoutConflict lorsque la RoutePolicy donnée est correctement configurée, mais a un conflit de délai d’expiration avec l’itinéraire cible

"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/le 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 Accept

"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 d’affinité de session

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.

Les conditions décrivent les conditions actuelles de RoutePolicy.

Les implémentations doivent préférer exprimer des conditions de RoutePolicy en utilisant les constantes RoutePolicyConditionType et RoutePolicyConditionReason afin que les opérateurs et les outils puissent converger sur un langage commun pour décrire l'état de RoutePolicy.

Les types de conditions connues sont les suivants :

• “Acceptée”

RouteTimeout est le délai d’expiration de l’itinéraire.

Durée de la fenêtre de démarrage lente.

La vitesse d'augmentation du trafic pendant la fenêtre de démarrage lente doit être supérieure à 0,0. La valeur par défaut est 1.0 si elle n’est pas spécifiée.

Pourcentage minimal ou de départ du trafic à envoyer vers de nouveaux points d'accès. La valeur par défaut est 10% si elle n’est pas spécifiée.

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

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

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

Les ports spécifient la liste des ports où la stratégie est appliquée.

Le nom d’hôte 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.

Métadonnées de l’objet ’.

La spécification correspond aux spécifications pour la ressource enfant de stratégie de sécurité de Passerelle d’application pour conteneurs.

L’état définit l’état actuel de la ressource enfant de stratégie de sécurité de Passerelle d’application pour conteneurs.

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

WebApplicationFirewallPolicy est utilisé pour spécifier une ressource WebApplicationPolicy

Les types de conditions connues sont les suivants :

• “Acceptée”
• “Déploiement”
• “ResolvedRefs”
• “Programmé”