Kubernetes CPU & Memory Requests/Limits – объясняем по-человечески

В Kubernetes YAML разделы requests и limits задают минимальные и максимальные ресурсы пода, и их неверная настройка может вызвать троттлинг CPU, OOMKill и принудительное удаление пода с узла при высоких нагрузках. Грамотная конфигурация этих параметров необходима для корректного шедулинга подов и поддержания стабильности кластера. В статье автор использует сравнение Kubernetes с отелем для наглядного объяснения.

👩‍💻Kubernetes можно представить как отель:
Под = гость отеля
Узел = здание отеля с ограниченным количеством ресурсов

⏺Каждому «гостю» нужно указать:
1. Requests – минимальные ресурсы, необходимые для корректной работы
2. Limits – максимальные ресурсы, которые под может потреблять

⏺Какая роль здесь отведена CPU?
• Request – гарантированное количество CPU, влияет на планирование, но не ограничивая максимум. Под может использовать больше CPU при наличии свободных ресурсов.
• Limit задаёт жёсткое ограничение на потребление CPU. Превышение лимита приводит к троттлингу.

Итак: request = минимальное количество электричества для работы 💡; limit = предел, который выдержит предохранитель ⚡️.

⏺Как настроить requests/limits в Kubernetes

Шаг 1: Измеряем среднее и пиковое потребление CPU/памяти (kubectl top pod, Prometheus/Grafana).

Шаг 2: Requests = Среднее × 1.2 → гарантируем стабильную работу без троттлинга.

Шаг 3: Limits = Пик × 1.3–1.5 → оставляем запас, чтобы под не падал из-за OOM.

⏺Что еще необходимо помнить при задании ресурсов приложению: QoS

Quality of Service (QoS) – это механизм, с помощью которого Kubernetes классифицирует Pods по уровню гарантии ресурсов на основе заданных requests и limits.

• Guaranteed Pods
Под получает строго равные значения request и limit для CPU и памяти. Kubernetes гарантирует, что Pod не будет уничтожен до тех пор, пока не превысит свои лимиты или не будут доступны приоритетные Pods.
• Burstable Pods
Могут использовать ресурсы сверх request при свободных ресурсах узла, но при давлении на узел они уничтожаются после Guaranteed и чаще получают OOMKill.
• BestEffort
Самый низкий уровень QoS: присваивается, если у Pod‑а нет ни requests, ни limits для CPU и памяти. Такие Pods используют остаточные ресурсов узла, и в случае дефицита именно они будут удалены первыми.

🚀Понимание и правильная настройка параметров requests и limits позволяет избежать непредвиденных завершений подов и поддерживать стабильность работы кластера.

#k8s #requests #limits #cpu

Обновленная версия 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

🛡Безопасность в Docker: SBOM и выявление уязвимостей

Сегодня разбираем, как обеспечить безопасность цепочки поставок в Docker на примере практического гайда Shamsher Khan: Advanced Docker Security: From Supply Chain Transparency to Network Defense. Подробно разберем обеспечение прозрачности цепочки поставок с помощью SBOM, спецификации ПО (Lab 07), а подробнее об установке эшелонированной защиты от DDoS и ботов (Lab 08) можете прочесть здесь.

👀Почему тема важна в сообществе?
• В 2021 инцидент с Log4Shell, ошибкой в библиотеке Log4j, указал на большую проблему современной разработки – незнание состава контейнеров.
• Кибератака SolarWinds произошла в том же году, что инцидент выше.

⏺В статье представлены две лабы, задеплоить можно уже сегодня:
1. Обеспечение прозрачности цепочки поставок с помощью SBOM (Lab 07)
2. Эшелонированная защита от DDoS и ботов (Lab 08)

💬Обеспечиваем безопасность цепочки поставок со SBOM (Lab 07)
Рассмотрим Dockerfile:

FROM python:3.11-slim 
COPY requirements.txt . 
RUN pip install -r requirements.txt 
COPY app.py . CMD ["python", "app.py"]

