Получение ошибок на рабочих узлах как «Слишком много открытых файлов в системе»

Question

Я использую kube-aws для создания кластера kubernetes в AWS, у меня есть версия kube-aws v0.12.3, у меня часто возникают проблемы с рабочими узлами как «слишком много открытых файлов в системе», когда я пытаюсьssh в рабочий узел, и узлы перестают отвечать и перезапускаются.

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

Какя могу решить эту проблему.

✗ kubectl version Версия клиента: version.Info {Major: "1", Minor: "11", GitVersion: "v1.11.3", GitCommit: "a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate: "2018-09-09T18: 02: 47Z", GoVersion: "go1.10.3", компилятор: "gc", платформа: "darwin / amd64"} Версия сервера: version.Info {Major: "1 ", Minor:" 11 ", GitVersion:" v1.11.3 ", GitCommit:" a4529464e4629c21224b3d52edfe0ea91b072862 ", GitTreeState:" clean ", BuildDate:" 2018-09-09T17: 53: 03Z ", GoVersion:" go1.10.10, Компилятор: "gc", платформа: "linux / amd64"}

Рабочий узел: узел | k8s- - core @ ip-10-0-214-11 ~ $ ulimit -a

размер файла ядра (блоки, -c) неограничен

размер сегмента данных (в килобайтах, -d) неограничен

приоритет планирования (-e) 0

размер файла (блоки, -f) неограничен

ожидающие сигналы(-i) 251640

макс. заблокированной памяти (в килобайтах, -l) 16384

макс. объем памяти (в килобайтах, -m) неограниченно

открытых файлов (-n) 1024

размер канала (512 байт, -p) 8

очереди сообщений POSIX (байты, -q) 819200

приоритет в реальном времени (-r) 0

размер стека (в килобайтах, -s) 8192

процессорное время (секунды, -t) неограничено

макс. пользовательских процессов (-u) 251640

виртуальная память (кбайт, -v) неограниченно

блокировки файлов (-x) неограниченно

Answer 1

Как видите, максимальное количество открытых файлов установлено на довольно маленькое значение (1024). Возможно, это унаследовано от шаблона AWS, используемого для экземпляра рабочего узла.

Вы должны увеличить это значение, но это должно быть сделано с четким пониманием того, на каком уровне оно должно быть установлено:

• глобально или для конкретного участника безопасности;
• к какому основному принципу должен применяться этот лимит: к учетной записи пользователя / системы / демона или группы;
• Служба входа (su, ssh, telnet и т. Д.)

Кроме того, вы должны быть осторожны, чтобы не превысить ограничение ядра.

Для простого случая просто добавьте две строки, как показано ниже, в конец файла /etc/security/limits.conf:

mike           soft    nofile          4096
mike           hard    nofile          65536

, а затем повторно войдите в систему или перезапустите службу, для которой вы вносите изменения.

Вы можете найти дополнительные объяснения в Интернете; одно из многих доступно здесь: Руководство по безопасности и усилению безопасности

Чтобы эти параметры применялись к экземпляру AWS во время запуска, вы можете написать простой код сценария, подобный следующему:

#!/bin/bash
cd /etc/security
cp limits.conf limits.conf.$(date "+%Y%m%d")
cat <<EndOfMyStrings >> limits.conf
mike           soft    nofile          4096
mike           hard    nofile          65536
EndOfMyStrings

и затем добавьте его в поле «Данные пользователя» мастера запуска экземпляра, как описано здесь: Выполнение команд в вашем экземпляре Linux при запуске