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
Improve this question
3
  • 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).
    – Software Engineer
    Commented Apr 23, 2018 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.
    – Software Engineer
    Commented Apr 23, 2018 at 16:06
  • @EngineerDollery Thank you for this point of view. Could you transform these comments into an answer?
    – 030
    Commented Jan 27, 2019 at 17:54

2 Answers 2

Reset to default
2

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.

Improve this answer
1

Supplementary to @Levi's answer I would also advise you to consider where you plan to test changes to your Kubernetes cluster (any change that can impact how your cluster operates e.g: lifecycle). To satisfy this and provide another alternative to the mix, you could operates 2 clusters. One for your non-prod environment (dev, test and acc) and one for the prod environment. This has the added benefit of protecting your production cluster from getting clobbered from non production workloads.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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