<p>Like most applications we have three distinct running environments:</p>

<ul>
<li>Production</li>
<li>Staging / QA</li>
<li>Development</li>
</ul>

<p>These are all basically configured through ENV variables.</p>

<p><strong>How is it best to run all the services/pods/containers in our environments? Through labels? or namespaces?</strong></p>

<p>I am not sure if there is an official best practice, but I have always preferred to separate environments using namespaces for the following reasons:</p>

<ol>
<li><p>It allows you to use the exact same YAML files for your deployments, services, etc in all three environments. To switch environments, all you have to do is add <code>--namespace=${YOUR_NS}</code> to your kubectl commands or even just specify one context for every namespace in your kubectl configuration, so you can say something like <code>kubectl config use-context production</code>. Check out the <a href="http://kubernetes.io/docs/user-guide/kubectl/kubectl_config/" rel="nofollow" title="docs">docs</a>!</p></li>
<li><p>You can use <a href="http://kubernetes.io/docs/admin/resourcequota/" rel="nofollow" title="Resource Quotas">Resource Quotas</a> to put limits on the amount of compute resources that should be available to each environment.</p></li>
<li><p>You could use <a href="http://kubernetes.io/docs/admin/authorization/" rel="nofollow" title="RBAC">RBAC</a> to control access to your environments. For example you could allow only a small group of people to make changes to the production environment, but have all developers do whatever they want in your development environment.</p></li>
</ol>

<p>Inside of every namespace you could then use labels to structure your app into different tiers, for example. This configuration would then be the same in every environment.</p>
