You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ Here's how a typical scenario might unfold:
16
16
-**!?!?!?**
17
17
-**9:08:00:** HPA scales back down to 10 `SuperHeavyApp` pods, with CPU utilization at 70% (among the 10 pods).
18
18
19
-
## In this case we have two options:
19
+
###In this case we have two options:
20
20
- Configure **Horizontal Pod Autoscaler (HPA)** to scale based on **40% CPU usage** with a `stabilizationWindowSeconds` of `3600`. This will keep it upscaled most of the time, leading to wasted resources and money.
21
21
- Use **Prescaler**. For the `SuperHeavyApp` HPA/Deployment, configure Prescaler's Custom Resource (CR) to prescale by **+50% at "56 * * * *"**. At 8:56:00, Prescaler will:
22
22
- Change HPA's CPU `averageUtilization` from 70% to 35% and set `hpa.Spec.Behavior.ScaleUp.StabilizationWindowSeconds` to 0 (for immediate scale-up).
@@ -28,11 +28,13 @@ Here's how a typical scenario might unfold:
28
28
- If the spike ends, HPA will scale down after it concludes (e.g., if the spike ends at 9:03:00, HPA scales down at 9:08:00, i.e., 9:03:00 + 5 minutes).
29
29
- This process repeats for every hour.
30
30
31
-
Important!
32
-
If your SuperHeavyApp takes a lot of time to start:
31
+
### If your SuperHeavyApp takes a lot of time to start:
33
32
- Increase `behavior.scaleDown.stabilizationWindowSeconds` from recommended 10 minutes (for example, to 20 minutes)
34
33
- Start prescaling earlier (for example, at `"51 * * * *"`), or use multiple schedules for different times of day.
35
-
With the new `schedules` field, you can define multiple prescale actions with different times and percentages, e.g.:
34
+
35
+
## Deployment and Custom Resources
36
+
37
+
**Attention!** When you specify a cron schedule, keep in mind a **timezone**! Probably controller will run in your Kubernetes cluster in UTC timezone!
36
38
37
39
[Helm Chart](dist/chart)
38
40
@@ -53,9 +55,7 @@ spec:
53
55
revertWaitSeconds: 40# max wait time before reverting back to original values. It is important, because we must provide Kubernetes time to detect and react on HPA changes (to trigger scaleup desiredReplicas)
54
56
```
55
57
56
-
P.S. Cron/schedule logic was taken from [book.kubebuilder.io/cronjob-tutorial](https://book.kubebuilder.io/cronjob-tutorial/controller-implementation#5-get-the-next-scheduled-run)
0 commit comments