Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Create and use an NGINX Ingress

Dernière mise à jour :Oct 09, 2026

Le NGINX Ingress Controller sert de passerelle d'entrée pour les clusters managés Alibaba Cloud Container Service for Kubernetes (ACK). Il achemine le trafic externe vers les services internes en appliquant des règles de routage flexibles. Grâce à la prise en charge du chiffrement HTTPS, des déploiements canary et des configurations personnalisées via des annotations, il offre un accès réseau sécurisé, hautement disponible et évolutif au niveau 7 (L7).

Important

Notes d'utilisation

  • Ne supprimez pas le service par défaut utilisé par le NGINX Ingress Controller. Après l'installation du module complémentaire, un service par défaut nommé nginx-ingress-lb est créé dans le namespace kube-system. La suppression de ce service rend le module complémentaire instable et peut provoquer son arrêt brutal.

  • Utilisez les Modules complémentaires ou l'OpenAPI pour configurer les paramètres personnalisés du module complémentaire. La modification de la configuration par d'autres méthodes peut entraîner un dysfonctionnement du module et interférer avec les futures mises à niveau.

  • Utilisez le ConfigMap NGINX Ingress pour les configurations personnalisées. Le support technique ne couvre pas les problèmes causés par des configurations supplémentaires, telles que les extraits de code (snippets) ou le code Lua.

  • Mettez à jour rapidement le module complémentaire NGINX Ingress Controller afin d'éviter les interruptions d'activité dues à des bugs ou des vulnérabilités de sécurité dans la version communautaire en amont.

Installer le module complémentaire NGINX Ingress Controller

Lors de la création du cluster

1. Sélectionnez le module complémentaire

  1. Connectez-vous à la console ACK et cliquez sur Create Kubernetes Cluster.

  2. À l'étape Component Configurations, dans la section Ingress, sélectionnez NGINX Ingress.

2. Sélectionnez une source Server Load Balancer (SLB)

  • New : crée automatiquement une instance CLB publique ou privée multi-zones dans le VPC du cluster. L'instance utilise la méthode de facturation pay-by-specification et dispose d'un type d'instance spécifié.

  • Use Existing : sélectionnez une instance CLB publique existante dans la même région que le cluster ou une instance CLB privée dans le même VPC. Assurez-vous que l'instance CLB n'est associée à aucun autre cluster.

Installer depuis la page Modules complémentaires

L'installation du module complémentaire depuis la page Modules complémentaires crée automatiquement une instance CLB accessible publiquement qui utilise la méthode de facturation pay-by-specification et le type d'instance Small I (slb.s1.small). Cette instance sert de point d'entrée du trafic pour le NGINX Ingress.

  1. Connectez-vous à la console ACKconsole ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .

  3. Recherchez le module complémentaire NGINX Ingress Controller dans l'onglet Network ou à l'aide de la barre de recherche. Dans le coin inférieur droit de la carte du module complémentaire, cliquez sur Install.

  4. Dans la boîte de dialogue Install Comment NGINX Ingress Controller, configurez les paramètres et cliquez sur OK.

Créer un exemple d'application

L'exemple d'application déploie deux charges de travail sans état (Deployments) nommées coffee et tea, ainsi que leurs Services correspondants nommés coffee-svc et tea-svc.

Console

1. Créez les ressources

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.

  3. Cliquez sur Create from YAML. Sélectionnez Custom dans la liste déroulante Sample Template. Copiez le contenu suivant dans l'éditeur de modèle et cliquez sur Create.

    Fichier YAML de l'exemple d'application

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    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
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: tea
      namespace: default
    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
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: tea
      type: ClusterIP

2. Consultez le résultat

Dans la boîte de dialogue YAML Resource Creation Result, cliquez sur View dans la colonne Actions d'une ressource pour confirmer qu'elle a bien été créée.

