amelbakry / kube-schedule-scaler Goto Github PK

I built and ran this on my 1.13.11 Cluster running in Azure Kubernetes Service. I get an error in the logs that it couldn't query the namespaces API. I installed the serviceaccount in the default namespace. Is there a specific role and rolebinding this code needs to query correctly?

Logs:

kubectl logs -f kube-schedule-scaler-858d5697c-rx82q
Traceback (most recent call last):
  File "/root/schedule_scaling/schedule_scaling.py", line 273, in <module>
    deploy_job_creator()
  File "/root/schedule_scaling/schedule_scaling.py", line 74, in deploy_job_creator
    deployments__to_scale = deployments_to_scale()
  File "/root/schedule_scaling/schedule_scaling.py", line 52, in deployments_to_scale
    for namespace in list(pykube.Namespace.objects(api)):
  File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 133, in __iter__
    return iter(self.query_cache["objects"])
  File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 123, in query_cache
    cache["response"] = self.execute().json()
  File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 108, in execute
    r.raise_for_status()
  File "/usr/local/lib/python3.5/dist-packages/requests/models.py", line 940, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://10.0.0.1:443/api/v1/namespaces
Running the Jobs of the last 5 minutes

I'm trying to start the container without errors, not defining any stackset (my case, I don't need them) and I got this error:

Deployments collected for scaling:
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 10, MaxReplicas: None, Schedule: 30 4 * * 1,2,3,4,5
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 5, MaxReplicas: None, Schedule: 00 8 * * 1,2,3,4,5
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 7, MaxReplicas: None, Schedule: 00 21 * * 1,2,3,4,5
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 12, MaxReplicas: None, Schedule: 30 5 * * 6,7
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 2, MaxReplicas: None, Schedule: 00 9 * * 6,7
Deployment: php-apache, Namespace: default, Replicas: None, MinReplicas: 20, MaxReplicas: None, Schedule: 00 21 * * 6,7
Traceback (most recent call last):
File "/root/schedule_scaling/schedule_scaling.py", line 274, in
stack_job_creator()
File "/root/schedule_scaling/schedule_scaling.py", line 155, in stack_job_creator
stacks__to_scale = stacks_to_scale()
File "/root/schedule_scaling/schedule_scaling.py", line 127, in stacks_to_scale
for stackset in StackSet.objects(api).filter(namespace=namespace):
File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 133, in iter
return iter(self.query_cache["objects"])
File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 123, in query_cache
cache["response"] = self.execute().json()
File "/usr/local/lib/python3.5/dist-packages/pykube/query.py", line 108, in execute
r.raise_for_status()
File "/usr/local/lib/python3.5/dist-packages/requests/models.py", line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://10.0.0.1:443/apis/zalando.org/v1/namespaces/custom-metrics/stacksets

As far as I can understand clear_cron() will commit the deletion before the rest of the code can determine the new jobs and commit them. This might lead to the following issues:

• if something fails in the code (such as an uncaught exception), the crontab will be totally blank and lose also the old rules
• there's a period of time between the execution of clear_cron() and the rest of the code in which the crontab is empty: what happens to the jobs that are supposed to run exactly in the moment the crontab is temporarily empty?

Wouldn't it be better to share a global instance of the crontab object and commit the changes only at the end? Possibly there must be a way to design this so that a single syntax error won't compromise the integrity of the whole crontab.

I wish to schedule downtime for stateful sets