Обновленная версия systemd, архитектура Debian и доступ к Docker Hardened Images (DHI)

👀Новостная среда по расписанию. Выкатываем дайджест с основными событиями за прошедшую неделю.

⏺Релиз systemd 259: что представлено в обновлении
Доступна версия системного менеджера systemd 259, комплексной системы инициализации и управления, скелета современных дистрибутивов Linux. В релиз включена частичная поддержка стандартной библиотеки Musl, альтернативной библиотеки C, опция --empower в run0 для выполнения привилегированных действий без перехода на root, динамическая загрузка зависимостей libsystemd (libacl, libblkid, libseccomp и др.), встроенная работа с TAR в systemd-importd и измененный режим хранения журнала. Подробнее о новой версии читайте в статье или переходите на GitHub.

⏺LoongArch (loong64) в Debian: официальная поддержка архитектуры
Более чем через два года после первоначального запуска в Ports, loong64 стала официальной архитектурой в Debian. Разработчики проекта поделились планами на включение архитектурных особенностей в предстоящий релиз Debian 14 («forky»). Адриан фон Биддер сообщил о сборке и импорте начального набора из 112 пакетов для создания начального chroot-окружения и настройки сборочного сервиса buildd. Подробный комментарий Адриана можно найти здесь, а статус buildd от loong64 тут.

⏺Открыто и бесплатно: DHI под Apache 2.0
На портале The New Stack вышла статья о предоставлении свободного доступа к защищенным образам Docker Hardened Images (DHI). DHI минимизируют риски для поставок на уровне контейнеров. Без root-прав, без лишних компонентов, без уязвимостей – и с поддержкой стандарта VEX. По результатам внутренней статистики Docker Hub фиксирует более 20 миллиардов pull-запросов в месяц. Компания стремится предоставить безопасную, готовую к продакшену платформу и установить новый отраслевой стандарт для разработчиков. Подробности о фичах в статье. А получить доступ к полному каталогу DHI и вариантам подписки можно здесь.

#новостнаясреда #docker #dhi #debian

CPU limits в работе с Kubernetes

💬В одном из недавних постов мы рассмотрели, как объяснить особенности Kubernetes CPU & Memory Requests, Limits по-человечески, сегодня обсудим опыт пользователей Reddit в работе с лимитами в проде. Весь тред можете прочесть здесь.

🗣По результатам опроса, в котором приняло участие 247 человек, ~54% используют CPU limits, но с небольшими оговорками:

ThePapanoob
В вопросе не отражены нюансы. Существует множество кейсов и в некоторых действительно нужно применять CPU limits, в других они только мешают работе

lulzmachine

Обычно начинаю без них, но всегда добавляю позже. Всеми способами избегаю «шумных соседей» (поды или контейнеры, которые

потребляют много ресурсов

и мешают другим подам нормально работать на том же ноде)

Xeroxxx

Да, мы используем лимиты в проде. Requests и Limits устанавливаются одинаково. Для скейлинга используем karpenter.

⏺Чуть меньше половины опрошенных не видит смысла в CPU limits при наличии CPU requests:

romeo_pentium

CPU limits становится причиной троттлинга и неиспользованных CPU. Мы всегда можем работать с CPU requests. Преимущество в том, что контейнер не будет использовать CPU request другого контейнера.
Linux kernel троттлит ваш CPU по мере его приближения к лимиту.
Без лимитов производительность выше, и я не нашел преимуществ в их установке.

Ariquitaun

CPU limits обычно приводят к снижению производительности. Нам нужны только CPU requests для гарантии базового уровня производительности на проде.
С памятью дела обстоят по-другому – ООМ приведет к прекращению рабочих нагрузок в самое неподходящее время, а иногда к «убийству» нодов.

th0th

Я преимущественно использую requests, limits очень редко. Я предпочитаю следить за фактическим использованием и обвновлять request по необходимости.
У меня установлены алерты на превышение CPU в нодах, использовании памяти. Мне кажется, безопаснее опираться на систему оповещений, чем на последствия использования лимитов, по типу троттлинга.

Какой алгоритм работы в проде используете вы и ваши коллеги? Делитесь опытом в комментариях👀

#kubernetes #cpu #cpu_limits #cpu_requests