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
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.
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.
This is the end-user application the client has access to. It should contain stable and well-tested features.
- 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.
- 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.
- 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 🙂
Once you created your organization, head to the “organization settings” and select “add a 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.
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.
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.
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.