Телеграм канал «Devops Bootcamp с Федосеевым»

У StatefulSet 7 реплик, а PDB задан как minAvailable: 50%. Сколько подов можно добровольно выселить одновременно?

У StatefulSet 7 реплик, а PDB задан как minAvailable: 50%. Сколько подов можно добровольно выселить одновременно?

Коллеги, приветствую! 👋

Рекомендую обратить внимание на новый интенсив Слёрма «n8n для DevOps: AI-ассистент за 3 недели».

⏩Коротко: 3 недели по 2–3 часа в день, 8 воркфлоу в репозитории. Поднимаете self-hosted n8n в Docker, строите пайплайны с триггерами и ветвлением, вызываете LLM со структурированным выводом, готовите воркфлоу к продакшену: секреты, ретраи, лимиты.

Для старта опыт с n8n не требуется.

🔴Полезно DevOps/SRE и сисадминам - автоматизировать алерты, проверки деплоя и рутину через API и вебхуки.
🔴Разработчикам и тимлидам - понять, где нужен агент, а где достаточно обычного IF.

⏩УЗНАТЬ ПОДРОБНОСТИ

«У вас что-то с кубером»

Коллеги всем привет👋🏻
Расскажу сегодня случай про обращение с проблемой:

Как обычно, вечер. У внешней команды установка релиза и он падает с ошибкой. Коллеги приходят с ошибкой и просят решить проблему. Релиз на их тестовых кластерах установился без проблем.

⏩В логах — отказ при создании роли из pre-upgrade hook. Примерно такой:
Error: UPGRADE FAILED: pre-upgrade hooks failed: warning: Hook pre-upgrade templates/reload-config.yml failed:roles.rbac.authorization.k8s.io "release-hook" is forbidden:
user "release-user" is attempting to grant RBAC permissions not currently held:
На первый взгляд всё очевидно: пользователю не хватает прав. Нужно поправить RBAC, выдать доступ и продолжить релиз.

Но сначала стоит спросить: а права на что именно мы собираемся выдавать?

⏩Открываем репозиторий, находим нужный продовый тег и смотрим что там применяется.
В списке нормальных обьектов, в чарте затаился интересный момент
- apiGroups: ["apps"]
resources: ["deployments/rollout", "deployments/status"]
⏩У стандартного Deployment нет подресурса rollout. Есть команда kubectl rollout, но это не одноимённый подресурс Kubernetes. В чарт попала правдоподобная, но несуществующая сущность — deployments/rollout.

Вероятно этот фрагмент написал ИИ. А результат не проверили.
А почему тогда на другом кластере работало?

⏩Потому что тестировали под администратором. Вот как выглядит проверка полномочий под cluster-admin — даже для выдуманных подресурсов:
$ kubectl auth can-i get deployments.apps --subresource=rollout -n production
yes
$ kubectl auth can-i get deployments.apps --subresource=shit -n production
yes
⏩Это иллюстративный вывод для учётной записи с cluster-admin, а не проверка существования этих подресурсов. Команда can-i отвечает на вопрос «разрешено ли мне такое действие?», а не «существует ли такой API?». Поэтому администратор получает yes даже для выдуманных названий

⏩При этом запись в RBAC не подтверждает существование указанного API-ресурса. Администратор может сохранить роль с deployments/rollout, но новый подресурс от этого не появится. В конфигурации просто останется бессмысленное правило.

⏩В продовом кластере RBAC был настроен корректно: установщик имел ограниченные полномочия и не мог выдавать разрешения, которыми сам не обладал.

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

⏩Выдать больше прав — значит заставить установку пройти, не исправив дефект.

ИИ удобно использовать в DevOps: он быстро собирает YAML, шаблоны и скрипты. Но правдоподобная конфигурация ещё не означает рабочую.

Существуют ли волшебные флаги?

Коллеги всех приветствую👋

Возникла задача копировать S3-бакеты. С небольшим количеством файлов всё нормально — справляется без проблем. Но когда файлов сотни миллионов, начинается боль.

