Comment utiliser la configuration ConfigMap avec le contrôleur Helm NginX Ingress - Kubernetes

Vous devriez l'utiliser dans le manifeste de déploiement du contrôleur d'entrée

Ce que vous avez est un yaml d'entrée et non un yaml de déploiement de contrôleur Ingress, Ingress Controller est le pod qui fait réellement le travail et est généralement un conteneur nginx lui-même. Un exemple d'une telle configuration peut être trouvé ici dans la documentation que vous avez partagée.

MISE À JOUR

En utilisant cet exemple fourni, vous pouvez également utiliser la méthode suivante pour charger la configuration dans nginx à l'aide de la carte de configuration

     volumeMounts:
      - name: nginx-config
        mountPath: /etc/nginx/nginx.conf
       subPath: nginx.conf
    volumes:
     - name: nginx-config
       configMap:
       name: nginx-config 

nginx-config contient votre configuration nginx dans le cadre de la carte de configuration

J'ai réussi à afficher ce que YAML est exécuté par Helm en utilisant les --dry-run --debug : --dry-run --debug à la fin de la helm install . Ensuite, j'ai remarqué que le contrôleur est exécuté avec le: --configmap={namespace-where-the-nginx-ingress-is-deployed}/{name-of-the-helm-chart}-nginx-ingress-controller . Afin de charger votre ConfigMap, vous devez le remplacer par le vôtre (consultez l'espace de noms).

kind: ConfigMap
apiVersion: v1
metadata:
  name: {name-of-the-helm-chart}-nginx-ingress-controller
  namespace: {namespace-where-the-nginx-ingress-is-deployed}
data:
  proxy-read-timeout: "86400"
  proxy-body-size: "2g"
  use-http2: "false"

La liste des propriétés de configuration peut être trouvée ici .

Lorsque vous appliquez la configuration ConfigMap avec des données clé-valeur nécessaires, le contrôleur Ingress récupère ces informations et les insère dans le fichier de configuration d'origine du pod nginx-ingress-controller imbriqué /etc/nginx/nginx.conf , il est donc facile de vérifier par la suite si ConfigMap les valeurs ont été reflétées avec succès ou non, en vérifiant le nginx.conf réel dans le pod correspondant.

Vous pouvez également vérifier les journaux du pod nginx-ingress-controller pertinent afin de vérifier si les données ConfigMap sont déjà rechargées dans le backend nginx.conf , ou si ce n'est pas le cas pour en rechercher la raison.

Si vous avez utilisé helm install pour installer ingress-nginx, si aucune valeur explicite pour laquelle ConfigMap le contrôleur nginx devrait examiner n'a été transmise, la valeur par défaut semble être {namespace} / {release-name} -nginx-ingress-controller . Ceci est généré par https://github.com/helm/charts/blob/1e074fc79d0f2ee085ea75bf9bacca9115633fa9/stable/nginx-ingress/templates/controller-deployment.yaml#L67 . (Voir similaire s'il s'agit d'un lien mort).

Pour vérifier par vous-même, essayez de trouver votre commande avec laquelle vous avez installé le graphique ingress-nginx et ajoutez --dry-run --debug à la commande. Cela vous montrera les fichiers yaml générés par Tiller à appliquer au cluster. La ligne # Source: nginx-ingress/templates/controller-deployment.yaml commence le déploiement du contrôleur qui a un arg de --configmap= . La valeur de cet arg est ce qui doit être le nom du ConfigMap pour que le contrôleur le détecte et l'utilise pour mettre à jour son propre fichier .conf . Cela pourrait être transmis explicitement, mais si ce n'est pas le cas, il aura une valeur par défaut.

Si un ConfigMap est créé avec le nom DROIT, les journaux du contrôleur montreront qu'il a récupéré le changement de configuration et s'est rechargé.

Cela peut être vérifié avec les kubectl logs <pod-name-of-controller> -n <namespace-arg-if-not-in-default-namespace> . Mes messages de journal contenaient le texte Configuration changes detected, backend reload required. Ces messages de journal ne seront pas présents si le nom ConfigMap était incorrect.

Je pense que la documentation officielle à ce sujet fait inutilement défaut, mais peut-être que je me trompe? Je vais essayer de soumettre un PR avec ces détails. Quelqu'un qui en sait plus devrait les aider à les étoffer pour que les gens n'aient pas à tomber inutilement dessus.

Merci pour votre message.

On peut également transmettre les propriétés de config mag au moment de l'installation:

helm install stable/nginx-ingress --name nginx-ingress --set controller.config.use-forwarded-headers='"true"'

REMARQUE: pour les valeurs non-chaîne, il fallait utiliser des guillemets simples autour des guillemets doubles pour que cela fonctionne.

J'ai lu les réponses ci-dessus mais je n'ai pas pu le faire fonctionner.

Ce qui a fonctionné pour moi était le suivant:

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-udp-ic-cm
  namespace: default
data:
  worker-connections : "10000"

et le tcp-udp-ic-cm.yaml est:

release_name=tcp-udp-ic

# add the helm repo from NginX and update the chart
helm repo add nginx-stable https://helm.nginx.com/stable
helm repo update

echo "- Installing -${release_name}- into cluster ..."

#delete the config map if already exists
kubectl delete cm tcp-udp-ic-cm

helm del --purge ${release_name}
helm upgrade --install ${release_name} \
--set controller.image.tag=1.6.0 \
--set controller.config.name=tcp-udp-ic-cm \
nginx-stable/nginx-ingress --version 0.4.0 #--dry-run --debug

