DevOps для ДевоПсов

Как перенести сервис Kubernetes из default без простоя Десятки сервисов обращаются к auth-svc.default.svc.cluster.local, поэтому синхронно обновить их нельзя. Разверните Deployment и Service в authentication, а Service в default замените на ExternalName: старое DNS-имя разрешится в новое. Метод не работает с жёстко заданным IP или ClusterIP. Проверяйте два маршрута отдельно. Для внутреннего трафика подтвердите по метрикам переход запросов на новый Deployment, затем уменьшите число старых подов до нуля для быстрого отката. Для внешнего временно разрешите два одинаковых Ingress, проверьте новый, удалите старый и снимите исключение из политики. В разборе Cloud Native Computing Foundation есть YAML и порядок в dev, staging и production.

Как перенести метрики на OpenTelemetry без массовой переделки сервисов Atlassian сохранила прежний контракт: приложения продолжили отправлять StatsD-метрики по UDP, а платформенная команда заменила сбор, приём, агрегацию и пересылку данных на собственные сборки OpenTelemetry Collector. Сборщик одновременно принимал StatsD и OTLP, поэтому команды могли менять инструментирование постепенно. Замена двух сайдкаров одним снизила среднюю загрузку CPU на 3,9% у самых дорогих сервисов Micros. Маршрутизация по идентификатору временного ряда распределила крупные сервисы между шардами, а новая агрегация сократила потребление CPU этого уровня примерно вдвое. Практический порядок: начинайте с dev- и staging-сред, непрерывно профилируйте под рабочей нагрузкой и раскатывайте по схеме 1% → 10% → 50% → 100%. Архитектура и выводы собраны в разборе миграции в блоге Cloud Native Computing Foundation.

Как RFC 9234 защищает от утечек BGP-маршрутов Настройте BGP Role на каждой eBGP-сессии по отношению с соседом: customer, provider или peer; для точек обмена есть RS и RS-client. Если обе стороны объявят несовместимые роли, сессия не установится. Атрибут Only to Customer (OTC) отмечает маршрут, который дальше можно передавать только клиентам. Совместимый маршрутизатор не объявит его провайдеру или пиру, а маршрут с OTC от клиента отклонит как утечку. В разборе Cloudflare Blog объяснены механизм и ограничения внедрения. При частичном внедрении не включайте строгий режим: он отклоняет соседей без BGP Role. Если с одним соседом совмещены разные отношения, разнесите их по отдельным eBGP-сессиям и назначьте каждой свою роль.

Как масштабировать GPU-нагрузки в Kubernetes до всплеска трафика Реактивный HPA может опоздать: в описанном инциденте порог сработал в 06:05, а первые GPU-ноды были готовы лишь в 06:45. К тому времени всплеск закончился, а пользователи увидели 15–20% ошибок. Авторы разобрали предиктивный контроллер для Kubernetes. Каждые 60 секунд он анализирует час метрик Prometheus, прогнозирует нагрузку на 10 минут вперёд и добавляет не более 20 подов в минуту. Отдельный детектор ускоряет масштабирование, если фактический спрос превысил прогноз. В теневом режиме 85% прогнозов уложились в отклонение ±10%, а детектор поймал 9 из 10 всплесков. Для проверки подхода соберите неделю метрик, неделю запускайте прогноз без масштабирования, затем задайте предел реплик и выключатель контроллера. HPA v2 можно оставить как реактивную страховку.

Защитите PostgreSQL 18 от забытых слотов репликации В PostgreSQL 18 появился idle_replication_slot_timeout. Он инвалидирует неактивный слот после заданного срока, чтобы тот не удерживал WAL до заполнения диска. По умолчанию стоит 0: защита выключена. Начните с 3d и оставьте запас дольше планового простоя потребителя. Проверка выполняется при checkpoint, поэтому слот может прожить ещё до checkpoint_timeout. Перезапуск сервера сбрасывает отсчёт. Параметр не удаляет слот: логическую подписку придётся синхронизировать заново, а физической реплике понадобится архив WAL или пересборка. Используйте его вместе с max_slot_wal_keep_size и настройте алерт на возраст inactive_since. В разборе параметра объяснены исключения и цена инвалидации.

Как сократить ожидание в GitLab CI с помощью дочерних пайплайнов и needs В монорепозитории полный прогон заставляет задания ждать несвязанные сборки и тесты. Вынесите конфигурации сервисов в дочерний пайплайн, а в родительском запуске добавьте strategy: depend: он дождётся дочерних заданий и вернёт общий результат. Несколько файлов в одном trigger: include GitLab объединяет в одну конфигурацию. Поэтому задания из этих файлов видят друг друга и могут через needs запускаться сразу после своих зависимостей, не ожидая завершения всей стадии. Отдельные trigger-задания создадут изолированные пайплайны, где такие связи не работают. В конфигурации из статьи выбор по изменённым файлам не настроен. Если нужен выборочный запуск сервисов, добавьте собственные правила изменений; пример используйте для организации дочернего пайплайна и зависимостей.