Как контролировать vhost_shared_traffi c память K8s nginx вход? - PullRequest
Новая
       4

Как контролировать vhost_shared_traffi c память K8s nginx вход?

0 голосов
/ 09 марта 2020

Фон

Мы запускаем кластер kubernetes, который обрабатывает несколько микроуслуг php / lumen. Мы начали видеть приложение php -fpm / nginx, сообщающее 499 кодов состояния в своих журналах, и это похоже на то, что клиент получает пустой ответ (curl возвращает curl: (52) Empty reply from server), в то время как приложения регистрируют 499. 

10.10.x.x - - [09/Mar/2020:18:26:46 +0000] "POST /some/path/ HTTP/1.1" 499 0 "-" "curl/7.65.3"

Насколько я понимаю, nginx вернет код 499, когда сокет клиента больше не открыт / недоступен для возврата содержимого. В этой ситуации это может что-то значить до того, как уровень nginx / application завершит соединение. В настоящее время наша конфигурация:

ELB -> k8s nginx ingress -> application

Так что я думаю, что это либо ELB, либо вход, так как приложение - это тот, у кого нет сокета, чтобы вернуться к , Итак, я начал нажимать на входные журналы ...

Потенциальная проблема с ядром?

Просматривая входные журналы, я вижу довольно много из них: 

2020/03/06 17:40:01 [crit] 11006#11006: ngx_slab_alloc() failed: no memory in vhost_traffic_status_zone "vhost_traffic_status"

Потенциальное решение

Я думаю, если бы я дал vhost_traffic_status_zone еще немного памяти, по крайней мере, эта ошибка могла бы go исчезнуть и перейти к поиску следующей ошибки ... но я могу Похоже, что не найти какое-либо значение configmap или аннотации, которые позволили бы мне контролировать это. Я проверил документы:

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/

Заранее благодарим за любые идеи / предложения / документация, которые я мог бы пропустить!

1 Ответ

2 голосов
/ 17 марта 2020

- это стандартный способ узнать, как изменить nginx .conf во входном контроллере. После этого я приведу некоторые сведения о том, сколько памяти вы должны выделить для зоны.

Сначала начните с получения версии входного контроллера, проверив версию образа при развертывании kubectl -n <namespace> get deployment <deployment-name> | grep 'image:'

Оттуда вы можете получить код для вашей версии по следующему URL. В дальнейшем я буду использовать версию 0.10.2. https://github.com/kubernetes/ingress-nginx/releases/tag/nginx-0.10.2

Шаблон nginx .conf можно найти по адресу rootfs / etc / nginx / template / nginx .tmpl в коде или / etc / nginx / template / nginx .tmpl на стручке. Это можно найти для интересующей линии. В этом примере мы находим следующую строку в nginx .tmpl

vhost_traffic_status_zone shared:vhost_traffic_status:{{ $cfg.VtsStatusZoneSize }};

Это дает нам переменную config для поиска в коде. Наш следующий grep для VtsStatusZoneSize приводит нас к строкам во внутреннем / 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"

Это дает нам добавляемый ключ "vts-status-zone-size" в конфигурационную карту "ingress- nginx -ingress-controller". Текущее значение можно найти в отрендеренном шаблоне nginx .conf на модуле в /etc/nginx/nginx.conf.

Когда дело доходит до того, какой размер вы можете установить для зоны, здесь есть документы, которые предлагают установить его на 2 * usedSize:

Если сообщение («ngx_slab_allo c () не удалось: нет памяти в vhost_traffic_status_zone»), напечатанное в error_log, увеличится до более чем (usedSize * 2).

https://github.com/vozlt/nginx-module-vts#vhost_traffic_status_zone

"usedSize" можно найти, нажав страницу статистики для nginx или через JSON конечная точка. Вот запрос на получение JSON версии статистики и, если у вас есть jq путь к значению: curl http://localhost:18080/nginx_status/format/json 2> /dev/null | jq .sharedZones.usedSize

Надеюсь, это поможет.

...