<p>Kubernetes supports <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/" rel="nofollow noreferrer">namespaces</a>. </p>

<blockquote>
  <p>multiple virtual clusters backed by the same physical cluster</p>
</blockquote>

<p>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.</p>

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

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

CC BY-SA 4.0
2019-01-31T23:50:37.297Z
2019-01-31T23:50:37.297Z
Levi
<p>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.</p>

CC BY-SA 4.0
2019-07-01T07:05:30.833Z
2019-07-01T08:39:07.397Z
2019-07-01T08:39:07.397Z
kaizenCoder
<p>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.</p>

<p><strong>Discussion</strong></p>

<p>There are at least two options, i.e. one k8s cluster or multiple.</p>

<p><em>one k8s cluster</em></p>

<ul>
<li>Lower costs</li>
<li>Dangerous as pods from production environment could be removed, while the intention was to removed dev pods.</li>
</ul>

<p><em>multiple k8s clusters</em></p>

<ul>
<li>Higher costs</li>
<li>Lower change that data will be removed accidentally due to isolation</li>
</ul>

CC BY-SA 3.0
2018-04-23T16:05:26.073Z
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
CC BY-SA 3.0
2018-04-23T16:06:10.013Z
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
CC BY-SA 4.0
2019-01-27T17:54:40.073Z
@EngineerDollery Thank you for this point of view. Could you transform these comments into an answer?
030
<kubernetes><dtap>
How to implement DTAP in k8s?
030
# How to implement DTAP in k8s?

(Asked by: username_0 on 2018-04-22)

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

**Tags:** kubernetes, dtap

> **Comments:**
> **username_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).  
> **username_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.  
> **username_0**: @EngineerDollery Thank you for this point of view. Could you transform these comments into an answer?  

---

## 2 answers

### Answer by username_2 on 2019-01-31. Score: 2 | Accepted answer

Kubernetes supports [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/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.


---

### Answer by username_3 on 2019-07-01. Score: 1

Supplementary to @username_2'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.


---

