Customize ALB Ingress forwarding rules - Container Service for Kubernetes

ALB Ingress prend en charge les règles de transfert personnalisées. Une règle de transfert se compose de conditions et d'actions de transfert. Vous pouvez définir des conditions de transfert personnalisées en fonction du nom de domaine, du chemin d'accès, de l'en-tête de requête, de la chaîne de requête, de la méthode de requête, du cookie ou de l'adresse IP source. Vous pouvez également définir des actions de transfert personnalisées, telles que le renvoi d'une réponse fixe, la création d'une redirection, l'insertion ou la suppression d'un en-tête de requête, la mise en miroir du trafic, le transfert des requêtes vers plusieurs groupes de serveurs principaux ou la réécriture des requêtes. Configurez ces règles de transfert personnalisées dans la console ou en ajoutant des annotations à une ressource Ingress.

Prérequis

Le composant ALB Ingress Controller doit être installé et sa version doit être égale ou supérieure à la v2.5.0. Pour plus d'informations, consultez Gérer les composants.

Conditions de transfert

Important

Une règle de transfert peut contenir au maximum 10 conditions.
Les conditions de transfert ResponseHeader et ResponseStatusCode sont valides uniquement pour les règles de transfert basées sur la réponse.

Conditions de transfert

ALB Ingress permet de configurer des conditions de transfert via l'annotation alb.ingress.kubernetes.io/conditions.<service-name>. Les différents blocs de règles de routage entretiennent une relation logique ET (AND), tandis que les valeurs au sein d'un même bloc obéissent à une logique OU (OR). Par exemple, deux blocs de règles Header distincts sont liés par un ET logique, mais les valeurs spécifiées dans un même bloc Header sont évaluées selon un OU logique. Voici le détail des règles de routage.

Condition de transfert	Description
Nom de domaine	Achemine les requêtes en fonction d'une correspondance avec le nom de domaine. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "Host", "hostConfig": { "values": [ "anno.example.com" ] } }]` type : type de correspondance. Définissez la valeur sur Host pour effectuer une correspondance par nom de domaine. hostConfig : nom de domaine à faire correspondre. Si vous spécifiez plusieurs noms de domaine, ils sont évalués selon une logique `OR`.
Chemin d'accès	Achemine les requêtes en fonction d'une correspondance avec le chemin d'accès. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "Path", "pathConfig": { "values": [ "/pathvalue1", "/pathvalue2" ] } }]` type : type de correspondance. Définissez la valeur sur Path pour faire correspondre le chemin d'accès de la requête. pathConfig : chemin d'accès à faire correspondre. Si vous spécifiez plusieurs chemins d'accès, ils sont évalués selon une logique `OR`.
En-tête	Achemine les requêtes en fonction d'une correspondance avec l'en-tête de requête. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "Header", "headerConfig": { "key": "headername", "values": [ "headervalue1", "headervalue2" ] } }]` type : type de correspondance. Définissez la valeur sur Header pour faire correspondre un en-tête de requête. headerConfig : clé et valeurs de l'en-tête. Si vous spécifiez plusieurs valeurs d'en-tête, elles sont évaluées selon une logique `OR`.
Chaîne de requête	Achemine les requêtes en fonction d'une correspondance avec la chaîne de requête. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "QueryString", "queryStringConfig": { "values": [ { "key":"querystringkey1", "value":"querystringvalue2" } ] } }]` type : type de correspondance. Définissez la valeur sur QueryString pour faire correspondre la chaîne de requête. queryStringConfig : paires clé-valeur de la chaîne de requête. La longueur d'une clé et d'une valeur doit être comprise entre 1 et 100 caractères. La clé et la valeur peuvent contenir des lettres minuscules, des caractères visibles ainsi que les caractères génériques astérisque (*) et point d'interrogation (?). Les espaces et les caractères `#[]{}\\|<>&` ne sont pas pris en charge. Si vous spécifiez plusieurs chaînes de requête, elles sont évaluées selon un OU logique. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 3 : Acheminer le trafic en fonction de la chaîne de requête, de plusieurs en-têtes et de plusieurs chemins d'accès.
Méthode de requête	Achemine les requêtes en fonction d'une correspondance avec la méthode de requête. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "Method", "methodConfig": { "values": [ "GET", "HEAD" ] } }]` type : type de correspondance. Définissez cette valeur sur Method pour faire correspondre la méthode de requête. methodConfig : méthode de requête. Valeurs prises en charge : `GET`, `POST`, `PUT`, `DELETE`, `HEAD`, `OPTIONS` et `PATCH`. Si vous spécifiez plusieurs méthodes, elles sont évaluées selon une logique `OR`.
Cookie	Achemine les requêtes en fonction d'une correspondance avec le cookie. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "Cookie", "cookieConfig": { "values": [ { "key":"cookiekey1", "value":"cookievalue2" } ] } }]` type : type de correspondance. Définissez la valeur sur Cookie pour faire correspondre un cookie. cookieConfig : paire clé-valeur d'un cookie. La longueur de la clé et de la valeur doit être comprise entre 1 et 100 caractères. La clé et la valeur peuvent contenir des lettres minuscules, des caractères visibles, le caractère générique astérisque (*) et le point d'interrogation (?). Les espaces et les caractères suivants ne sont pas pris en charge : `#[]{}\\|<>&`. Si vous configurez plusieurs cookies, ils sont évalués selon un OU logique. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 2 : Acheminer le trafic en fonction du nom de domaine, de la méthode de requête et du cookie.
Adresse IP source	Achemine les requêtes en fonction d'une correspondance avec l'adresse IP source. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "SourceIp", "sourceIpConfig": { "values": [ "192.168.0.0/16", "172.16.0.0/16" ] } }]` type : type de correspondance. Définissez la valeur sur SourceIP pour faire correspondre l'adresse IP source de la requête. sourceIpConfig : adresse IP source ou bloc CIDR. Si vous spécifiez plusieurs adresses IP ou blocs CIDR, ils sont évalués selon une logique `OR`. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 1 : Acheminer le trafic en fonction de l'adresse IP source et de l'en-tête.
En-tête de réponse	Fait correspondre l'en-tête de réponse et exécute l'action de transfert uniquement sur les réponses contenant l'en-tête correct. Notez que cette option doit être utilisée conjointement avec l'annotation `alb.ingress.kubernetes.io/rule-direction.<service-name>: Response`. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "ResponseHeader", "headerConfig": { "key": "headername", "values": [ "headervalue1", "headervalue2" ] } }]` type : type de condition. Définissez cette valeur sur `ResponseHeader` pour faire correspondre un en-tête dans la réponse. headerConfig : clé et valeurs de l'en-tête. Si vous spécifiez plusieurs valeurs d'en-tête, elles sont évaluées selon une logique `OR`.
Code d'état de la réponse	Fait correspondre le code d'état de la réponse. Le service est accessible uniquement si le code d'état correct est renvoyé. Notez que cette fonctionnalité doit être utilisée avec une action de transfert orientée réponse et l'annotation de règle de transfert orientée réponse `alb.ingress.kubernetes.io/rule-direction.<service-name>: Response`. Voici un exemple. `alb.ingress.kubernetes.io/conditions.service-name: \| # The service name must match a backend service name in spec.rules. These conditions apply to that service. [{ "type": "ResponseStatusCode", "responseStatusCodeConfig": { "values": [ "statuscode1", "statuscode2" ] } }]` type : type de correspondance. Définissez la valeur sur `ResponseStatusCode` pour faire correspondre le code d'état de la réponse. responseStatusCodeConfig : code d'état de la réponse. Si vous spécifiez plusieurs codes d'état, ils sont évalués selon une logique `OR`.

