⚖️ Requests vs Limits: Почему твой под тормозит на пустой ноде?

Всем привет! 👋 Сегодня о наболевшем - о ресурсах в Kubernetes.

Я часто вижу манифесты, где секция resources либо отсутствует вовсе ("пусть берет сколько надо"), либо настроена "на глаз". А потом начинаются вопросы: "Почему приложение тупит, хотя CPU загружен на 5%?" или "Почему мой под постоянно убивает OOMKilled?"

Давайте разберем главную ловушку новичка.

1. Requests (Запросы) - Это про "Обещание" 🤝

requests - это то, что Kubernetes гарантирует вашему поду.
Шедулер смотрит на реквесты и ищет ноду, где есть свободное место. Если вы не указали реквесты - K8s считает, что поду ничего не нужно, и может запихнуть его на перегруженную ноду, где он будет страдать.

2. Limits (Лимиты) - это про "Наказание" 👮‍♂️

limits - это верхняя планка. И тут поведение CPU и RAM кардинально отличается.

💀 RAM Limit (Жесткая смерть)
Память - ресурс не сжимаемый. Если приложение съело больше лимита - приходит OOMKiller (Out Of Memory Killer) и пристреливает процесс. Под рестартится.

• Ошибка: Ставить лимит памяти впритык к потреблению Java-хипа. Дайте запас на оверхед!

🐌 CPU Limit (Тормоза / Троттлинг)
CPU - ресурс сжимаемый. Если приложение хочет больше лимита, его не убивают. Его троттлят.
Шедулер просто перестает давать процессу процессорное время на определенные кванты времени.

• Результат: Ваше приложение начинает отвечать не за 50мс, а за 500мс. Ошибок нет, логов нет, но все тормозит.

🔥 QoS Classes: Битва за приоритет

Kubernetes делит все поды на 3 касты (Quality of Service):

1. Guaranteed (Элита) 👑
• requests = limits (и по CPU, и по RAM).
• Эти поды убиваются последними, если на ноде кончается место. Идеально для Баз Данных и критичного прода.


2. Burstable (Средний класс) 💼
• requests < limits.
• Они могут "бурстить" (потреблять больше реквеста), если есть свободные ресурсы. Но если на ноде начнется давка, их начнут выселять первыми. Подходит для большинства веб-сервисов.


3. BestEffort (Бомжи) 🗑
• Ресурсы не указаны вообще.
• Живут "на птичьих правах". При любой нехватке ресурсов на ноде эти поды улетают в небытие первыми. Используйте только для неважных тестовых джобов.


💡Золотое правило настройки

1. Memory: Всегда ставьте Requests == Limits.
• Почему? Чтобы K8s гарантировал вам эту память и не пытался выселить под при нехватке ресурсов на ноде. Это дает класс Guaranteed (по памяти).


2. CPU:
• Requests: Обязательно ставьте честные значения (сколько реально надо при средней нагрузке).
• Limits: Осторожно! Некоторые инженеры вообще не ставят CPU лимиты (или ставят их очень высокими), чтобы избежать троттлинга при резких всплесках трафика. Если нода свободна - пусть приложение забирает всё!


📝 Пример "Надежного" конфига:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"  # 0.25 ядра
  limits:
    memory: "512Mi" # Равно реквесту!
    # cpu: "1000m"  # Можно не ставить или ставить с запасом

Не бойтесь давать памяти с запасом, но бойтесь зажать CPU в тиски.

#k8s #performance #cpu #ram #bestpractices #troubleshooting

Подпишись 👉@devopslib

🥊 Helm vs Kustomize: Вечная битва или идеальный симбиоз?

Салют! 👋

Сегодня затронем тему, из-за которой в курилках девопсов доходит до драки. Как управлять манифестами?

В левом углу ринга - Helm (пакетный менеджер, шаблоны, {{ .Values }}).
В правом углу - Kustomize (оверлеи, патчи, native k8s).

Многие пытаются выбрать один инструмент на всё. И это ошибка. Давайте разберем, где каждый из них король.

⚓️ Helm: Король дистрибуции

Helm - это про упаковку.
Если вы хотите поставить Redis, Prometheus или Ingress-Nginx - вы берете Helm. Почему?

1. Параметризация: Вам не надо знать внутренности чарта, просто переопределите values.yaml.

2. Хуки: Возможность запустить джобу перед установкой (например, миграцию БД).

3. Версионирование: Удобно откатываться (helm rollback).

🔴 Боль: "Template Hell".
Вы когда-нибудь отлаживали чарт на 500 строк с вложенными {{ if }}, циклами range и проблемами с отступами YAML? Это ад. Читать чужой (или свой спустя месяц) Helm-шаблон - больно.

🦎 Kustomize: Король конфигурации

Kustomize - это про вариативность.
Он встроен прямо в kubectl (-k). Идея проста: есть Base (общий манифест) и Overlays (dev, stage, prod), которые накладывают патчи поверх базы.

1. Чистый YAML: Никаких фигурных скобок. Это валидный YAML, который можно проверить линтером.

2. Наглядность: Вы четко видите в папке prod, чем именно он отличается от dev (другой CPU limit, другая репликация).

3. Композиция: Легко собрать приложение из кусков.

🔴 Боль: Нет логики.
В Kustomize нельзя написать if enabled: true. Если вам нужно динамически менять структуру манифеста в зависимости от переменной - придется дублировать код или писать сложные патчи.

💡 Мой рецепт (Best Practice)

Я перестал выбирать и использую гибридный подход.

1. Сторонний софт (Redis, ELK, Cert-Manager) 👉 Helm.
Не изобретайте велосипед. Возьмите готовый чарт, напишите к нему values-prod.yaml и радуйтесь.

2. Свои микросервисы (Internal Apps) 👉 Kustomize.
Для своих приложений шаблоны часто избыточны. У вас меняется только тег образа и Env-vars. Kustomize здесь чище и понятнее разработчикам.

3. Высший пилотаж: Helm + Kustomize.
Есть такая техника: helm template генерит "сырой" манифест, а Kustomize потом патчит то, что в Helm чарте не предусмотрено.

helm template my-chart . | kustomize build . | kubectl apply -f -

Так вы получаете гибкость Helm и точность Kustomize.


#k8s #helm #kustomize #gitops #tools #battle

Подпишись 👉@devopslib