CODEWITHSUNDEEP
kubernetes
eran meiri
eran meiri

Reputation: 1518

should we use 1 cluster on divide into clusters

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

Upvotes: 0

Views: 209

Answers (1)

javajon
javajon

Reputation: 1698

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.

Upvotes: 1

Related Questions