Cas d'utilisation 1 : Routage par adresse IP source et en-tête

Important

Vous pouvez spécifier au maximum cinq conditions source IP dans une seule règle de transfert.

Ce fichier YAML définit un Ingress qui achemine les requêtes uniquement lorsque l'adresse IP source, l'en-tête et le chemin d'accès correspondent aux conditions spécifiées.

Si l'adresse IP source d'une requête provient de 192.168.0.0/16 ou 172.16.0.0/16, si l'en-tête de requête contient gray-hello avec la valeur value1 ou value2, et si le chemin d'accès de la requête est /hello, alors la requête est acheminée vers le service gray-hello-svc. Dans le cas contraire, la requête est acheminée vers d'autres services.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/order: "1"
   alb.ingress.kubernetes.io/conditions.gray-hello-svc: | # The service name must match a backend service name in spec.rules. These conditions apply to that service.
     [{
       "type": "Header",
       "headerConfig": {
          "key":"gray-hello",
           "values": [
              "value1",
              "value2"
           ]
       }
      },
      {
         "type": "SourceIp",
         "sourceIpConfig": {
           "values": [
             "192.168.0.0/16",
             "172.16.0.0/16"
           ]
         }
     }]
  name: gray-hello-ingress
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /hello
        pathType: ImplementationSpecific
        backend:
          service:
            name: gray-hello-svc # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
            port:
              number: 88

alb.ingress.kubernetes.io/order : spécifie la priorité de l'Ingress. Plus le nombre est petit, plus la priorité est élevée.

Cas d'utilisation 2 : Routage par domaine, méthode et cookie

Ce fichier YAML définit un Ingress qui achemine les requêtes uniquement lorsque le nom de domaine, la méthode de requête et le cookie correspondent aux conditions spécifiées.

Cela signifie qu'une requête est acheminée vers le service-a uniquement si la méthode de requête est GET ou HEAD, si l'hôte de la requête est example.com ou *.edu, si le cookie de la requête possède la clé cookiekey1 et la valeur cookievalue1, et si le chemin d'accès de la requête est /test. Dans le cas contraire, la requête est acheminée vers le service-b.

Remarque

