Advanced ALB Ingress usage - Container Service for Kubernetes

Acheminer les requêtes en fonction des noms de domaine

Créez un Ingress pour acheminer les requêtes en fonction d'un nom de domaine ou d'un nom de domaine vide.

Nom de domaine

Cet exemple définit le chemin de routage sur /hello. Les requêtes adressées à demo.domain.ingress.top/hello sont transférées vers le service backend.

Déployez le manifeste suivant pour créer un Service, un Deployment et un Ingress qui acheminent les requêtes en fonction du nom de domaine spécifié.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Versions de Kubernetes antérieures à 1,19

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - backend:
              serviceName: demo-service
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Exécutez kubectl get ing pour obtenir l'adresse de l'instance ALB. Exécutez ensuite la commande suivante en remplaçant ADDRESS par l'adresse de l'instance.
```
curl -H "host: demo.domain.ingress.top" ADDRESS/hello
```
Résultat attendu :
```
{"hello":"coffee"}
```

Nom de domaine vide

Avec un nom de domaine vide et un chemin de routage défini sur /hello, les requêtes adressées à ADDRESS/hello sont transférées vers le service backend.

Déployez le manifeste suivant pour créer un Service, un Deployment et un Ingress.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: ""
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Versions de Kubernetes antérieures à 1,19

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: ""
      http:
        paths:
          - backend:
              serviceName: demo-service
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Exécutez kubectl get ing pour obtenir l'adresse de l'instance ALB. Exécutez ensuite la commande suivante en remplaçant ADDRESS par l'adresse de l'instance.
```
curl ADDRESS/hello
```
Résultat attendu :
```
{"hello":"coffee"}
```

Routage basé sur les chemins d'URL

ALB Ingress achemine les requêtes en fonction des chemins d'URL. Spécifiez le mode de correspondance dans le champ pathType. Le champ pathType prend en charge trois modes.

Correspondance exacte (Exact) : correspond exactement au chemin d'URL.
Par défaut (ImplementationSpecific) : le contrôleur ALB Ingress traite ce mode comme une correspondance exacte. Si aucun chemin n'est spécifié, la valeur par défaut est /.
Correspondance par préfixe (Prefix) : correspond au préfixe du chemin d'URL.

Important

Lorsque pathType est défini sur Exact ou Prefix, le chemin doit être un chemin absolu non vide. Sinon, la validation échoue.
En cas de conflit entre les politiques de correspondance d'URL, les requêtes sont acheminées en fonction de la priorité des règles de transfert.

Chemins simples (/, /foo, /foo/)

Mode de correspondance	Chemin de la règle	Chemin de la requête	Correspondance ?
Correspondance par préfixe (Prefix)	/	/ (correspond à tous les chemins)	Oui
	/foo	/foo /foo/	Oui
	/foo/	/foo /foo/	Oui
	/aaa	/ccc	Non. Le préfixe ne correspond pas.
Correspondance exacte (Exact) ou par défaut (ImplementationSpecific)	/foo	/foo	Oui
		/bar	Non
		/foo/	Non
	/foo/	/foo	Non

Chemins hiérarchiques (/aaa/bb, /aaa/bbb, /aaa/bbb/)

Mode de correspondance	Chemin de la règle	Chemin de la requête	Correspondance ?
Correspondance par préfixe (Prefix)	/aaa/bb	/aaa/bbb	Non
	/aaa/bbb	/aaa/bbb	Oui
	/aaa/bbb/	/aaa/bbb	Oui. La barre oblique finale dans le chemin de la règle est ignorée.
	/aaa/bbb	/aaa/bbb/	Oui. La barre oblique finale dans le chemin de la requête est prise en compte.
	/aaa/bbb	/aaa/bbb/ccc	Oui. Le chemin de la règle est un préfixe du chemin de la requête.

Deux chemins de règle

Mode de correspondance	Chemin de la règle	Chemin de la requête	Correspondance ?
Correspondance par préfixe (Prefix)	/ /aaa	/aaa/ccc	Oui. Le chemin de la requête correspond au chemin de règle `/aaa`.
	/aaa /	/aaa/ccc	Oui. Le chemin de la requête correspond au chemin de règle `/aaa`.
	/aaa /	/ccc	Oui. Le chemin de la requête correspond au chemin de règle `/`.
	/aaa /bbb	/ccc	Non. Le préfixe ne correspond pas.

Exemples pour chaque mode de correspondance :

Correspondance par préfixe (Prefix)

Ce mode effectue une correspondance de préfixe sensible à la casse sur les éléments du chemin d'URL, séparés par /.

Le chemin de règle / correspond à tous les chemins commençant par /, tels que /hello.

Déployez le manifeste suivant pour créer la ressource Ingress.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path-prefix
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          backend:
            service:
              name: demo-service
              port:
                number: 80
          pathType: Prefix

Versions de Kubernetes antérieures à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo-path-prefix
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          backend:
            serviceName: demo-service
            servicePort: 80
          pathType: Prefix

Exécutez kubectl get ing pour obtenir l'adresse de l'instance ALB. Exécutez ensuite la commande suivante en remplaçant ADDRESS par l'adresse obtenue.
```
curl ADDRESS/hello
```
Résultat attendu :
```
{"hello":"coffee"}
```

