Winter soldier: scale down Kubernetes made easy

Member post originally published on the Devtron blog by Bhushan Nemade

TL;DR: Stop wasting money on idle resources! Winter Soldier, an open-source tool, helps you automatically scale down non-production environments, saving you up to 28% on your annual infrastructure costs.

As organizations rush towards the cloud-native paradigm, most face an unexpected issue i.e. skyrocketing infrastructure expenses. Inefficient resource management and the lack of proper demand-driven provisioning result in continuously active resources, regardless of having actual usage patterns. These factors emerge as primary reasons the cloud provider’s pay-as-you-go feature appears to be a nightmare for infrastructure costs to organizations. In this blog post, we will discuss an open-source tool Winter Soldier, a tool crafted by Devtron for time-based scaling of Kubernetes that can help us save some bucks and also how to optimize resource utilization.

The time-based autoscaling scales your workloads according to defined time, it can be used to execute batch processes like hibernating microservices. The most effective way to use time-based autoscaling is where we know the exact pattern of the incoming traffic for your services. The time-based scaling perfectly aligns with our cost optimization goal, where by utilizing the pattern of our traffic we can scale down or scale up our infrastructure.

So, now we will scale down the production environment to optimize the cost…? No, there is one hidden culprit that contributes significantly to cloud costs for every organization without even coming to notice. The “Non-Production Environments” (Dev, Staging, Testing, Preview), exist in every organization and in large quantities. All these environments keep running 24/7 and along with them, the cost meter keeps spinning.

In the case of Non-production, it’s easy to track the pattern of traffic and time-based scaling can be a good option. For instance, Dev environments can be scaled down at night time and can be scaled up in the day time similarly all these environments can be scaled down at the start of the weekend say Friday evening, and can be scaled up on Monday morning. Scaling down these environments can have a significant impact on cost as every organization maintains multiple non-production servers behind a single production server.

For instance, imagine scaling down your non-production environments every Saturday and Sunday throughout the year, let’s do some calculations and get the numbers on how much we can save on the cost.

• 365 days a year.
• 104 weekend days  (52*2)
• Potential saving= little more than 3 months a year i.e. approximately 28% of annual non-production environment costs

Winter Soldier: A Metal Arm from Devtron to Optimize the Cost

Winter Soldier is an open-source tool from Devtron, it enables time-based scaling for Kubernetes workloads. The time-based scaling with Winter Soldier helps us to reduce the cloud cost, it can be deployed to execute things such as:

1. Batch deletion of the unused resources
2. Scaling of Kubernetes workloads

Winter Soldier can be operated in three modes, “scale”, “sleep”, and “delete”. These three are the modes of actions that can be executed by the Winter Soldier, if the action for the Winter Soldier is defined as scale the Kubernetes workloads will be scaled up according to the pre-defined time.

As we have seen above non-production environments often contribute significantly to cloud costs. By implementing Winter Soldier for these environments, we can automatically scale down our non-production infrastructure during off-peak hours like nights and weekends.

The scaling down of the infrastructure can also be done manually but it takes a lot of effort and time of the system administrators.

Is time-based scaling the only way to do this? No, it can also be done with HPA or Event-Driven Autoscaling, but time-based is recommended as we know the correct incoming traffic pattern. The HPA and Event-Driven autoscaling scale the workloads when the request is made, so it takes time to scale up and down the workloads.

Let’s explore how Winter Soldier can help and how to implement it in our Kubernetes infrastructure.

Winter Soldier comes as an operator for Kubernetes which requires the Custom Resource Definition (CRD) named Hibernator. Devtron provides a Helm chart for the deployment of the Winter Soldier in our Kubernetes cluster which makes the whole simpler.

Note: Winter Soldier can be used independently for any Kubernetes cluster. Still, I’ll proceed with devtron for this blog as it provides multiple additional features, for managing my Kubernetes native application and provides support for seamless CI/CD operations including visibility for the Helm applications.

Winter Soldier in Action

In this section, we will deploy Winter Soldier and configure it to scale down our dev environment. Let’s configure it to scale down the dev environment from Friday midnight to Monday morning. The current state of the dev environment can be seen in Figure 1, as of now we are having 2 applications up and running with their pods in the Resource Browser of Devtron.

Step 1: Installation of Devtron

