ALB Ingress quick start - route traffic by URL path - Container Compute Service

ALB Ingress offre une gestion du trafic de couche 7 basée sur Application Load Balancer (ALB) d'Alibaba Cloud, avec prise en charge des protocoles HTTP, HTTPS et QUIC. Ce tutoriel vous montre comment acheminer le trafic vers différents services backend en fonction du chemin d'URL.

Fonctionnement d'ALB Ingress

Concepts clés :

ALB Ingress Controller : ce composant gère les ressources Ingress. Il récupère dynamiquement les modifications apportées aux ressources Ingress et AlbConfig depuis l'API Server du cluster et met à jour les instances ALB en conséquence. Contrairement au NGINX Ingress Controller, l'ALB Ingress Controller sert de plan de contrôle pour les instances ALB. Il gère les instances ALB mais ne traite pas directement le trafic utilisateur. Les instances ALB se chargent plutôt de transférer le trafic utilisateur. L'ALB Ingress Controller récupère dynamiquement les modifications apportées aux ressources Ingress depuis l'API Server du cluster et met à jour les instances ALB en fonction des règles de transfert définies dans Ingress.
Un AlbConfig est une définition de ressource personnalisée (CRD) au niveau du cluster, créée par l'ALB Ingress Controller. Chaque AlbConfig contient des paramètres qui définissent la configuration d'une seule instance ALB. Une instance ALB sert de point d'entrée pour le trafic et transfère les requêtes vers les services backend. Elle est entièrement gérée par Application Load Balancer (ALB). Contrairement au Nginx Ingress Controller, ALB Ingress ne nécessite aucune opération ni maintenance (O&M) et offre une meilleure élasticité.
IngressClass : une IngressClass définit l'association entre un Ingress et un AlbConfig.
Ingress : dans Kubernetes, Ingress est un objet de ressource qui définit les règles de routage et d'accès du trafic externe. L'ALB Ingress Controller surveille les modifications apportées aux ressources Ingress et met à jour les instances ALB pour assurer le transfert du trafic.
Service : point d'entrée stable pour un groupe de Pods ayant la même fonction. Les autres applications accèdent aux Pods backend via l'adresse IP virtuelle et le port du Service, indépendamment des modifications individuelles des Pods.

La figure suivante illustre la relation entre une instance ALB et ALB Ingress.

Limites

Les noms de ressources AlbConfig, namespace, ingress et service ne doivent pas commencer par aliyun.

Scénario d'exemple

Ce tutoriel déploie quatre Pods Nginx et configure ALB Ingress pour acheminer le trafic par chemin d'URL sous le même domaine.

Requête frontend

Service backend

demo.domain.ingress.top/coffee

Service coffee

demo.domain.ingress.top/tea

Service tea

Prérequis

Vous avez installé l'ALB Ingress Controller.
Vous avez créé deux vSwitches dans des zones de disponibilité différentes au sein du VPC de votre cluster. Create and manage VSwitches.

Instructions

Lisez le contenu en anglais pour comprendre CE qui doit être communiqué
Rédigez le français À PARTIR DE ZÉRO — oubliez la structure de phrase anglaise
Conservez exactement tout le formatage Markdown, les blocs de code, les liens et les images
Balises xref (<a data-tag="xref" ...>texte</a>) — conservez la balise ENTIERE avec tous ses attributs dans l'ordre et la casse d'origine, traduisez UNIQUEMENT le texte visible entre > et
Appliquez strictement toutes les règles spécifiques à la langue
Appliquez les règles de stopwords avec une tolérance zéro
Utilisez le mode impératif dans les étapes numérotées et les listes à puces procédurales
Assurez la cohérence terminologique — un même terme = une même traduction partout
Variez les débuts de phrase dans les listes/tableaux — aucun début répété plus de 3 fois

Renvoyez UNIQUEMENT le document markdown en français, sans explication

Étape 1 : Déployer le service backend

Utilisation de la console

Connectez-vous à la console ACS. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, sélectionnez Workloads > Deployments.
Sur la page Deployments, cliquez sur Create from YAML dans le coin supérieur droit.

