Is there a reccomended practice for how kubernetes service names are included in a microservice?

5/16/2018

I know this is an odd question, and I make the bet that this is likely to depend on the scenario or preference.

If I have a set of microservices, lets just generically call them A, B, and C. Each of these is running in its own bod.

If A needs to get access to B and C to handle a request, then I would want to rely on Kubernetes DNS resolution and create a service that will route to B, and another service that would route to C. Let's generically call these ServiceB, and ServiceC.

Right now, I just store the service names in constants defined in the client code that makes the requests.

Based on your own experience, is there a good reason for these to be stored in a config file (or configmap)? I can't imagine them changing much, if at all throughout the lifecycle of the application.

What do you do in your practice, and why?

-- Brian
kubernetes
microservices
service

1 Answer

5/16/2018

Based on your own experience, is there a good reason for these to be stored in a config file (or configmap)?

  • As a general best practice guideline we tend to avoid "magic things" hardcoded in code. If even just for a off chance to be able to redirect it later, say, from dev service to qa service for some bug hunting or testing.

What do you do in your practice, and why?

  • If it is remotely configurable - we place it in some form of config, being it config file, ConfigMap or Environment variable tossed around. We like more to have it exposed and not to have to change it than to hardcode it and later regret it... Depending on how often we anticipate change we place it (in ascending order) in: some config file bundled in docker image, ConfigMap with file content, ConfigMap with environment variable, Environment variable directly in container definition, Database field that app is reading.
-- Const
Source: StackOverflow