Kubernetes: how to isolate your production from staging
So you have a Kubernetes cluster, and you are tempted to isolate your production from staging? If you are still unsure, don’t know where to start, or have doubts about the cost, this article should help you shine a light through all of your interrogations.
Albane TonnellierMarch 8, 2022 · 4 min read
Albane is a Product Owner at Qovery with previous RoR developer experience.See all articles
What is a Kubernetes cluster?
A Kubernetes cluster is a set of nodes with a certain amount of CPU and RAM that run and manage your application workload in a resilient way. Kubernetes is ideal in case of worker node disruption. There is no need to panic; Kubernetes got you back and will keep your application up and running.
What is a staging cluster?
A staging cluster is used for iterations/testing and validation before releasing in production - to the client. The main idea behind a staging cluster is to mimic the production cluster. So it must be perfectly similar. Same Kubernetes version, number of nodes, and applications than the production.
What is a production cluster?
This is the end-user application the client has access to. It should contain stable and well-tested features.
Why you should use a different cluster for production and staging
Performance: Isolation of the production environment
- So, you can take care of testing a new version of Kubernetes in staging only without impacting the production.
- Changing some of the configurations, such as the number of nodes, can make your production slow; having a cluster dedicated for staging can ensure that you can make some changes without impacting the product speed.
Security: Lock access to the prod cluster
- You can decide to give access to the production cluster to a reduced number of people, so it reduces the risk of human error.
- If you have a set of debugging tools and framework testing in your production cluster, it can give anyone in the team access to some sensible data. Your team should do all the testing before going to production; it’s better to add those debugging tools and framework testing for your staging cluster only so you can reduce the risk of a data leak.
Productivity: Iterate faster and release with confidence
- Never be scared of doing changes on your staging cluster before releasing it in production. You will never break your production application while testing.
- Prevent failure in production before they happen 🙂
How to separate staging from production clusters with Qovery
Once you created your organization, head to the “organization settings” and select “add a cluster”.
Step 1 - Set up and deploy your staging cluster
You can start by creating a cluster called “Staging”, add your credential, choose the features you need then select “create”.
After you have entered your credential and selected “create”, you can click on the three dots on the right of your cluster and select “install”.
Your cluster should take about 30 mn to be ready. You can see the status of your cluster on the left, and a green dot should appear once your cluster is set up and deployed.
Step 2 - Set up and deploy your production cluster
The process is the same here except that you want to call your second cluster “Production” so you can recognize it quickly.
Once you have entered your credential and selected “create”, you can deploy this second cluster.
Once you have created and deployed both your staging and production clusters, you can deploy your application on both clusters; here is a tutorial that can help you get started with your first application.
How much does it cost to run multiple clusters on AWS?
To run one EKS cluster, the minimum requirement will be:
- Control-plane Kube → ~75$ per month
- 3 nodes minimum: t3a.large → $55 per instance - $165 in total per month
- Network load balancer → $30 per month
This comes up to 270$ for one EKS cluster, and using two clusters for production and staging will cost a minimum of 540$ per month.
When using a staging cluster?
If a production disruption costs you more than a cluster per month, you are better considering using a staging environment before releasing it in production. A good temporary solution is to put your staging in a production cluster if it does not take too many resources. However, it’s much better to consider using a fully dedicated staging cluster.
Your production is what the client will see; therefore, you want to make sure that it’s as stable as possible and risk-free.
By using two different clusters for your production and staging, you can say goodbye to the fear of breaking something in production; it’s also an easy way to ensure its safety and give you total control of your product.
Deploy your apps in production on AWS in minutes
Qovery combines the power of Kubernetes, the reliability of AWS, and the simplicity of Heroku to deploy your apps on AWS.Deploy my apps