Correspondance exacte ou par défaut

Le chemin de règle /hello correspond uniquement aux requêtes adressées à /hello.

Déployez le manifeste suivant pour créer la ressource Ingress.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            service:
              name: demo-service
              port: 
                number: 80
          pathType: Exact

Versions de Kubernetes antérieures à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            serviceName: demo-service
            servicePort: 80
          pathType: Exact

Exécutez kubectl get ing pour obtenir l'adresse de l'instance ALB. Exécutez ensuite la commande suivante en remplaçant ADDRESS par l'adresse obtenue.
```
curl ADDRESS/hello
```
Résultat attendu :
```
{"hello":"coffee"}
```

Configurer les checks de santé

Utilisez des annotations pour configurer les checks de santé pour ALB Ingress.

Cliquez pour afficher l'exemple YAML complet

Kubernetes 1.19 et versions ultérieures

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # Configure the context path
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # Configure the context path
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Versions de Kubernetes antérieures à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # Configure the context path.
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      # Configure the context path.
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

Exemples d'annotations :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
... ...

Paramètre	Description	Valeur par défaut
`alb.ingress.kubernetes.io/healthcheck-enabled`	Indique si les contrôles d'état (health checks) doivent être activés pour le groupe de serveurs backend. `true` : active les contrôles d'état. `false` : désactive les contrôles d'état.	`false`
`alb.ingress.kubernetes.io/healthcheck-path`	Le chemin utilisé pour les contrôles d'état.	`/`
`alb.ingress.kubernetes.io/healthcheck-protocol`	Le protocole utilisé pour les contrôles d'état. `HTTP` : envoie une requête HEAD ou GET pour vérifier l'état du serveur. `HTTPS` : envoie une requête HEAD ou GET pour vérifier l'état du serveur. `TCP` : envoie un paquet de handshake SYN pour vérifier la disponibilité du port. `GRPC` : envoie une requête POST ou GET pour vérifier l'état du serveur.	`HTTP`
`alb.ingress.kubernetes.io/healthcheck-httpversion`	Version du protocole HTTP. Ne prend effet que si `healthcheck-protocol` est défini sur `HTTP` ou `HTTPS`. `HTTP1,0` `HTTP1,1`	`HTTP1,1`
`alb.ingress.kubernetes.io/healthcheck-method`	La méthode utilisée pour les contrôles d'état. `HEAD` `POST` `GET` Important Si `healthcheck-protocol` est défini sur `GRPC`, vous devez définir ce paramètre sur `POST` ou `GET`.	`HEAD`
`alb.ingress.kubernetes.io/healthcheck-httpcode`	Code(s) d'état indiquant qu'un serveur backend est sain. Spécifiez une ou plusieurs options, séparées par des virgules. `http_2xx` `http_3xx` `http_4xx` `http_5xx`	`http_2xx`
`alb.ingress.kubernetes.io/healthcheck-code`	Code(s) d'état indiquant qu'un serveur backend est sain. Ce paramètre est prioritaire sur `healthcheck-httpcode` si les deux sont spécifiés. Les valeurs valides dépendent de `healthcheck-protocol` : `HTTP ou HTTPS` : Spécifiez une ou plusieurs options, séparées par des virgules. `http_2xx` `http_3xx` `http_4xx` `http_5xx` `GRPC` : la valeur doit être un entier compris entre 0 et 99. Spécifiez jusqu'à 20 plages de valeurs, séparées par des virgules.	`HTTP ou HTTPS` `http_2xx` `GRPC` `0`
`alb.ingress.kubernetes.io/healthcheck-timeout-seconds`	Le délai d'expiration du contrôle d'état en secondes. Valeurs valides : 1 à 300.	`5`
`alb.ingress.kubernetes.io/healthcheck-interval-seconds`	L'intervalle entre les contrôles d'état en secondes. Valeurs valides : 1 à 50.	`2`
`alb.ingress.kubernetes.io/healthy-threshold-count`	Le nombre de contrôles d'état réussis consécutifs requis pour marquer un serveur backend comme sain. Valeurs valides : 2 à 10.	`3`
`alb.ingress.kubernetes.io/unhealthy-threshold-count`	Le nombre de contrôles d'état échoués consécutifs requis pour marquer un serveur backend comme non sain. Valeurs valides : 2 à 10.	`3`
`alb.ingress.kubernetes.io/healthcheck-connect-port`	Le port utilisé pour les contrôles d'état.	`0` Remarque Une valeur de `0` indique que le port du serveur backend est utilisé pour le contrôle d'état.

Rediriger les requêtes HTTP vers HTTPS

Ajoutez l'annotation suivante pour rediriger les requêtes HTTP vers le port HTTPS 443.

Important

Cette fonctionnalité s'applique uniquement aux règles de transfert HTTP sur le port d'écoute 80.
Cette annotation doit être utilisée conjointement avec des annotations pour les actions de transfert personnalisées, telles que RemoveHeader, InsertHeader et Cors.
Avant d'utiliser cette annotation, assurez-vous qu'un écouteur HTTPS est configuré sur le port 443 dans l'AlbConfig. Consultez Configurer un écouteur ALB à l'aide d'un AlbConfig.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service-ssl
                port: 
                  number: 80
            path: /
            pathType: Prefix

