Kube-Green: Shuts down Your K8s (few)Resources When not in use

We have seen about how to deploy any application and scale etc, to improve our organization productivity, but have we thought about sustainability or environment causes when we deploy any applications? As if there is n number of pods, how much energy, resource and money it consumes? You may understand this on our latest article about Optimizing Microservice architecture for sustainability. Let’s leave about Production, how much we are utilizing in non-production environment? Non-production is always more then production, this is true. Also, this emits how much CO2? This would be big worry in the future. Before it is big, you can calculate How many CO2 produced by the pod. How we can fix this? Well, there is a tool called Kube-green. Which helps to shutdown the pods automatically when there is no use. Let’s see in-detail about the kube-green in this post.

What is Kube-Green?

As we mentioned managing resource utilization is essential to contain the costs and limit energy consumption. But we have most of the tools to manage the nodes, but how many solutions we have for taking care the pods? Well, kube-green which is nothing but a Kubernetes operator that allows to shut down environments or specific resources in order to optimize resource utilization, limiting energy waste.

But how does Kube-green succeed in managing correctly Kubernetes resources to limit energy waste?

• It sets the selected Deployments replicas to 0
• It stops the selected Cronjobs by changing their status as suspended
• It allows to stop those resources at a set time and wake them up when needed

Sounds good? Yes, with Kube-green you can limit the up-time of resources and environments that are not needed for 24/7, like development, staging or test environment.

How it works?

The kube-green project works by deploying a controller and implementing a new CRD called SleepInfo. The SleepInfo resource describes what time and days to “sleep” and “wake up” Deployments. Then the controller takes that configuration and patches the targeted Deployments to set the replicas to 0 when sleeping. Then returns the replicas value to its original state when waking up.

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: working-hours
spec:
  weekdays: "1-5"
  sleepAt: "20:00"
  wakeUpAt: "08:00"
  timeZone: "Europe/Rome"
  suspendCronJobs: true
  excludeRef:
    - apiVersion: "apps/v1"
      kind:       Deployment
      name:       my-deployment

With this SleepInfo, called working-hours, namespace will be slept at 20:00 and woken up at 08:00 (Italy time zone) on weekdays (Monday to Friday).

The SleepInfo spec contains:

• weekdays: day of the week. * is every day, 1 is monday, 1-5 is from monday to friday
• sleepAt: time in hours and minutes (HH:mm) when namespace will go to sleep. Valid values are, for example, 19:00or : for every minute and every hour. Resources sleep will be deployments (setting replicas value to 0) and, if suspendCronjobs option is set to true, cron jobs will be suspended.
• wakeUpAt (optional): time in hours and minutes (HH:mm) when namespace should be restored to the initial state (before sleep). Valid values are, for example, 19:00or : for every minute and every hour. If wake up value is not set, pod in namespace will not be restored. So, you will need to deploy the initial namespace configuration to restore it.
• timeZone (optional): time zone in IANA specification. For example for italian hour, set Europe/Rome.
• suspendCronJobs (optional): if set to true, cronjobs will be suspended.
• excludeRef (optional): an array of object containing the resource to exclude from sleep. It contains:
  • apiVersion: version of the resource. Now it is supported “apps/v1”, “batch/v1beta1” and “batch/v1”
  • kind: the kind of resource. Now it is supported “Deployment” and “CronJob”
  • name: the name of the resource

For now, it manages,

• Deployment
• CronJobs

By default, on sleep, deployment resources are stopped (if not excluded). If you want to suspend also cronjobs, set suspendCronJobs to true.

For more example: https://kube-green.dev/docs/configuration/

Install

Prerequisite

kube-green support all Kubernetes cluster versions >= 1.19 <= 1.24 and OpenShift Container Platform v4.

Supported architectures are: amd64, arm64.

To successfully install kube-green, in the cluster must be installed a cert-manager. If it is not already installed installed, click here.

Kubectl

With this method, you can not change the default configuration parameters. The default static configuration for the latest release can be installed with:

# kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml

If you want to install a specific release version, run:

# kubectl apply -f https://github.com/kube-green/kube-green/releases/download/${RELEASE_TAG}/kube-green.yaml

with ${RELEASE_TAG} correctly filled.

For more installation steps, please check Kube-green installation.

Utilize kube-green in your project​

You can deploy kube-green resources (SleepInfo CRDs’) with two different scopes in your project:

• Deploy in every Environment
• Deploy in a specific Environment

Deploy in every Environment​

‘deploying in every Environment‘ means that the resources that you have created to manage kube-green will be deployed singularly in every Environment/Namespace of your project. To achieve this result, you need to identify if your project template uses default Kubernetes resource or Kustomize structure, and then save the resources in the correct path.

• Base project: The resources need to be saved in the path configuration/<resource.yaml>
• Kustomize project: The resources need to be saved in the path configuration/<resource.yaml>

Deploy in a specific Environment​

When deploying kube-green configurations in a specific environment, the resource-managing features of kube-green will be applied only to the Deployments and CronJobs running in that environment.

Depending which template, you are using:

• Base project: The resources need to be saved in the path configuration/<environmentId>/<resource.yaml>
• Kustomize project: The resources need to be saved in the path overlays/<environmentId>/<resource.yaml>

Where environmentId is a variable identified with the parameter envId configured on the console.