CODEWITHSUNDEEP
kubernetesminikube
cjm
cjm

Reputation: 844

Kubernetes unknown field "behavior"

I'm creating a HorizontalPodAutoscaler in Kubernetes and I need to configure the downscale stabilization window to be smaller than the default. The code used and error are below:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
    name: busy-autoscaler
spec:
    behavior:
        scaleDown:
            stabilizationWindowSeconds: 10
    scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: busy-worker
    minReplicas: 1
    maxReplicas: 2
    metrics:
        - type: Resource
          resource:
              name: cpu
              target:
                  type: Utilization
                  averageUtilization: 50

$ kubectl create -f some-autoscale.yaml
error validating "some-autoscale.yaml": error validating data: ValidationError(HorizontalPodAutoscaler.spec): unknown field "behavior" in io.k8s.api.autoscaling.v2beta2.HorizontalPodAutoscalerSpec

My understanding is that the behavior field should be supported from Kubernetes 1.17 as stated in the docs. Running kubectl version gives the following output:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.1", GitCommit:"d224476cd0730baca2b6e357d144171ed74192d6", GitTreeState:"clean", BuildDate:"2020-01-14T21:04:32Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

The API reference doesn't have the behavior field for v2beta2 which makes this more confusing.

I'm running Minikube 1.6.2 locally. What am I doing wrong?

Upvotes: 4

Views: 7294

Answers (4)

Kiruthika kanagarajan
Kiruthika kanagarajan

Reputation: 944

Client Version: v1.20.2 Server Version: v1.18.9-eks-d1db3c

Make sure kubectl api-versions and your cluster supports autoscaling/v2beta2

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: {{ template "ks.fullname" . }}-keycloak
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{ template "ks.fullname" . }}-keycloak
  minReplicas: {{ .Values.keycloak.hpa.minpods }}
  maxReplicas: {{ .Values.keycloak.hpa.maxpods }}
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: {{ .Values.keycloak.hpa.memory.averageUtilization }}
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: {{ .Values.keycloak.hpa.cpu.averageUtilization }}
  behavior:
    scaleDown:
      stabilizationWindowSeconds: {{ .Values.keycloak.hpa.stabilizationWindowSeconds }}
      policies:
        - type: Pods
          value: 1
          periodSeconds: {{ .Values.keycloak.hpa.periodSeconds }}

Upvotes: 4

Lubo
Lubo

Reputation: 11

The Doc has updated it to v1.18 starting to behavior field

Support for configurable scaling behavior Starting from v1.18 the v2beta2 API allows scaling behavior to be configured through the HPA behavior field. Behaviors are specified separately for scaling up and down in scaleUp or scaleDown section under the behavior field. A stabilization window can be specified for both directions which prevents the flapping of the number of the replicas in the scaling target. Similarly specifying scaling policies controls the rate of change of replicas while scaling.

Upvotes: 0

cjm
cjm

Reputation: 844

So it looks like this was a case of incorrect documentation that was corrected shortly after I asked my question. PR #18157 on kubernetes/website adds the following text to the page on the Horizontal Pod Autoscaler.

Starting from v1.17 the downscale stabilization window can be set on a per-HPA basis by setting the behavior.scaleDown.stabilizationWindowSeconds field in the v2beta2 API. See Support for configurable scaling behavior.

PR #18965 reverts the previous pull request since the behavior object is functionality targeted in 1.18, not 1.17.

For now, the solution is to use the --horizontal-pod-autoscaler-downscale-stabilization flag on the controller manager as mentioned in @ShantyMan's answer above which will set the value for every HPA.

Upvotes: 4

Discombobulate
Discombobulate

Reputation: 269

You read the docs incorrectly. There is no such object like behavior thus the error why applying the yaml and that's why it's missing from Api reference.

Here you have details regarding the algorithm that is being used for scaling.

But I think you are thinking about this Support for cooldown/delay

--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 (5m0s).

Note: When tuning these parameter values, a cluster operator should be aware of the possible consequences. If the delay (cooldown) value is set too long, there could be complaints that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if the delay value is set too short, the scale of the replicas set may keep thrashing as usual.

Upvotes: 0

Related Questions