Kubernetes antérieur à 1,19

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: demo-service-ssl
              servicePort: 80
            path: /
            pathType: Prefix

Paramètre	Description	Exemple d'annotation
`alb.ingress.kubernetes.io/ssl-redirect: "true"`	Redirige les requêtes HTTP vers le port HTTPS 443.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/ssl-redirect: "true" name: demo-ssl ... ...`

Configurer HTTPS ou gRPC en backend

Ajoutez l'annotation suivante pour utiliser HTTPS ou gRPC comme protocole backend.

Exemples YAML

Kubernetes 1.19 et versions ultérieures

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:  
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grpc-demo-svc
            port:
              number: 9080

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: grpc-demo-svc
              servicePort: 9080
            path: /
            pathType: Prefix

Remarque

Le protocole backend ne peut pas être modifié après la création de l'Ingress. Supprimez et recréez l'Ingress pour le modifier.

Paramètre	Description	Exemple YAML
`alb.ingress.kubernetes.io/backend-protocol`	https : spécifie HTTPS comme protocole backend. grpc : spécifie gRPC comme protocole backend. Lors du transfert de requêtes vers un service gRPC via un Ingress, vous devez configurer un certificat SSL pour le nom de domaine et utiliser le protocole TLS.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/backend-protocol: "grpc" name: demo-alb-ingress ... ...`

Configurer les expressions régulières

Utilisez l'annotation alb.ingress.kubernetes.io/use-regex: "true" pour activer la correspondance par expression régulière pour les règles de chemin dans spec.rules avec pathType: Prefix.

Important

S'applique uniquement aux règles de chemin avec pathType: Prefix. Active la syntaxe regex dans le champ path de spec.rules, indépendamment des conditions de transfert personnalisées.
Cette annotation active la correspondance regex quelle que soit sa valeur (true ou false). Supprimez l'annotation pour la désactiver.
Sans cette annotation, la création de l'Ingress échoue si le chemin contient des caractères spéciaux tels que =^()[]|, etc..
Les valeurs de chemin dans une condition de transfert personnalisée (alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME) sont transmises directement à ALB et ne nécessitent pas l'annotation use-regex. Pour activer la correspondance regex, ajoutez le préfixe ~* ou ~ à la valeur du chemin. L'annotation use-regex affecte uniquement le champ path dans spec.rules.

Règles de transfert personnalisées

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME: | ## Replace YOUR-SVC-NAME with the actual Service name. It must match backend.service.name below.
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*/pathvalue1", ## Add the ~* or ~ prefix to a regular expression. The text after the prefix is the regular expression itself. ~* indicates a case-sensitive match, and ~ indicates a case-insensitive match.
              "/pathvalue2"    ## An exact match does not require a prefix.
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test-path-for-alb
        pathType: Prefix
        backend:
          service:
            name: YOUR-SVC-NAME ## YOUR-SVC-NAME here must match the Service name specified in the custom forwarding condition annotation to define the association.
            port:
              number: 88

Spec.rules

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true"  ## Allows the path in spec.rules to use a regular expression.
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test-[a-z]-alb[()^]*
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 88

Paramètre

Description

alb.ingress.kubernetes.io/use-regex: "true"

Active les expressions régulières pour les règles de chemin dans spec.rules avec pathType: Prefix.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true"
  name: demo-alb-ingress
... ...

alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME

Configure une condition de transfert personnalisée. Consultez Personnaliser les règles de transfert pour un Ingress ALB.

Remplacez YOUR-SVC-NAME par le nom réel du service. Ce nom doit correspondre à backend.service.name ci-dessous.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME: | ## Remplacez YOUR-SVC-NAME par le nom réel du service. Il doit correspondre à backend.service.name ci-dessous.
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*/pathvalue1", ## Ajoutez le préfixe ~* ou ~ à une expression régulière. Le texte après le préfixe est l'expression régulière elle-même. ~* indique une correspondance sensible à la casse, et ~ une correspondance insensible à la casse.
              "/pathvalue2"    ## Une correspondance exacte ne nécessite pas de préfixe.
           ]
       }
      }]
  name: ingress-example
... ...

Le tableau suivant décrit les règles de correspondance par expression régulière.

Objet	Préfixe	Exemple de règle	Chemin client	Correspondance ?	Description
Nom de domaine	Commence par `~`	`~test.example.com`	test.EXAMPLE.com	Oui	Les noms de domaine prennent en charge la correspondance par expression régulière insensible à la casse.
Chemin	Commence par `~`	`~/api`	/API	Oui	Les chemins prennent en charge la correspondance par expression régulière insensible à la casse.
Chemin	Commence par `~*`	`~*/api`	/Api	Non	Les chemins prennent en charge la correspondance par expression régulière sensible à la casse.

Correspondance de préfixe par expression régulière

