Hallo.
Ich habe einen Database-Driven Kubernetes Operator entwickelt und möchte ihn den möglicherweise interessierten Leserinnen und Lesern kurz vorstellen.
Lynq ist ein Operator, der Daten, die eine Anwendung bereits in einer DB verwaltet, unverändert nutzt, um Kubernetes-Ressourcen automatisch zu erstellen, zu aktualisieren und aufzuräumen.
(Lynq kann man zwar „Lynk“ lesen, wir sprechen es aber in Anlehnung an Link als „Link“ aus.)
Der Anlass für die Entwicklung war сравнительно einfach.
In einer Situation, in der Informationen wie Umgebungen, Tenants und Nodes alle in der DB lagen,
war es jedes Mal zu zeitaufwendig und umständlich, Änderungen auch nur kleiner Art immer wieder neu zu übernehmen.
Daher kam mir folgender Gedanke:
„Was wirklich mit Git verwaltet werden muss, ist eigentlich nur ein wiederkehrendes Template,
und alles andere sollte nicht einfach automatisch nachziehen, sobald sich die zu provisionierenden Daten ändern?“
Ich habe vieles recherchiert, aber kein zufriedenstellendes Tool gefunden.
Obwohl ich bereits seit mehr als 5–6 Jahren Helm und Terraform nutze, gab es dabei folgende Grenzen:
- Änderungen in der DB konnten nicht sofort aufgegriffen werden,
- es gab kein kontinuierliches Reconcile-Modell, und
- am Ende mussten verschiedene Skripte und Pipelines doch direkt selbst gepflegt werden.
Deshalb habe ich Lynq als Operator gebaut, der diese Anforderungen direkt erfüllt.
Außerdem investiert Lynq viel Arbeit in Visualisierung und Dokumentation, damit es im produktiven Einsatz ohne Missverständnisse betrieben werden kann.
Zum Beispiel lassen sich Visualisierungen zum besseren Verständnis von Erstellung/Löschung/Konflikten auf den folgenden Seiten auf einen Blick ansehen (interaktiv):
=> Policies Docs
=> Dependency Visualizer
Besonders hilfreich scheint es in solchen Fällen zu sein
- Automatische Erstellung von Kunden-/Tenant-Konfigurationen in SaaS-Umgebungen
- Systeme, die Staging-/Preview-Umgebungen in großer Zahl erstellen und ihren Lebenszyklus verwalten müssen
- Architekturen, in denen Ressourcen auch ohne GitOps schnell synchronisiert werden müssen
- Teams, die große Konfigurationen DB-basiert betreiben
- Strukturen, in denen Konfigurationen für mehrere Standorte/Nodes/Sites template-basiert zentral verwaltet werden müssen
Falls jemand die Idee hat „Mit diesem Ansatz könnte man das auch dort einsetzen“
oder konkrete Problemfälle aus eigener Erfahrung kennt, wäre ich für unkompliziertes Feedback sehr dankbar.
Vielen Dank.
Wenn Sie der Quick-Start-Dokumentation folgen, können Sie es problemlos lokal ausführen; eine Installation per Helm ist ebenfalls möglich.
Zusätzlich werden auch Prometheus Rule und Grafana Dashboard JSON für das Monitoring bereitgestellt.
- GitHub Repo: https://github.com/k8s-lynq/lynq
- Docs: https://lynq.sh/
2 Kommentare
Und die Dokumentation haben Sie wirklich unglaublich ausführlich und schön gestaltet.
Vielen Dank, hehe
Da es kaum ähnliche Tools gibt und das Ganze eher ungewohnt ist, achte ich derzeit vor allem darauf, das visuelle Verständnis zu erleichtern.
Falls beim Lesen der Dokumentation dennoch etwas unklar ist oder Konzepte verwirrend wirken, wäre ich dankbar für Feedback dazu, welche Stellen ich verbessern sollte!
Im Moment arbeite ich daran, die Qualität mit einer Live-Demo und E2E-Tests weiter zu erhöhen, also würde ich mich freuen, wenn Sie dranbleiben.