Les règles de transfert pour les noms de domaine prennent en charge les caractères génériques.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: | # The service name must match a backend service name in spec.rules. These conditions apply to that service.
     [{
       "type": "Cookie",
       "cookieConfig": {
         "values": [
           {
             "key":"cookiekey1",
             "value":"cookievalue1"
           }
        ]
       }
      },
      {
       "type": "Method",
       "methodConfig": {
         "values": [
           "GET",
           "HEAD"
         ]
       }
      },
     {
       "type": "Host",
       "hostConfig": {
           "values": [
              "example.com",
              "*.edu" 
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

Cas d'utilisation 3 : Routage par chaîne de requête, en-tête et chemin d'accès

Ce fichier YAML définit un Ingress qui achemine les requêtes uniquement lorsque la chaîne de requête, les en-têtes et le chemin d'accès correspondent aux conditions spécifiées.

Cela signifie qu'une requête est acheminée vers le service service-a si le chemin d'accès de la requête est /pathvalue1, /pathvalue2 ou /test, si la chaîne de requête possède la clé querystringkey1 et la valeur querystringvalue2, et si l'en-tête de requête doit contenir headerkey1 et headerkey2. De plus, pour l'en-tête de requête contenant headerkey1, la valeur doit être headervalue1 ou headervalue2, et pour l'en-tête de requête contenant headerkey2, la valeur doit être headervalue3 ou headervalue4. Dans le cas contraire, la requête est acheminée vers le service service-b.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: | # The service name must match a backend service name in spec.rules. These conditions apply to that service.
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "/pathvalue1",
              "/pathvalue2"
           ]
       }
      },
      {
       "type": "QueryString",
       "queryStringConfig": {
         "values": [
           {
             "key":"querystringkey1",
             "value":"querystringvalue2"
           }
        ]
       }
      },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey1",
           "values": [
              "headervalue1",
              "headervalue2"
           ]
       }
     },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey2",
           "values": [
              "headervalue3",
              "headervalue4"
           ]
       }
     }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

Actions de transfert

ALB Ingress vous permet de configurer des actions de transfert pour les requêtes et les réponses à l'aide de l'annotation alb.ingress.kubernetes.io/actions.<service-name>. Les actions prises en charge incluent le renvoi d'une réponse fixe, la redirection, l'insertion ou la suppression d'un en-tête, la mise en miroir du trafic, le transfert vers plusieurs groupes de serveurs backend et la réécriture des requêtes. En définissant ces actions de transfert, vous pouvez gérer avec flexibilité la façon dont les requêtes et les réponses sont traitées dans votre ALB Ingress.

Important

Pour l'annotation alb.ingress.kubernetes.io/actions.<service-name>, assurez-vous que le nom du service indiqué dans l'annotation correspond au nom du service sous backend dans le champ rule.
N'utilisez qu'une seule action de transfert terminal, telle qu'une redirection, une réponse fixe ou un transfert vers plusieurs groupes de serveurs, dans la même règle de transfert.

Lorsque vous configurez une redirection, une réponse fixe ou un transfert vers plusieurs groupes de serveurs, vous devez définir backend.service.port.name sur use-annotation.

Actions de transfert de requête