Devtron is an open-source modular Kubernetes dashboard, designed to ease the Kubernetes operations. It is built on top of some of the popular open source tools like ArgoCD, Grafana, Trivy, etc, and is built in a modular fashion where its capabilities can be extended from an advanced Kubernetes dashboard to Kubernetes-native CI/CD pipelines, DevSecOps, Continous Delivery, and GitOps, depending upon the requirements. Its installation is pretty straightforward.

helm repo add devtron https://helm.devtron.ai

helm repo update devtron

helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd

Check out the Devtron documentation for more details about the installation and integrations.

Step 2: Helm Chart for Winter Soldier

Navigate to the Chart Store.

Select the Helm Chart for Winter Soldier: devtron/winter-soldier

Once you click the chart, you will be able to see a brief description of the chart, README, and an option to Configure & Deploy.

Step 3: Configuring Winter Soldier

Let’s take a look at configurations of Winter Soldier for our environment, here we want the dev environment to scale down on weekends i.e. Friday night to Monday morning.

Default values for winter-soldier.


replicaCount: 1
image: quay.io/devtron/winter-soldier:abf5a822-196-14744
graceperiod: 10


resources: {}
   limits:
     cpu: 100m
     memory: 128Mi
   requests:
     cpu: 100m
     memory: 128Mi


nodeSelector: {}


tolerations: []


affinity: {}


  Provide the list of Hibernator objects in the yaml format with your custom requirements.
hibernator: []
  - apiVersion: pincher.devtron.ai/v1alpha1
    kind: Hibernator
    metadata:
      name: sleep-hibernator
    spec:
      timeRangesWithZone:
        timeZone: "Asia/Kolkata"
       timeRanges:
        - timeFrom: 00:00
          timeTo: 06:59:59
          weekdayFrom: Fri
          weekdayTo: Mon
      selectors:
      - inclusions:
        - objectSelector:
           name: "all"
            type: "deployment,rollout,StatefulSet"
        exclusions:
        - namespaceSelector:
            name: “devtron-ci,devtron-cd,argo,kube-system,devtroncd”
          objectSelector:
             name: ""
              type: "deployment,rollout,StatefulSet"
     action: sleep

• In the resources section, you can set the resource limits and request for Winter Soldier itself. You can adjust these according to your cluster.
• In the hibernator section, we define how Winter Soldier manages your resources i.e. in timeRangesWithZone we need to define timezone for instance, we are taking Asia/Kolkata. In timeRanges we need to define the start time in timeFrom and the end time in timeTo, similarly in weekdayFrom and weekdayTo. In selectors, in inclusions we specify which resources to manage and in the exclusions, we define the exceptions.
• In the spec section of the hibernator we can define `pause: true and `
pauseUntil: "Jan 2, 2026 3:04pm". By defining the pause action we can put the already scheduled hibernator at pause for a specific time window.
• In the action we define the goal for Winter Soldier, for the above example, we have set it as sleep. We can also set the action as delete or scale according to need.

Once the configurations are set we can proceed with the deployment of Winter Soldier.

Step 4: Winter Soldier in Action

Our application from the dev environment is up and running fine before the deployment of Winter Soldier.

Effect of Winter Soldier sleep action on our applications from the dev environment. Before the deployment of Winter Soldier, we were having frontend-app and backend-app deployed at the dev environment, both were up and running. Let’s see what actions are taken by Winter Soldier.

Let’s look at other applications in the same environment.

Now that Winter Soldier has been deployed and we have checked the events of applications, to verify let’s navigate to the Resource Browser of Devtron to gain visibility for our dev environment.

Figure 9 shows that Winter Soldier has scaled down the pods previously visible in Figure 1, resulting in no active pods currently running in the dev environment.

Conclusion

Time-based scaling, allows organizations to automatically adjust their resource allocation based on predictable traffic patterns, such as scaling down during nights and weekends. Winter Soldier is a powerful open-source tool that helps organizations implement time-based scaling for their environments. By leveraging Winter-Soldier, organizations can significantly reduce their cloud infrastructure cost by around 28% of the total cost of the year just by scaling workloads on weekends, particularly in non-production settings like development, staging, and testing environments.

If you liked the winter-soldier, feel free to give it a ⭐️ on GitHub. Join our actively growing Discord Community and ask your questions if you have any.