<p>I need advice in managing deployments in K8S. I need to have blue/green deployment, using gitops, and this leave me basically two options:</p>

<h2>1. Use single namespace.</h2>

<p>This will necessitate using helm to manage removing resources and whatnot, and by proxy managing blue/green through helm, and this in turn will necessitate creating <strong>duplicate deployment templates</strong> (for green and blue).</p>

<p>Pros: managed by helm, will delete removed resources; seems to be general practice.</p>

<p>Cons: managed by helm, can mess up something, <a href="https://github.com/kubernetes/helm/issues/3275" rel="nofollow noreferrer">especially in multiple failed deployments</a>; can create snowflake namespace if someone quickly fix/add some resource and will not commit to repo;</p>

<h2>2. Using one namespace per deployment</h2>

<p>Just deploy each revision to it's namespace like <em>web-front-2142</em>, check, promote to ingress, then delete all other <em>web-front-[\d]</em> I can still use helm template engine, but without tiller. No need to rely on tiller managing resources - namespace will be deleted after production namespace promotion.</p>

<p>I will need to create separate namespace for ingress, because it is singular resource, but this will be a really simple namespace, something like <em>web-front-ingress</em>.</p>

<p>Pros: no snowflakes, every deployment has been created fully from repo; if it works - it works; no dependency on previous deployments in any way, if previous deployment was totally foobar-ed, it doesn't matter.</p>

<p>Cons: separate namespace for singular resources like ingress; seems to be not how k8s was designed and can lead to unforeseen consequences; all deployments tools including spinnaker revolves around single namespace deployment.</p>

<hr>

<p>Need some advice and best practices! :)</p>

<p>The official <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/" rel="nofollow noreferrer">documentation</a> mentions the following:</p>
<blockquote>
<p>Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.</p>
<p>It is not necessary to use multiple namespaces just to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.</p>
</blockquote>
<p>The <a href="https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/" rel="nofollow noreferrer">Kubernetes Namespaces: use cases and insights&quot;</a> article tells us more about best approaches using namespaces.
It is not recommended to use different namespaces for versioning software:</p>
<blockquote>
<p>An easy to grasp anti-pattern for Kubernetes namespaces is versioning. You should not use Namespaces as a way to disambiguate versions of your Kubernetes resources. Support for versioning is present in the containers and container registries as well as in Kubernetes Deployment resource. Multiple versions should coexist by utilizing the Kubernetes container model which also provides for auto migration between versions with deployments. Furthermore versions scope namespaces will cause massive proliferation of namespaces within a cluster making it hard to manage.</p>
</blockquote>
<p>Other resources (e.g. <a href="https://cloudplatform.googleblog.com/2018/04/Kubernetes-best-practices-Organizing-with-Namespaces.html" rel="nofollow noreferrer">GCPB</a>) describe namespaces usage mostly for separating Kubernetes objects for various stages, teams, projects, clients.<br />
So you can assume that using separate namespaces for blue-green deployments or canary deployment is not a very common approach.</p>