Action	Description
Réponse fixe	Envoie une réponse fixe au client depuis l'Application Load Balancer (ALB). Vous pouvez définir le code d'état de la réponse, le contenu et le type de contenu. Le code suivant fournit un exemple. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "FixedResponse", "FixedResponseConfig": { "contentType": "text/plain", "httpCode": "503", "content": "503 error text" } }]` type : le type d'action de transfert. Définissez cette valeur sur FixedResponse pour cette action. contentType : le type de contenu du corps de la réponse. httpCode : le code d'état de la réponse. content : le corps de la réponse. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 1 : Définir une réponse fixe.
Redirection	Redirige le client vers une adresse différente à l'aide d'un code d'état HTTP 3xx. Le code suivant fournit un exemple. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "Redirect", "RedirectConfig": { "host": "${host}", "path": "/test", "port": "443", "protocol": "https", "query": "querystring", "httpCode": "301" } }]` type : le type d'action de transfert. Définissez cette valeur sur Redirect pour cette action. host : l'hôte vers lequel la requête est redirigée. path : le chemin vers lequel la requête est redirigée. port : le port vers lequel la requête est redirigée. protocol : le protocole vers lequel la requête est redirigée. query : la chaîne de requête de la requête redirigée. httpCode : le code d'état renvoyé après la redirection. Important Vous pouvez configurer les paramètres host, path, port, protocol et query pour utiliser les valeurs de la requête d'origine, mais au moins l'un d'entre eux doit être défini sur une valeur non par défaut. Par exemple, si vous définissez host sur `${host}`, laissez-le vide (`"host": ""`) ou n'incluez pas le paramètre, la valeur de la requête d'origine est utilisée. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 2 : Utiliser une redirection 301.
Mise en miroir du trafic	Copie la requête et la transfère vers un groupe de serveurs de mise en miroir du trafic. Vous devez spécifier l'ID du groupe de serveurs. Le code suivant fournit un exemple. Important L'action de transfert de mise en miroir du trafic ne peut être utilisée qu'avec le transfert, l'insertion d'un en-tête, la suppression d'un en-tête et la limitation QPS. Elle ne peut pas être utilisée avec la réécriture, la réponse fixe ou la redirection. Vous ne pouvez joindre un groupe de serveurs de mise en miroir du trafic qu'en spécifiant son ServerGroupID. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "TrafficMirror", "TrafficMirrorConfig": { "TargetType" : "ForwardGroupMirror", "MirrorGroupConfig": { "ServerGroupTuples" : [{ "ServerGroupID": "sgp-2auud2fxj1r46*****" }] } } }]` type : le type d'action de transfert. Définissez cette valeur sur TrafficMirror pour configurer la mise en miroir du trafic. TargetType : le type de cible pour la mise en miroir. Actuellement, seul `ForwardGroupMirror` est pris en charge, ce qui permet de mettre en miroir les requêtes vers un groupe de serveurs. ServerGroupID : l'ID du groupe de serveurs de mise en miroir du trafic. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 4 : Mettre en miroir le trafic.
Transfert vers plusieurs groupes de serveurs backend	Transfère les requêtes ALB vers plusieurs groupes de serveurs backend. Vous pouvez spécifier les groupes de serveurs backend à l'aide de ServerGroupID, ou créer ou joindre des groupes de serveurs à l'aide de ServiceName+ServicePort. Vous pouvez également définir un poids de transfert pour chaque groupe de serveurs backend et activer la persistance de session entre les groupes de serveurs. Important Une instance ALB standard peut être associée à un maximum de cinq groupes de serveurs. Si vous associez des groupes de serveurs à l'aide de ServerGroupID et de ServiceName+ServicePort, la correspondance privilégie ServerGroupID. Lorsque la persistance de session est activée, ALB Ingress transfère les requêtes de la même session vers le même backend. alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "ForwardGroup", "ForwardConfig": { "ServerGroups" : [{ "ServiceName": "tea-svc", "Weight": 30, "ServicePort": 80 }, { "ServiceName": "coffee-svc", "Weight": 20, "ServicePort": 80 }, { "ServerGroupID": "sgp-71aexb9y93ypo***", "Weight": 20 }, { "ServerGroupID": "sgp-slygpbvm2cydo***", "Weight": 30 }], "ServerGroupStickySession": { "Enabled": true, "Timeout": 80 } } }] type : le type d'action de transfert. Définissez cette valeur sur ForwardGroup pour configurer le transfert vers plusieurs groupes de serveurs backend. ForwardConfig : les paramètres des groupes de serveurs backend. Si vous configurez plusieurs groupes de serveurs, les requêtes sont transférées vers chaque groupe de serveurs en fonction de son poids. ServerGroupID : l'ID du groupe de serveurs. ServiceName : le nom du service. ServicePort : le port du service. Weight : le poids pour le transfert des requêtes vers chaque groupe de serveurs. Enabled : indique s'il faut activer la persistance de session entre les groupes de serveurs. Timeout : le délai d'expiration pour la persistance de session entre les groupes de serveurs. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 5 : Transférer vers plusieurs groupes de serveurs.
Réécriture	Réécrit la requête avant de la transférer au backend. L'Application Load Balancer (ALB) peut modifier l'hôte, le chemin et la chaîne de requête de la requête. Important L'action de réécriture entre en conflit avec l'annotation `rewrite-target`. Ne les utilisez pas ensemble. L'action de réécriture ne peut pas être utilisée avec les actions de réponse fixe ou de redirection. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "Rewrite", "RewriteConfig": { "Host": "demo.domain.ingress.top", "Path": "/test", "Query": "querystring" } }]` type : le type d'action de transfert. Définissez cette valeur sur Rewrite pour utiliser la fonctionnalité de réécriture. host : l'hôte utilisé dans la requête réécrite. Si vous définissez cette valeur sur `${host}`, laissez-la vide (`"host": ""`) ou n'incluez pas le paramètre, la valeur de la requête d'origine est utilisée. path : le chemin utilisé dans la requête réécrite. Si vous définissez cette valeur sur `${path}`, laissez-la vide (`"path": ""`) ou n'incluez pas le paramètre, la valeur de la requête d'origine est utilisée. query : la chaîne de requête de la requête réécrite. Si vous définissez cette valeur sur `${query}`, laissez-la vide (`"query": ""`) ou n'incluez pas le paramètre, la valeur de la requête d'origine est utilisée. Important Les paramètres host, path et query peuvent être configurés pour utiliser les valeurs de la requête d'origine. Cependant, au moins l'un de ces paramètres doit être défini sur une valeur autre que la valeur par défaut. Par exemple, si vous définissez host sur `${host}`, laissez-le vide (`"host": ""`) ou n'incluez pas le paramètre, la valeur de la requête d'origine est utilisée. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 6 : Réécrire une requête.
Insérer un en-tête	Définit le nom et le contenu du champ d'en-tête. Cela écrase tout en-tête existant portant le même nom dans la requête. Le code suivant fournit un exemple. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "InsertHeader", "InsertHeaderConfig": { "key": "key", "value": "value", "valueType": "UserDefined" } }]` type : le type d'action de transfert. Définissez cette valeur sur InsertHeader pour insérer un en-tête de requête. key : le nom du champ d'en-tête. value : le contenu du champ d'en-tête. valueType : le type de la valeur. Pour un cas d'utilisation et un exemple, consultez Cas d'utilisation 3 : Insérer un en-tête de requête.
Supprimer un en-tête	Supprime un en-tête de la requête. Le code suivant fournit un exemple. `alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "key" } }]` type : le type d'action de transfert. Définissez cette valeur sur RemoveHeader pour supprimer un en-tête de requête. key : le nom du champ d'en-tête à supprimer.
Limitation QPS	Cette action limite le taux de requêtes en requêtes par seconde (QPS). Vous pouvez configurer une limite globale et une limite distincte pour chaque IP source cliente. Le code suivant fournit un exemple de configuration : Important L'action de transfert de limitation QPS doit être utilisée conjointement avec le transfert vers un groupe de serveurs. Lorsque l'en-tête de requête `X-Forwarded-For` contient plusieurs adresses IP, telles que `X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …`, l'adresse la plus à gauche est l'IP réelle du client. Pour utiliser la limitation basée sur l'IP source cliente, vous devez activer la récupération de l'adresse IP cliente sur l'écouteur. Cela permet à l'instance ALB d'extraire l'adresse IP cliente de l'en-tête `X-Forwarded-For`. Pour plus d'informations, consultez XForwardedForConfig. `annotations: alb.ingress.kubernetes.io/actions.service-name: \| # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service. [{ "type": "TrafficLimit", "TrafficLimitConfig": { "QPS": "1000", "QPSPerIp": "100" } }]` `type` : spécifie le type d'action de transfert. Définissez cette valeur sur `TrafficLimit` pour configurer la limitation de débit. `QPS` : la limite globale de taux de requêtes en requêtes par seconde (QPS). La valeur doit se situer dans la plage de 1 à 1 000 000. Si le taux de requêtes dépasse la limite spécifiée, les requêtes excédentaires sont rejetées et le client reçoit un code d'état HTTP 503. `QPSPerIp` : la limite de taux de requêtes pour chaque IP source cliente, en QPS. La valeur doit se situer dans la plage de 1 à 1 000 000. Si `QPS` (limite globale) et `QPSPerIp` (limite par IP) sont tous deux définis, la valeur de `QPSPerIp` doit être inférieure à la valeur de `QPS`. Si le taux de requêtes provenant d'une seule adresse IP dépasse la limite spécifiée, les requêtes excédentaires sont rejetées et le client reçoit un code d'état HTTP 503.

