0

Dev, Tst, Acc, Prd (DTAP) is about isolating multiple environments to ensure that data will not be mixed, e.g. production data in development or lost, e.g. database removal removes all production data. DTAP is also about environments that are identical, e.g. if a database in prd, then there should be a database in dev as well, but the data should not be mixed. It is about prediction. The more the environments are identical the bigger the change that if a certain change works in dev, then it will work in tst, acc and prd.

Discussion

There are at least two options, i.e. one k8s cluster or multiple.

one k8s cluster

  • Lower costs
  • Dangerous as pods from production environment could be removed, while the intention was to removed dev pods.

multiple k8s clusters

  • Higher costs
  • Lower change that data will be removed accidentally due to isolation
  • 1
    So, this is a simplified view of the world -- a classification system -- that for a lot of cases is not really relevant anymore. These days I prefers to build an environment dynamically with all the bits I need in it. This running environment is then externally tooled for testing purposes, and test workloads are pushed through it, intended to prove its behavior and demonstrate robustness - tests are run against this environment (and they are run very fast if the environment is scalable, and the test-execution environment can run its test suite in parallel). – Engineer Dollery Apr 23 '18 at 16:05
  • 1
    Then, if everything is ok, production data/workloads can be pushed through it. In this scenario there is only one environment, and what changes is everything else. We shouldn't think of 'pushing' (deploying) our software into an environment, but rather of feeding our environments with workloads from different sources. In this way, our environments become fully immutable, and we promote the exact same environment we tested to production. – Engineer Dollery Apr 23 '18 at 16:06
  • @EngineerDollery Thank you for this point of view. Could you transform these comments into an answer? – 030 Jan 27 at 17:54
0

Kubernetes supports namespaces.

multiple virtual clusters backed by the same physical cluster

These namespaces can allow you to use one cluster for all your environments. You can also do fancy things in your CI/CD pipeline so that each branch or each commit gets its own namespace. Those pods in prod namespace can still speak to pods in dev namespace unless you segment with NACL's. Just make sure you CNI supports that.

That being said most large companies I have worked for are running a cluster per environment.

I don't think there are right or wrong answers here. Do what you think is best for your company/team/workload/environment etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.