🔴Исходные данные: несколько терабайт, средний размер файла 10–15 КБ, общее количество файлов 300–400+ миллионов. Доступной оперативной памяти 256–512 ГБ. Ожидаемая скорость хотя бы 50–100 МБ/с. Реальная скорость 1–2 МБ/с.

В чём проблема:
--fast-list — это флаг rclone, который загружает весь список объектов в память сразу, а потом начинает передачу.

🔴С --fast-list: память = N_объектов × 1 КБ. Для 400 млн файлов: 400 000 000 × 1 КБ = ~381 ГБ. Вывод: не укладывается в доступную память → rclone падает по OOM.

🔴Без --fast-list: rclone обрабатывает по одной папке (префиксу) за раз. Память = N_файловвкрупнейшей_папке × 1 КБ. Если крупнейшая папка = 5 млн файлов: 5 000 000 × 1 КБ = ~4.8 ГБ. НО: каждый файл = отдельный LIST + PUT запрос к S3.

Почему всё равно медленно:
Проблема не в нагруженности API, а в том, что запросов физически много. rclone упирается не в пропускную способность сети, а в количество операций, которые нужно выполнить. Каждый файл требует LIST (получить метаданные), HEAD (проверить mtime/size), PUT (загрузить файл), проверку destination. Итого ~4 API-вызова на файл × 400 млн = 1.6 млрд запросов.

Даже если S3-провайдер не режет rate limits и API не перегружен, просто физическое время на выполнение 1.6 млрд запросов при 1000–3000 запросов/сек даёт 6–18 дней только на запросы.

Как подобрать параметры transfers и checkers:
transfers и checkers — самые важные параметры копирования. Чтобы подобрать их правильно, нужно посчитать потребление памяти.
⏩transfers — сколько файлов копируется параллельно. Каждый transfer занимает buffer_size памяти (по умолчанию 16 МБ). Формула: transfers × buffer_size. Например, 256 × 16 МБ = ~4 ГБ.
⏩checkers — сколько файлов проверяется параллельно (сравнивает метаданные source и destination). Каждый checker держит в памяти ~1000 файлов по 1 МБ на файл. Формула: checkers × 1000 × 1 МБ. Например, 256 × 1000 × 1 МБ = ~250 ГБ.

🔴Парадокс с настройками transfers и checkers:
НО: это всё имеет смысл только с --fast-list. Без --fast-list rclone работает так медленно, что память вообще не утилизируется. Можно выставить transfers 256, checkers 256, но реальная скорость будет 1–2 МБ/с из-за количества S3-запросов.

🔴Получается замкнутый круг: с --fast-list нужно 381 ГБ памяти для 400 млн файлов (столько памяти может не быть), без --fast-list память не нужна, но скорость падает в 50–100 раз, потому что каждый файл = отдельный запрос.

➡️Выводы: --fast-list обязателен для миллионов файлов, но требует огромной памяти (~1 КБ на объект). Для 400 млн файлов это уже ~381 ГБ, что превышает типичные лимиты памяти. Без --fast-list rclone упирается в количество операций S3 — каждый файл = отдельный запрос. Оптимизация параметров (transfers, checkers, buffer-size) не даёт эффекта — бутылочное горлышко в количестве запросов, а не в rclone. Единственное решение: разбивать на префиксы и запускать параллельно несколько процессов

➡️Итог: сотни миллионов мелких файлов = ад для любого S3-клиента. rclone не виноват — это ограничение архитектуры S3 API, где каждый файл требует отдельного запроса.

P.S. Если кто сталкивался с такой же проблемой — поделитесь опытом, как решали? Может, есть волшебный флаг или сервис, который это умеет? Или скажите какую еще проблему я не учел, которая будет проблемой при такой большой переливке?

Жду ваши ответы в комментариях👇

Коллеги, приветствую👋

Курс «Профессия DevOps-инженер» уже стартовал🔥

В закрытом чате уже активно идёт знакомство: участники из разных компаний, городов и даже стран общаются, делятся опытом, обсуждают CI/CD, кластеры и автоматизацию.

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

Начать погружение в курс можно бесплатно)

➡️ ПРИСОЕДИНИТЬСЯ ПО ССЫЛКЕ