2

We're evaluating GKE and I'm wondering about the recommended strategy for dividing clusters. We have approx 20 sites for different clients in production at the mo. Should each project have its own separate clusters? One for prod and one for stage? Should we just have two giant cluster, one for prod and one for stage for all projects?

It's tempting to think that it would be nice to have one giant cluster with all of the prod sites on, so that they could all share resources most efficiently, but similarly that means a problem with the cluster would take everyone down at once. I don't really know how common this is.

Probably a side question, but when we upgraded our cluster we're experimenting on (with 2 nodes) the site running on it experienced 4 minutes of downtime. The GKE UI does say that it may experience downtime if there's not too many nodes, but it doesn't specify how many - I guess this should be a consideration in how to divide the clusters too.

Thanks for any help.

Ludo
  • 1,049
  • 3
  • 10
  • 11

1 Answers1

2

You can find here some insight and use cases on when to consider using a single cluster and multiple namespaces to separate your environments.

A single cluster could help you save on resources and money, but you’ll need to be careful on setting the appropriate resource quotas. Otherwise staging pods can affect your production environment.

Depending on your budget you might want to run multi-zone or even federated services.

For advice on how to troubleshoot the down time you can refer to this discussion.

Community
  • 1
Carlos
  • 1,385
  • 8
  • 15