Sur la page Create, configurez les paramètres.

Sample Template : sélectionnez Custom.

Template : saisissez la configuration YAML pour déployer deux Deployments (coffee et tea) et deux Services (coffee-svc et tea-svc).

Exemple de YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  type: ClusterIP
---
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: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Cliquez sur Create. Le message Created. s'affiche.
Vérifiez que les Deployments et les Services ont bien été créés.
1. Dans le volet de navigation de gauche, sélectionnez Workloads > Stateless. Les Deployments nommés coffee et tea apparaissent.
2. Dans le volet de navigation de gauche, sélectionnez Network > Services. Les Services nommés coffee-svc et tea-svc apparaissent.

Utilisation de kubectl

Créez un fichier nommé cafe-service.yaml avec le contenu suivant. Cela déploie deux Deployments (coffee et tea) et deux Services (coffee-svc et tea-svc).

Référence du fichier de configuration YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  type: ClusterIP
---
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: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Exécutez la commande suivante pour déployer les ressources.

kubectl apply -f cafe-service.yaml

Sortie attendue :

deployment "coffee" created
service "coffee-svc" created
deployment "tea" created
service "tea-svc" created

Vérifiez les Deployments et les Services.

Vérifiez les Deployments.

kubectl get deployment

Sortie attendue :

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
coffee                           2/2     2            2           2m26s
tea                              2/2     2            2           2m26s

Vérifiez les Services.

kubectl get svc

Sortie attendue :

NAME                          TYPE            CLUSTER-IP       EXTERNAL-IP           PORT(S)           AGE
coffee-svc                    ClusterIP       172.16.XX.XX     <none>                80/TCP            9m38s
tea-svc                       ClusterIP       172.16.XX.XX     <none>                80/TCP            9m38s

Étape 2 : Créer un ALBConfig

Console

Connectez-vous à la console ACS. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, choisissez Workloads > Custom Resources.

Sous l'onglet CRDs, cliquez sur Create from YAML.

Sample Template : sélectionnez Custom.

Template : collez le manifeste YAML.

Exemple de configuration YAML

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressType: Internet
    zoneMappings:                          # To ensure high availability, select vSwitches in at least two different availability zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in availability zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in availability zone 2, which must be different from the preceding one).
  listeners:
    - port: 80
      protocol: HTTP

Le tableau suivant décrit les paramètres.

Paramètre	Obligatoire	Description
`metadata.name`	Oui	Nom de l'ALBConfig. Remarque Le nom de l'ALBConfig doit être unique au sein du cluster pour éviter les conflits de nommage.
`spec.config.name`	Non	Nom de l'instance ALB.
`spec.config.addressType`	Non	Type de réseau de l'instance ALB. Valeurs possibles : Internet (par défaut) : l'instance fournit des services d'équilibrage de charge publics via Internet. Remarque Les instances ALB orientées Internet utilisent une adresse IP élastique (EIP). Vous êtes facturé pour l'instance EIP, la bande passante et le transfert de données. Paiement à l'utilisation. Intranet : l'instance fournit des services d'équilibrage de charge privés au sein d'un VPC.
`spec.config.zoneMappings`	Oui	ID des vSwitches pour l'instance ALB. Pour savoir comment créer un vSwitch, consultez Créer et gérer des vSwitches. Remarque Les vSwitches doivent se trouver dans une zone de disponibilité prise en charge par ALB et dans le même VPC que le cluster. Régions et zones de disponibilité prises en charge par ALB. Si votre région propose plusieurs zones de disponibilité, nous vous recommandons de sélectionner des vSwitches dans au moins deux zones différentes pour garantir une haute disponibilité.
`spec.listeners`	Non	Port et protocole de l'écouteur. Cet exemple utilise HTTP sur le port 80. L'Ingress ALB nécessite un écouteur. Conservez cette valeur par défaut pour éviter toute configuration manuelle.