Actions de transfert de réponse

Action

Description

Insérer un en-tête

Lorsqu'elle est appliquée à une règle de réponse, cette action définit un champ d'en-tête et sa valeur dans la réponse. Cela écrase tout en-tête de réponse existant portant le même nom. Le code suivant fournit un exemple.

alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]

type : le type d'action de transfert. Définissez cette valeur sur InsertHeader pour insérer un en-tête de réponse.
key : le nom du champ d'en-tête.
value : le contenu du champ d'en-tête.
valueType : le type de la valeur.

Pour des cas d'utilisation et des exemples de modification des en-têtes de réponse, consultez Cas d'utilisation 7 : Modifier les en-têtes de réponse et Cas d'utilisation 8 : Modifier les en-têtes de réponse par code d'état.

Supprimer un en-tête

Lorsqu'elle est appliquée à une règle de réponse, cette action supprime un en-tête de la réponse. Le code suivant fournit un exemple.

alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type : le type d'action de transfert. Définissez cette valeur sur RemoveHeader pour supprimer un en-tête de réponse.

key : le nom du champ d'en-tête à supprimer.

Cas d'utilisation 1 : Définir une réponse fixe

Console

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, sélectionnez Network > Ingresses.

Sur la page Ingresses, cliquez sur Create Ingress. Dans la boîte de dialogue Create Ingress, configurez l'Ingress.

Parameter	Description	Example
Gateway Type	Vous pouvez sélectionner ALB Ingress, MSE Ingress ou Nginx Ingress selon vos besoins. Pour plus d'informations sur les différences entre ces types de passerelles, consultez la rubrique Comparison of Nginx Ingress, ALB Ingress, and MSE Ingress.	ALB Ingress
Name	Un nom personnalisé pour l'Ingress.	ingress
Ingress Class	Le nom de la classe Ingress associée.	alb
Rules	Cliquez sur + Add Rule pour ajouter des règles de routage. Host : un hôte personnalisé. Mappings : configurez les paramètres suivants. Path : route les requêtes en fonction du chemin d'URL. Match type : Prefix match : fait correspondre le préfixe du chemin d'URL de la requête. Exact match : effectue une correspondance exacte avec le chemin d'URL de la requête. ImplementationSpecific (Default Value) : le comportement dépend de l'implémentation du contrôleur Ingress. Pour ALB Ingress, cela correspond par défaut à une correspondance exacte. Service : sélectionnez le service cible, qui est un Service Kubernetes. Port : sélectionnez le port exposé par le service. Un Ingress prend en charge plusieurs chemins sous le même hôte. Cliquez sur + Add pour ajouter un chemin.	Host : laissez vide. Mappings : Path : / Match type : Prefix match Service : response-503 Port : 80
Custom Forwarding Rules	Configurez des règles de transfert personnalisées pour une gestion fine du trafic. Remarque Une règle de transfert peut comporter au maximum 10 conditions. Dans la liste déroulante Add Condition, sélectionnez une option. Host : Fait correspondre l'hôte de la requête. Si vous spécifiez plusieurs hôtes, ils sont évalués selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.host-example` est ajoutée. Path : Fait correspondre le chemin de la requête. Si vous spécifiez plusieurs chemins, ils sont évalués selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.path-example` est ajoutée. HTTP Header : Fait correspondre les informations d'en-tête de la requête sous forme de paire clé-valeur. Par exemple, définissez Key sur `headername` et Value sur `headervalue1`. Si vous spécifiez plusieurs valeurs d'en-tête, elles sont évaluées selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.http-header-example` est ajoutée. Dans la liste déroulante Action, sélectionnez une option. Return Fixed Response Renvoie une réponse fixe au client via l'ALB. Vous pouvez configurer le code d'état de la réponse, le contenu et le type de contenu. Configurez Response Status Code, Response Content Type (Optional) et Response Content (Optional) selon vos besoins. Response Content Type : text/plain : un type de contenu texte brut. text/css : un type de contenu CSS. text/html : un type de contenu HTML. application/javascript : un type de contenu JavaScript. application/json : un type de contenu JSON.	Add Condition : sélectionnez Path. (Conservez la valeur par défaut) Action : Return Fixed Response Response Status Code : 503 Response Content Type (Optional) : text/plain Response Content (Optional) : error

