lilic / kube-start-stop

Schedule Scaling of Kubernetes Resources

kube-start-stop

Schedule Scaling of Kubernetes Resources.

Automatically start and stop Kubernetes resources in the namespace. Schedule your resources to automatically scale down during a desired time period, e.g. scale down your dev workloads during the weekend.

Usage

Deploy controller:

  kubectl apply -f manifests/ 

Example manifest file:

apiVersion: scheduler.io/v1alpha1
kind: Schedule
metadata:
  name: schedule
  labels:
    schedule: weekly-dev
spec:
  schedules:
  - replicas: 0
    selector: my-deployment
    start:
      day: Monday 
      time:
        hour: 16 
        minute: 30
    stop:
      day: friday
      time:
        hour: 8
        minute: 10

After filling out the manifest file with the desired schedule, you just have to apply that your cluster that is running the kube-start-stop controller:

  kubectl apply -f example.yml

kube-start-stop's Issues

Gaps in the schedule

Schedules overlapping

can not build the project

 $ make build
go build -i github.com/lilic/kube-start-stop
can't load package: package github.com/lilic/kube-start-stop: cannot find package "github.com/lilic/kube-start-stop" in any of:
	/usr/local/go/src/github.com/lilic/kube-start-stop (from $GOROOT)
	/home/snarwade/go/src/github.com/lilic/kube-start-stop (from $GOPATH)
make: *** [Makefile:5: build] Error 1

Create RBAC rules

Scale all the workloads/resources in a given namespace

Currently only deployments are scaled.

Clarify timezones

Possible conflict with pod autoscaler

Hi,

First of all, thank you for the awesome project! Creating this issue to track this after the talk we had at Kubecon EU.

This may interact badly with the pod autoscaler.
Say there is a schedule that scales down a deployment every weekend to 1 replica. It turns out that this weekend is actually a work weekend and people are developing and working on the cluster. The pod autoscaler wants to scale up to 5 replicas on some metric( say memory, or CPU or a custom metric such as number of requests), but the kube-start-stop is set to 1 replica. They may get in a fight( scale up to 5, scale down to 1, scale up to 5 and so on).

This was not tested at all and the default behavior is to scale down to 0 replicas which would likely eliminate such issues.