Библиотека девопса | DevOps, SRE, Sysadmin

🔥 DevOps-антипаттерны, которые мешают вашей инфраструктуре

DevOps — это не только про автоматизацию, но и про культуру. Однако некоторые решения и привычки могут привести к хаосу. Давайте разберем топ антипаттернов, которые могут испортить вашу инфраструктуру.

🔹 Хрупкая инфраструктура
Вы выкатываете изменения в прод без тестов, мониторинга и резервных копий? Поздравляю, у вас хрупкая инфраструктура, которая рухнет при первом же сбое.

🔹 Один DevOps-инженер на все задачи
"У нас есть DevOps, он все делает". Такой подход быстро приводит к выгоранию и техническому долгу. DevOps — это культура, а не человек.

🔹 Отсутствие IaC (Infrastructure as Code)
Если вы настраиваете серверы руками, вы уже проиграли. Terraform, Ansible, Pulumi — вот ваши лучшие друзья.

🔹 Логирование в "черную дыру"
Вы собираете логи, но никто их не смотрит? Или, что еще хуже, нет нормального логирования? Тогда успехов в поиске багов "на ощупь".

🔹 "Работает — не трогай"
Этот принцип может убить ваш прод. Обновления закрывают уязвимости, повышают стабильность и улучшают производительность. Если у вас все еще Kubernetes 1.18 или Ubuntu 16.04 — пора задуматься.

🔹 CI/CD с кучей ручных шагов
Если ваш деплой требует 10 шагов в Confluence и ручного одобрения от трех человек, это не CI/CD, а боль. Автоматизируйте!

🚀 Что делать?
Пересмотрите свою инфраструктуру, уберите устаревшие практики и не допускайте этих ошибок. DevOps — про эффективность, а не про героизм в 3 часа ночи.

🔥 DevOps-антипаттерны, которые мешают вашей инфраструктуре

DevOps — это не только про автоматизацию, но и про культуру. Однако некоторые решения и привычки могут привести к хаосу. Давайте разберем топ антипаттернов, которые могут испортить вашу инфраструктуру.

🔹 Хрупкая инфраструктура
Вы выкатываете изменения в прод без тестов, мониторинга и резервных копий? Поздравляю, у вас хрупкая инфраструктура, которая рухнет при первом же сбое.

🔹 Один DevOps-инженер на все задачи
"У нас есть DevOps, он все делает". Такой подход быстро приводит к выгоранию и техническому долгу. DevOps — это культура, а не человек.

🔹 Отсутствие IaC (Infrastructure as Code)
Если вы настраиваете серверы руками, вы уже проиграли. Terraform, Ansible, Pulumi — вот ваши лучшие друзья.

🔹 Логирование в "черную дыру"
Вы собираете логи, но никто их не смотрит? Или, что еще хуже, нет нормального логирования? Тогда успехов в поиске багов "на ощупь".

🔹 "Работает — не трогай"
Этот принцип может убить ваш прод. Обновления закрывают уязвимости, повышают стабильность и улучшают производительность. Если у вас все еще Kubernetes 1.18 или Ubuntu 16.04 — пора задуматься.

🔹 CI/CD с кучей ручных шагов
Если ваш деплой требует 10 шагов в Confluence и ручного одобрения от трех человек, это не CI/CD, а боль. Автоматизируйте!

🚀 Что делать?
Пересмотрите свою инфраструктуру, уберите устаревшие практики и не допускайте этих ошибок. DevOps — про эффективность, а не про героизм в 3 часа ночи.

📲 Мы в MAX

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

🔹Как DevOps может ускорить CI/CD?

Каждый DevOps-инженер рано или поздно сталкивается с проблемами долгих сборок и развертываний. Чем больше микросервисов, тем сложнее их быстро катить в прод. Давай разберем ключевые методы ускорения CI/CD!