Par défaut, la correspondance par expression régulière fonctionne sur le mode « contient ». Pour ne faire correspondre que les chemins commençant par un contenu spécifique, ajoutez ^ au début de l'expression. Par exemple, ^/api ne correspond qu'aux chemins commençant par /api.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true"  ## Enable regex matching.
    alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME: |     ## Replace YOUR-SVC-NAME with the actual service name. This must match backend.service.name below.
      [
        {
          "type": "Path",
          "pathConfig": {
            "values": [
              "~*^/pathvalue1",  # A path that starts with ~* or ~ indicates a regex match. The caret (^) indicates "starts with /pathvalue1".
              "/pathvalue2"     # For a standard prefix or exact match, do not add ~* or ~.
            ]
          }
        }
      ]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /test-path-for-alb
            pathType: Prefix
            backend:
              service:
                name: YOUR-SVC-NAME   # Replace with the actual service name, which must match the annotation.
                port:
                  number: 88

Configurer les réécritures

L'Ingress ALB réécrit les chemins de requête avant de les transférer vers le Service backend. Utilisez les deux annotations suivantes :

alb.ingress.kubernetes.io/rewrite-target: /path/${number} : spécifie le chemin vers lequel les requêtes sont réécrites.
Important
- Utilisez les variables ${number} pour référencer les groupes de capture issus de l'expression régulière définie dans le chemin de l'Ingress. Vous pouvez référencer jusqu'à trois groupes de capture à l'aide de ${1}, ${2} et ${3}.
- Le paramètre pathType de l'Ingress doit être défini sur Prefix.
alb.ingress.kubernetes.io/use-regex: true : active l'utilisation d'une expression régulière dans le chemin. Cette option est activée par défaut lorsque vous configurez rewrite-target.
Important
- Cette annotation active la correspondance par expression régulière quelle que soit sa valeur (true ou false). Supprimez l'annotation pour la désactiver.
- Sans cette annotation, la création de l'Ingress échoue si le chemin contient des caractères spéciaux tels que "%#;!()[]^,"\"".

Exemples de configuration

Exemple 1 : Supprimer un préfixe

Dans l'exemple YAML suivant, le chemin path: /something(/|$)(.*) utilise une expression régulière pour diviser le chemin de la requête client en trois parties :

/something : correspond au préfixe à supprimer.
(/|$) : premier groupe de capture, qui correspond soit à un / après /something, soit à la fin du chemin ($).
(.*) : deuxième groupe de capture, qui correspond à tous les caractères situés après /something/ et est référencé comme ${2} dans le chemin réécrit.

L'annotation alb.ingress.kubernetes.io/rewrite-target définit le chemin réécrit comme / suivi de ${2}. Le tableau suivant présente les résultats de la réécriture.

Chemin client d'origine	Correspondance regex du chemin	Chemin réécrit
`/something`	Correspondance. Le deuxième groupe de capture est vide.	`/`
`/something/`	Correspondance. Le deuxième groupe de capture est vide.	`/`
`/something/new`	Correspondance. Le deuxième groupe de capture est `new`.	`/new`
`/something-new/item`	Aucune correspondance. Dans cet exemple, comme la requête ne correspond à aucune règle de routage, l'Ingress ALB renvoie un code d'état 503.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # Allows the path field to use a regular expression.
    alb.ingress.kubernetes.io/rewrite-target: /${2} # This annotation supports regular expression replacement.
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Exemple 2 : Capturer et réorganiser plusieurs parties

L'exemple suivant capture et réorganise plusieurs parties du chemin /items/(.*)/(.*)/(.*). Il convertit également les segments de chemin en paramètres de requête, sans nécessiter de modification côté client. Le chemin réécrit est construit sous la forme /, suivi du deuxième groupe de capture ${2}, de la chaîne ?code= et du troisième groupe de capture ${3}. Le tableau suivant présente les résultats de la réécriture.

Cet exemple nécessite que le client utilise un format de chemin fixe comportant quatre segments.

