Давно хотела попробовать реализовать управляемый через GitOps мультиоблачный control plane с использованием Crossplane.
🍀 Основная идея 🍀
Управляющий кластер (gke-mgmt) запускает Crossplane, который непрерывно сверяет желаемое состояние, описанное в Git, с реальным состоянием в облаке. Добавили YAML-файл с описанием базы данных, закоммитили — Crossplane её создаёт. Удалили файл — он её уничтожает. Никаких ручных apply и никакого рассинхрона между тем, что задокументировано, и тем, что реально работает.
За GitOps отвечает FluxCD; Crossplane обрабатывает вызовы к API облачных провайдеров; OpenBao хранит секреты, которые синхронизируются в кластере через External Secrets Operator.
Для Crossplane существуют провайдеры практически для всех облаков (AWS, Azure и другие), провайдеры для Helm и Kubernetes. «Мультиоблачность» означает единый декларативный шаблон, которому неважно, где именно находится конечная точка API.
🍀 Два типа репозиториев🍀
Код инфраструктуры и код приложений живут в разных репозиториях с разным жизненным циклом. За инфраструктуру отвечают три репозитория: один для слоя бутстрапа (Terraform), один для GitOps-состояния управляющего кластера и по одному на каждый рабочий кластер (workload cluster).
Всё остальное — сами приложения, работающие поверх этой системы — живет в собственных репозиториях со своими CI-пайплайнами. Они собирают и публикуют Docker-образы, которые инфраструктурный слой подхватывает автоматически через автоматизацию images во Flux. Изменения в инфраструктуре и деплой приложений никогда не пересекаются в одном Pull Request, и каждый репозиторий имеет ровно тот уровень доступа, который ему необходим — ничего лишнего.
🍀 Terraform всё ещё нужен на первом этапе 🍀
Crossplane должно где-то исполняться в Kubernetes-кластере, который должен быть чем-то создан. Итоговая архитектура представляет собой двухслойную развертку:
- Terraform (как пример) создаёт управляющий кластер, базовые связи IAM/OIDC и ключи KMS — ту часть инфраструктуры, которая меняется редко и требует участия человека.
- Crossplane, работая внутри этого кластера, берет на себя всё остальное: дополнительные рабочие кластеры (в том числе в других облаках), управляемые базы данных, бакеты хранилища и т.д.
Вы можете ставить управляющий кластер на паузу, когда не занимаетесь активными изменениями инфраструктуры. Созданные рабочие кластера, экземпляры Cloud SQL, бакеты в Object Storage — не зависят от работоспособности Crossplane. Его можно запустить, когда вам нужна сверка состояний, исправление рассинхронизаций или создание новых ресурсов.
Но пока он на паузе, автоисправление не работает, замена секретов приостанавливается. Экономит бюджет, но скорее при личном использовании или небольших проектов.
🍀🍀🍀🍀🍀🍀🍀🍀🍀
#Мультиоблачность#DevOps#GitOps#IaC