🚀 Кэширование артефактов
Используй кэш для зависимостей и промежуточных сборок. Например, в GitHub Actions можно хранить кэш NPM-модулей или Docker-образов.

⚡ Параллельные джобы
Запускай тесты и сборки в параллель, если твой CI/CD позволяет. Например, в GitLab CI можно указать parallel: 4, чтобы запустить 4 одинаковых джобы.

🐳 Оптимизация Docker-образов
1. Правильный порядок команд в Dockerfile – сначала COPY package.json и RUN npm install, потом сам код.
2. Меньше слоев – объединяй команды RUN через &&.
3. Используй легковесные базовые образы – Alpine вместо Debian.

🔄 Incremental Builds
Используй механизмы buildx в Docker и Bazel для сборки только измененных частей кода. Это снижает нагрузку на CI/CD.

🌍 Локальные runner'ы
Если GitHub Actions или GitLab CI тормозят из-за облачных ресурсов, разворачивай self-hosted runners. Это особенно полезно для проектов с высокой нагрузкой на CI.

📊 Мониторинг CI/CD
Включай метрики (Prometheus + Grafana) и анализируй узкие места пайплайна. Иногда проблема – не в коде, а в ресурсах билд-агентов.

📲 Мы в MAX

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

🔥 Как мониторить логи в реальном времени?

Мониторинг логов в реальном времени — одна из важнейших задач DevOps-инженера. Если сервис падает или выдаёт ошибки, нужно быстро понять, что произошло. Давайте разберём несколько инструментов, которые помогут оперативно анализировать логи.

🔹 tail -f и less +F
Классика UNIX. tail -f позволяет следить за последними строками лога, а less +F даёт возможность как мониторить в реальном времени, так и быстро пролистывать вверх для анализа.

🔹 multitail
Продвинутый вариант tail -f, который позволяет следить за несколькими логами одновременно в одном терминале.

🔹 journalctl -f
Если у вас systemd, используйте journalctl -f -u <service> для слежения за логами конкретного сервиса.

🔹 lnav
Очень мощный CLI-инструмент для логов с синтаксическим разбором, цветовой разметкой и возможностью фильтрации.

🔹 Grafana Loki + Promtail
Если нужен централизованный сбор и визуализация логов, то связка Loki + Promtail отлично подойдёт. Loki индексирует метаданные логов, а Promtail забирает их с серверов.

🔹 ELK (Elasticsearch + Logstash + Kibana)
Если нужно что-то мощнее и удобнее для анализа, то ELK-стек — отличный вариант. Kibana позволяет гибко фильтровать и строить дашборды по логам.

🔹 Vector
Современная альтернатива Logstash и Fluentd, очень эффективен для передачи логов в S3, Kafka, Elasticsearch и другие хранилища.

🔹 Sentry и New Relic
Если нужна агрегация логов и ошибок приложений, используйте Sentry или New Relic. Они позволяют быстро находить проблемные места в коде.

📲 Мы в MAX

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

🚀 Зачем DevOps инженеру уметь писать код?

Часто можно услышать мнение, что DevOps — это про инфраструктуру, пайплайны и кубер, а кодить должны разработчики. Но на практике хороший DevOps инженер неизбежно сталкивается с кодом и скриптингом. Почему это важно?

🔹 Автоматизация всего
Ручные операции = баги и потери времени. Написание CI/CD пайплайнов, автоматизация деплоя, инфраструктура как код (IaC) — все это требует хорошего знания Python, Bash, Go или даже Ruby.

🔹 Глубокое понимание приложений
Если ты можешь прочитать код, понять его логику, то тебе проще решать проблемы в продакшене. Debugging, логирование, мониторинг — все это связано с кодом.

🔹 Эффективный troubleshooting
Зачастую DevOps инженер — первый, к кому приходят с проблемами продакшена. Понимание кода помогает быстро локализовать ошибки, а не просто перезапускать контейнеры в надежде, что "само пройдет".

