How to make available backing service configuration to a consumer service with Kubernetes

user_6949713 0
Viewed 47

Although in an ideal world of Kubernetes you don't need to care about dependencies, the reality is different; we do have applications (consumer services) that rely on backing services (e.g. databases) to be available at startup.

To achieve this deployment order for services we have a few options available with k8s:

  • check the backing service readiness in an init container
  • check the backing service readiness in the readiness probe
  • check the backing service readiness in the application itself

Now, the backing services do own some configuration properties that are required by the consumer services as well e.g. the k8s service name, credentials, ports etc.

The usual approach I encountered is that these configuration properties are hardcoded into the initContainer/readinessProbe implementation for the consumer service. I think this is suboptimal as you have to manually keep the backing service and consumer service configuration in sync, duplicate the configuration in both services and manually reconfigure the consumer service when the backing service updates its config.

What are some best practices/patterns to keep the consumer service in sync with a backing service configuration changes?

Is it a good practice to rely on operators for backing service deployment and inject secrets/configmaps as requested by the consumer service through CRs?

Thanks!

kubernetes
1 Answers

You are right,

i think the reality is that without automation, it is impossible to manage the large scalable system of Consumers and Producers.

Operators are widely used for handling database backups & and other automation tasks.

If you see with some scenarios like vault : https://www.hashicorp.com/blog/dynamic-database-credentials-with-vault-and-kubernetes

They are also using the Operator to solve problems.

HashiCorp Vault solves this problem by enabling operators to provide dynamically generated credentials for applications. Vault manages the lifecycle of credentials, rotating and revoking as required.

What are some best practices/patterns to keep the consumer service in sync with a backing service configuration changes?

You can use the vault to store the key-value pair at the central level or secret & configmap to store store creds or files inside it and inject it further.

user_55258240
Related