Капстоун: mini-PaaS — реестр, сборка, run, здоровье и zero-downtime раскат

Пять стадий как один конвейер

Прежде чем читать пять контрактов ниже, замети, чем был инцидент из Hook на самом деле: не одной упущенной фичей, а упущенной композицией. Каждый контракт по отдельности выглядел приемлемым; вместе им не хватало того единственного, что делает остальные осмысленными.

Всё в этом юните — стадия одной машины. Минимальная продовая платформа — твой mini-PaaS — это композиция пяти контрактов, каждый из которых проваливает другие, если неверен.

1 · Реестр — неизменяемость. Реестр — источник истины для артефактов, и его единственное непреложное правило: деплои ссылаются по неизменяемому digest, а не по мутабельному тегу. myapp:latest можно перезаписать; myapp@sha256:9f2c... — нет: тот же digest всегда тянет ровно те же байты. Пинуй digest в деплой-манифесте — и откат по-настоящему возвращает к известно-хорошему коду, два пода никогда не разойдутся в том, что значит latest, а image-pull воспроизводим по узлам и времени. Теги — удобные ярлыки для людей; digest’ы — контракт для машин.

2 · Сборка — тонкая и воспроизводимая. Multi-stage сборка (из урока про утоньшение) компилирует в тулчейн-стадии и отгружает distroless-артефакт ~25 МБ, так что новая версия тянется на холодные узлы за ~2 с во время раската вместо его застопоривания на 90 с. Сборка пинована (база по digest, зависимости по lock-файлу), так что digest детерминирован — тот же исходник даёт тот же образ.

3 · Run — ограниченные ресурсы. Каждый контейнер бежит с лимитом памяти (из урока про OOM), так что один плохой релиз не может OOM-уронить узел и убрать другую версию посреди раската, плюс cgroup-aware цель рантайма (GOMEMLIMIT / MaxRAMPercentage), так что рантайм держится под стеной. Ограниченные ресурсы — то, что делает безопасным гонять старую и новую версии бок о бок во время раската.

4 · Здоровье — честное гейтирование. Readiness-проба, гоняющая реальный запрос (из урока про здоровье), гейтит трафик: новый под не получает запросов, пока по-настоящему не готов, а больной под сливается. Это сигнал, которого ждёт контроллер раската — без честной readiness «раскат завершён» это ложь, и трафик бьёт в под, что не может обслужить.

Раскат — композиция в zero downtime

Пятый контракт — rolling-деплой, и он работает лишь потому, что держатся четыре других. Rolling-обновление заменяет поды инкрементально под двумя ручками: maxUnavailable (сколько существующих подов могут быть недоступны разом — ставь низко, напр. 0 или 25%, чтобы сохранить ёмкость) и maxSurge (сколько лишних подов можно создать сверх желаемого числа, напр. 25%, чтобы добавить ёмкость новой версии до удаления старой).

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0      # никогда не падать ниже желаемой ёмкости
    maxSurge: 1            # поднять один новый под до вывода старого

Последовательность связывает весь трек. Контроллер создаёт новый под из пинованного по digest тонкого образа (стадии 1–2); он тянется за ~2 с и стартует под своим лимитом памяти (стадия 3); контроллер ждёт прохождения честной readiness-пробы нового пода до отправки ему трафика (стадия 4); и лишь тогда завершает старый под, который гонит свой цикл preStop → SIGTERM → слив (из урока про здоровье), так что его запросы в полёте завершаются; и повторяет, пока каждый под не станет новой версией — с maxUnavailable: 0 ёмкость никогда не проседает, а с честной readiness трафик никогда не приземляется на не-готовый под. Убери любой контракт — и раскат ломается: мутабельный тег делает откат ненадёжным, жирный образ застопоривает surge, отсутствующий лимит памяти даёт новой версии OOM-уронить узел с старой, нечестная проба маршрутизирует трафик на мёртвый под, а отсутствующий preStop теряет запросы в полёте выводимых подов. В этом урок всего юнита: продовые контейнеры — не пять независимых лучших практик, а один конвейер, где каждая стадия несущая для следующей.