kubectl

  1. Récupérez le fichier KubeConfig de votre cluster et utilisez kubectl pour vous y connecter.

  2. Créez un fichier nommé test-deployment-service.yaml avec le contenu suivant.

    Fichier YAML d'exemple

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    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
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: tea
      namespace: default
    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
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: tea
      type: ClusterIP
  3. Appliquez la configuration pour créer le Deployment et le Service.

    kubectl apply -f test-deployment-service.yaml
  4. Vérifiez l'état des Deployments coffee et tea.

    kubectl get deployment coffee tea

    Sortie attendue :

    NAME     READY   UP-TO-DATE   AVAILABLE   AGE
    coffee   2/2     2            2           14m
    tea      2/2     2            2           14m
  5. Vérifiez l'état des Services coffee-svc et tea-svc.

    kubectl get service coffee-svc tea-svc

    Sortie attendue :

    NAME         TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
    coffee-svc   ClusterIP   192.168.xxx.xxx   <none>        80/TCP    15m
    tea-svc      ClusterIP   192.168.xxx.xxx   <none>        80/TCP    15m

Créer un NGINX Ingress

Cet exemple utilise test-nginx-ingress.com comme nom de domaine (host). Remplacez-le par votre propre nom de domaine enregistré. Le mappage de chemin (paths) est issu de l'exemple Créer un exemple d'application. Modifiez ces chemins pour qu'ils correspondent à la configuration de votre application.

Console

1. Créez un Ingress

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, choisissez Network > Ingresses. Sélectionnez le namespace default, cliquez sur Create Ingress et configurez l'Ingress comme suit.

    • Gateway Type : Nginx Ingress

    • Name : test-nginx-ingress

    • Domain Name : test-nginx-ingress.com (remplacez par votre nom de domaine enregistré)

    • Mappings :

      • Path : /coffee

      • Rule : Default (ImplementationSpecific)

      • Service : coffee-svc

      • Port : 80

  3. Cliquez sur +Add pour configurer un chemin pour le service tea-svc.

    • Mappings :

      • Path : /tea

      • Rule : Default (ImplementationSpecific)

      • Service : tea-svc

      • Port : 80

  4. Cliquez sur +Add Rule pour ajouter le nom de domaine www.test-nginx-ingress.com (remplacez par votre nom de domaine enregistré) et configurez ses mappages de chemins. Une fois terminé, cliquez sur OK.

2. Obtenez le endpoint

Après environ une minute, actualisez la page. Le Nginx Ingress est créé avec succès lorsqu'une adresse IP élastique (EIP) apparaît dans la colonne Endpoint. Cette EIP est l'adresse de service publique de l'instance Cloud Load Balancer (CLB) associée.

Si les informations de endpoint n'apparaissent pas après quelques minutes, cliquez sur le nom de l'Ingress et vérifiez l'onglet Events pour le dépannage.

