Lynq - opérateur d’automatisation Kubernetes piloté par la base de données

Bonjour.
J’ai développé un Database-Driven Kubernetes Operator et je souhaitais le présenter à celles et ceux qui pourraient être intéressés.

Lynq est un opérateur qui utilise directement les données déjà gérées par une application dans une base de données pour créer, mettre à jour et nettoyer automatiquement des ressources Kubernetes.
(Lynq peut se lire « Lynq », mais comme le nom vient de Link, nous le prononçons « Link ».)

L’origine du projet est assez simple.
Dans une situation où toutes les informations sur les environnements, les tenants ou les nœuds se trouvent dans la base de données,
le fait de devoir tout réappliquer à chaque moindre changement prenait trop de temps et était trop contraignant.

D’où cette idée :

« En réalité, ce qui doit être géré avec Git peut se limiter à un seul template répétitif,
et tout le reste ne pourrait-il pas simplement suivre automatiquement dès que les données à provisionner changent ? »

J’ai mené pas mal de recherches, mais je n’ai pas trouvé d’outil vraiment satisfaisant.
J’utilisais déjà Helm et Terraform depuis plus de 5 à 6 ans, mais ils présentaient les limites suivantes :

• ils ne réagissent pas immédiatement aux changements dans la base de données ;
• ils n’ont pas de modèle de reconcile continu ;
• au final, il fallait quand même maintenir soi-même divers scripts et pipelines.

C’est pour répondre exactement à ce besoin que j’ai créé Lynq sous la forme d’un opérateur.

Par ailleurs, Lynq accorde beaucoup d’importance à la visualisation et à la documentation afin de pouvoir être exploité en production sans ambiguïté.
Par exemple, vous pouvez voir en un coup d’œil des visualisations interactives facilitant la compréhension de la création, de la suppression, des conflits, etc., sur les pages ci-dessous :
=> Policies Docs
=> Dependency Visualizer

---

Cas où cela peut être particulièrement utile

• génération automatique de configurations client/tenant dans un environnement SaaS ;
• systèmes où il faut créer en masse des environnements de staging/prévisualisation et en gérer le cycle de vie ;
• architectures où les ressources doivent être synchronisées rapidement même sans GitOps ;
• équipes qui exploitent des configurations à grande échelle sur une base pilotée par la base de données ;
• structures où les configurations de plusieurs points, nœuds ou sites doivent être gérées de façon centralisée à l’aide de templates.

Si cette approche vous donne des idées du type « cela pourrait aussi servir dans tel cas »,
ou si vous avez vous-même rencontré ce genre de problème, vos retours me seraient très utiles.

Merci.

---

En suivant la documentation Quick Start, vous pouvez facilement l’exécuter en local, et l’installation via Helm est également possible.
En complément, des Prometheus Rule et un Grafana Dashboard JSON pour le monitoring sont aussi fournis.

• GitHub Repo: https://github.com/k8s-lynq/lynq
• Docs: https://lynq.sh/

[atobaum]

Et la documentation a été réalisée de manière extrêmement détaillée et soignée.

[selene]

Merci haha
Comme il existe très peu d’outils similaires et que le concept peut sembler peu familier, je m’efforce avant tout d’aider à la compréhension visuelle.
Si, même en consultant la documentation, certains points restent difficiles à comprendre ou si certains concepts vous paraissent confus, je vous serais reconnaissant de me faire part de vos retours sur ce qui pourrait être amélioré !

En ce moment, je travaille à améliorer le niveau de finition avec une démo en direct et la rédaction de tests E2E, donc merci de continuer à suivre le projet.