🔹 Разработка внутренних инструментов
Часто приходится писать собственные тулзы: CLI утилиты, API сервисы для инфраструктуры, кастомные плагины для Kubernetes, Terraform или Ansible.

🔹 Общение с разработчиками
Если ты говоришь с разработчиками на одном языке (и в прямом, и в переносном смысле), то взаимодействие между командами становится более продуктивным.

💡 Вывод: кодинг — это не просто полезный навык, а must-have для современного DevOps. Если еще не кодишь — самое время начать!

📲 Мы в MAX

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

🔥 Kubernetes: Как уменьшить время старта подов? 🔥

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

🚀 1. Используйте лёгкие образы
Выбирайте образы с минимальным количеством зависимостей. Вместо ubuntu:latest лучше взять alpine или distroless.

⚡ 2. Настройте readinessProbe и livenessProbe
Некорректные пробки могут заставить Kubernetes перезапускать поды или считать их неготовыми дольше, чем нужно. Используйте их осознанно.

🎯 3. Предзагружайте образы (Image Pull Policy)
Если ваши поды используют публичные образы, включите ImagePullPolicy: IfNotPresent или Never, чтобы не скачивать образ при каждом старте.

containers:
  - name: app
    image: my-registry/app:latest
    imagePullPolicy: IfNotPresent

💾 4. Используйте InitContainers для подготовки окружения
Если поду требуется что-то до старта (например, миграции БД), лучше использовать InitContainers, чтобы основное приложение стартовало быстрее.

📦 5. Настройте ресурсы
Ограничения CPU и памяти (requests и limits) могут повлиять на скорость старта пода. Если ресурсов мало, контейнеру придётся ждать, пока Kubernetes выделит ему место.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

🏎 6. Используйте preStopHook для graceful shutdown
Чтобы уменьшить задержки при перезапуске подов, обрабатывайте завершение работы приложения через preStopHook.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 5"]

🔄 7. Включите startupProbe для долгозапускающихся сервисов
Если приложение стартует долго, лучше использовать startupProbe, чтобы Kubernetes не убивал его раньше времени.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

📲 Мы в MAX

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

🚀 GitOps: революция в управлении инфраструктурой

GitOps — это подход к управлению инфраструктурой и развертыванию приложений, основанный на использовании Git как единственного источника правды. Все изменения проходят через pull request'ы, что дает прозрачность, контроль версий и автоматизацию.

🔹 Как это работает?
1️⃣ Вся конфигурация хранится в Git-репозитории.
2️⃣ Изменения происходят через коммиты и pull request'ы.
3️⃣ Автоматические агенты (ArgoCD, FluxCD) следят за репозиторием и применяют изменения в кластер.

🔹 Преимущества GitOps:
✅ Полная история изменений — легко откатиться назад.
✅ Автоматизация CI/CD — минимум ручной работы.
✅ Единая точка правды — все изменения в Git.
✅ Повышенная безопасность — политика pull request'ов предотвращает случайные ошибки.

🔹 Лучшие инструменты для GitOps:
🔸 ArgoCD — мощный инструмент с UI для визуального управления деплоями.
🔸 FluxCD — легковесное решение, полностью интегрируемое с Kubernetes.
🔸 Terraform + GitHub Actions — для инфраструктуры как кода.

GitOps — это не просто хайп, а будущее управления инфраструктурой! А ты уже внедрил его в проде?

📲 Мы в MAX

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

🔹 DevOps: секреты работы с Terraform State 🔹

Terraform — мощный инструмент для управления инфраструктурой, но работа с его state-файлом требует особого внимания. Сегодня разберем, как правильно управлять состоянием и избегать проблем.

🚀 Основные проблемы с Terraform State
1️⃣ State-файл локально – потеряешь файл = потеряешь инфраструктуру.
2️⃣ Конфликты изменений – если несколько людей работают с одним state-файлом, возможны проблемы.
3️⃣ Частичная поломка state – если во время apply что-то пойдет не так, можно остаться с "битым" состоянием.