kubectl

  1. Créez un fichier nommé test-ingress.yaml avec le contenu suivant.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: test-nginx-ingress
      namespace: default
    spec:
      ingressClassName: nginx
      rules:
      - host: test-nginx-ingress.com # Replace with your registered domain name
        http:
          paths:
          - path: /coffee
            backend:
              service: 
                name: coffee-svc
                port:
                  number: 80
            pathType: ImplementationSpecific
          - path: /tea
            backend:
              service: 
                name: tea-svc
                port:
                  number: 80
            pathType: ImplementationSpecific
      - host: www.test-nginx-ingress.com # Replace with your registered domain name
        http:
          paths:
          - path: /coffee
            backend:
              service: 
                name: coffee-svc
                port:
                  number: 80
            pathType: ImplementationSpecific
          - path: /tea
            backend:
              service: 
                name: tea-svc
                port:
                  number: 80
            pathType: ImplementationSpecific

    Descriptions des paramètres :

    • name : le nom de l'Ingress. Dans cet exemple, le nom est test-nginx-ingress.

    • host : le nom de domaine utilisé pour accéder au service. Dans cet exemple, le nom de domaine est test-nginx-ingress.com. Remplacez cette valeur par votre nom de domaine enregistré.

    • path : le chemin URL de la règle. Pour qu'une requête soit routée vers le backend, elle doit correspondre au host et au path spécifiés. Dans cet exemple, les chemins sont /coffee et /tea.

    • backend : composé d'un nom de service et d'un port de service.

      • Nom du service : le nom du service backend vers lequel l'Ingress transfère le trafic. Par exemple, coffee-svc et tea-svc.

      • Port du service : le port cible sur le Service backend. Dans cet exemple, le port est 80.

  2. Créez l'Ingress.

    kubectl apply -f test-ingress.yaml
  3. Consultez l'Ingress et obtenez son adresse IP élastique (EIP), par exemple 8.xxx.xxx.117.

    kubectl get ingress

    Résultat attendu :

    NAME                 CLASS   HOSTS                                               ADDRESS         PORTS   AGE
    test-nginx-ingress   nginx   test-nginx-ingress.com,www.test-nginx-ingress.com   8.xxx.xxx.117   80      2m39s
  4. Utilisez l'EIP pour vérifier que le Nginx Ingress fonctionne correctement.

    curl http://8.xxx.xxx.117/coffee -H "Host: test-nginx-ingress.com"

    Résultat attendu :

    ...
    <title>Hello World</title>
    ...
    <p><span>Server&nbsp;address:</span> <span>10.xxx.xxx.19:80</span></p>
    <p><span>Server&nbsp;name:</span> <span>coffee-96d4bc87-l29dh</span></p>
    <p class="smaller"><span>Date:</span> <span>08/Aug/2025:02:21:02 +0000</span></p>
    <p class="smaller"><span>URI:</span> <span>/coffee</span></p>
    ...
        <div id="footer">
            <div id="center" align="center">
                Request ID: 42e2d73c85b16b55b6ab52deb7d995d4<br/>
                &copy; NGINX, Inc. 2018
            </div>
        </div>
    ...

Configurer la résolution DNS

Enregistrer un nom de domaine. Il vous suffit d'ajouter un nom de domaine s'il est enregistré auprès d'un fournisseur tiers. Alibaba Cloud ajoute automatiquement les noms de domaine achetés via sa plateforme aux zones autoritaires publiques dans Alibaba Cloud DNS, ce qui vous permet d'ajouter directement des enregistrements DNS.

1. Ajouter un nom de domaine

  1. Accédez à Alibaba Cloud DNS - Public Zone.

    Dans l'onglet Public Zone, cliquez sur Add Zone.

  2. Saisissez le nom de domaine que vous souhaitez ajouter et sélectionnez l'instance Public Zone que vous avez créée. Pour plus d'informations sur les paramètres, consultez la rubrique Acheter et lier un nom de domaine.

2. Ajouter un enregistrement DNS

  1. Recherchez le nom de domaine cible et cliquez sur Settings dans la colonne Actions. Ensuite, cliquez sur Add Record. Ajoutez un enregistrement DNS avec le type d'enregistrement A et l'enregistrement hôte @. La Record Value correspond à l'adresse d'accès du NGINX Ingress.

  2. Suivez les mêmes étapes pour ajouter un autre enregistrement DNS avec l'enregistrement hôte défini sur www.

  3. Cliquez sur Probing à côté du nouvel enregistrement DNS pour vérifier son état de résolution.

Pour plus d'informations, consultez la rubrique Ajouter un enregistrement de résolution de site Web.

3. Vérifier le nom de domaine et le chemin

Dans votre navigateur, accédez à http://test-nginx-ingress.com/coffee, en remplaçant test-nginx-ingress.com par votre nom de domaine réel, afin de vérifier que le chemin du service est accessible.

Si la requête aboutit, la page renvoie les informations du pod backend NGINX, y compris les champs server address, server name, Date et URI.

Pour confirmer le résultat, vous pouvez également consulter les Méthodes de test de la résolution DNS. Si un enregistrement DNS ne prend pas effet, consultez la rubrique Dépannage rapide des échecs de résolution DNS.

Configurer la sécurité HTTPS

Achetez un certificat commercial, puis demandez le certificat. Assurez-vous que le certificat est à l'état Issued. Suivez ensuite les étapes ci-dessous pour télécharger le certificat et ajouter une configuration TLS. Cela permet d'activer l'accès HTTPS chiffré à votre domaine.

Console

