Multiple environments (Staging, QA, production, etc) with Kubernetes

What is considered a good practice with K8S for managing multiple environments (QA, Staging, Production, Dev, etc)?

As an example, say that a team is working on a product which requires deploying a few APIs, along with a front-end application. Usually, this will require at least 2 environments:

  • Staging: For iterations/testing and validation before releasing to the client
  • Production: This the environment the client has access to. Should contain stable and well-tested features.

So, assuming the team is using Kubernetes, what would be a good practice to host these environments? This far we’ve considered two options:

  1. Use a K8s cluster for each environment
  2. Use only one K8s cluster and keep them in different namespaces.

(1) Seems the safest options since it minimizes the risks of potential human mistake and machine failures, that could put the production environment in danger. However, this comes with the cost of more master machines and also the cost of more infrastructure management.

(2) Looks like it simplifies infrastructure and deployment management because there is one single cluster but it raises a few questions like:

  • How does one make sure that a human mistake might impact the production environment?
  • How does one make sure that a high load in the staging environment won’t cause a loss of performance in the production environment?

There might be some other concerns, so I’m reaching out to the K8s community on StackOverflow to have a better understanding of how people are dealing with these sort of challenges.

8 Answers
8

Leave a Comment