Capstone: деплой — это цепочка, а авария живёт в стыке

Все блоки в диаграмме релиза были зелёными. Образ собрался и запушился. K8s-Deployment применился без ошибок. Rolling update отрапортовал успех за 40 секунд. И тут запищал пейджер: 30% запросов отдают 502 две минуты. Никто не выкатил баг. Образ был в порядке, манифест в порядке, миграция в порядке — по отдельности. У Deployment не было readinessProbe, поэтому k8s объявлял каждый новый под «готовым» в тот миг, когда стартовал процесс контейнера, ещё до того, как приложение открыло пул к БД. Rolling update послушно перенаправил трафик на поды, которые были живыми, но ещё не обслуживали. Авария не жила ни в одной стадии. Она жила в стыке между двумя верными.

Пайплайн — это один собранный объект, а не семь шагов

Весь трек деплоя шёл по одной стадии за раз: собрать лёгкий multi-stage образ, запушить в реестр, объявить k8s-объекты, выбрать стратегию раскатки, поставить перед сервисом балансировщик, инжектить секреты, закодировать всё как infrastructure-as-code. Озарение capstone в том, что ни одна из этих стадий сама по себе не выкатывает софт. Релиз — это композиция всех их, а у композиции есть эмерджентные режимы отказа, которые не ловят тесты ни одной отдельной стадии.

Думай об этом как о цепочке, где каждое звено передаёт артефакт следующему:

Каждая колонка «стык» — это реальная авария, которую кто-то выкатил. Каждая предполагает, что предыдущая стадия отработала — и всё равно сломалась, потому что контракт между стадиями никто не проверял.

Health-чеки — это клей между «запущен» и «обслуживает»

Самый несущий кусок клея — readiness-проба, потому что она задаёт контракт, на который опирается раскатка. Вся работа rolling update такая: поднять новый под, дождаться, пока он готов, затем погасить старый, по maxUnavailable за раз. Слово «готов» делает тут гигантскую работу. Без readinessProbe k8s рапортует под готовым в тот миг, когда стартовал главный процесс контейнера, — а это до того, как прогрелась JVM, открылся пул соединений, прогрелись кэши. Rolling update видит зелёное, добавляет под в эндпоинты Service, и трафик льётся в процесс, который отдаёт 502 / connection-refused.

Фикс — проба, которая реально дёргает зависимости, плюс surge-арифметика, которая никогда не падает ниже ёмкости:

readinessProbe:
  httpGet: { path: /healthz/ready, port: 8080 }
  initialDelaySeconds: 5
  periodSeconds: 5
strategy:
  rollingUpdate:
    maxUnavailable: 0   # никогда ниже желаемого числа реплик
    maxSurge: 1         # добавить новый под до удаления старого

Две пробы делают две разные работы, и их смешение — отдельная авария. Проба readiness управляет трафиком — провалил её, и под убирают из Service, но оставляют работать. Проба liveness управляет рестартами — провалил её, и kubelet убивает и пересоздаёт контейнер. Заведи медленную зависимость (флапающую БД) в liveness-пробу — и получишь шторм рестартов: каждый под, который не достучался до БД, убивают, что делает проблему БД хуже, а не лучше. Liveness должна проверять «я в дедлоке?», а не «весь ли мой мир здоров?».

Стратегия раскатки и миграция — это одно решение

Самый дорогой стык во всей цепочке — между стратегией раскатки и базой данных, потому что флип балансировщика обратим, а изменение схемы обычно нет. Представь blue-green деплой: blue live, green — новая версия, ты флипаешь LB и мгновенно откатываешься, если green ведёт себя плохо. Теперь допустим, релиз green «прибрал» схему — удалил колонку, которую blue всё ещё читает. Флип проходит, green обслуживает нормально. Потом green кидает ошибку, и ты откатываешься на blue — и blue немедленно 500-ит на каждом запросе, потому что нужной колонки больше нет. Твой «мгновенный откат» теперь односторонняя авария.

Дисциплина, которая делает раскатку и миграцию композируемыми, — expand-contract (он же «parallel change»): никогда не выкатывай изменение схемы, несовместимое с кодом, который сейчас работает. Ты разбиваешь одно логическое изменение на отдельные деплои, каждый держит N-1 совместимость (новая схема работает со старым кодом и наоборот):

1. Expand — добавь новую колонку/таблицу; оставь старую. Обе версии работают.
2. Migrate — перелей данные в новую форму; пиши из приложения в обе (dual-write).
3. Contract — только после того, как весь трафик на новом коде, удали старую колонку. Отдельный, более поздний деплой.

Цена реальна: переименование колонки, которое «должно» быть одной миграцией, становится тремя деплоями, размазанными по релизам, плюс dual-write код, который надо не забыть удалить. Выигрыш в том, что любое промежуточное состояние безопасно для отката, поэтому твоя стратегия раскатки сохраняет обратимость, которую обещала.

Draining и observability замыкают цепочку

Даже с пробами и безопасными миграциями cutover может убить запросы, которые уже были в полёте. Когда под завершается, k8s убирает его из эндпоинтов Service и шлёт SIGTERM — но эти два события гоняются, и LB может ещё пару мгновений роутить запросы на умирающий под. L7-балансировщик умеет draining: перестаёт слать новые запросы и ждёт настраиваемый таймаут (хороший дефолт — 1.5–2× твоего p99 времени запроса), пока завершатся те, что в полёте. Наивная L4-схема, которая просто рвёт на уровне соединения, может оборвать запрос посреди ответа. Сторона приложения обязана сотрудничать: ловить SIGTERM, перестать принимать новую работу, доделать запросы в полёте, затем выйти — всё внутри terminationGracePeriodSeconds (дефолт 30s), с preStop-паузой, чтобы покрыть гонку с удалением эндпоинта.

И единственная причина, по которой ты узнал, что авария readiness-пробы в Hook была про 502, а не про «успех», — это observability. Exit-код раскатки говорит, что манифест применился; он не говорит про error rate, p99 latency или saturation на новых подах. Несущий сигнал — сравнение golden-метрик новой версии с baseline старой во время раскатки — ровно то, что canary делает автоматически: сдвинуть 5% трафика, понаблюдать error rate и latency пару минут, продвинуть или авто-откатить по метрике, а не по возвращаемому значению команды деплоя.