Fondo
Ejecutamos un clúster de kubernetes que maneja varios microservicios de php/lumen. Comenzamos a ver la aplicación php-fpm/nginx informando el código de estado 499 en sus registros, y parece corresponder con que el cliente obtenga una respuesta en blanco (curl devuelve curl: (52) Empty reply from server ) mientras que las aplicaciones registran 499.
10.10.xx - - [09/Mar/2020:18:26:46 +0000] "POST /some/path/ HTTP/1.1" 499 0 "-" "curl/7.65.3"Tengo entendido que nginx devolverá el código 499 cuando el socket del cliente ya no esté abierto/disponible para devolver el contenido. En esta situación, eso parece significar algo antes de que la capa de nginx/aplicación finalice esta conexión. Nuestra configuración actualmente es:
ELB -> entrada k8s nginx -> aplicación
Entonces, mis pensamientos son ELB o ingreso, ya que la aplicación es la que no tiene ningún socket al que regresar. Así que comencé a golpear los registros de ingreso...
¿Posible problema central?
Mientras miro los registros de ingreso, veo algunos de estos:
2020/03/06 17:40:01 [crit] 11006#11006: ngx_slab_alloc() failed: no memory in vhost_traffic_status_zone "vhost_traffic_status"Solucion potencial
Me imagino que si le doy a vhost_traffic_status_zone algo más de memoria, al menos ese error desaparecerá y buscará el siguiente error... pero parece que no puedo encontrar ningún valor de mapa de configuración o anotación que me permita controlar esto. He revisado los documentos:
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
¡Gracias de antemano por cualquier información/sugerencia/documentación que me pueda faltar!
Esta es la forma estándar de buscar cómo modificar nginx.conf en el controlador de ingreso. Después de eso, vincularé información sobre sugerencias sobre la cantidad de memoria que debe otorgar a la zona.
En primer lugar, comience por obtener la versión del controlador de entrada comprobando la versión de la imagen en kubectl -n <namespace> get deployment <deployment-name> | grep 'image:'
Desde allí, puede recuperar el código de su versión desde la siguiente URL. A continuación, utilizaré la versión 0.10.2. https://github.com/kubernetes/ingress-nginx/releases/tag/nginx-0.10.2
La plantilla nginx.conf se puede encontrar en rootfs/etc/nginx/template/nginx.tmpl en el código o /etc/nginx/template/nginx.tmpl en un pod. Esto puede ser grepped para la línea de interés. En el caso del ejemplo, encontramos la siguiente línea en el nginx.tmpl
vhost_traffic_status_zone shared:vhost_traffic_status:{{ $cfg.VtsStatusZoneSize }};
Esto nos da la variable de configuración para buscar en el código. Nuestro próximo grep para VtsStatusZoneSize nos lleva a las líneas en internal/ingress/controller/config/config.go
// Description: Sets parameters for a shared memory zone that will keep states for various keys. The cache is shared between all worker processe // https://github.com/vozlt/nginx-module-vts#vhost_traffic_status_zone // Default value is 10m VtsStatusZoneSize string `json:"vts-status-zone-size,omitempty"Esto nos da la clave "vts-status-zone-size" para agregar al mapa de configuración "ingress-nginx-ingress-controller". El valor actual se puede encontrar en la plantilla nginx.conf renderizada en un pod en /etc/nginx/nginx.conf.
Cuando se trata de qué tamaño es posible que desee configurar la zona, hay documentos aquí que sugieren configurarlo en 2 * usedSize:
Si el mensaje ("ngx_slab_alloc() falló: no hay memoria en vhost_traffic_status_zone") impreso en error_log, aumente a más de (usedSize * 2).
https://github.com/vozlt/nginx-module-vts#vhost_traffic_status_zone
"usedSize" se puede encontrar accediendo a la página de estadísticas de nginx o a través del punto final de JSON. Aquí está la solicitud para obtener la versión JSON de las estadísticas y, si tiene jq, la ruta al valor: curl http://localhost:18080/nginx_status/format/json 2> /dev/null | jq .sharedZones.usedSize
Espero que esto ayude.