1

In our micro-service architecture we have a number of stateful services:

  • MongoDB
  • MySQL
  • Redis
  • ElasicSearch

We also have two Kubernetes namespaces we use for our different environments:

  • Staging
  • Production

We run each of the above stateful services in both environments / namespaces. I have been wondering as we are limited for resources in our cluster due to a limited budget. Should we create a third namespace for a these services and use them for both production and staging environments? e.g. create a

"Services" namespace?

Whats the best practice in this case? Are there any disadvantages?

AndrewMcLagan
  • 13,459
  • 23
  • 91
  • 158

1 Answers1

0

Namespaces don't usually talk to each other, unless you use full qualified names.

Using the same backend service for Staging and Prod sounds like a very risky bet: anything you screw up in staging will be automatically in Prod. Probably not what you want...

but if you want to know if you can, yes you can, if you use FQDN (i.e. service-name.svc..cluster.local ) for reaching the service.

MrE
  • 19,584
  • 12
  • 87
  • 105
  • Yeah, I thought as much, better to have an isolated environment. We usually use the external domain / DNS exposed by a loadbalancer service. Is that a bad practice? e.g. elasticsearch.myapp.com, redis.myapp.com? – AndrewMcLagan Nov 19 '16 at 04:09
  • if your whole cluster is at the same provider, you should NOT expose your services externally... especially if you're not protecting them with TLS and authentication. – MrE Nov 19 '16 at 04:25
  • you should only have you app exposed outside, and have that Pod talk to your internal services – MrE Nov 19 '16 at 04:26
  • Is that only for security reasons? We usually monitor these services with various tools e.g. SequalPro, Redis client, Kabana...Are there other reasons such as latency and routing? – AndrewMcLagan Nov 19 '16 at 04:27
  • why are these tools external? they should all be behind your firewall. then use vpn to get in from outside, or expose the Ui only. the DB services have no reason to be exposed – MrE Nov 19 '16 at 04:29
  • Being lazy :-( I guess. – AndrewMcLagan Nov 19 '16 at 04:30