Cliquez sur Create. Le message Created. s'affiche.
Vérifiez l'instance ALB :
1. Connectez-vous à la console Application Load Balancer (ALB).
2. Dans la barre de navigation supérieure, sélectionnez la région de l'instance.
3. Sur la page Instance, vérifiez que l'instance ALB nommée alb-test apparaît dans la liste des instances.

Kubectl

Copiez le contenu suivant dans un fichier nommé alb-test.yaml pour créer un ALBConfig.

Exemple de configuration YAML

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressType: Internet
    zoneMappings:                          # To ensure high availability, select vSwitches in at least two different availability zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in availability zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in availability zone 2, which must be different from the preceding one).
  listeners:
    - port: 80
      protocol: HTTP

Le tableau suivant décrit les paramètres.

Paramètre	Obligatoire	Description
`metadata.name`	Oui	Nom de l'ALBConfig. Remarque Le nom de l'ALBConfig doit être unique au sein du cluster pour éviter les conflits de nommage.
`spec.config.name`	Non	Nom de l'instance ALB.
`spec.config.addressType`	Non	Type de réseau de l'instance ALB. Valeurs possibles : Internet (par défaut) : l'instance fournit des services d'équilibrage de charge publics via Internet. Remarque Les instances ALB orientées vers Internet utilisent une adresse IP élastique (EIP). Vous êtes facturé pour l'instance EIP, la bande passante et le transfert de données. Paiement à l'utilisation. Intranet : l'instance fournit des services d'équilibrage de charge privés au sein d'un VPC.
`spec.config.zoneMappings`	Oui	Identifiants des vSwitches pour l'instance ALB. Pour savoir comment créer un vSwitch, consultez la rubrique Créer et gérer des vSwitches. Remarque Les vSwitches doivent se trouver dans une zone de disponibilité prise en charge par ALB et dans le même VPC que le cluster. Régions et zones de disponibilité prises en charge par ALB. Si votre région propose plusieurs zones de disponibilité, nous vous recommandons de sélectionner des vSwitches dans au moins deux zones différentes pour garantir une haute disponibilité.
`spec.listeners`	Non	Port et protocole de l'écouteur. Cet exemple utilise HTTP sur le port 80. L'Ingress ALB nécessite un écouteur. Conservez cette valeur par défaut pour éviter toute configuration manuelle.

Exécutez la commande suivante pour créer l'ALBConfig.
```
kubectl apply -f alb-test.yaml
```
Résultat attendu :
```
albconfig.alibabacloud.com/alb-demo created
```
Ce résultat confirme que l'ALBConfig a été créé.

Étape 3 : Créer une IngressClass

Nous vous recommandons de créer une IngressClass pour chaque AlbConfig.

Console

Connectez-vous à la console ACS. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, choisissez Workloads > Custom Resources.

Sous l'onglet CRDs, cliquez sur Create from YAML.

Sample Template : sélectionnez Custom.

Template : saisissez le manifeste YAML.

Exemple de configuration YAML

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb-demo

Le tableau suivant décrit les paramètres.

Parameter	Required	Description
metadata.name	Yes	Nom de l'IngressClass. Remarque Le nom doit être unique au sein du cluster.
spec.parameters.name	Yes	Nom de l'AlbConfig associé.

Cliquez sur Create. Un message de confirmation s'affiche.
Vérifiez que l'IngressClass a bien été créée :
1. Dans le volet de navigation de gauche, choisissez Workloads > Custom Resources.
2. Cliquez sur l'onglet Resource Objects.
3. Dans la zone de recherche API Group, saisissez IngressClass. L'IngressClass créée apparaît.

Kubectl

Créez un fichier nommé alb.yaml avec le contenu suivant.

Exemple de configuration YAML

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb-demo

Le tableau suivant décrit les paramètres.

Parameter	Required	Description
`metadata.name`	Yes	Nom de l'IngressClass. Remarque Le nom doit être unique au sein du cluster.
`spec.parameters.name`	Yes	Nom de l'AlbConfig associé.

Exécutez la commande suivante pour créer l'IngressClass.
```
kubectl apply -f alb.yaml
```
Résultat attendu :
```
ingressclass.networking.k8s.io/alb created
```