🔧 Как правильно работать с state?
✔️ Храни state в удаленном бекенде (S3 + DynamoDB, GCS, Azure Blob) – это защитит от потерь.
✔️ Включай блокировку state – например, DynamoDB table предотвратит конфликты.
✔️ Используй команды terraform state – они помогут править state без лишних apply.
✔️ Настрой шифрование – если хранишь state в облаке, включай AES-256.
✔️ Разделяй стейты по окружениям – лучше иметь отдельные файлы для dev, staging, prod.

⚠️ Лайфхак: как восстановить state?
Если state поврежден, попробуй:
🔹 terraform state pull > backup.tfstate – сохранить текущий state.
🔹 terraform import – добавить ресурсы вручную.
🔹 terraform refresh – попытаться синхронизировать текущее состояние с реальными ресурсами.

💡 Привычка правильно работать с Terraform State спасет тебе кучу нервов!

📲 Мы в MAX

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

Как мониторить сервер без Prometheus?

Не всегда есть возможность поднять полноценный стек мониторинга, особенно если нужно быстро проверить состояние сервера. В таких случаях можно обойтись стандартными утилитами Linux.

🔥 1. Нагрузка на процессор

top -o %CPU
htop

top покажет общую картину, htop— более детализированную с цветами.

🔥 2. Использование памяти

free -h
vmstat -s

Команда free -h выведет статистику по RAM в удобном виде.

🔥 3. Диск и файловая система

df -h
du -sh /var/log

Если место пропадает загадочным образом, du -sh /path поможет найти, куда оно ушло.

🔥 4. Сетевые соединения

netstat -tulnp
ss -tulnp

Хотите узнать, какие процессы слушают порты? ss -tulnp поможет.

🔥 5. Нагрузка на дисковую систему

iostat -dx 1
iotop

Если сервер тормозит, а CPU не загружен — возможно, виноват диск.

🔥 6. Логи в реальном времени

tail -f /var/log/syslog
journalctl -f

Полезно для отладки проблем в режиме реального времени.

Эти команды помогут быстро оценить состояние сервера без лишних сложностей. А какие утилиты используешь ты? Делись в комментариях!

📲 Мы в MAX

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

🔥 Как не попасть в ад Kubernetes? 🔥

Все любят Kubernetes, пока он не начинает тащить вас в бездну бесконечных YAML-файлов и неожиданных фейлов. Держи чек-лист, чтобы не превратить кластер в хаос:

✅ RBAC с первого дня – без ограничений все контейнеры вдруг получают суперспособности (и это не круто). Разграничивай доступ сразу!

✅ Readiness & Liveness Probes – не будь тем, кто деплоит сервис без проверки его живучести. Без этих проб — гарантированные проблемы с балансировкой.

✅ Resource Requests & Limits – хочешь, чтобы один под сожрал все CPU и мем? Нет? Тогда ставь лимиты!

✅ Поднимай мониторинг раньше, чем тебе понадобится – Prometheus, Grafana, Loki… Не жди, пока что-то сломается.

✅ Network Policies – не будь дырявым – если не ограничить трафик, твои поды будут общаться как захотят. Взломать такой кластер проще простого.

✅ Backup etcd – всегда! – потеря etcd = потеря всего. Делай бэкапы, иначе одна ошибка и привет, восстановление с нуля.

✅ Автоматизируй деплои и GitOps – ручные правки в манифестах — путь к страданиям. ArgoCD, FluxCD в помощь!

📌 Kubernetes – мощь, но без дисциплины он превращается в боль. Делай всё с умом!

📲 Мы в MAX

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

Как DevOps-у не сгореть на работе? 🔥🚒

DevOps — это бесконечный поток задач, инцидентов и улучшений. Но если постоянно тушить пожары и не заботиться о себе, можно быстро перегореть. Как этого избежать?

