We use cookies and other similar technology to collect data to improve your experience on our site, as described in our Privacy Policy.
Run Production-Grade Databases on Kubernetes
Backup and Recovery Solution for Kubernetes
Run Production-Grade Vault on Kubernetes
Secure HAProxy Ingress Controller for Kubernetes
Kubernetes Configuration Syncer
Kubernetes Authentication WebHook Server
KubeDB simplifies Provision, Upgrade, Scaling, Volume Expansion, Monitor, Backup, Restore for various Databases in Kubernetes on any Public & Private Cloud
A complete Kubernetes native disaster recovery solution for backup and restore your volumes and databases in Kubernetes on any public and private clouds.
KubeVault is a Git-Ops ready, production-grade solution for deploying and configuring Hashicorp's Vault on Kubernetes.
Secure HAProxy Ingress Controller for Kubernetes
Kubernetes Configuration Syncer
Kubernetes Authentication WebHook Server
New to KubeDB? Please start here.
KubeDB
concepts:
Schema Manager
is a Kubernetes operator developed by AppsCode that implements multi-tenancy inside KubeDB provisioned database servers like MySQL, MariaDB, PosgreSQL and MongoDB etc. With Schema Manager
one can create database into specific database server. An user will also be created with KubeVault and assigned to that database. Using the newly created user credential one can access the database and run operations into it. One may pass the database server reference, configuration, user access policy through a single yaml and Schema Manager
will do all the task above mentioned. Schema Manager
also allows initializing the database and restore snapshot while bootstrap.
The following diagram shows how MongoDB Schema Manager process worked. Open the image in a new tab to see the enlarged version.
The process consists of the following steps:
At first the user will deploy a MongoDBDatabase
object.
Once a MongoDBDatabase
object is deployed to the cluster, the Schema Manager
operator first verifies if it has the required permission to be able to interact with the referred database-server by checking Double-OptIn
. After the Double-OptIn
verification Schema Manager
operator checks in the MongoDB
server if the target database is already present or not. If the database already present there, then the MongoDBDatabase
object will be immediately denied.
Once everything is ok in the MongoDB
server side, then the target database will be created and an entry for that will be entered in the kubedb_system
database.
Then Schema Manager
operator creates a MongoDB Role
.
Vault
operator always watches for a Database Role
.
Once Vault
operator finds a Database Role
, it creates a Secret
for that Role
.
After this process, the Vault
operator creates a User
in the MongoDB
server. The user gets all the privileges on our target database and its credentials are served with the Secret
. The user credentials secret reference is patched with the MongoDBDatabase
object yaml in the .status.authSecret.name
field.
If there is any init script
associated with the MongoDBDatabase
object, it will be executed in this step with the Schema Manager
operator.
The user can also provide a snapshot
reference for initialization. In that case Schema Manager
operator fetches necessary appbinding
, secrets
, repository
.
Stash
operator watches for a Restoresession
.
Once Stash
operator finds a Restoresession
, it Restores the targeted database with the Snapshot
.
In the next doc, we are going to show a step by step guide of using MongoDB Schema Manager with KubeDB.