Étape 4 : Créer un Ingress

Console

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

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

Paramètre	Description	Valeur d'exemple
Gateway Type	Sélectionnez le type de passerelle. Les options incluent ALB et MSE.	ALB Ingress
Name	Un nom personnalisé pour l'Ingress.	cafe-ingress
IngressClass	Une classe personnalisée pour l'Ingress.	alb
Rules	Cliquez sur +Add Rule pour ajouter plusieurs règles de routage. Domain Name : Un nom de domaine personnalisé. Mappings : Configurez les paramètres suivants. Path : Le chemin d'URL pour accéder au service. Dans cet exemple, ce paramètre est laissé vide pour utiliser le chemin racine /. Rule : Prend en charge Prefix (Prefix-based Match), Exact (Exact Match) et ImplementationSpecific (Default Value). Service : Le backend cible, qui est un service Kubernetes. Port : Le port exposé par le service. Un Ingress prend en charge plusieurs chemins sous le même nom de domaine. Cliquez sur +Add pour ajouter un nouveau chemin.	Domain Name : demo.domain.ingress.top Path mapping : Path : /tea Rule : ImplementationSpecific Service : tea-svc Port : 80 Mappings : Path : /coffee Rule : ImplementationSpecific Service : coffee-svc Port : 80
TLS Settings	Activez cette option pour sécuriser l'Ingress avec un certificat TLS (HTTPS). Domain Name : Saisissez un nom de domaine personnalisé. Secret : Sélectionnez le Secret contenant le certificat TLS. Pour créer un Secret, procédez comme suit : À droite de Secret, cliquez sur Create. Dans la boîte de dialogue Create Secret, définissez les champs Name, Cert et Key, puis cliquez sur OK. Dans la liste déroulante Secret, sélectionnez le Secret que vous avez créé. Cliquez sur Add pour configurer plusieurs paramètres TLS. Pour plus d'informations, consultez Configurer un certificat HTTPS pour une communication chiffrée.	Laissez l'option TLS Settings désactivée. Cette configuration n'est pas requise pour cet exemple.
More	Canary Release : Activez l'option de déploiement canari. Vous pouvez définir des règles canari basées sur les en-têtes de requête, les cookies ou les pondérations. Remarque Vous pouvez définir des règles basées sur l'en-tête de requête, le cookie ou la pondération. Si vous configurez plusieurs types de règles, ils sont mis en correspondance dans l'ordre de priorité suivant : en-tête de requête, cookie, puis pondération. Based on Request Header : Répartit le trafic en fonction de l'en-tête de requête. Si vous configurez ce paramètre, les annotations `alb.ingress.kubernetes.io/canary-by-header` et `alb.ingress.kubernetes.io/canary-by-header-value` sont ajoutées. Based on Cookie : Répartit le trafic en fonction d'un cookie. Si vous configurez ce paramètre, l'annotation `alb.ingress.kubernetes.io/canary-by-cookie` est ajoutée. Based on Weight : Définit le pourcentage de requêtes à acheminer vers un service spécifique. La valeur doit être un entier compris entre 0 et 100. Si vous configurez ce paramètre, l'annotation `alb.ingress.kubernetes.io/canary-weight` est ajoutée. Protocol : Prend en charge les services backend utilisant les protocoles HTTPS et gRPC. La configuration de ce paramètre ajoute l'annotation `alb.ingress.kubernetes.io/backend-protocol`. Rewrite Path : Réécrit le chemin de la requête avant de la transférer au service backend. Ce paramètre ajoute l'annotation alb.ingress.kubernetes.io/rewrite-target.	Laissez le déploiement canari désactivé et conservez les paramètres par défaut pour le protocole et la réécriture de chemin. Ces configurations ne sont pas requises pour cet exemple.
Custom Forwarding Rules	Activez les règles de transfert personnalisées pour gérer le trafic entrant avec un contrôle granulaire. Remarque Vous pouvez ajouter un maximum de 10 entrées de condition à une règle de transfert. Dans la liste déroulante Add Condition, sélectionnez une option : Domain Name : Met en correspondance le domaine de la requête. Si vous spécifiez plusieurs domaines, une requête est mise en correspondance si elle utilise l'un des domaines spécifiés. Lorsque vous configurez cette condition, l'annotation `alb.ingress.kubernetes.io/conditions.host-example` est ajoutée. Path : Met en correspondance le chemin de la requête. Si vous spécifiez plusieurs chemins, une requête est mise en correspondance si elle utilise l'un des chemins spécifiés. Lorsque vous configurez cette condition, l'annotation `alb.ingress.kubernetes.io/conditions.path-example` est ajoutée. HTTP Header : Met en correspondance l'en-tête de la requête sous forme de paire clé-valeur. Par exemple, Key est `headername` et Value est `headervalue1`. Si plusieurs valeurs d'en-tête sont configurées, la relation entre elles est OU. Lorsque vous configurez cette condition, 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 un ou plusieurs services backend en fonction de la pondération. Dans le champ Service, sélectionnez le service cible. Dans le champ Port, sélectionnez le numéro de port cible. Ensuite, spécifiez une pondération. Remarque Si vous sélectionnez cette action, vous n'avez pas besoin de configurer le mappage de chemin dans la règle. Return Fixed Response Configure ALB pour renvoyer une réponse fixe au client. Vous pouvez définir le code d'état de la réponse, le contenu du corps et le type de contenu. Selon vos besoins, configurez les champs Response Status Code, Response Content Type (Optional) et Response Content (Optional). Type de corps de réponse : text/plain : texte brut. text/css : contenu CSS. text/html : contenu HTML. application/javascript : contenu JavaScript. application/json : contenu JSON. Les règles de transfert personnalisées prennent en charge des conditions basées sur le domaine, le chemin ou l'en-tête HTTP, ainsi que des actions telles que le transfert vers un service ou le renvoi d'une réponse fixe. Personnaliser les règles de transfert pour un Ingress ALB.	Laissez les règles de transfert personnalisées désactivées. Cette configuration n'est pas requise pour cet exemple.
Annotations	Vous pouvez spécifier un nom et une valeur d'annotation personnalisés, ou sélectionner ou rechercher une annotation à configurer. Pour plus d'informations sur les annotations Ingress, consultez Annotations.	Non requis pour cet exemple.
Labels	Spécifie les libellés à ajouter à l'Ingress. Les libellés sont des paires clé-valeur attachées aux objets pour spécifier des attributs d'identification.	Non requis pour cet exemple.

