Horizontal Pod Autoscaler Operations: Difference between revisions
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[Kubernetes_Horizontal_Pod_Autoscaler#Operations|Horizontal Pod Autoscaler]] | * [[Kubernetes_Horizontal_Pod_Autoscaler#Operations|Horizontal Pod Autoscaler]] | ||
* [[Kubernetes Operations]] | |||
=Create an Autoscaler= | =Create an Autoscaler= | ||
Line 8: | Line 10: | ||
===With CLI=== | ===With CLI=== | ||
{{External|https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#autoscale}} | |||
<syntaxhighlight lang='text'> | <syntaxhighlight lang='text'> | ||
kubectl autoscale deployment <deployment-name> --cpu-percent=50 --min=1 --max=10 | kubectl autoscale deployment <deployment-name> --cpu-percent=50 --min=1 --max=10 | ||
Line 35: | Line 39: | ||
===Playground=== | ===Playground=== | ||
{{External|https://github.com/ovidiuf/playground/tree/master/kubernetes/horizontal-pod-autoscaler}} | {{External|https://github.com/ovidiuf/playground/tree/master/kubernetes/horizontal-pod-autoscaler/cpu-based}} | ||
=Horizontal Pod Autoscaler Controller Configuration= | |||
==--horizontal-pod-autoscaler-sync-period== | |||
Sets the period of the control loop. By default, the value is 15 seconds. | |||
==--horizontal-pod-autoscaler-tolerance== | |||
See: {{Internal|Kubernetes_Horizontal_Pod_Autoscaler#Autoscaling_Algorithm|Autoscaling Algorithm}} | |||
==--horizontal-pod-autoscaler-initial-readiness-delay== | |||
==--horizontal-pod-autoscaler-cpu-initialization-period== | |||
==--horizontal-pod-autoscaler-downscale-stabilization== | |||
The value for this option is a duration that specifies how long the autoscaler has to wait before another downscale operation can be performed after the current one has completed. The default value is 5 minutes. Also see: {{Internal|Kubernetes_Horizontal_Pod_Autoscaler#Autoscaling_Algorithm|Autoscaling Algorithm}} | |||
==--horizontal-pod-autoscaler-use-rest-clients== | |||
This should be set to true or be unset to configure the autoscaler to read metrics from metrics APIs. Setting this to false switches to Heapster-based autoscaling, which is deprecated. Also see: {{Internal|Kubernetes_Horizontal_Pod_Autoscaler#How_it_Works|How Horizontal Pod Autoscaler Works}} | |||
=Horizontal Pod Autoscaler Controller Troubleshooting= | |||
Horizontal Pod Autoscaler operations are logged in the controller-manager logs. Failures such as not being able to pull a specific metric from a certain metrics API are logged there. |
Latest revision as of 20:34, 15 October 2020
Internal
Create an Autoscaler
CPU-Based Autoscaler
For the autoscaler to work, the pods subject to autoscaling must have their CPU requests set.
With CLI
kubectl autoscale deployment <deployment-name> --cpu-percent=50 --min=1 --max=10
With Metadata
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: example
spec:
minReplicas: 1
maxReplicas: 5
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: httpd
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
Playground
Horizontal Pod Autoscaler Controller Configuration
--horizontal-pod-autoscaler-sync-period
Sets the period of the control loop. By default, the value is 15 seconds.
--horizontal-pod-autoscaler-tolerance
See:
--horizontal-pod-autoscaler-initial-readiness-delay
--horizontal-pod-autoscaler-cpu-initialization-period
--horizontal-pod-autoscaler-downscale-stabilization
The value for this option is a duration that specifies how long the autoscaler has to wait before another downscale operation can be performed after the current one has completed. The default value is 5 minutes. Also see:
--horizontal-pod-autoscaler-use-rest-clients
This should be set to true or be unset to configure the autoscaler to read metrics from metrics APIs. Setting this to false switches to Heapster-based autoscaling, which is deprecated. Also see:
Horizontal Pod Autoscaler Controller Troubleshooting
Horizontal Pod Autoscaler operations are logged in the controller-manager logs. Failures such as not being able to pull a specific metric from a certain metrics API are logged there.