Puede que se de el caso de que encuentres algún fallo en tu código o proyecto, recuerda probar siempre en un ambiente de testing antes aplicar el código al trabajo final.
Solución:
Me las arreglé para mostrar lo que Helm ejecuta YAML usando: --dry-run --debug opciones al final de helm install dominio. Luego me di cuenta de que el controlador se ejecuta con: --configmap=namespace-where-the-nginx-ingress-is-deployed/name-of-the-helm-chart-nginx-ingress-controller. Para cargar su ConfigMap, debe anularlo con el suyo propio (consulte el espacio de nombres).
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 lista de propiedades de configuración se puede encontrar aquí.
También se pueden pasar las propiedades de config mag en el momento de la instalación:
helm install stable/nginx-ingress --name nginx-ingress --set controller.config.use-forwarded-headers='"true"'
NOTA: para no-string los valores tenían que usar comillas simples alrededor de comillas dobles para que funcionara.
si usaste helm install para instalar el ingreso-nginx, si no se pasó ningún valor explícito para el cual ConfigMap debe mirar el controlador nginx, el valor predeterminado parece ser namespace/release-name-nginx-ingress-controller. Esto lo genera https://github.com/helm/charts/blob/1e074fc79d0f2ee085ea75bf9bacca9115633fa9/stable/nginx-ingress/templates/controller-deployment.yaml#L67. (Ver similar si es un enlace muerto).
Para verificarlo usted mismo, intente encontrar el comando con el que instaló el gráfico de ingreso-nginx y agregue --dry-run --debug al mando. Esto le mostrará los archivos yaml generados por Tiller para aplicarlos al clúster. La línea # Source: nginx-ingress/templates/controller-deployment.yaml comienza el despliegue del controlador que tiene un arg de --configmap=. El valor de este arg es lo que debe ser el nombre del ConfigMap para que el controlador lo detecte y lo use para actualizar su propio .conf expediente. Esto podría pasarse explícitamente, pero si no es así, tendrá un valor predeterminado.
Si se crea un ConfigMap con el nombre CORRECTO, los registros del controlador mostrarán que recogió el cambio de configuración y se recargó.
Esto se puede verificar con kubectl logs . Mis mensajes de registro contenían el texto Configuration changes detected, backend reload required. Estos mensajes de registro no estarán presentes si el nombre de ConfigMap era incorrecto.
Creo que falta innecesariamente la documentación oficial para esto, pero ¿tal vez estoy equivocado? Intentaré enviar un PR con estos detalles. Alguien que sepa más debería ayudar a desarrollarlos para que la gente no tenga que tropezarse con esto innecesariamente.
Saludos, gracias por tu publicación.
Puntuaciones y reseñas
Si sostienes alguna suspicacia y forma de aclarar nuestro sección eres capaz de ejecutar una reseña y con deseo lo interpretaremos.