should we use 1 cluster on divide into clusters

3/31/2019

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.

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

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?

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?

thanks for any help

-- eran meiri
kubernetes

1 Answer

4/1/2019

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 kind: Namespace and you may want to consider kind: NetworkPolicy. Istio Mesh can also help with isolation.

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.

-- javajon
Source: StackOverflow