#kubernetes #memory-management #kubelet
#kubernetes #управление памятью #kubelet
Вопрос:
Моя настройка
У меня есть один физический узел K8s кластера, где я заражаю главный узел, чтобы он также мог действовать как рабочий. на узле установлен Centos7 с общим объемом памяти 512 ГБ. Я ограничиваю свои эксперименты одним кластером узлов; как только решение будет найдено, я протестирую его на своем небольшом кластере k8s, где основные и рабочие службы находятся на отдельных узлах.
Что я пытаюсь сделать
Я хочу, чтобы k8s worker для начала использовал только 256 ГБ памяти. позже, если выполняется определенное условие узла, я хочу увеличить выделение памяти для рабочего узла k8s до (допустим) 400 ГБ
Где я сейчас с этим
- Я перезагружаю свой компьютер, и узел загружается с полной памятью 512 ГБ.
- Я использую
chmem -d <range>для отключения 256 ГБ памяти. Теперь ОС видит, что доступно только 256 ГБ памяти. - Я выполняю шаги от
kubeadm initдоkubectl taint nodes --all node-role.kubernetes.io/master- - Мой набор K8s с одним узлом настроен, и я могу развернуть до 2 модулей. каждый модуль запрашивает 100 ГБ и использует память не более 200 Гб. Выполняется модуль Pod
sleep 100000. таким образом, нет нагрузки на память. - Когда я пытаюсь запустить третий модуль; модуль застрял в состоянии ожидания, потому что планировщик обнаруживает, что у единственного рабочего узла, которым он управляет, отсутствует выделяемый ресурс памяти. Это имеет смысл. третий модуль просто навсегда застрял в состоянии ожидания.
- Теперь, через некоторое время; узел выполнил требуемое условие; на данный момент я
chmem -e <range>включал некоторую память, и теперь ОС видит 400 ГБ. - На этом этапе я хочу, чтобы k8s worker знал об этом изменении объема ресурсов памяти, чтобы можно было развернуть третий модуль, застрявший на стадии ожидания.
- Здесь мне нужна ваша помощь. как я могу обновить емкость ресурсов памяти рабочего без перезапуска моего k8s. Если я перезапущу кластер, он сможет увидеть 400 ГБ памяти; но это означает, что мне нужно уничтожить уже запущенные модули, а уничтожение уже запущенного модуля неприемлемо.
Комментарии:
1. Здравствуйте, пожалуйста, скажите, пробовали ли вы то, что Бернард Халас связал вас в комментариях, т.Е.: kubernetes.io/docs/tasks/administer-cluster /… ?
Ответ №1:
Это долгий путь, но вы можете попробовать перезапустить kubelet через systemctl restart kubelet . Контейнеры не следует перезапускать таким образом, и есть надежда, что после перезапуска он заметит увеличенную конфигурацию памяти.
Комментарии:
1. Я проверил журналы kubelet; это отражает изменение объема памяти при использовании оперативной / автономной памяти. но это не влияет на решение о планировании для третьего модуля; он остается в стадии ожидания. С другой стороны, когда я проверяю
kubectl describe nodesдетали, объем памяти остается неизменным и не отражает изменений, связанных с памятью / онлайн / оффлайн. Я также попытался перезапустить kubelet, как вы предложили, но никаких изменений в поведении планирования или статусе модуля не произошло2. Хм, в etcd, вероятно, есть старая информация о размере памяти узла, и планировщик использует ее при принятии решений о планировании новых модулей. Пока не уверен, как принудительно выполнить обновление здесь. С другой стороны: пожалуйста, имейте в виду, что K8s рассматривает модули как эфемерные, и со временем они будут уничтожены.
3. Поэтому, если внесенное вами изменение не вступит в силу через несколько минут, есть еще один рискованный вариант: изменив один из параметров резервирования памяти для
kubelet, вы сможете принудительно перенастроить узел в базе данных. Например. измените значение дляsystem-reservedи обратите внимание: kubernetes.io /документы / задачи / администрирование-кластер / …4. Я вижу, что вы использовали
kubeadmдля подготовки своего кластера, но внесли ли вы какие-либо изменения вkubeletконфигурацию?5. Спасибо, Бернард; перезапуск kubelet сработал … каждый раз, когда я подключался к сети / сети, карты памяти и показатели ОС обновлялись немедленно, но для того, чтобы K8s получил эти изменения, я перезапустил kubelet, и в течение нескольких секунд это отразилось и на уровне K8s. Модули / контейнеры продолжали работать, когда kubelet перезапускался; что было неожиданностью; у меня создалось впечатление, что если я перезапущу kubelet на работающем рабочем компьютере; это приведет к уничтожению / перезапуску всех модулей.
Ответ №2:
- Пожалуйста, предоставьте вывод следующей команды
kubectl describe nodes
- Перезапуск kubelet с помощью приведенной ниже команды должен работать, потому что kubelet пересчитывает выделяемый процессор и память при каждом запуске
systemctl restart kubelet
- Вы пытались удалить и воссоздать третий модуль после перезапуска kubelet?
Комментарии:
1. Благодаря Сагару перезапуск kubelet сработал … каждый раз, когда я подключался к сети / сети, карты памяти и показатели ОС обновлялись немедленно, но для того, чтобы K8s получил эти изменения, я перезапустил kubelet, и в течение нескольких секунд это отразилось и на уровне K8s. Модули / контейнеры продолжали работать, когда kubelet перезапускался; что было неожиданностью; у меня создалось впечатление, что если я перезапущу kubelet на работающем рабочем компьютере; это приведет к уничтожению / перезапуску всех модулей.
2. системный демон kubelet вызывает API среды выполнения контейнера для создания контейнеров. Так что на самом деле это среда выполнения контейнера, такая как Docker, Containerd и т. Д., Которая запускает контейнеры. Таким образом, вы можете перезапустить системный демон kubelet в любое время, не опасаясь перезапуска контейнеров. Но если по какой-либо причине демон kubelet не запускается и он долгое время не работает, то Kubernetes сообщает, что узел не работает, и Kubernetes удаляет модули из узла, что приводит к запуску модулей Deployment / ReplicaSet на других узлах. В этом случае у вас возникнет проблема с избыточной емкостью.