Couchbase décompose son opérateur Kubernetes pour affiner la gestion des clusters

Casser l’aspect monolithique de l’opérateur

À déployer via Helm, l’Autonomous Operator complète l’API Kubernetes et est associé avec un registre nommé CRD (Custom Resource Definition) pour effectuer les tâches citées ci-dessus. La version 2.0 disponible en bêta introduit une nouvelle manière de gérer les ressources personnalisées. Depuis Autonomous Operator 1.0, un fichier de configuration monolithique CouchbaseCluster définissait la structure d’un cluster (nombres de nœuds, de buckets, XDCR, etc). L’éditeur a décidé de séparer ce document afin de différencier certaines Customs Ressources. L’opérateur les agrège en utilisant un système de labélisation.

Selon l’éditeur, cela permet d’obtenir une gestion affinée des différentes ressources nécessaires au déploiement d’un cluster Couchbase. Cela doit faciliter l’embarquement de nouveaux utilisateurs dans un environnement multi-clusters via le RBAC. L’opérateur gère directement la réplication de données entre clusters potentiellement situés dans différents centres de données (XDCR). Autonomous Operator profite d’un support complet du mTLS et automatise la restauration et les backups. Il s’intègre nativement à l’exportateur Prometheus de Couchbase pour ensuite visualiser les données dans Grafana. Par ailleurs, l’éditeur maintient la compatibilité avec Sync Gateway pour synchroniser Couchbase Lite (SGBD IoT ou mobile) et Server.

Ce sont à peu de choses près les fonctionnalités dans la version DBaaS de Couchbase.

Autonomous Operator 2.0 est compatible avec Couchbase Server Enterprise Edition 6.0.4 et 6.5. Il peut être déployé à côté de Kubernetes 1.13 et plus et sur OpenShift 4.1. Comme précédemment, les clusters peuvent être déployés sur Red Hat OpenShift, Amazon EKS, Google GKE et Microsoft AKS.

« Le grand attrait des microservices a toujours été la capacité de déployer des centaines de grappes de bases de données, que ce soit pour le développement, le test, la pré-production ou la production, là où elles sont le plus nécessaires. Pour y parvenir, l'architecture des bases de données doit elle-même évoluer », déclare Ravi Mayuram, CTO et SVP Engineering de Couchbase dans un communiqué de presse

Automatisation ne veut pas forcément dire simplification

Autonomous Operator répondrait à ce défi de simplification. MongoDB et DataStax empruntent à peu de choses près le même chemin avec leur opérateur respectif.

Ce passage d’un fichier de configuration monolithique à une approche basée sur des microservices demande toutefois des changements pour les clients qui veulent l’adopter. Les ressources personnalisées dépendent d’un nouveau format qu’il faut obligatoirement adopter. À cet effet, Couchbase fournit cbopconv, un convertisseur dédié à ces modifications.

Par ailleurs, cette version 2.0 vise en premier lieu une meilleure prise en charge des évolutions de Kubernetes. Si Autonomous Operator facilite en principe la gestion des clusters Couchbase, les DevOps doivent maintenant gérer la multiplication de ces applications natives pour Kubernetes, sans compter les doublons pour certains produits open source. Il suffit de consulté OperatorHub.io pour s’en rendre compte : 125 opérateurs pour autant de produits y sont référencés. Les associer avec un outil open source comme Operator Framework (développé par CoreOS, propriété de Red Hat) semble essentiel pour éviter la complexité induite par l’automatisation.