Chemin client d'origine	Correspondance regex du chemin	Chemin réécrit
`/items/electronics/computers/554`	Correspondance. Le deuxième groupe de capture est `computers` et le troisième est `554`.	`/computers?code=554`
`/items/produce/fruits/12`	Correspondance. Le deuxième groupe de capture est `fruits` et le troisième est `12`.	`/fruits?code=12`
`/items/headphones/5`	Aucune correspondance. Dans cet exemple, comme la requête ne correspond à aucune règle de routage, l'Ingress ALB renvoie un code d'état 503.
`/drinks/41`	Aucune correspondance. Dans cet exemple, comme la requête ne correspond à aucune règle de routage, l'Ingress ALB renvoie un code d'état 503.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # Allows the path field to use a regular expression.
    alb.ingress.kubernetes.io/rewrite-target: /${2}?code=${3} # This annotation supports regular expression replacement.
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /items/(.*)/(.*)/(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Exemple 3 : Réécrire plusieurs chemins vers un seul chemin

L'exemple suivant utilise une expression régulière pour faire correspondre plusieurs chemins (/app-a(/|$)(.*) et /app-b(/|$)(.*)) et les réécrit vers un seul chemin. Le chemin réécrit est /app-c/ suivi de ${2}. Le tableau suivant présente les résultats de la réécriture.

Chemin client d'origine	Correspondance regex du chemin	Chemin réécrit
`/app-a/item1`	Correspondance. Le deuxième groupe de capture est `item1`.	`/app-c/item1`
`/app-a/item2`	Correspondance. Le deuxième groupe de capture est `item2`.	`/app-c/item2`
`/app-a` ou `/app-a/`	Correspondance. Le deuxième groupe de capture est vide.	`/app-c/`
`/drinks/41`	Aucune correspondance. Dans cet exemple, comme la requête ne correspond à aucune règle de routage, l'Ingress ALB renvoie un code d'état 503.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # allows the path field to use a regular expression.
    alb.ingress.kubernetes.io/rewrite-target: /app-c/${2} # This annotation supports regular expression replacement.
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /app-a(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080
      - path: /app-b(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Exemple 4 : Réécrire le nom de domaine

L'annotation alb.ingress.kubernetes.io/rewrite-target prend uniquement en charge la modification du chemin. Pour modifier d'autres parties de l'URL, telles que le nom de domaine ou les paramètres de requête, utilisez une règle de transfert personnalisée.

Tester les règles de réécriture

Utilisez la commande sed pour vérifier si un chemin client correspond à l'expression régulière du chemin et pour prévisualiser le chemin réécrit.

Cet exemple utilise le chemin de capture /items/(.*)/(.*)/(.*) et la règle de réécriture /${2}?code=${3} de l'Exemple 2 : Capturer et réorganiser plusieurs parties.

Enregistrez les exemples de chemins suivants dans un fichier nommé path2.txt :

/items/electronics/computers/554
/items/produce/fruits/12
/items/headphones/5
/drinks/41

Vérifiez si les chemins correspondent et affichez les chemins réécrits :

La commande suivante adapte l'expression régulière du chemin de l'exemple ( /items/(.*)/(.*)/(.*) ) et le chemin réécrit ( /${2}?code=${3} ) pour sed. Lors de l'utilisation de sed, les caractères spéciaux tels que / doivent être échappés avec une barre oblique inverse ( \ ), et les références aux groupes de capture s'écrivent \2 au lieu de ${2} .
```
sed -E 's#\/items\/(.*)\/(.*)\/(.*)#Matched: []  ---  Rewritten: [/\2?code=\3]#' path2.txt
```
Le résultat attendu est le suivant. Les deux premiers chemins correspondent à la règle et sont réécrits, tandis que les deux derniers ne correspondent pas et restent inchangés.
```
Matched: [/items/electronics/computers/554]  ---  Rewritten: [/computers?code=554]
Matched: [/items/produce/fruits/12]  ---  Rewritten: [/fruits?code=12]
/items/headphones/5
/drinks/41
```

Configurer des ports d'écoute personnalisés

Ajoutez une annotation pour exposer un service à la fois sur le port 80 (HTTP) et le port 443 (HTTPS).

Exemple YAML complet

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
  name: cafe-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Important

ALB ne permet pas de créer directement des écouteurs dans un Ingress. Créez d'abord les ports et protocoles d'écoute requis dans un AlbConfig, puis référencez-les dans l'Ingress. Consultez la rubrique Utiliser un AlbConfig pour configurer un écouteur ALB.

Paramètre	Description	Exemple YAML
`alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'`	Expose le service sur les ports 80 et 443.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' ... ...`

Configurer la priorité des règles de transfert

Par défaut, ALB hiérarchise les règles de transfert selon les critères suivants :

Le système trie les ressources Ingress par ordre lexicographique en fonction de namespace/name. Un Ingress dont la valeur lexicographique est plus faible possède une priorité plus élevée.

Les namespaces sont comparés en premier, puis les noms caractère par caractère.
Au sein d'un même Ingress, les règles sont hiérarchisées selon leur ordre dans le champ rules. Les règles listées en premier ont une priorité plus élevée.
```
rules:
  - host: www.example.com
    http: ...
  - host: www.test.com
    http: ...
```

Pour spécifier la priorité d'une règle de transfert ALB sans modifier le namespace/name de l'Ingress, ajoutez l'annotation Ingress suivante :

Cliquez pour afficher l'exemple YAML complet

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/order: "2"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2" 
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Paramètre

Description

Valeur

Exemple YAML

alb.ingress.kubernetes.io/order

Spécifie la priorité de la règle de transfert ALB. Une valeur plus faible indique une priorité plus élevée.

La priorité de chaque règle doit être unique au sein du même écouteur.

[1, 1000]

Par défaut : 10

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/order: "2"
spec:
... ...

Implémenter des versions canari à l'aide d'annotations

ALB prend en charge les versions canari basées sur les en-têtes, les cookies et les pondérations. Consultez la rubrique Implémenter des versions canari à l'aide d'un Ingress ALB pour connaître les bonnes pratiques.

Paramètre	Description	Description
`alb.ingress.kubernetes.io/canary: "true"`	Active la fonctionnalité de version canari.	Le trafic canari peut être distribué en fonction des en-têtes, des cookies ou des pondérations. ALB applique ces règles selon l'ordre de priorité suivant (du plus élevé au plus faible) : en-tête > cookie > pondération. Ne supprimez pas l'Ingress d'origine pendant une version canari. Après avoir vérifié que la version canari est stable, mettez à jour l'Ingress d'origine pour utiliser le nouveau Service, puis supprimez l'Ingress canari.

Distribuer le trafic canari en fonction d'un en-tête spécifié

Paramètre

Description

Exemple YAML

alb.ingress.kubernetes.io/canary-by-header

Ces annotations définissent un en-tête de requête personnalisé et sa valeur pour le routage du trafic. Les deux annotations sont obligatoires.

Lorsque l'en-tête et la valeur d'en-tête d'une requête correspondent aux valeurs configurées, le trafic de la requête est dirigé vers le point d'entrée du service canari.
Les requêtes non correspondantes sont évaluées selon des règles de priorité inférieure.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
spec:
... ...

alb.ingress.kubernetes.io/canary-by-header-value

Si une requête contient l'en-tête location: hz, ALB achemine le trafic vers le Service canari. Les autres requêtes sont évaluées selon des règles de priorité inférieure, telles que celles basées sur un cookie ou une pondération.

Exemple YAML complet

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Distribuer le trafic canari en fonction d'un cookie spécifié

Paramètre

Valeur du cookie

Exemple YAML

alb.ingress.kubernetes.io/canary-by-cookie

always : Achemine toutes les requêtes vers le Service canari.
never : N'achemine jamais les requêtes vers le Service canari.

Les versions canari basées sur les cookies ne prennent pas en charge les valeurs personnalisées, uniquement always et never.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  ... ...

Si une requête contient l'en-tête Cookie: demo=always, ALB achemine le trafic vers le Service canari. Si l'en-tête contient Cookie: demo=never, ALB n'achemine pas le trafic vers le Service canari.

Exemple YAML complet

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Distribuer le trafic par pondération

Paramètre

Description

Exemple YAML

alb.ingress.kubernetes.io/canary-weight

Pourcentage du trafic acheminé vers le Service canari. Valeurs valides : 0 à 100.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight

Exemple YAML complet

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              serviceName: demo-service-hello
              servicePort: 80
            path: /hello
            pathType: ImplementationSpecific

Configurer la persistance de session avec des annotations

Utilisez les annotations suivantes pour configurer la persistance de session pour un Ingress ALB.

Exemple YAML

Kubernetes 1.19 ou version ultérieure

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"   # To use a custom cookie, set this annotation to Server.
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: tea-svc
            port:
              number: 80
        path: /tea2
        pathType: ImplementationSpecific
      - backend:
          service:
            name: coffee-svc
            port:
              number: 80
        path: /coffee2
        pathType: ImplementationSpecific

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"  # To use a custom cookie, set this annotation to Server.
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # Configure a context path.
      - path: /tea2
        pathType: ImplementationSpecific
        backend:
          serviceName: tea-svc
          servicePort: 80
      # Configure a context path.
      - path: /coffee2
        pathType: ImplementationSpecific
        backend:
          serviceName: coffee-svc
          servicePort: 80

Exemple d'annotations :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Server"   # To use a custom cookie, set this annotation to Server.
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
... ...

Paramètre	Description	Valeur par défaut
`alb.ingress.kubernetes.io/sticky-session`	Indique s'il faut activer la persistance de session. `true` : Active la persistance de session. `false` : Désactive la persistance de session.	`false`
`alb.ingress.kubernetes.io/sticky-session-type`	Spécifie la manière dont l'équilibreur de charge gère le cookie. `Insert` : L'équilibreur de charge insère un cookie `SERVERID` dans la première réponse. Les requêtes suivantes contenant ce cookie sont acheminées vers le même serveur backend. `Server` : L'équilibreur de charge réécrit le cookie d'origine avec un cookie personnalisé. Les requêtes suivantes contenant le nouveau cookie sont acheminées vers le même serveur backend. Remarque S'applique uniquement lorsque `alb.ingress.kubernetes.io/sticky-session` est défini sur `"true"`. Consultez la rubrique Créer un groupe de serveurs pour connaître les paramètres du groupe de serveurs.	`Insert`
`alb.ingress.kubernetes.io/cookie-timeout`	Le délai d'expiration du cookie en secondes. Valeurs valides : 1 à 86400. S'applique uniquement lorsque `alb.ingress.kubernetes.io/sticky-session-type` est défini sur `Insert`.	1000
`alb.ingress.kubernetes.io/cookie`	La valeur du cookie personnalisé. Obligatoire (non vide) lorsque `alb.ingress.kubernetes.io/sticky-session-type` est défini sur `Server`.	""

Spécifier l'algorithme d'équilibrage de charge

Utilisez une annotation pour spécifier l'algorithme d'équilibrage de charge pour un groupe de serveurs backend.

Exemple YAML

Kubernetes 1.19 et versions ultérieures

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # Set this to wrr, sch, or wlc as needed.
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only when the load balancing algorithm is uch. It is not needed for wrr, sch, or wlc.
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Kubernetes antérieur à 1,19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # Set this to wrr, sch, or wlc as needed.
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only when the load balancing algorithm is uch. It is not needed for wrr, sch, or wlc.
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
    - host: demo.alb.ingress.top
      http:
        paths:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

Paramètre	Valeur	Description
`alb.ingress.kubernetes.io/backend-scheduler`	`wrr`	Round robin pondéré. Les serveurs ayant des pondérations plus élevées reçoivent plus de requêtes. (Par défaut)	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: alb.ingress.kubernetes.io/backend-scheduler: "uch" # Set this to wrr, sch, or wlc as needed. alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only when the load balancing algorithm is uch. It is not needed for wrr, sch, or wlc. spec: ... ...`
	`wlc`	Distribue les requêtes en fonction de la pondération et du nombre actuel de connexions. Si les pondérations sont égales, le serveur ayant le moins de connexions est sélectionné.
	`sch`	Achemine les requêtes provenant de la même adresse IP source vers le même serveur backend.
	`uch`	Achemine les requêtes en fonction d'un hachage d'un paramètre d'URL spécifié. Utilisez l'annotation `alb.ingress.kubernetes.io/backend-scheduler-uch-value` pour spécifier le paramètre d'URL à utiliser pour le hachage.

Configuration CORS

Utilisez les annotations suivantes pour configurer le partage de ressources cross-origin (CORS) pour l'Ingress ALB.

Cliquez pour afficher l'exemple YAML complet

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"
    alb.ingress.kubernetes.io/cors-allow-origin: "Allowed origin domain name"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Exemples d'annotations :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"
    alb.ingress.kubernetes.io/cors-allow-origin: "Allowed origin domain name"
spec:
... ...

Paramètre	Description	Valeur par défaut
`alb.ingress.kubernetes.io/enable-cors`	Active le partage de ressources cross-origin (CORS).	Valeur par défaut : `"false"`
`alb.ingress.kubernetes.io/cors-allow-origin`	Spécifie les origines autorisées à accéder aux ressources du serveur. Séparez plusieurs origines par une virgule (,). Chaque valeur doit commencer par `http://` ou `https://`, suivi d'un nom de domaine valide ou d'un nom de domaine générique. Les adresses IP ne sont pas prises en charge.	Valeur par défaut : `*` Exemple : `alb.ingress.kubernetes.io/cors-allow-origin: "https://example.com:4443, http://aliyundoc.com, https://example.org:1199"`
`alb.ingress.kubernetes.io/cors-allow-methods`	Spécifie les méthodes HTTP autorisées pour les requêtes cross-origin. Les valeurs ne sont pas sensibles à la casse. Séparez plusieurs méthodes HTTP par une virgule (,).	Valeur par défaut : `GET, PUT, POST, DELETE, PATCH, OPTIONS` Exemple : `alb.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"`
`alb.ingress.kubernetes.io/cors-allow-headers`	Spécifie les en-têtes de requête autorisés pour les requêtes cross-origin. Définissez ce paramètre sur `*` ou sur une liste de valeurs d'en-tête séparées par des virgules. Chaque valeur ne peut contenir que des lettres majuscules, des lettres minuscules et des chiffres. Une valeur ne peut pas commencer ni se terminer par un trait de soulignement (_) ou un tiret (-). La longueur maximale d'une seule valeur est de 32 caractères.	Valeur par défaut : `DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization` Exemple : `alb.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For, X-app123-XPTO"`
`alb.ingress.kubernetes.io/cors-expose-headers`	Spécifie les en-têtes de réponse à exposer au client. Définissez ce paramètre sur `*` ou sur une liste de valeurs d'en-tête séparées par des virgules. Chaque valeur ne peut contenir que des lettres majuscules, des lettres minuscules et des chiffres. Une valeur ne peut pas commencer ni se terminer par un trait de soulignement (_) ou un tiret (-). La longueur maximale d'une seule valeur est de 32 caractères.	Valeur par défaut : `""` Exemple : `alb.ingress.kubernetes.io/cors-expose-headers: "*,X-CustomResponseHeader"`
`alb.ingress.kubernetes.io/cors-allow-credentials`	Indique s'il faut inclure les informations d'identification dans les requêtes cross-origin.	Valeur par défaut : `true` Exemple : `alb.ingress.kubernetes.io/cors-allow-credentials: "false"`
`alb.ingress.kubernetes.io/cors-max-age`	Durée de mise en cache des réponses préliminaires, en secondes. Valeurs valides : 0 à 172 800.	Valeur par défaut : `172800`

Connexion persistante avec le backend

Les connexions persistantes avec le backend permettent à ALB de réutiliser les connexions TCP vers les serveurs backend, réduisant ainsi la surcharge liée aux connexions dans les scénarios à haut débit.

Exemple YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Paramètre	Description	Exemple YAML
`alb.ingress.kubernetes.io/backend-keepalive: "true"`	Active les connexions persistantes avec le backend pour réduire la surcharge des connexions TCP.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: alb-ingress annotations: alb.ingress.kubernetes.io/backend-keepalive: "true" spec:`

Association de backends IPv6 aux groupes de serveurs

L'association de backends IPv6 permet d'utiliser des Pods IPv4 et IPv6 au sein d'un même groupe de serveurs, mais nécessite un cluster à double pile. Consultez Créer un cluster ACK managé.

Remarque

Les limitations suivantes s'appliquent lorsque l'association de backends IPv6 est activée :

Pour activer l'association de backends IPv6 pour un groupe de serveurs, vous devez activer l'IPv6 pour le VPC du groupe de serveurs.
L'association de backends IPv6 n'est pas prise en charge pour les groupes de serveurs de type IP ou Function Compute lorsqu'ils sont associés via une action de transfert personnalisée.
Si un Ingress est associé à une instance ALB uniquement IPv4, vous ne pouvez pas activer l'association de backends IPv6 pour ses groupes de serveurs.

Exemple YAML

apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  # To configure dual-stack, set ipFamilyPolicy to RequireDualStack or PreferDualStack and specify both IPv4 and IPv6 in ipFamilies.
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv4
  - IPv6
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-ipv6: "true"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Configurez le Service et l'Ingress ALB pour la double pile. Après avoir créé une instance ALB à double pile, vous pouvez associer des serveurs backend IPv4 et IPv6 au groupe de serveurs.

Objet de configuration	Paramètre	Valeur	Description	Exemple YAML
Service	`ipFamilies`	`IPv4` `IPv6`	Spécifie les types d'adresses IP disponibles pour le Service.	`apiVersion: v1 kind: Service metadata: name: tea-svc spec: # To configure dual-stack, set ipFamilyPolicy to RequireDualStack or PreferDualStack and specify both IPv4 and IPv6 in ipFamilies. ipFamilyPolicy: RequireDualStack ipFamilies: - IPv4 - IPv6 ... ...`
Service	`ipFamilyPolicy`	`RequireDualStack` `PreferDualStack`	Définit la stratégie IP du Service, activant ainsi la mise en réseau à double pile.
Ingress ALB	`alb.ingress.kubernetes.io/enable-ipv6`	`"true"`	Active l'association de backends IPv6 pour le groupe de serveurs.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: alb.ingress.kubernetes.io/enable-ipv6: "true" spec: ... ...`

Configurer la limitation du débit (QPS)

Ajoutez l'annotation suivante pour activer la limitation du débit (QPS) pour les règles de transfert.

Afficher l'exemple YAML complet

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Annotation	Description	Exemple YAML
`alb.ingress.kubernetes.io/traffic-limit-qps`	Spécifie la limite QPS pour les règles de transfert. Valeurs valides : 1 à 1 000 000.	`apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: alb.ingress.kubernetes.io/traffic-limit-qps: "50" spec: ... ...`

Démarrage progressif

Le démarrage progressif augmente graduellement le trafic vers les Pods nouvellement ajoutés, évitant ainsi les surcharges dues à des pics de trafic soudains.

Exemple YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/slow-start-enabled: "true"
    alb.ingress.kubernetes.io/slow-start-duration: "100"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Paramètre

Description

Exemple YAML

alb.ingress.kubernetes.io/slow-start-enabled

Indique s'il faut activer le démarrage progressif. Désactivé par défaut.

true : Active la fonctionnalité de démarrage progressif.
false : Désactive la fonctionnalité de démarrage progressif.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/slow-start-enabled: "true"
    alb.ingress.kubernetes.io/slow-start-duration: "100"
  name: alb-ingress
... ...

alb.ingress.kubernetes.io/slow-start-duration

Durée de montée en charge progressive du démarrage, en secondes. Valeurs valides : 30–900. Par défaut : 30.

Drainage de connexion

Lorsqu'un Pod passe à l'état Terminating, l'Ingress ALB le retire du groupe de serveurs mais ne ferme pas immédiatement les connexions existantes, ce qui peut provoquer des erreurs de requête ou empêcher un arrêt gracieux. Le drainage de connexion maintient les connexions existantes ouvertes pendant un délai configurable avant de les fermer. Consultez Utiliser le drainage de connexion avec un Ingress ALB pour arrêter gracieusement un service.

Important

L'Ingress ALB ne garantit pas que les Pods restent en cours d'exécution jusqu'à la fin du drainage de connexion. Pour contrôler la disponibilité des Pods pendant la terminaison, configurez spec.terminationGracePeriodSeconds ou utilisez un hook preStop.

Exemple YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/connection-drain-enabled: "true"
    alb.ingress.kubernetes.io/connection-drain-timeout: "199"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Paramètre

Description

Exemple YAML

alb.ingress.kubernetes.io/connection-drain-enabled

Indique s'il faut activer le drainage de connexion.

true : Active le drainage de connexion.
false : Désactive le drainage de connexion. (Par défaut)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/connection-drain-enabled: "true"
    alb.ingress.kubernetes.io/connection-drain-timeout: "199"
  name: alb-ingress
... ...

alb.ingress.kubernetes.io/connection-drain-timeout

Spécifie le délai d'expiration du drainage de connexion en secondes. Valeurs valides : [0, 900]. Par défaut : 300.

Désactiver l'équilibrage de charge inter-zones

Par défaut, ALB répartit le trafic entre les zones de disponibilité. La désactivation de l'équilibrage de charge inter-zones restreint le trafic aux services backend situés dans la même zone.

Important

Si vous désactivez l'équilibrage de charge inter-zones, assurez-vous que chaque zone de disponibilité dispose de ressources backend suffisantes.

Utilisez l'exemple suivant pour désactiver l'équilibrage de charge inter-zones :

Exemple YAML complet

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/cross-zone-enabled: "false"
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Paramètre

Description

Exemple YAML

alb.ingress.kubernetes.io/cross-zone-enabled

Indique s'il faut activer l'équilibrage de charge inter-zones. Activé par défaut.

true : Active l'équilibrage de charge inter-zones.
false : Désactive l'équilibrage de charge inter-zones.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/cross-zone-enabled: "false"
... ...