<p>Based on my experience I'd suggest following scenario:</p>
<p>First you should make your apps deployment process similar for all environments, so same tool and set of files will be responsible for this part. And only difference should goes to parameters.</p>
<p>And second it's always a good practice to have kubernetes cluster per stage. Very common situation when your changes goes not only to kubernetes apps manifests, but to surrounding infrastructure also (LoadBalancer, Object Buckets, Disks Storage, etc).</p>
<p>You cat try to cut costs on kubernetes part by using same cluster for dev/stage but still situations with differences in infra resources could happen. And that could lead to more efforts on support and release deployment level.</p>
<p>In case you will use AWS, you can put kuberentes load to EC2 Spot Instances and that could heavily reduce your monthly bill.</p>
<p>As for toolset for k8s apps manifests, I've tried multiple tools and ways, and from my experience terraform+terragrunt works better here. Single tool for all infra resources, parameterization works easily, common code could be separated to reusable modules.</p>
<p>Other option is kustomize or helm, but those tools could help with kubernetes manifests only, and can't manage external resources.</p>

CC BY-SA 4.0
2021-03-07T12:18:19.590Z
2021-03-07T12:18:19.590Z
Peter Salnikov
<p>We are converting a traditional docker-compose based service stack to a Kubernetes based services</p>
<p>Before the conversion we had three deployment environments</p>
<ol>
<li>Local : Basically this is the developer's working machine.</li>
<li>Dev : Where the everyday releases happens and developers who belongs to other projects like web apps and mobile app uses endpoints from this environment to get their daily work done.</li>
<li>Staging : Project owners/clients see this space</li>
<li>Production : This is where the world facing actual services are living.</li>
</ol>
<p>So when its come to Kubernetes, we need to specially invest on Kubernetes supported clusters and those are heavily expensive.
Since we need three deployment environments , do we need to purchase three Kubernetes cluster groupes?
Or how other traditional teams managing this requirement?</p>

CC BY-SA 4.0
2021-03-08T13:51:49.660Z
Worth reading: [Multiple environments (Staging, QA, production, etc) with Kubernetes](https://stackoverflow.com/a/55604007/7641078)
Eduardo Baitello
<kubernetes><deployment><servers><orchestration><environments>
What are the cost effective ways to deploy services using Kubernetes on multiple deployment environments?
inckka
# What are the cost effective ways to deploy services using Kubernetes on multiple deployment environments?

(Asked by: username_0 on 2021-03-06)

We are converting a traditional docker-compose based service stack to a Kubernetes based services

Before the conversion we had three deployment environments

1. Local : Basically this is the developer's working machine.
2. Dev : Where the everyday releases happens and developers who belongs to other projects like web apps and mobile app uses endpoints from this environment to get their daily work done.
3. Staging : Project owners/clients see this space
4. Production : This is where the world facing actual services are living.

So when its come to Kubernetes, we need to specially invest on Kubernetes supported clusters and those are heavily expensive.
Since we need three deployment environments , do we need to purchase three Kubernetes cluster groupes?
Or how other traditional teams managing this requirement?

**Tags:** kubernetes, deployment, servers, orchestration, environments

> **Comments:**
> **username_1**: Worth reading: [Multiple environments (Staging, QA, production, etc) with Kubernetes](https://stackoverflow.com/a/55604007/7641078)  

---

## 1 answers

### Answer by username_2 on 2021-03-07. Score: 1

Based on my experience I'd suggest following scenario:

First you should make your apps deployment process similar for all environments, so same tool and set of files will be responsible for this part. And only difference should goes to parameters.

And second it's always a good practice to have kubernetes cluster per stage. Very common situation when your changes goes not only to kubernetes apps manifests, but to surrounding infrastructure also (LoadBalancer, Object Buckets, Disks Storage, etc).

You cat try to cut costs on kubernetes part by using same cluster for dev/stage but still situations with differences in infra resources could happen. And that could lead to more efforts on support and release deployment level.

In case you will use AWS, you can put kuberentes load to EC2 Spot Instances and that could heavily reduce your monthly bill.

As for toolset for k8s apps manifests, I've tried multiple tools and ways, and from my experience terraform+terragrunt works better here. Single tool for all infra resources, parameterization works easily, common code could be separated to reusable modules.

Other option is kustomize or helm, but those tools could help with kubernetes manifests only, and can't manage external resources.


---