1️⃣ Автоматизируй всё, что можно
Если ты делаешь одну и ту же рутину более двух раз — это кандидат на автоматизацию. Bash-скрипты, Ansible, Terraform, GitHub Actions — твои лучшие друзья.

2️⃣ Логи и мониторинг – твой щит 🛡️
Не жди звонка в 3 ночи из-за того, что прод лег. Настрой Prometheus + Grafana, Loki, ELK или OpenTelemetry. Ставь алерты заранее, чтобы проблемы решались до того, как их заметит бизнес.

3️⃣ Не будь "героем", работай в команде 🤝
Нет ничего хуже, чем быть единственным, кто знает, как работает инфраструктура. Делегируй, пиши документацию, проводи knowledge-sharing сессии.

4️⃣ Баланс между работой и жизнью 🌿
Если ты постоянно на связи 24/7, это путь в никуда. Разделяй работу и личную жизнь. Учись говорить «нет» и отдыхать без чувства вины.

5️⃣ Следи за трендами, но не будь их рабом
Kubernetes, Istio, eBPF, AI в DevOps — технологии меняются быстро, но не надо бежать за каждым хайпом. Оценивай их пользу для своего проекта, прежде чем внедрять.

Береги себя, DevOps! И помни: лучший DevOps — это отдохнувший DevOps. 😉


📲 Мы в MAX

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

🔥 Kubernetes vs Docker Compose: Что выбрать? 🔥

Когда приходит время управлять контейнерами, многие задаются вопросом: использовать Docker Compose или Kubernetes? Разбираемся!

🚀 Docker Compose
✅ Простота развертывания — один YAML-файл, одна команда docker-compose up.
✅ Идеально подходит для локальной разработки и тестирования.
✅ Быстрый старт без сложных конфигураций.
❌ Не поддерживает автоматическое масштабирование и самовосстановление контейнеров.
❌ Ограниченные возможности оркестрации.

🏗️ Kubernetes
✅ Масштабируемость и отказоустойчивость из коробки.
✅ Автоматическое управление состоянием контейнеров (перезапуск, балансировка нагрузки).
✅ Гибкость за счет Helm, CRD и сложных политик.
❌ Сложность в настройке и сопровождении.
❌ Требует значительных ресурсов.

💡 Вывод
👉 Docker Compose — лучший вариант для разработки и небольших проектов.
👉 Kubernetes — когда нужна продакшен-инфраструктура, масштабирование и высокая доступность.

📲 Мы в MAX

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

Как проверить, что твои бэкапы не просто занимают место?

Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?

🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.

🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.

🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.

🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.

🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.

Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!

📲 Мы в MAX

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

🔍Тестовое собеседование с Head of DevOps уже завтра

18 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.

Как это будет:
📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Александру

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot

Реклама.
О рекламодателе.

💡 Когда docker system prune спасает твой диск... но не всё так просто

Все мы знаем, что Docker любит кушать диск. Особенно, если часто собирать образы, поднимать временные контейнеры или играться с volume'ами. Рано или поздно ты ловишь No space left on device, и начинается пляска с du -sh * в /var/lib/docker.

И вот тут на сцену выходит герой — docker system prune.

docker system prune -a --volumes

🔪 Удалит всё:

* остановленные контейнеры
* неиспользуемые образы
* все dangling volume'ы
* неиспользуемые networks

Но вот в чём засада: он удалит и то, что тебе может быть нужно. Например, образы, которые не используются сейчас, но могут быть нужны через 5 минут.

⚠️ Советы по выживанию:

* Перед запуском — проверь, что ты точно хочешь всё вычистить.
* Если нужны только образы без volume'ов — не добавляй --volumes.
* Лучше сначала посмотреть, что будет удалено:

docker system df

или

docker images --filter dangling=true