Conservez les valeurs par défaut pour les autres paramètres.

Une fois la configuration terminée, cliquez sur OK.

Kubectl

L'extrait YAML suivant illustre comment renvoyer un code d'état 503 et le texte 503 error text lorsqu'une requête est adressée au service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
      [{
          "type": "FixedResponse",
          "FixedResponseConfig": {
              "contentType": "text/plain",
              "httpCode": "503",
              "content": "503 error text"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service-name  # Note: The name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
                port:
                  name: use-annotation # The service port name must be set to use-annotation.

Cas d'utilisation 2 : Utiliser une redirection 301

Cet exemple YAML montre comment rediriger les requêtes vers le port HTTPS du service.

Redirection

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.redirect: | # Note: The "redirect" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "demo.domain.ingress.top",
              "path": "/test",
              "port": "443",
              "protocol": "https",
              "query": "querystring",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redirect # Note: The name of the backend service must match "redirect" in the custom forwarding action annotation. The forwarding action applies to this backend service.
                port:
                  name: use-annotation # The service port name must be set to use-annotation.

Multiple redirections

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: |
     [{"HTTP": 8001}]
    alb.ingress.kubernetes.io/actions.redirect-1: |
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "demo.domain.ingress.top",
              "path": "/test",
              "port": "443",
              "protocol": "https",
              "query": "querystring",
              "httpCode": "301"
          }
      }]
    alb.ingress.kubernetes.io/actions.redirect-2: |
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "demo.domain.ingress.top",
              "path": "/test",
              "port": "443",
              "protocol": "https",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: ml-test-ingressclass-rolechain-2
  rules:
    - http:
        paths:
          - path: /foo
            pathType: Prefix
            backend:
              service:
                name: redirect-1
                port:
                  name: use-annotation 
          - path: /bar
            pathType: Prefix
            backend:
              service:
                name: redirect-2
                port:
                  name: use-annotation

Cas d'utilisation 3 : Insérer un en-tête de requête

