Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-31T23:50:37.297Z
Answers: 2019-01-31T23:50:37.297Z
Answers: Levi
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-07-01T07:05:30.833Z
Answers: 2019-07-01T08:39:07.397Z
Answers: 2019-07-01T08:39:07.397Z
Answers: kaizenCoder
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-23T16:05:26.073Z
Comments: 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).
Comments: Software Engineer
Comments: CC BY-SA 3.0
Comments: 2018-04-23T16:06:10.013Z
Comments: 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.
Comments: Software Engineer
Comments: CC BY-SA 4.0
Comments: 2019-01-27T17:54:40.073Z
Comments: @EngineerDollery Thank you for this point of view. Could you transform these comments into an answer?
Comments: 030
Tags: <kubernetes><dtap>
Title: How to implement DTAP in k8s?
UserDisplayName: 030
ThreadText: # 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 username_1 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.
  
  
  ---
  
  