I am planning to create a special 'deployer' deployment on k8s (one 'deployer' per cluster). It's role would be to pull specifications from a central place, create k8s manifests and apply them. The end result should be multiple deployments, each in it's own namespace with service and ingress, as well as a secret containing DB credentials.
I don't want to directly transmit and manage the DB details. Instead, I was thinking of creating a CustomResourceDefinition 'dbservice' that would contain a DB service name among the rest. Then configure a k8s operator that would:
- Take (monitor) such a 'dbservice' resource.
- Check with a DB hosting service if such a service exists already. If not it would create it with some specifications from the custom resource.
- Get the hostname, password, user, database name and port, and store them in a secret that would be used by the deployment (envvar).
That way:
- Each deployment would wait for it's DB secret and would not start until the secret exists, which means that the DB is ready.
- I wouldn't have to manage DB services manually.
- I wouldn't have to transmit passwords via wire.
What needs to happen for this to work (according to my plan):
- The operator would need to have permissions to talk with the DB hosting provider (will probably access another k8s stored secret with the API key).
- The operator would need to have permissions to create secrets in all namespaces.
Since I'm fairly new to k8s and devops in general, I wanted to verify that this approach is sane and not an anti-pattern.
