<p>we have a kubernetes cluster that holds all our components on version 1.9.2.
the cluster includes streaming components and NOSQL data-base components plus a few more smaller editions.</p>

<p>we need to integrate with a different group which will rely deeply on our platform/streaming/databases and all our kubernetes cluster.</p>

<p>I was wondering what is the proper approach for that?
should the components of the second group reside on the same cluster as those streaming/data-base components?</p>

<p>what will be the meaning if we decide to split into 2 different clusters?
assuming those the other group components will have to interact the the streaming/data-base components heavily , will it affect performmnace if they reside on a different cluster opposed to running on the same cluster?</p>

<p>thanks for any help</p>

eran meiri
<p>Consider using Namespaces. Having multiple clusters can increase costs and complicate logistics (security, installation, updates, monitoring). For an HA cluster close to 5 nodes (2 masters, 3 etcd) are needed for the control plane of Kubernetes. It's often more cost effective to scale up more nodes on your existing cluster. Isolation can be achieved with <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#when-to-use-multiple-namespaces" rel="nofollow noreferrer">kind: Namespace</a> and you may want to consider <a href="https://kubernetes.io/docs/concepts/services-networking/network-policies/" rel="nofollow noreferrer">kind: NetworkPolicy</a>. <a href="https://istio.io/blog/2018/soft-multitenancy/" rel="nofollow noreferrer">Istio Mesh can also help with isolation</a>.</p>

<p>Another consideration is cost and cluster administration. If you are using any other provider than GKE, each master will cost you on a monthly basis. Different clusters will also require their independent cluster roles, which can be a double-edged sword.</p>