# update the /etc/nginx/nginx.conf file with my attributes, via the config map
kubectl apply -f tcp-udp-ic-cm.yaml

Essentiellement, je dois déployer avec helm la version et définir le nom du config-map qui va utiliser. Helm crée le config-map mais vide. Ensuite, j'applique le fichier config-map afin de mettre à jour la ressource config-map avec mes valeurs. Cette séquence est la seule que je puisse faire fonctionner.

Si vous souhaitez donner votre propre configuration lors du déploiement de nginx-ingress-controller , vous pouvez avoir un graphique Helm wrapper sur le graphique Helm nginx-ingress et fournir votre propre values.yaml qui peut avoir une configuration personnalisée.

Utiliser Helm 3 ici.

Créez un graphique:

$ helm lint <path/to/chart>
$ helm install --debug --dry-run --namespace <namespace> <release-name> <path/to/chart>

Donc, ma structure de graphique ressemble à ceci:

$ helm dependency update <path/to/chart>

Il y a quelques choses supplémentaires ici. Plus précisément, je n'ai pas besoin du répertoire complet des templates/ et de son contenu, je vais donc simplement les supprimer:

$ cat custom-nginx/values.yaml 
# Default values for custom-nginx.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

nginx-ingress:
  controller:
    ingressClass: internal-nginx
    replicaCount: 1
    service:
      externalTrafficPolicy: Local
    publishService:
      enabled: true
    autoscaling:
      enabled: true
      minReplicas: 1
      maxReplicas: 3
      targetCPUUtilizationPercentage: "80"
      targetMemoryUtilizationPercentage: "80"
    resources:
      requests:
        cpu: 1
        memory: 2Gi
      limits:
        cpu: 1
        memory : 2Gi
    metrics:
      enabled: true
    config:
      compute-full-forwarded-for: "true"

Maintenant, la structure du graphique devrait ressembler à ceci:

 $ cat custom-nginx/Chart.yaml 
apiVersion: v2
name: custom-nginx
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 1.39.1

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
appVersion: 0.32.0

dependencies:
- name: nginx-ingress
  version: 1.39.1
  repository: https://kubernetes-charts.storage.googleapis.com/ 

Depuis, nous devons inclure le graphique nginx-ingress original en tant que dépendance, mon Chart.yaml ressemble à ceci:

custom-nginx/
├── Chart.yaml
├── charts
└── values.yaml

Ici, appVersion est la version de l'image docker nginx-controller et la version correspond à la version du graphique nginx-ingress que j'utilise.

La seule chose qui reste est de fournir votre configuration personnalisée. Voici une version allégée de ma configuration personnalisée:

$ rm custom-nginx/templates/*
$ rmdir custom-nginx/templates

Nous pouvons vérifier les clés disponibles à utiliser comme configuration (section config dans values.yaml ) dans https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/

Et le reste de la configuration peut être trouvé ici: https://github.com/helm/charts/tree/master/stable/nginx-ingress#configuration

Une fois les configurations définies, téléchargez simplement la dépendance de votre graphique:

custom-nginx/
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

Il est recommandé d'effectuer des vérifications de base sur votre graphique avant de le déployer:

$ helm create custom-nginx
$ tree custom-nginx

Puis déployez votre graphique (qui déploiera votre nginx-ingress-controller avec vos propres configurations personnalisées).

De plus, puisque vous avez un graphique maintenant, vous pouvez mettre à niveau et restaurer votre graphique.

Un moyen plus simple de faire cela consiste simplement à modifier les valeurs déployées via helm. Les valeurs à modifier pour entrer dans ConfigMap se trouvent maintenant dans controller.config.entries . Afficher les dernières valeurs avec: helm show values nginx-stable/nginx-ingress et rechercher le format sur la version que vous exécutez.

J'ai eu des tonnes de problèmes avec cela puisque toutes les références en ligne indiquaient controller.config , jusqu'à ce que je vérifie avec la commande ci-dessus.

Après avoir entré les valeurs, mettez à niveau avec:

helm upgrade -f <PATH_TO_FILE>.yaml <NAME> nginx-stable/nginx-ingress

Juste pour confirmer la réponse @NeverEndingQueue ci-dessus, le nom de la carte de configuration est présent dans la spécification du pod nginx-controller lui-même, donc si vous inspectez le yaml du pod nginx-controller : kubectl get po release-name-nginx-ingress-controller-random-sequence -o yaml , sous spec.containers , vous trouverez quelque chose comme:

I1116 10:35:45.174127       6 event.go:278] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"default", Name:"release-name-nginx-ingress-controller", UID:"76819abf-4df0-41e3-a3fe-25445e754f32", APIVersion:"v1", ResourceVersion:"62559702", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap default/release-name-nginx-ingress-controller
I1116 10:35:45.184627       6 controller.go:141] Configuration changes detected, backend reload required.
I1116 10:35:45.396920       6 controller.go:157] Backend successfully reloaded.

Par exemple, ici, une mappe de configuration nommée release-name-nginx-ingress-controller dans l'espace de noms default doit être créée.

Une fois terminé, vous pouvez vérifier si les modifications ont eu lieu en vérifiant les journaux. Normalement, vous verrez quelque chose comme:

  - args:
    - /nginx-ingress-controller
    - --default-backend-service=default/release-name-nginx-ingress-default-backend
    - --election-id=ingress-controller-leader
    - --ingress-class=nginx
    - --configmap=default/release-name-nginx-ingress-controller