Типы и Архетипы

[мысли] reconciliation loop или один из лучших паттернов в инфраструктурных системах Как-то мне довелось писать reconcilation loop для того, что управлять инфраструктурными системами и, мне кажется, что это идеальный паттерн в таких случаях, особенно если мы говорим про "production-grade" масштабируемые системы. Традиционная request-response модель тут работает достаточно плохо, потому что реальность не синхронная, например, узел может быть недоступен, агент может применить конфиг, но не успеть обновить статус, сеть может разделиться, процесс может умереть между "почти сделал" и "успел сохранить статус". Т.е. класс модели "request-response" имеет слишком бедную онтологию и не учитывает реальные проблемы и состояния системы, которая управляет инфраструктурой. Его применение в некоторых случаях, связанных с управлением инфраструктурой, может быть таким же архитектурным преступлением, как и CORBA https://t.me/types_and_archetypes/34. И вот в таких случаях reconciliation loop оказывается, на мой взгляд, одним из самых правильных. Его идея очень простая: у системы есть desired state - то, как мир должен выглядеть, и actual state - то, как он выглядит сейчас. Контроллер снова и снова смотрит на разницу между желаемым и фактическим состоянием и делает следующий шаг во внутренней стейт машине, пока система не сойдется. Именно в этом, как мне кажется, и состоит настоящая техническая сила Kubernetes, т.е. это не в YAML, не в контейнеры и даже не в оркестрации как таковой, а в том, что вся модель построена вокруг вот такой сходимости. Почему это так хорошо работает? Во-первых, reconciliation loop естественно переживает сбои. Если контроллер упал, ничего страшного: он поднимется, снова посмотрит на мир и продолжит. Если агент не ответил, задача просто осталась в состоянии, из которого можно продолжить. Если кто-то руками поменял конфигурацию на хосте, это а drift, который можно обнаружить и исправить. Во-вторых, этот паттерн очень хорошо сочетается с идемпотентностью. Повторный запуск движка сравнения не создаёт новый стейт или новые состояния, он должен доводить текущий стей до нужной формы. В-третьих, reconciliation loop отлично дисциплинирует архитектуру. Как только эта модель принимается всерьёз, то приходится уже чётко разделять: - что пользователь хочет - что контроллер уже увидел - что реально применено - что только запланировано - и что делать при удалении или откате Отсюда появляются очень понятные и правильные вещи: спецификации, статусы, генерации, инварианты, стейт машины и прочее-прочее. Это делает систему не только надежнее, но и гораздо понятнее в эксплуатации. В-четвёртых, такой паттерн даёт хорошее масштабирование и более строгие инварианты. Но у паттерна есть и минусы: Главный минус в том, что reconciliation loop сложнее, чем условный CRUD. Намного сильнее сложнее. Нужно думать о стейт машинах, о повторных попытках, о статусах и так далее. Второй минус - eventual consistency. Для инженера это нормально, а для пользователя или продакт-логики уже сложновато. Третий важный минус - его легко сделать декоративным. Очень многие системы копируют внешнюю форму кубера: ресурсы, статусы, контроллеры, но не забирают суть. Если в модели нет четкого desired state, нет наблюдаемого actual state, нет идемпотентных действий и нет повторяемого reconcile, то это не reconcilation loop-модель, а какой-то просто более запутанный бекенд. Итог Reconciliation loop особенно хорош там, где система управляет внешними, ненадежными, медленными или частично наблюдаемыми сущностями. Кластеры, виртуальные машины, сетевые туннели, DNS, сертификаты - его естественная среда. Этот паттерн позволяет точнее описать операционную реальность такой, какая она есть: с лагами, сбоями, гонками, повторными попытками и частичной наблюдаемостью. И вместо того чтобы бороться с этой реальностью или заметать её под порог, он делает все эти проблемы first-class citizens, заставляя работать и думать про них. Это и делает reconciliation loop по-настоящему сильным для инфраструктурных задач.