<p>I am a beginner and learning about Kubernetes.</p>
<p>As per my understanding, namespace is a virtual cluster backed by the same physical cluster.</p>
<p>In which usecases do we go for separate physical Kubernetes cluster?</p>
<p>What are the main resources that can be saved by opting for namespace instead of physical Kubernetes cluster? (Kubernetes objects present in one namespace of the physical cluster can be shared by all other namespaces, like the ones in kube-system? And are the nodes in the physical Kubernetes cluster shared by all the namespaces but it is not possible to share nodes between multiple physical Kubernetes clusters?)</p>

firstpostcommenter
<p>A namespace isn't a &quot;virtual cluster&quot; in any meaningful way; it's just a way to group together resources.  For instance, these Services are different because they're in different namespaces:</p>
<pre class="lang-sh prettyprint-override"><code>kubectl describe service --namespace n1 foo
kubectl describe service --namespace n2 foo
</code></pre>
<p>But a service in <code>n1</code> can make a call to <code>foo.n2.svc.cluster.local</code> without doing any special setup.</p>
<p>A namespace is a natural boundary for Kubernetes RBAC settings.  If one object directly references another (<em>e.g.</em>, a pod mounts a persistent volume claim or gets environment variables from a config map) they generally must be in the same namespace.</p>
<p>In an actual cluster, the nodes are shared.  A given node can run any pod from any namespace (unless that's specifically configured at the pod level); <code>kubectl describe node</code> will show this.  If a pod makes very heavy use of some resource (CPU, memory, disk I/O) this can impact other pods running on the same node.  That completely ignores namespace boundaries.</p>
<p>You want different clusters when you want things to actually be separated: when a service in one environment shouldn't be able to call a service in a different environment, when cluster-level resources like NodePort services need to be separated, if you have different policies around things like PersistentVolume allocation.</p>
<p>Sharing a cluster means that you need fewer copies of some cluster-global processes (the Kubernetes core, service meshes like Istio) and you can share nodes.  That could result in better utilization of large nodes.</p>
<p>You might, for example, separate your test and production environments into separate clusters.  These would have different external-DNS settings, separate ingress controllers, and separate node pools.  You couldn't accidentally send requests into the test environment from outside, and a load test on the test environment wouldn't impact the production environment.</p>