Вопрос знатокам: какие пакеты в этом образе? Без SBOM мы можем догадаться: e.g. Python 3.11, requirements.txt и OS уязвимости.
SBOM позволяет получить полный список всех компонентов, версий и лицензий, сгенерированный за секунды.

🚀На старт, внимание, SBOM
В статье представлен демо-скрипт для выполнения с последовательностью из 12-ти шагов.

💬Шаг 1: установка инструментов.

# Install Syft (SBOM generation) 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 

# Install Grype (vulnerability scanning) 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 

# Verify installation 
syft version grype version

💬Шаг 2: установка SBOM

From a Docker image
syft nginx:alpine -o spdx-json > nginx-sbom.json

# From a directory
syft dir:./myapp -o cyclonedx-json > myapp-sbom.json

# Multiple formats at once
syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json

💬Шаг 3: выявляем уязвимости

# Scan the SBOM
grype sbom:./nginx-sbom.json

# Or scan image directly
grype nginx:alpine

💬Шаг 4: сравниваем версии SBOM

# Generate SBOMs for two versions
syft myapp:v1.0 -o json > v1.0-sbom.json
syft myapp:v2.0 -o json > v2.0-sbom.json

# Compare (using provided noscript)
./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json



💬Шаг 5: выявляем уязвимости в SBOM

# Scan the SBOM
grype sbom:./nginx-sbom.spdx.json

# Or scan image directly
grype nginx:alpine

💬Шаг 6: определяем типы уязвимостей по параметрам

# Only show CRITICAL and HIGH
grype nginx:alpine --fail-on high

# Only show CRITICAL
grype nginx:alpine --fail-on critical

# Show only specific severity
grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")'

# Export vulnerabilities to JSON
grype nginx:alpine -o json > vulnerabilities.json

В шагах 7 и 8 сравниваем версии SBOM и ищем конкретные пакеты, а в 9 – рассматривает отчёт/журнал SBOM

💬Финальный шаг, 12: интеграция в CI/CD (Azure DevOps)

azure-pipeline.yml

- task: Docker@2
  inputs:
    command: build
    dockerfile: '**/Dockerfile'
    tags: $(Build.BuildId)

- noscript: |
    syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json
  displayName: 'Generate SBOM'

- noscript: |
    grype sbom:./sbom.json --fail-on high
  displayName: 'Scan for Vulnerabilities'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'sbom.json'
    artifactName: 'SBOM'

👨‍💻В результате, скорость реагирования при обнаружении уязвимостей сокращается с 14 до 2 дней, осуществляется поддержка 3-х форматов (SPDX, CycloneDX, Syft JSON) и гарантируется полное соответствие требованиям – EO 14028.

👩‍💻Делимся репозиториями:
• Syft – установка SBOM
• Grype – выявление уязвимостей
• Docker Security Practical Guide – полный гайд с Lab 07 и Lab 08

#devsecops #SBOM #zerotrust #kubernetes

Как DDoS повлиял на Arch Linux и что нового в релизах Kitty Terminal, Angie?

Последний новостной дайджест… в этом году. Что приготовили обновления последних дней 2025-го?

⏺Arch Linux и DDoS атаки: доступ по IPv6
Arch Linux временно отключил доступ к web-сервисам на домене archlinux.org по IPv4 в ответ на DDoS-атаку. Cайт остаётся доступным по IPv6, и сервисы AUR, Wiki, форум и GitLab продолжают работать. Если основным репозиториям недоступен доступ по IPv4, рекомендуем переключиться на зеркала, перечисленные в pacman-mirrorlist, чтобы продолжить обновления и установки. Подробнее о статусе можете прочесть здесь ,больше о доступе найдете в треде.