1. Télécharger le certificat

  1. Connectez-vous à la console Certificate Management Service. Dans le volet de navigation de gauche, sélectionnez Certificate Management > SSL Certificate Management.

  2. Dans l'onglet Commercial Certificates, sélectionnez le certificat à télécharger, puis cliquez sur Download dans le coin inférieur gauche de la liste des certificats.

  3. Dans la boîte de dialogue qui s'affiche, sélectionnez Nginx comme type de serveur, téléchargez le package de certificat et décompressez-le.

Pour plus de détails, consultez la rubrique Télécharger un certificat SSL.

2. Créer un Secret

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Configurations > Secrets.

  3. Sur la page Secrets, sélectionnez le namespace default, cliquez sur Create dans le coin supérieur gauche, configurez un nouveau Secret dans le panneau qui s'affiche, puis cliquez sur OK.

    • Name : nginx-ingress-tls

    • Type : Ingress TLS Certificate

    • Certificates : Contenu intégral du fichier de certificat téléchargé et décompressé (.pem).

    • Key : Contenu intégral du fichier de clé privée téléchargé et décompressé (.key).

3. Ajouter une configuration TLS

  1. Dans le volet de navigation de gauche, sélectionnez Network > Ingresses. Dans la colonne Actions de l'Ingress cible, cliquez sur Update.

  2. Sur la page Modify Ingress, ajoutez la configuration TLS suivante, puis cliquez sur OK.

    • TLS Settings : Activé

    • Domain Name : test-nginx-ingress.com (Remplacez cette valeur par votre nom de domaine enregistré réel.)

    • Secrets : nginx-ingress-tls

4. Vérifier l'accès HTTPS

Dans votre navigateur web, accédez à https://test-nginx-ingress.com/coffee (remplacez cette valeur par votre nom de domaine enregistré réel) pour vérifier l'accès HTTPS chiffré au chemin du service.

Kubectl

  1. Connectez-vous à la console Certificate Management Service. Dans le volet de navigation de gauche, sélectionnez Certificate Management > SSL Certificate Management.

  2. Dans l'onglet Commercial Certificates, sélectionnez le certificat à télécharger, puis cliquez sur Download dans le coin inférieur gauche de la liste des certificats.

  3. Dans la boîte de dialogue qui s'affiche, sélectionnez Nginx comme type de serveur, téléchargez le package de certificat et décompressez-le.

  4. Utilisez le fichier de certificat téléchargé (.pem) et le fichier de clé privée (.key) pour créer un Secret.

    kubectl create secret tls nginx-ingress-tls --cert test-nginx-ingress.com.pem --key test-nginx-ingress.com.key -n default
  5. Ajoutez une configuration TLS à l'Ingress test-nginx-ingress. Remplacez test-nginx-ingress.com dans la commande par votre nom de domaine enregistré réel.

    kubectl patch ingress test-nginx-ingress -p '{"spec":{"tls":[{"hosts":["test-nginx-ingress.com"],"secretName":"nginx-ingress-tls"}]}}'
  6. Vérifiez l'accès HTTPS chiffré au chemin du service en exécutant la commande suivante avec votre adresse IP élastique réelle.

    curl -v -k https://8.xxx.xxx.117/coffee -H "Host: test-nginx-ingress.com"
    • Paramètres :

      • -v : Affiche une sortie détaillée, y compris la négociation TLS.

      • -k (ou --insecure) : Ignore la vérification du certificat. Utilisez cette option si vous utilisez un certificat auto-signé.

    • Sortie attendue :

      ...
      *   Trying 8.xxx.xxx.117:443...
      * Connected to 8.xxx.xxx.117 (8.xxx.xxx.117) port 443
      * ALPN: curl offers h2,http/1.1
      * (304) (OUT), TLS handshake, Client hello (1):
      * (304) (IN), TLS handshake, Server hello (2):
      * (304) (IN), TLS handshake, Unknown (8):
      * (304) (IN), TLS handshake, Certificate (11):
      * (304) (IN), TLS handshake, CERT verify (15):
      * (304) (IN), TLS handshake, Finished (20):
      * (304) (OUT), TLS handshake, Finished (20):
      ...
      <title>Hello World</title>
      ...
      <p><span>Server&nbsp;address:</span> <span>10.xxx.xxx.159:80</span></p>
      <p><span>Server&nbsp;name:</span> <span>coffee-96d4bc87-6cstv</span></p>
      <p class="smaller"><span>Date:</span> <span>14/Aug/2025:09:27:42 +0000</span></p>
      <p class="smaller"><span>URI:</span> <span>/coffee</span></p>
      ...
          <div id="footer">
              <div id="center" align="center">
                  Request ID: fee5fe107106748a35d99a2dbbbc6652<br/>
                  &copy; NGINX, Inc. 2018
              </div>
          </div>
      ...

