sh112 Jun 25 at 15:35

Автообновления Linux: почему сервер моргает по утрам, а кластер теряет кворум

Medium

8 min

11K

System administration * DevOps * *nix *

Tutorial

+11

Comments 13

ChillyVanilly Jun 25 at 15:45

ubuntu/debian не место на сервере, а не вот это всё

а обновы ставить руками )

sh112 Jun 25 at 15:46

Вполне вероятно, что так, ваши рекомендации?

ChillyVanilly Jun 25 at 16:31

Увы, я должен был написать "ubuntu не место на сервере", но купился на ложь автора. А серверы с дебианом у меня немного есть (и да, описываемой фигни не замечал в 10-13), хотя в важных местах конечно oracle linux )

bardak_roman Jun 26 at 01:54

В дебиан этого нет по умолчанию

gerbert_MX Jun 25 at 15:50

первое спорно, второе согласен

обновы нужны только если сервис явно торчит в сеть и то закрываем все порты по максимуму и 99% проблем обойдет стороной

sh112 Jun 25 at 15:57

Тут тоже есть нюанс: закрытие внешнего контура не гарантирует безопасность. Все узлы должны быть настроены так, как будто они находятся во внешней сети. Так мы усложним жизнь злоумышленнику, который пробил первый контур, а себе дадим время на обнаружение его действий.

smke Jun 25 at 21:08

О, бест практис подъехали!

bloomeatt Jun 25 at 16:06

Интересно, не знал о таком, проверил на случайном сервере - в 6 утра действительно что то происходит.

+-150 серваков, за 2,5 года ни разу не заметил. Миновало как то.

Heggi Jun 25 at 16:15

До Debian 12 такого не было? Или образа у хостеров уже почищены от этого. У меня на всех серверах нет файлика 20auto-upgrades. Все сервера старые, стартовали с Debian 10 или 11, сейчас проапгрейжены до 13.

sh112 Jun 25 at 16:23

А вот тут я оказался не прав, спасибо. На Debian есть механизм получения обновлений безопасности, но из коробки он не включен. Статью поправил

Xelld Jun 25 at 22:29

А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.

VenbergV Jun 26 at 07:02

Приводим 20auto-upgrades к виду:

APT::Periodic::Update-Package-Lists “0”;
APT::Periodic::Unattended-Upgrade “0”;
Запускаем обновления своим сценарием ansible для каждого хоста, с отдельной управляющей машины.
В сценарии еще и автопроверка работоспособности нужных сервисов после обновления каждого хоста.

lked Jun 29 at 10:48

По кластеру важный момент: RandomizedDelaySec - это рандомизация, а не координация. Задержка случайная и берётся заново при каждом срабатывании таймера, между узлами никак не согласована - два узла спокойно попадут в одно окно, и кворум всё равно уедет. Для кворума это не лечение, а лотерея.

Если надо железно по одному - либо выключить автоприменение и катить своим плейбуком (как выше с ansible), либо развести окна ребута по узлам, чтобы они физически не пересекались. В k8s для этого есть kured: держит кластерный лок и ребутит строго по одному, уважая PodDisruptionBudget (сам по себе PDB ребут ноды не сдержит - выше верно подметили).

А "моргание" одиночного сервера - это needrestart дёргает сервисы после апдейта библиотек. Если внезапный рестарт хуже отложенного, переведи его в list-only ($nrconf{restart} = ‘l’) и перезапускай в своё окно.