🧼 А ещё можно настроить регулярную очистку через cron или systemd timers, но аккуратно — лучше вручную, чем потерять нужное.

📲 Мы в MAX

Подпишись 👉@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

⚖️ 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

🛑 Не убивай меня сразу! Настраиваем Graceful Shutdown

Коллеги, бывало такое? Вы делаете kubectl rollout restart, Kubernetes обещает бесшовное обновление, но в момент переключения подов пару юзеров все равно ловят 502 Bad Gateway или обрывы соединений.

Проблема часто не в балансировщике, а в том, что ваше приложение не умеет "красиво уходить" (Graceful Shutdown).

Когда Kubernetes хочет остановить под, происходит следующий танец:

1. K8s посылает процессу сигнал SIGTERM.
2. K8s ждет terminationGracePeriodSeconds (по дефолту 30 сек).
3. Если процесс еще жив -прилетает SIGKILL (выстрел в голову).

❌ Как делают новички

Приложение получает SIGTERM и... мгновенно закрывается.

🔘Результат: Все запросы, которые обрабатывались в эту миллисекунду (транзакция в БД, загрузка файла), обрываются. Клиент получает ошибку.

✅ Как надо (Уровень Code)

Приложение должно перехватывать SIGTERM.
Получив сигнал, оно должно:

1. Перестать принимать новые соединения.
2. Дождаться завершения текущих запросов.
3. Закрыть коннекты к БД/очередям.
4. Выйти (exit 0).

💀 Скрытая проблема Kubernetes (Race Condition)

Даже если ваш код идеален, вы все равно можете словить 502.
Почему?
В тот момент, когда K8s посылает SIGTERM, он параллельно начинает удалять IP пода из Endpoints (Service).
Это асинхронный процесс. Может случиться так, что Ingress Controller все еще шлет трафик на под, а приложение уже получило SIGTERM и закрыло порт.

💊 Решение: "The Sleep Hack"
Как бы глупо это ни звучало, но best practice в мире K8s - это вставить небольшую паузу перед остановкой.

Мы используем preStop хук. Он выполняется ДО отправки SIGTERM.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 5"]

Что это дает?

1. K8s запускает хук: sleep 5.
2. Под помечается как Terminating.
3. За эти 5 секунд Ingress/Service успевают обновить свои таблицы маршрутизации и перестают слать новый трафик на этот под.
4. sleep заканчивается -> летит SIGTERM -> приложение спокойно доделывает старые запросы -> Profit! 🚀

⚙️ Чек-лист для идеального деплоя:

1. В коде обработан SIGTERM.
2. В K8s добавлен preStop хук со слипом (5-10 сек).
3. terminationGracePeriodSeconds выставлен с запасом (напр. 60 сек, если у вас долгие запросы), чтобы SIGKILL не прилетел слишком рано.

Уважайте своих пользователей, не сбрасывайте их сессии посередине оплаты! 😉

#k8s #devops #architecture #go #python #bestpractices

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

🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?

Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).

Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская.

Разберем две крайности и как делать правильно.

❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)

Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.

🔘Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода.

🔘Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки.

🔘Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса.

❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)

Вы решили быть умными и в /health эндпоинт засунули проверку коннекта к Базе, Редису и S3.

🔘Сценарий: База данных немного приуныла (медленные запросы).

🔘Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать.

🔘Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself.

✅ Как делать правильно: Liveness vs Readiness

В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.

1. Liveness Probe (Я жив?)

🔘Цель: Понять, не завис ли процесс намертво.
🔘Действие при сбое: РЕСТАРТ контейнера.
🔘Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться.


2. Readiness Probe (Я готов работать?)

🔘Цель: Понять, можно ли пускать на меня трафик.
🔘Действие при сбое: УБРАТЬ из балансировки (не убивать!).
🔘Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров.



📝 Пример (K8s Manifest):

