Три слоя без пересечений
Инфраструктура, сервисы, край площадки. Правило нулевого перекрытия между ними — не эстетика, а способ понять, кто виноват, когда что-то сломалось.
Инструмент делит инфраструктуру на три слоя: инфраструктура, сервисы, край. И задаёт между ними правило нулевого перекрытия — каждый объект принадлежит ровно одному слою.
Правило выглядит бюрократическим. Оно решает конкретную проблему: понять, кто владеет объектом, когда объект сломался.
Слой инфраструктуры
Машины, сети, кластеры, тома. То, что предоставляет облако или железо.
Владелец на производственном треке — Cluster API. Инструмент оркестрирует, но жизненным циклом ресурса управляет оператор в кластере, и состояние живёт в etcd.
Слой сервисов
Всё, что работает в кластере: приложения, базы, вспомогательные компоненты.
Владелец — ArgoCD. Инструмент не делает установку в кластер напрямую: он пишет желаемое состояние в репозиторий, коммитит и отправляет канонический GitOps-источник, после чего применяет ArgoCD.
Это принципиально. Команда установки приложения не означает «поставить сейчас», она означает «записать, что оно должно быть». Разница видна в момент, когда кто-то удалит приложение из кластера руками: слой сервисов вернёт его обратно, потому что владелец — репозиторий.
Слой края
Физическая площадка: устройства, кабели, порты, питание, слаботочка, зоны, шкафы.
У этого слоя другая природа. Он не «применяется» — он описывается, проверяется и экспортируется. Опасные живые действия здесь заблокированы до появления доказанного бэкенда, модели полномочий, резервного копирования и откатной процедуры.
Почему перекрытие запрещено
Представьте объект, который принадлежит и слою инфраструктуры, и слою сервисов. Тогда у него два владельца с правом приводить его к своему представлению о желаемом состоянии.
Дальше начинается борьба сверок: один владелец меняет, другой возвращает, оба считают себя правыми. Симптом со стороны — объект «мигает», и разбирательство занимает дни, потому что каждый слой по отдельности ведёт себя корректно.
Правило нулевого перекрытия убирает этот класс отказов конструктивно.
Что делать, когда объект похож на два слоя
Такое бывает. Балансировщик — это инфраструктура или сервис. Секрет — это сервис или край.
Ответ всегда один: выбрать слой и записать выбор в описание проекта. Не «зависит от контекста» и не «оба». Владелец должен быть определён до того, как объект появился, а не в момент разбирательства.
Практическое следствие: часть решений при заведении проекта неприятны, потому что требуют определённости там, где хочется гибкости. Это та же цена, что и у требования git, и платится она в том же месте — на старте.
Как это связано с журналом
Раз у каждого объекта один владелец, у каждого изменения один источник. Журнал аудита собирается из нескольких мест — записи инструмента, история git, состояние кластера, — но запрос к нему единый, и в нём нет двух конкурирующих версий события.
Без правила слоёв единый журнал был бы невозможен: пришлось бы объяснять, почему один и тот же объект изменялся дважды разными системами в одну секунду.