Dans le coin inférieur gauche de la page Create Ingress, cliquez sur OK.
Vérifiez l'Ingress :
1. Dans le volet de navigation de gauche, choisissez Network > Routes. L'Ingress cafe-ingress apparaît.
2. La colonne Endpoint pour cafe-ingress affiche l'adresse de l'endpoint.

kubectl

Créez un fichier nommé cafe-ingress.yaml et ajoutez le contenu suivant :

Référence du fichier de configuration YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress 
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     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

Le tableau suivant décrit les paramètres.

Paramètre	Obligatoire	Description
`metadata.name`	Oui	Le nom de l'Ingress. Remarque Le nom doit être unique au sein du cluster pour éviter les conflits.
`spec.ingressClassName`	Oui	Le nom de la classe Ingress associée.
`spec.rules.host`	Non	Le nom de domaine dans l'en-tête HTTP `Host`. Définissez-le sur votre propre nom de domaine. Kubernetes met en correspondance les en-têtes Host entrants avec les règles Ingress et achemine les requêtes correspondantes vers le service backend spécifié. Remarque Les noms de domaine personnalisés nécessitent un dépôt ICP valide pour l'accès depuis la Chine continentale. Processus de dépôt ICP. Si vous ne définissez pas ce paramètre, la règle Ingress met en correspondance toutes les requêtes atteignant le contrôleur Ingress.
`spec.rules.http.paths.path`	Oui	L'URL du chemin de transfert.
`spec.rules.http.paths.pathType`	Oui	La règle de correspondance d'URL. Acheminer les requêtes en fonction des chemins d'URL.
`spec.rules.http.paths.backend.service.name`	Oui	Le nom du service backend.
`spec.rules.http.paths.backend.service.port.number`	Oui	Le numéro de port du service backend. Assurez-vous que ce port correspond à la définition du service.