Cet exemple YAML montre comment ajouter ou remplacer l'en-tête de requête par source: alibaba.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.insert-header: | # Note: The "insert-header" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
      [{
          "type": "InsertHeader",
          "InsertHeaderConfig": {
              "key": "source",
              "value": "alibaba",
              "valueType": "UserDefined"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: insert-header # Note: The name of the backend service must match "insert-header" in the custom forwarding action annotation. The forwarding action applies to this backend service.
                port:
                  number: 80

Cas d'utilisation 4 : Répliquer le trafic

L'extrait YAML suivant illustre comment répliquer le trafic vers un groupe de serveurs.

Connectez-vous à la console Application Load Balancer (ALB). Dans le volet de navigation de gauche, choisissez Application Load Balancer > Server Groups. Sur la page Server Groups, récupérez l'ID du groupe de serveurs. 服务器组

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
  # The mirror-svc must be one of the backend.service names specified below.
  # ALB Ingress mirrors traffic that is forwarded to mirror-svc to the backend server specified by "ServerGroupID".
  # To configure traffic mirroring for multiple services, add a separate annotation for each service.
   alb.ingress.kubernetes.io/actions.mirror-svc: | # Note: The "mirror-svc" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
       [{
           "type": "TrafficMirror",
           "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: mirror-svc # Note: The name of the backend service must match "mirror-svc" in the custom forwarding action annotation. The forwarding action applies to this backend service.
            port:
              number: 80

Cas d'utilisation 5 : Transfert vers plusieurs groupes de serveurs

Console

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Network > Ingresses.

Sur la page Ingresses, cliquez sur Create Ingress. Dans la boîte de dialogue Create Ingress, configurez l'Ingress.

Paramètre	Description	Exemple
Type de passerelle	Vous pouvez sélectionner ALB Ingress, MSE Ingress ou Nginx Ingress selon vos besoins. Pour plus d'informations sur les différences entre ces types de passerelles, consultez la rubrique Comparaison de Nginx Ingress, ALB Ingress et MSE Ingress.	ALB Ingress
Nom	Un nom personnalisé pour l'Ingress.	forward-ingress
Classe Ingress	Le nom de la classe Ingress associée.	alb
Règles	Cliquez sur + Add Rule pour ajouter des règles de routage. Host : un hôte personnalisé. Mappings : configurez les paramètres suivants. Path : routage des requêtes en fonction du chemin d'URL. Match type : Prefix match : correspond au préfixe du chemin d'URL de la requête. Exact match : effectue une correspondance exacte avec le chemin d'URL de la requête. ImplementationSpecific (Default Value) : dépend de la logique implémentée par le contrôleur Ingress. ALB Ingress utilise la logique de correspondance exacte. Service : sélectionnez le service cible, qui est un service Kubernetes. Port : sélectionnez le port exposé par le service. Un Ingress prend en charge plusieurs chemins sous le même hôte. Cliquez sur + Add pour ajouter un chemin.	Host : demo.domain.ingress.top Mappings : Path : /path Match type : Prefix match Service : forward Port : 80
Custom Forwarding Rules	Activez les règles de transfert personnalisées pour gérer le trafic entrant avec un contrôle granulaire. Remarque Une règle de transfert peut comporter au maximum 10 conditions. Dans la liste déroulante Add Condition, sélectionnez une option. Host : Correspond à l'hôte de la requête. Si vous spécifiez plusieurs hôtes, ils sont évalués selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.host-example` est ajoutée. Path : Correspond au chemin de la requête. Si vous spécifiez plusieurs chemins, ils sont évalués selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.path-example` est ajoutée. HTTP Header : Correspond aux informations d'en-tête de la requête sous forme de paire clé-valeur. Par exemple, définissez Key sur `headername` et Value sur `headervalue1`. Si vous spécifiez plusieurs valeurs d'en-tête, elles sont évaluées selon une logique `OR`. Une fois ce paramètre défini, l'annotation `alb.ingress.kubernetes.io/conditions.http-header-example` est ajoutée. Dans la liste déroulante Action, sélectionnez une option. Forward To Transfère les requêtes vers plusieurs groupes de serveurs backend. Dans le champ Service Name, sélectionnez le service cible. Dans le champ Port, sélectionnez le numéro de port cible. Configurez ensuite une valeur de pondération personnalisée. Remarque Les services ClusterIP ne sont pas pris en charge pour les clusters utilisant le plug-in réseau Flannel. Lorsque vous sélectionnez Forward To, vous n'avez pas besoin de configurer les mappages de chemin dans la règle.	Add Condition : sélectionnez Host. Host : demo.domain.ingress.top Action : Forward To Service Name : tea-svc Port : 80 Configure weight : 80 Add Service Service Name : coffee-svc Port : 80 Configure weight : 20

Conservez les valeurs par défaut pour les autres paramètres.

Une fois la configuration terminée, cliquez sur OK dans le coin inférieur gauche de la page Create Ingress.

Kubectl

Le fichier YAML suivant montre comment transférer une requête vers plusieurs services au sein du cluster.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
  # The service in the annotation must exist in the cluster, and its name must match the service name under backend in the rule field.
    alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
       [{
           "type": "ForwardGroup",
           "ForwardConfig": {
             "ServerGroups" : [{
               "ServiceName": "tea-svc",
               "Weight": 80,
               "ServicePort": 80
             },
             {
               "ServiceName": "coffee-svc",
               "Weight": 20,
               "ServicePort": 80
             }]
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /path
        pathType: Prefix
        backend:
          service:
            name: service-name # Note: The name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
            port:
              name: use-annotation # The service port name must be set to use-annotation.

Cas d'utilisation 6 : Réécriture d'une requête

Une réécriture modifie l'URL d'une requête avant qu'elle ne soit transférée à un serveur backend. ALB Ingress peut modifier l'hôte, le chemin et la chaîne de requête, ce qui s'avère utile pour simplifier les URL, effectuer des redirections transparentes pour le client et masquer les détails d'implémentation du backend. Dans l'exemple suivant, une réécriture est configurée à l'aide de l'annotation alb.ingress.kubernetes.io/actions.service-name.

Par exemple, si un client accède à https://example.com/api/users, la réécriture modifie l'URL en https://example.org/users tout en conservant la chaîne de requête d'origine.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.service-name: | # The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "example.org", 
               "Path": "/users", 
               "Query": "${query}" # ${query} indicates that the original request query string is used. 
           }
       }]
spec:
  ingressClassName: alb
  rules:
    - host: example.com
      http:
        paths:
          - path: /api/users
            pathType: ImplementationSpecific
            backend:
              service:
                name: service-name # The name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
                port: 
                  number: 80

Cas d'utilisation 7 : Modification des en-têtes de réponse

Important

Par défaut, les règles de transfert ALB Ingress s'appliquent aux requêtes. Pour appliquer une règle à une réponse, vous devez définir l'annotation alb.ingress.kubernetes.io/rule-direction.<service-name> sur Response.
Lorsque vous créez une règle de transfert pour les réponses, vous devez définir backend.service.port.name sur use-annotation.

Le bloc de code suivant définit que lorsque ResponseHeader correspond, c'est-à-dire que l'en-tête contient response-hello avec une valeur de value1 ou value2, un nouvel en-tête de requête source: alibaba est inséré.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-header: Response
   alb.ingress.kubernetes.io/conditions.response-header: | # Note: The "response-header" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding condition applies to that backend service.
     [{
         "type": "ResponseHeader",
         "responseHeaderConfig": {
            "key": "response-hello",
            "values": [
               "value1",
               "value2"
            ]
         }
     }]
   alb.ingress.kubernetes.io/actions.response-header: | # Note: The "response-header" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
     [{
         "type": "InsertHeader",
         "InsertHeaderConfig": {
             "key": "source",
             "value": "alibaba",
             "valueType": "UserDefined"
         }
     }]
  name: response-header
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-header # Note: The name of the backend service must match "response-header" in the custom forwarding condition and action annotations. The configured conditions and actions apply to this backend service.
            port:
              name: use-annotation # The service port name must be set to use-annotation.

Cas d'utilisation 8 : Modification des en-têtes de réponse par code d'état

Important

Par défaut, les règles de transfert ALB Ingress s'appliquent aux requêtes. Pour appliquer une règle à une réponse, vous devez définir l'annotation alb.ingress.kubernetes.io/rule-direction.<service-name> sur Response.
Lorsque vous créez une règle de transfert pour les réponses, vous devez définir backend.service.port.name sur use-annotation.

Cet exemple YAML supprime l'en-tête response-hello de la réponse si le code d'état de la réponse est 200 ou 300.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-hello: Response
   alb.ingress.kubernetes.io/conditions.response-hello: | # Note: The "response-hello" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding condition applies to that backend service.
     [{
       "type": "ResponseStatusCode",
       "responseStatusCodeConfig": {
         "values": [
             "200",
             "300"
         ]
       }
     }]
   alb.ingress.kubernetes.io/actions.response-hello: | # Note: The "response-hello" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "response-hello"
         }
     }]
  name: response-hello
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-hello # Note: The name of the backend service must match "response-hello" in the custom forwarding condition and action annotations. The configured conditions and actions apply to this backend service.
            port:
              name: use-annotation # The service port name must be set to use-annotation.

Conditions et actions de transfert

Cas d'utilisation 1 : Transfert du trafic en fonction d'un nom de domaine

Cette section explique comment configurer les conditions et les actions de transfert basées sur un nom de domaine dans la console ACK afin d'acheminer le trafic vers un service spécifique.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, sélectionnez Network > Ingresses.

Sur la page Ingresses, cliquez sur Create Ingress. Dans la boîte de dialogue Create Ingress, configurez l'Ingress.

Paramètre	Description	Exemple
Gateway type	Vous pouvez sélectionner ALB Ingress, MSE Ingress ou Nginx Ingress selon vos besoins. Pour plus d'informations sur les différences entre ces types de passerelles, consultez la rubrique Comparaison des Nginx Ingress, ALB Ingress et MSE Ingress.	ALB Ingress
Name	Un nom personnalisé pour l'Ingress.	alb_ingress
Ingress Class	Le nom de la classe Ingress associée.	alb
Rules	Cliquez sur + Add Rule pour ajouter une ou plusieurs règles de routage. Domain name : Un nom de domaine personnalisé. Mappings : Configurez les paramètres suivants. Path : Chemin URL pour la correspondance des requêtes. Rule : Prefix (prefix match) : Fait correspondre le préfixe du chemin URL de la requête. Exact (exact match) : Fait correspondre exactement le chemin URL de la requête. ImplementationSpecific (Default) : Le comportement dépend de l'implémentation du contrôleur Ingress. Pour ALB Ingress, cette option fonctionne comme une correspondance exacte. Service name : Sélectionnez le service cible, qui est un Service Kubernetes. Port : Sélectionnez le port exposé par le service. Un Ingress prend en charge plusieurs chemins sous le même nom de domaine. Cliquez sur + Add Path pour ajouter d'autres chemins.	Domain name : .example.com Mappings* : Path : /tes Rule : ImplementationSpecific Service name : tea-svc Port : 80
Custom forwarding rules	Définissez des règles de transfert personnalisées pour un contrôle granulaire du trafic entrant. Remarque Une règle de transfert peut comporter au maximum 10 conditions. Dans la liste déroulante Condition, sélectionnez une option. Domain name : Fait correspondre le nom de domaine de la requête. Si vous spécifiez plusieurs noms de domaine, ils sont évalués selon une logique OU. Lorsque cette condition est définie, l'annotation `alb.ingress.kubernetes.io/conditions.host-example` est ajoutée. Path : Fait correspondre le chemin de la requête. Si vous spécifiez plusieurs chemins, ils sont évalués selon une logique OU. Lorsque cette condition est définie, l'annotation `alb.ingress.kubernetes.io/conditions.path-example` est ajoutée. Important Lorsque vous configurez une condition de transfert basée sur le chemin, la console ajoute automatiquement une règle de transfert avec le chemin `/created-by-<ALB-ID>` à l'Ingress. HTTP header : Fait correspondre une paire clé-valeur spécifiée dans l'en-tête de la requête. Par exemple, définissez Key sur `headername` et Value sur `headervalue1`. Si vous spécifiez plusieurs valeurs d'en-tête, elles sont évaluées selon une logique OU. Lorsque cette condition est définie, l'annotation `alb.ingress.kubernetes.io/conditions.http-header-example` est ajoutée. Dans la liste déroulante Action, sélectionnez une option. Forward to Transmet les requêtes à plusieurs groupes de serveurs backend. Dans le champ Service name, sélectionnez le service cible. Dans le champ Port, sélectionnez le port cible. Configurez ensuite un poids. Remarque Les services ClusterIP ne sont pas pris en charge dans les clusters utilisant le plug-in réseau Flannel. Lorsque vous sélectionnez Forward to, vous n'avez pas besoin de configurer Créer et utiliser un ALB Ingress pour exposer des services dans la règle.	Condition : Sélectionnez Domain Name, Path et HTTP Header. Domain name : example.com. Cliquez sur Add domain name pour ajouter un autre nom de domaine, tel que test.com. Action : Sélectionnez Forward to. Service name : tea-svc Port : 80 Weight : 100

Conservez les valeurs par défaut pour les autres paramètres.

La configuration est terminée. Dans le coin inférieur gauche de la page Create Ingress, cliquez sur OK.