Autres configurations

Déploiement Canary

Pour mettre à niveau les services, vous pouvez utiliser diverses stratégies de déploiement, telles que les mises à jour progressives, les déploiements par phases, les déploiements blue-green et les déploiements canary. Pour obtenir des instructions détaillées, consultez la rubrique Mettre en œuvre des déploiements par phases et blue-green à l'aide de NGINX Ingress.

Protocole du service backend

Pour spécifier le protocole d'un service backend, ajoutez l'annotation nginx.ingress.kubernetes.io/backend-protocol. Les protocoles pris en charge sont HTTP, HTTPS, gRPC et gRPCS. Pour un exemple de configuration, consultez la rubrique Configurer un service gRPC pour NGINX Ingress.

Réécriture d'URL

Lorsque vous utilisez le contrôleur NGINX Ingress, il transfère les requêtes en fonction du chemin complet. Par exemple, une requête vers /service1/api est transférée vers le chemin /service1/api du pod backend. Si le chemin de votre service backend est /api, une incompatibilité de chemin se produit, entraînant une erreur 404. Pour résoudre ce problème, vous pouvez ajouter l'annotation nginx.ingress.kubernetes.io/rewrite-target afin de réécrire le chemin de la requête vers le répertoire correct.

Pour obtenir des instructions détaillées, consultez la rubrique Configurer la redirection d'URL.

Annotations

NGINX Ingress prend en charge un large éventail de fonctionnalités que vous pouvez activer via des annotations. Pour plus d'informations, consultez les rubriques Dictionnaire de configuration NGINX Ingress et Configurations avancées de NGINX Ingress.

Observabilité

Activez Simple Log Service (SLS) lors de la création du cluster pour accéder à des rapports complets d'analyse des journaux d'accès NGINX Ingress et à des tableaux de bord de surveillance en temps réel. Pour plus de détails, consultez la rubrique Analyser et surveiller les journaux d'accès NGINX Ingress.

Scénarios à forte charge

Pour améliorer les performances et la stabilité du contrôleur NGINX Ingress dans les scénarios à forte charge, consultez les rubriques Configurer un contrôleur NGINX Ingress pour les scénarios à charge élevée et Recommandations pour l'utilisation d'un contrôleur NGINX Ingress.

FAQ

IP externe inaccessible depuis l'intérieur d'un cluster

Symptôme

Certains Pods du cluster ne peuvent pas accéder aux Pods backend en utilisant l'adresse externe du contrôleur NGINX Ingress (l'adresse IP de l'instance d'équilibreur de charge), tandis que d'autres le peuvent.

Cause

Ce problème est dû au paramètre externalTrafficPolicy du Service du contrôleur, qui détermine la manière dont le trafic externe est géré. Lorsqu'il est défini sur local, seuls les Pods backend situés sur le même nœud que le Pod du contrôleur peuvent recevoir les requêtes. Lorsqu'il est défini sur Cluster, l'accès fonctionne comme prévu. Lorsqu'une ressource au sein du cluster accède au Service en utilisant l'adresse IP externe de l'équilibreur de charge, la requête est également traitée comme du trafic externe.