⏺Kitty Terminal 0.45 – стабильность и расширенные возможности превью
Состоялся релиз терминала Kitty 0.45. Многофункциональная версия, с поддержкой опции GPU‑accelerated, кроссплатформенного эмулятора ориентирована на стабильность. Исходный код проекта написан на Python, C и Go и опубликован на GitHub под лицензией GNU General Public License v3.0. В версии 0.45 представили опцию choose-files для выбора файлов с интерфейсом, ориентированным на клавиатуру, и поддержкой предварительного просмотра содержимого. Новая версия решения в значительной степени ориентирована на стабильность, в ней исправлены ранее найденные некритичные ошибки. Подробнее читайте здесь.

⏺Веб-сервер Angie 1.11.0, созданный бывшей командой Nginx
24 декабря 2025 года разработчики из компании «Веб-Сервер» выпустили веб-сервер Angie 1.11.0. Форк Nginx получил сертификаты совместимости с российскими ОС «Ред ОС», Astra Linux Special Edition, «Роса Хром Сервер», «Альт» и «ФСТЭК‑версии Альт». В Angie 1.11.0 команда сосредоточилась на observability и надёжности: появился новый модуль метрик для сбора и агрегации в реальном времени с выходом в Prometheus/JSON, что упрощает детекторинг узких мест; параллельно решены проблемы с HTTP/3 и улучшена маршрутизация QUIC через BPF-доработки, а также расширена поддержка ACME (включая ALPN и отчёт о перевыпуске сертификатов в API/Prometheus), что делает работу с TLS более предсказуемой. Подробнее о релизе читайте здесь или в обзоре.

#archlinux #ipv6 #linux #kittyterminal

Дед Мороз заглянул в DevOps FM...

Чтобы поздравить подписчиков с наступающим Новым годом!🎄Как снегурочки-администраторы мы благодарим вас за участие в обсуждениях, пересылки гайдов (и не только) коллегам, внесение правок и коррективов в посты о штурвалах и кораблях 👩‍💻 И говорим спасибо за то, что вы есть!

В 2026 году желаем спокойных смен, реализации самых смелых идей и движения вперёд к поставленным целям!

В качестве благодарности за вашу активность, продолжаем традицию дарить открытки. Если возникнет желание порадовать коллегу в офисе, версия для печати – здесь.

⏺А чтобы было чем заняться на январских, подготовили подборку постов за 2025:
•Использование скрытых каталогов Unix
•Слышали про bundle-uri в Git?
•Стратегии по disaster recovery с Terraform
•Как подготовиться к облачным инцидентам: рассказали подробнее
•Выбор in-memory БД в 2025: Redis, Valkey, DragonflyDB и KeyDB
•Логирование и мониторинг — топ-3 инструмента для DevOps в 2025
•От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

С наступающим Новым годом и до встречи в 2025+1👩‍💻

🖖Всем DevOps! Новогодние салаты кончаются, салюты отгремели, а исполнение желаний требует сил и планирования...с Новым 2026 годом!🎄

Самое время порадоваться успехам ушедшего года и задуматься, как избежать ошибок в новом. Рекомендуем провести базовый аудит, рассмотреть пути карьерного роста и повышение квалификации. Все эти шаги помогут, если проблемы возникли в работе инженера или разработчика, а не менеджера, куратора, pm-а.

По результатам опроса коллег из State of DevOps, среднее количество задач на технического сотрудника выросло с 3,76 до 4,15. Жаль, не был замечен рост зарплаты... А если серьезно, на рабочем месте инженер всё больше и швец, и жнец, и на игре дудец. Помимо повышенной нагрузки возникают и другие проблемы. В крупных компаниях все действия и бездействия приходится согласовывать, а в компаниях малого и среднего бизнеса – брать больше задач и обучать джунов. Свои плюсы и минусы есть везде, но как выбрать из двух зол?

👨‍💻Если вы всё ещё в раздумьях, в какой компании можно развить компетенции и не умереть в 2026, пройдите наш тест "Я был рождён, чтобы работать в...", а в комментариях делитесь результатами.

Узнайте, где комфортно работать – тут.

P.S. для C-level и владельцев бизнесов: спасибо за ваш труд, тест – развлекательный, с юмором и стереотипами. Предлагаем поделиться мыслями в комментариях💬