livenessProbe:
  httpGet:
    path: /health/live # Максимально тупой ответ 200 OK
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready # Проверка БД, очередей и т.д.
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

💡 Главный совет

Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он Ready, или отдавать ошибку юзеру, оставаясь "живым".

#k8s #devops #fails #stability #bestpractices

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

🐳 Хватит тащить curl и vim в продакшн! (Используем Ephemeral Containers)

Салют, коллеги, всех с прошедшими праздниками! 👋

Сколько раз я видел Dockerfile, который начинается за здравие (FROM alpine), а заканчивается установкой половины интернета: apk add curl vim net-tools bind-tools...?

Аргумент всегда один: "Ну мне же надо как-то дебажить, если под отвалится!"

В итоге мы получаем:

1. Раздутый образ. (Платим за сторадж и трафик).
2. Дыру в безопасности. (Хакер, попавший в контейнер, скажет спасибо за curl и nmap, любезно оставленные вами).

Правильный путь - это Distroless образы или минимальный Alpine, где нет даже шелла. А для дебага мы используем Ephemeral Containers (эфемерные контейнеры).

🛠 Как это работает?

В Kubernetes (начиная с v1.25 это уже стабильная фича) вы можете "подселить" временный контейнер в работающий Pod. Он будет делить с подом пространство имен процессов (PID) и иногда сети, но файловая система у него будет своя.

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

🔥 Практика: kubectl debug

Допустим, у вас есть "глухой" под my-app, в котором нет ничего, кроме бинарника приложения. Вам нужно проверить сеть.

Вместо того чтобы пересобирать образ, делаем так:

kubectl debug -it my-app \
  --image=nicolaka/netshoot \
  --target=my-app-container

Разберем магию:

🔘 --image=nicolaka/netshoot: Мой любимый образ для траблшутинга. Там есть ВСЁ: tcpdump, curl, dig, iperf, mtr.
🔘 --target: Указываем, к какому контейнеру в поде подключиться (важно, чтобы видеть процессы друг друга).

Теперь вы внутри пода, но со швейцарским ножом в руках. Проверили коннект до базы, сняли дамп трафика, вышли и эфемерный контейнер исчез. Чисто, красиво, секьюрно. 🛡

💡 А если я не в K8s?

Если вы сидите на чистом Docker, похожий трюк делается через --pid и --network:

docker run -it --rm \
  --network container:my-prod-container \
  --pid container:my-prod-container \
  nicolaka/netshoot

Итог: Перестаньте бояться Distroless образов. Инструментарий для внешнего дебага уже давно вырос.

💬 А какой у вас любимый тул-кит для дебага сети? Пишите в комменты! 👇

#k8s #docker #security #tips #debug

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

Одна из самых недооценённых вещей в DevOps - подготовленные сценарии отказов.

Большинство инцидентов выглядят одинаково:

💚 02:37 ночи
💚 CPU 100%, latency растёт
💚 кто-то пишет «у нас всё легло?»
💚 начинается хаотичный SSH-тур по серверам

Проблема не в том, что система упала.
Проблема - никто не знает, что делать дальше.

Что реально спасает

Runbook, но не «для галочки».

Хороший runbook - это:

✅ конкретный триггер (какой алерт)
✅ чёткая цель (что восстановить)
✅ пошаговые действия (без “разберись по ситуации”)
✅ команды, ссылки, контакты
✅ критерий «инцидент закрыт»

Плохой runbook:

💕 «Проверь логи»
💕 «Перезапусти сервис»
💕 «Если не помогло - эскалируй»

Практика

Если runbook:

💕 не обновлялся после последнего инцидента - его не существует
💕 не может выполнить дежурный без автора - он бесполезен
💕 не проверялся в рабочее время - ночью он не сработает

Минимальный лайфхак

После каждого падения:

1. открой runbook
2. зафиксируй, где было непонятно
3. допиши одну строку

Через 5 инцидентов у тебя будет документ, который реально работает.

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