Exécutez la commande suivante pour créer l'Ingress avec un routage basé sur le path pour les services coffee et tea.
```
kubectl apply -f cafe-ingress.yaml
```
Sortie attendue :
```
ingress.networking.k8s.io/cafe-ingress created
```

(Facultatif) Obtenez le nom DNS ALB attribué à l'Ingress.

kubectl get ingress

Sortie attendue :

NAME           CLASS    HOSTS                         ADDRESS                                               PORTS   AGE
cafe-ingress   alb      demo.domain.ingress.top       alb-m551oo2zn63yov****.cn-hangzhou.alb.aliyuncs.com   80      50s

(Facultatif) Étape 5 : Configurer la résolution de nom de domaine

Si vous avez spécifié un domaine personnalisé dans spec.rules.host, ajoutez un enregistrement CNAME pointant vers le nom DNS de l'ALB afin d'autoriser l'accès via votre domaine.

Connectez-vous à la console Container Service for Kubernetes (ACK).
Cliquez sur le nom du cluster pour ouvrir la page de gestion du cluster.
Dans le volet de navigation de gauche, choisissez Network > Routes.
Dans la colonne Endpoint de cafe-ingress, copiez son nom DNS.

Pour ajouter un enregistrement CNAME :

Connectez-vous à la console Alibaba Cloud DNS.
Sur la page Domain Name Resolution, cliquez sur Add Zone.
Dans la boîte de dialogue Add Zone, saisissez votre nom de domaine et cliquez sur OK.

Important
Vous devez vérifier le nom de domaine à l'aide d'un enregistrement TXT.
Pour le domaine cible, cliquez sur Settings dans la colonne Actions.
Sur la page Settings, cliquez sur Add Record.

Dans le panneau Add Record, configurez les paramètres suivants pour l'enregistrement CNAME et cliquez sur OK.

Parameter

Description

Record Type

Dans la liste déroulante, sélectionnez CNAME.

Hostname

Le préfixe de votre nom de domaine, par exemple www.

DNS Query Source

Sélectionnez la valeur par défaut.

Record Value

Saisissez le nom DNS que vous avez copié depuis la colonne Endpoint.

TTL

Durée pendant laquelle un enregistrement DNS est mis en cache sur un serveur DNS. Utilisez la valeur par défaut.

Étape 6 : Tester le transfert du trafic

Saisissez le domaine de test et le chemin d'URL dans votre navigateur pour vérifier le routage du trafic.

Remarque

Si vous avez configuré un domaine personnalisé, utilisez ce domaine.
Si vous n'avez pas configuré de domaine personnalisé, utilisez le nom DNS de l'endpoint cafe-ingress.

Dans cet exemple, le domaine est demo.domain.ingress.top :

Saisissez demo.domain.ingress.top/coffee dans votre navigateur. La page affiche le service backend coffee-svc, indiquant le nom du serveur comme étant le nom du Pod coffee et l'URI comme /coffee, ce qui confirme que la requête est correctement routée vers le service backend coffee.
Saisissez demo.domain.ingress.top/tea dans votre navigateur. La page affiche le service backend tea-svc, indiquant l'URI comme /tea et le nom du serveur commençant par tea-6, ce qui confirme que la requête est correctement routée vers le Pod backend tea.

Références

Utilisation avancée du service ALB Ingress couvre les vérifications d'état, la redirection HTTPS, les déploiements canary et les ports d'écoute personnalisés.
Personnaliser les règles de transfert pour ALB Ingress.
Configurer un certificat HTTPS pour une communication chiffrée.
Résoudre les problèmes liés à ALB Ingress et FAQ sur ALB Ingress.