Solution

  • (Recommandé) Depuis l'intérieur du cluster Kubernetes, accédez à NGINX Ingress en utilisant son ClusterIP ou son nom de service. Le nom de service de NGINX Ingress est nginx-ingress-lb.kube-system.

  • Exécutez kubectl edit svc nginx-ingress-lb -n kube-system pour modifier le Service NGINX Ingress. Changez la valeur externalTrafficPolicy du Service LoadBalancer en Cluster. Si le plugin réseau de conteneurs du cluster est Flannel, les requêtes perdent l'adresse IP source du client. Si vous utilisez Terway, l'adresse IP source du client est conservée.

    Exemple :

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        service.beta.kubernetes.io/backend-type: eni   # Passes traffic directly to the Elastic Network Interface (ENI).
      labels:
        app: nginx-ingress-lb
      name: nginx-ingress-lb
      namespace: kube-system
    spec:
      externalTrafficPolicy: Cluster

Pour plus d'informations sur les annotations de Service, consultez la rubrique Configurer Classic Load Balancer (CLB) à l'aide d'annotations.

En-têtes ou cookies volumineux

Si une requête client contient des en-têtes de requête ou des cookies volumineux, NGINX Ingress peut renvoyer une erreur telle que "400 Request Header Or Cookie Too Large /Bad request". Pour résoudre ce problème, augmentez la taille des tampons en modifiant les paramètres suivants :

  • client-header-buffer-size : Taille du tampon pour les en-têtes de requête client. La valeur par défaut est 1k.

  • large-client-header-buffers : Nombre et taille maximum des tampons utilisés pour lire les en-têtes de requête client volumineux. La valeur par défaut est 4 8k.

Exécutez kubectl edit cm -n kube-system nginx-configuration pour modifier le ConfigMap et ajuster ces paramètres. Exemple :

client-header-buffer-size: "16k"
large-client-header-buffers: "4 32k" 

Après avoir mis à jour les paramètres, vérifiez que le plan de données NGINX reflète les modifications. Exécutez kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf | vim - pour afficher le fichier nginx.conf et confirmer que les modifications du ConfigMap sont synchronisées.

Configuration CORS

Activez le partage de ressources cross-origin (CORS) en ajoutant des annotations spécifiques à la section metadata.annotations de votre ressource Ingress. Pour plus d'informations, consultez la rubrique Configurer CORS pour NGINX Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"     # Enables CORS.
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"  # Allows access from all domains.
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET, PUT, POST, DELETE, PATCH, OPTIONS"  # Allowed HTTP methods.
    nginx.ingress.kubernetes.io/cors-allow-headers: "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range" # Allowed custom request headers.
    nginx.ingress.kubernetes.io/cors-expose-headers: "Content-Length,Content-Range"  # Exposed response headers.
    nginx.ingress.kubernetes.io/cors-max-age: "86400"  # Preflight request cache duration.
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

Transmission de l'adresse IP du client

Par défaut, NGINX Ingress utilise les en-têtes X-Forwarded-For et X-Real-IP pour transmettre l'adresse IP du client. Toutefois, si un client définit explicitement ces en-têtes dans la requête, le serveur backend peut ne pas être en mesure d'obtenir l'adresse IP réelle du client.

Pour activer la transmission de l'adresse IP du client au niveau de la couche 7 pour l'Ingress, exécutez la commande kubectl edit cm -n kube-system nginx-configuration et ajoutez les paramètres suivants au ConfigMap.

compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"

Si NGINX Ingress se trouve derrière plusieurs couches de proxy, ajustez la configuration en fonction du paramètre proxy-real-ip-cidr. Ajoutez les adresses IP des proxys amont à proxy-real-ip-cidr au format CIDR, en séparant plusieurs blocs CIDR par des virgules. Pour plus d'informations, consultez la rubrique Utiliser un WAF.

proxy-real-ip-cidr:  "0.0.0.0/0,::/0"  

Dans un scénario IPv6 avec un Classic Load Balancer (CLB) amont, si l'en-tête X-Forwarded-For reçu par NGINX Ingress est vide, activez le Proxy Protocol sur le CLB pour obtenir l'adresse IP du client. Pour plus d'informations sur le Proxy Protocol, consultez la rubrique Obtenir les adresses IP réelles des clients via un écouteur de couche 4 d'une instance CLB.

Références