<p>We are going to provide customers a function by deploying and running a container in customers kubernetes environment. After the job is done, we will clean up the container. Currently, the plan is to use k8s default namespace, but I'm not sure whether it can be a concern for customers. I don't have much experience in k8s related field. Should we give customers' an option to specify a namespace to run container, or just use the default namespace? I appreciate your suggestions!</p>

<p>I would recommend you <strong>not</strong> use (!?) the default namespace for anything <strong>ever</strong>.</p>
<p>The following is more visceral than objective but it's drawn from many years' experience of Kubernetes. In 2016, a now former colleague and I blogged about the use of namespaces:</p>
<p><a href="https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/" rel="nofollow noreferrer">https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/</a></p>
<p><strong>NB</strong> since then, RBAC was added and it permits enforcing separation, securely.</p>
<p>Although it exists as a named (<code>default</code>) namespace, it behaves as if there is (the cluster has) no namespace. It may be (!?) that it was retcon'd into Kubernetes after namespaces were added</p>
<p>Unless your context is defined to be a specific other namespace, <code>kubectl ...</code> behaves as <code>kubectl ... --namespace=default</code>. So, by accident it's easy to pollute and be impacted by pollution in this namespace. I'm sure your team will use code for your infrastructure but mistakes happen and &quot;I forgot to specify the namespace&quot; is easily done (and rarely wanted).</p>
<p>Using non-default namespaces becomes very intentional, explicit and, I think, precise. You must, for example (per @david-maze answer) be more intentional about RBAC for the namespace's resources.</p>
<p>Using namespaces is a mechanism that promotes multi-tenancy which is desired for separation of customers (business units, versions etc.)</p>
<p>You can't delete the default namespace but you can delete (and by consequence delete all the resources constrained by) any non-default namespace.</p>
<p>I'll think of more, I'm sure!</p>
<h3>Update</h3>
<ul>
<li>Corollary: generally don't constrain resources to <code>namespace</code> in specs but use e.g. <code>kubectl apply --filename=x.yaml --namespace=${NAMESPACE}</code></li>
</ul>
