Automatically scaling pods with the horizontal pod autoscaler - Working with pods | Nodes (2024)

Table of Contents
Understanding horizontal pod autoscalers Supported metrics Scaling policies Creating a horizontal pod autoscaler for CPU utilization Creating a horizontal pod autoscaler object for memory utilization Understanding horizontal pod autoscaler status conditions Viewing horizontal pod autoscaler status conditions Additional resources
  • Understanding horizontal pod autoscalers
    • Supported metrics
    • Scaling policies
  • Creating a horizontal pod autoscaler for CPU utilization
  • Creating a horizontal pod autoscaler object for memory utilization
  • Understanding horizontal pod autoscaler status conditions
    • Viewing horizontal pod autoscaler status conditions
  • Additional resources

As a developer, you can use a horizontal pod autoscaler (HPA) tospecify how OpenShift Container Platform should automatically increase or decrease the scale ofa replication controller or deployment configuration, based on metrics collectedfrom the pods that belong to that replication controller or deploymentconfiguration.

Understanding horizontal pod autoscalers

You can create a horizontal pod autoscaler to specify the minimum and maximum number of podsyou want to run, as well as the CPU utilization or memory utilization your pods should target.

Autoscaling for Memory Utilization is a Technology Preview feature only.

After you create a horizontal pod autoscaler, OpenShift Container Platform begins to query the CPU and/or memory resource metrics on the pods.When these metrics are available, the horizontal pod autoscaler computesthe ratio of the current metric utilization with the desired metric utilization,and scales up or down accordingly. The query and scaling occurs at a regular interval,but can take one to two minutes before metrics become available.

For replication controllers, this scaling corresponds directly to the replicasof the replication controller. For deployment configurations, scaling correspondsdirectly to the replica count of the deployment configuration. Note that autoscalingapplies only to the latest deployment in the Complete phase.

OpenShift Container Platform automatically accounts for resources and prevents unnecessary autoscalingduring resource spikes, such as during start up. Pods in the unready statehave 0 CPU usage when scaling up and the autoscaler ignores the pods when scaling down.Pods without known metrics have 0% CPU usage when scaling up and 100% CPU when scaling down.This allows for more stability during the HPA decision. To use this feature, you must configurereadiness checks to determine if a new pod is ready for use.

In order to use horizontal pod autoscalers, your cluster administrator must haveproperly configured cluster metrics.

Supported metrics

The following metrics are supported by horizontal pod autoscalers:

Table 1. Metrics
MetricDescriptionAPI version

CPU utilization

Number of CPU cores used. Can be used to calculate a percentage of the pod’s requested CPU.

autoscaling/v1, autoscaling/v2beta2

Memory utilization

Amount of memory used. Can be used to calculate a percentage of the pod’s requested memory.

autoscaling/v2beta2

For memory-based autoscaling, memory usage must increase and decreaseproportionally to the replica count. On average:

  • An increase in replica count must lead to an overall decrease in memory(working set) usage per-pod.

  • A decrease in replica count must lead to an overall increase in per-pod memoryusage.

Use the OpenShift Container Platform web console to check the memory behavior of your applicationand ensure that your application meets these requirements before usingmemory-based autoscaling.

Scaling policies

The autoscaling/v2beta2 API allows you to add scaling policies to a horizontal pod autoscaler. A scaling policy controls how the OpenShift Container Platform horizontal pod autoscaler (HPA) scales pods. Scaling policies allow you to restrict the rate that HPAs scale pods up or down by setting a specific number or specific percentage to scale in a specified period of time. You can also define a stabilization window, which uses previously computed desired states to control scaling if the metrics are fluctuating. You can create multiple policies for the same scaling direction, and determine which policy is used, based on the amount of change. You can also restrict the scaling by timed iterations. The HPA scales pods during an iteration, then performs scaling, as needed, in further iterations.

Sample HPA object with a scaling policy

apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata: name: hpa-resource-metrics-memory namespace: defaultspec: behavior: scaleDown: (1) policies: (2) - type: Pods (3) value: 4 (4) periodSeconds: 60 (5) - type: Percent value: 10 (6) periodSeconds: 60 selectPolicy: Min (7) stabilizationWindowSeconds: 300 (8) scaleUp: (9) policies: - type: Pods value: 5 (10) periodSeconds: 70 - type: Percent value: 12 (11) periodSeconds: 80 selectPolicy: Max stabilizationWindowSeconds: 0...
1Specifies the direction for the scaling policy, either scaleDown or scaleUp. This example creates a policy for scaling down.
2Defines the scaling policy.
3Determines if the policy scales by a specific number of pods or a percentage of pods during each iteration. The default value is pods.
4Determines the amount of scaling, either the number of pods or percentage of pods, during each iteration. There is no default value for scaling down by number of pods.
5Determines the length of a scaling iteration. The default value is 15 seconds.
6The default value for scaling down by percentage is 100%.
7Determines which policy to use first, if multiple policies are defined. Specify Max to use the policy that allows the highest amount of change, Min to use the policy that allows the lowest amount of change, or Disabled to prevent the HPA from scaling in that policy direction. The default value is Max.
8Determines the time period the HPA should look back at desired states. The default value is 0.
9This example creates a policy for scaling up.
10The amount of scaling up by the number of pods. The default value for scaling up the number of pods is 4%.
11The amount of scaling up by the percentage of pods. The default value for scaling up by percentage is 100%.

Example policy for scaling down

apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata: name: hpa-resource-metrics-memory namespace: defaultspec:... minReplicas: 20... behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 4 periodSeconds: 30 - type: Percent value: 10 periodSeconds: 60 selectPolicy: Max scaleUp: selectPolicy: Disabled

In this example, when the number of pods is greater than 40, the percent-based policy is used for scaling down, as that policy results in a larger change, as required by the selectPolicy.

If there are 80 pod replicas, in the first iteration the HPA reduces the pods by 8, which is 10% of the 80 pods (based on the type: Percent and value: 10 parameters), over one minute (periodSeconds: 60). For the next iteration, the number of pods is 72. The HPA calculates that 10% of the remaining pods is 7.2, which it rounds up to 8 and scales down 8 pods. On each subsequent iteration, the number of pods to be scaled is re-calculated based on the number of remaining pods. When the number of pods falls below 40, the pods-based policy is applied, because the pod-based number is greater than the percent-based number. The HPA reduces 4 pods at a time (type: Pods and value: 4), over 30 seconds (periodSeconds: 30), until there are 20 replicas remaining (minReplicas).

The selectPolicy: Disabled parameter prevents the HPA from scaling up the pods. You can manually scale up by adjusting the number of replicas in the replica set or deployment set, if needed.

If set, you can view the scaling policy by using the oc edit command:

$ oc edit hpa hpa-resource-metrics-memory

Example output

apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata: annotations: autoscaling.alpha.kubernetes.io/behavior:\'{"ScaleUp":{"StabilizationWindowSeconds":0,"SelectPolicy":"Max","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":15},{"Type":"Percent","Value":100,"PeriodSeconds":15}]},\"ScaleDown":{"StabilizationWindowSeconds":300,"SelectPolicy":"Min","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":60},{"Type":"Percent","Value":10,"PeriodSeconds":60}]}}'...

Creating a horizontal pod autoscaler for CPU utilization

You can create a horizontal pod autoscaler (HPA) for an existing DeploymentConfig or ReplicationController objectthat automatically scales the pods associated with that object in order to maintain the CPU usage you specify.

The HPA increases and decreases the number of replicas between the minimum and maximum numbers to maintain the specified CPU utilization across all pods.

When autoscaling for CPU utilization, you can use the oc autoscale command and specify the minimum and maximum number of pods you want to run at any given time and the average CPU utilization your pods should target. If you do not specify a minimum, the pods are given default values from the OpenShift Container Platform server.To autoscale for a specific CPU value, create a HorizontalPodAutoscaler object with the target CPU and pod limits.

Prerequisites

In order to use horizontal pod autoscalers, your cluster administrator must have properly configured cluster metrics.You can use the oc describe PodMetrics <pod-name> command to determine if metrics are configured. If metrics areconfigured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

Example output

Name: openshift-kube-scheduler-ip-10-0-135-131.ec2.internalNamespace: openshift-kube-schedulerLabels: <none>Annotations: <none>API Version: metrics.k8s.io/v1beta1Containers: Name: wait-for-host-port Usage: Memory: 0 Name: scheduler Usage: Cpu: 8m Memory: 45440KiKind: PodMetricsMetadata: Creation Timestamp: 2019-05-23T18:47:56Z Self Link: /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internalTimestamp: 2019-05-23T18:47:56ZWindow: 1m0sEvents: <none>

Procedure

To create a horizontal pod autoscaler for CPU utilization:

  1. Perform one of the following one of the following:

    • To scale based on the percent of CPU utilization, create a HorizontalPodAutoscaler object for an existing DeploymentConfig object:

      1Specify the name of the DeploymentConfig object. The object must exist.
      2Optionally, specify the minimum number of replicas when scaling down.
      3Specify the maximum number of replicas when scaling up.
      4Specify the target average CPU utilization over all the pods, represented as a percent of requested CPU. If not specified or negative, a default autoscaling policy is used.

    • To scale based on the percent of CPU utilization, create a HorizontalPodAutoscaler object for an existing replication controller:

      $ oc autoscale rc/<rc-name> (1) --min <number> \(2) --max <number> \(3) --cpu-percent=<percent> (4)
      1Specify the name of the replication controller. The object must exist.
      2Specify the minimum number of replicas when scaling down.
      3Specify the maximum number of replicas when scaling up.
      4Specify the target average CPU utilization over all the pods, represented as a percent of requested CPU. If not specified or negative, a default autoscaling policy is used.

    • To scale for a specific CPU value, create a YAML file similar to the following for an existing DeploymentConfig object or replication controller:

      1. Create a YAML file similar to the following:

        apiVersion: autoscaling/v2beta2 (1)kind: HorizontalPodAutoscalermetadata: name: cpu-autoscale (2) namespace: defaultspec: scaleTargetRef: apiVersion: v1 (3) kind: ReplicationController (4) name: example (5) minReplicas: 1 (6) maxReplicas: 10 (7) metrics: (8) - type: Resource resource: name: cpu (9) target: type: AverageValue (10) averageValue: 500m (11)
        1Use the autoscaling/v2beta2 API.
        2Specify a name for this horizontal pod autoscaler object.
        3Specify the API version of the object to scale:

        • For a replication controller, use v1,

        • For a DeploymentConfig object, use apps.openshift.io/v1.

        4Specify the kind of object to scale, either ReplicationController or DeploymentConfig.
        5Specify the name of the object to scale. The object must exist.
        6Specify the minimum number of replicas when scaling down.
        7Specify the maximum number of replicas when scaling up.
        8Use the metrics parameter for memory utilization.
        9Specify cpu for CPU utilization.
        10Set to AverageValue.
        11Set to averageValue with the targeted CPU value.

      2. Create the horizontal pod autoscaler:

        $ oc create -f <file-name>.yaml

  2. Verify that the horizontal pod autoscaler was created:

    $ oc get hpa cpu-autoscale

    Example output

    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEcpu-autoscale ReplicationController/example 173m/500m 1 10 1 20m

For example, the following command creates a horizontal pod autoscaler that maintains between 3 and 7 replicas of the pods that are controlled by the image-registry DeploymentConfig object in order to maintain an average CPU utilization of 75% across all pods.

$ oc autoscale dc/image-registry --min 3 --max 7 --cpu-percent=75

Example output

deploymentconfig "image-registry" autoscaled

The command creates a horizontal pod autoscaler with the following definition:

$ oc edit hpa frontend -n openshift-image-registry

Example output

apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata: creationTimestamp: "2020-02-21T20:19:28Z" name: image-registry namespace: default resourceVersion: "32452" selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/frontend uid: 1a934a22-925d-431e-813a-d00461ad7521spec: maxReplicas: 7 minReplicas: 3 scaleTargetRef: apiVersion: apps.openshift.io/v1 kind: DeploymentConfig name: image-registry targetCPUUtilizationPercentage: 75status: currentReplicas: 5 desiredReplicas: 0

The following example shows autoscaling for the image-registry DeploymentConfig object. The initial deployment requires 3 pods. The HPA object increased that minimum to 5 and will increase the pods up to 7 if CPU usage on the pods reaches 75%:

  1. View the current state of the image-registry deployment:

    $ oc get dc image-registry

    Example output

    NAME REVISION DESIRED CURRENT TRIGGERED BYimage-registry 1 3 3 config

  2. Autoscale the image-registry DeploymentConfig object:

    $ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75

    Example output

    horizontalpodautoscaler.autoscaling/image-registry autoscaled

  3. View the new state of the deployment:

    $ oc get dc image-registry

    There are now 5 pods in the deployment:

    Example output

    NAME REVISION DESIRED CURRENT TRIGGERED BYimage-registry 1 5 5 config

Creating a horizontal pod autoscaler object for memory utilization

You can create a horizontal pod autoscaler (HPA) for an existing DeploymentConfig object or ReplicationController objectthat automatically scales the pods associated with that object in order to maintain the average memory utilization you specify,either a direct value or a percentage of requested memory.

The HPA increases and decreases the number of replicas between the minimum and maximum numbers to maintainthe specified memory utilization across all pods.

For memory utilization, you can specify the minimum and maximum number of pods and the average memory utilizationyour pods should target. If you do not specify a minimum, the pods are given default values from the OpenShift Container Platform server.

Autoscaling for memory utilization is a Technology Preview feature only.Technology Preview features are not supported with Red Hat production servicelevel agreements (SLAs), might not be functionally complete, and Red Hat doesnot recommend to use them for production. These features provide early access toupcoming product features, enabling customers to test functionality and providefeedback during the development process.

For more information on Red Hat Technology Preview features support scope, seehttps://access.redhat.com/support/offerings/techpreview/.

Prerequisites

In order to use horizontal pod autoscalers, your cluster administrator must have properly configured cluster metrics.You can use the oc describe PodMetrics <pod-name> command to determine if metrics are configured. If metrics areconfigured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler

Example output

Name: openshift-kube-scheduler-ip-10-0-129-223.compute.internalNamespace: openshift-kube-schedulerLabels: <none>Annotations: <none>API Version: metrics.k8s.io/v1beta1Containers: Name: scheduler Usage: Cpu: 2m Memory: 41056Ki Name: wait-for-host-port Usage: Memory: 0Kind: PodMetricsMetadata: Creation Timestamp: 2020-02-14T22:21:14Z Self Link: /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-129-223.compute.internalTimestamp: 2020-02-14T22:21:14ZWindow: 5m0sEvents: <none>

Procedure

To create a horizontal pod autoscaler for memory utilization:

  1. Create a YAML file for one of the following:

    • To scale for a specific memory value, create a HorizontalPodAutoscaler object similar to the following for an existing DeploymentConfig object or replication controller:

      Example output

      apiVersion: autoscaling/v2beta2 (1)kind: HorizontalPodAutoscalermetadata: name: hpa-resource-metrics-memory (2) namespace: defaultspec: scaleTargetRef: apiVersion: v1 (3) kind: ReplicationController (4) name: example (5) minReplicas: 1 (6) maxReplicas: 10 (7) metrics: (8) - type: Resource resource: name: memory (9) target: type: AverageValue (10) averageValue: 500Mi (11) behavior: (12) scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 4 periodSeconds: 60 - type: Percent value: 10 periodSeconds: 60 selectPolicy: Max
      1Use the autoscaling/v2beta2 API.
      2Specify a name for this horizontal pod autoscaler object.
      3Specify the API version of the object to scale:

      • For a replication controller, use v1,

      • For a DeploymentConfig object, use apps.openshift.io/v1.

      4Specify the kind of object to scale, either ReplicationController or DeploymentConfig.
      5Specify the name of the object to scale. The object must exist.
      6Specify the minimum number of replicas when scaling down.
      7Specify the maximum number of replicas when scaling up.
      8Use the metrics parameter for memory utilization.
      9Specify memory for memory utilization.
      10Set the type to AverageValue.
      11Specify averageValue and a specific memory value.
      12Optional: Specify a scaling policy to control the rate of scaling up or down.

    • To scale for a percentage, create a HorizontalPodAutoscaler object similar to the following:

      Example output

      apiVersion: autoscaling/v2beta2 (1)kind: HorizontalPodAutoscalermetadata: name: memory-autoscale (2) namespace: defaultspec: scaleTargetRef: apiVersion: apps.openshift.io/v1 (3) kind: DeploymentConfig (4) name: example (5) minReplicas: 1 (6) maxReplicas: 10 (7) metrics: (8) - type: Resource resource: name: memory (9) target: type: Utilization (10) averageUtilization: 50 (11) behavior: (12) scaleUp: stabilizationWindowSeconds: 180 policies: - type: Pods value: 6 periodSeconds: 120 - type: Percent value: 10 periodSeconds: 120 selectPolicy: Max
      1Use the autoscaling/v2beta2 API.
      2Specify a name for this horizontal pod autoscaler object.
      3Specify the API version of the object to scale:

      • For a replication controller, use v1,

      • For a DeploymentConfig object, use apps.openshift.io/v1.

      4Specify the kind of object to scale, either ReplicationController or DeploymentConfig.
      5Specify the name of the object to scale. The object must exist.
      6Specify the minimum number of replicas when scaling down.
      7Specify the maximum number of replicas when scaling up.
      8Use the metrics parameter for memory utilization.
      9Specify memory for memory utilization.
      10Set to Utilization.
      11Specify averageUtilization and a target average memory utilization over all the pods,represented as a percent of requested memory. The target pods must have memory requests configured.
      12Optional: Specify a scaling policy to control the rate of scaling up or down.

  2. Create the horizontal pod autoscaler:

    $ oc create -f <file-name>.yaml

    For example:

    $ oc create -f hpa.yaml

    Example output

    horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

  3. Verify that the horizontal pod autoscaler was created:

    $ oc get hpa hpa-resource-metrics-memory

    Example output

    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEhpa-resource-metrics-memory ReplicationController/example 2441216/500Mi 1 10 1 20m
    $ oc describe hpa hpa-resource-metrics-memory

    Example output

    Name: hpa-resource-metrics-memoryNamespace: defaultLabels: <none>Annotations: <none>CreationTimestamp: Wed, 04 Mar 2020 16:31:37 +0530Reference: ReplicationController/exampleMetrics: ( current / target ) resource memory on pods: 2441216 / 500MiMin replicas: 1Max replicas: 10ReplicationController pods: 1 current / 1 desiredConditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource ScalingLimited False DesiredWithinRange the desired count is within the acceptable rangeEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 6m34s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
See Also
Advanced Features of Kubernetes' Horizontal Pod Autoscaler

Understanding horizontal pod autoscaler status conditions

You can use the status conditions set to determinewhether or not the horizontal pod autoscaler (HPA) is able to scale and whether or not it is currently restrictedin any way.

The HPA status conditions are available with the v2beta1 version of theautoscaling API.

The HPA responds with the following status conditions:

  • The AbleToScale condition indicates whether HPA is able to fetch and update metrics, as well as whether any backoff-related conditions could prevent scaling.

    • A True condition indicates scaling is allowed.

    • A False condition indicates scaling is not allowed for the reason specified.

  • The ScalingActive condition indicates whether the HPA is enabled (for example, the replica count of the target is not zero) and is able to calculate desired metrics.

    • A True condition indicates metrics is working properly.

    • A False condition generally indicates a problem with fetching metrics.

  • The ScalingLimited condition indicates that the desired scale was capped by the maximum or minimum of the horizontal pod autoscaler.

    • A True condition indicates that you need to raise or lower the minimum or maximum replica count in order to scale.

    • A False condition indicates that the requested scaling is allowed.

      $ oc describe hpa cm-test

      Example output

      Name: cm-testNamespace: promLabels: <none>Annotations: <none>CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000Reference: ReplicationController/cm-testMetrics: ( current / target ) "http_requests" on pods: 66m / 500mMin replicas: 1Max replicas: 4ReplicationController pods: 1 current / 1 desiredConditions: (1) Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_request ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable rangeEvents:
      1The horizontal pod autoscaler status messages.

The following is an example of a pod that is unable to scale:

Example output

Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale False FailedGetScale the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedGetScale 6s (x3 over 36s) horizontal-pod-autoscaler no matches for kind "ReplicationController" in group "apps"

The following is an example of a pod that could not obtain the needed metrics for scaling:

Example output

Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: unable to get metrics for resource cpu: no metrics returned from heapster

The following is an example of a pod where the requested autoscaling was less than the required minimums:

Example output

Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_request ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range

Viewing horizontal pod autoscaler status conditions

You can view the status conditions set on a pod by the horizontal pod autoscaler (HPA).

The horizontal pod autoscaler status conditions are available with the v2beta1 version of theautoscaling API.

Prerequisites

In order to use horizontal pod autoscalers, your cluster administrator must have properly configured cluster metrics.You can use the oc describe PodMetrics <pod-name> command to determine if metrics are configured. If metrics areconfigured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

Example output

Name: openshift-kube-scheduler-ip-10-0-135-131.ec2.internalNamespace: openshift-kube-schedulerLabels: <none>Annotations: <none>API Version: metrics.k8s.io/v1beta1Containers: Name: wait-for-host-port Usage: Memory: 0 Name: scheduler Usage: Cpu: 8m Memory: 45440KiKind: PodMetricsMetadata: Creation Timestamp: 2019-05-23T18:47:56Z Self Link: /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internalTimestamp: 2019-05-23T18:47:56ZWindow: 1m0sEvents: <none>

Procedure

To view the status conditions on a pod, use the following command with the name of the pod:

$ oc describe hpa <pod-name>

For example:

$ oc describe hpa cm-test

The conditions appear in the Conditions field in the output.

Example output

Name: cm-testNamespace: promLabels: <none>Annotations: <none>CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000Reference: ReplicationController/cm-testMetrics: ( current / target ) "http_requests" on pods: 66m / 500mMin replicas: 1Max replicas: 4ReplicationController pods: 1 current / 1 desiredConditions: (1) Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_request ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range

Additional resources

For more information on replication controllers and deployment controllers,see Understanding deployments and deployment configs.

Automatically scaling pods with the horizontal pod autoscaler - Working with pods | Nodes (2024)
Top Articles
Q&A with Pilot Travel Centers: “Our goal is to make each location feel familiar”
Pilot Travel Center in Warsaw, NC | 2574 W NC Highway 24
Kmart near me - Perth, WA
Caesars Rewards Loyalty Program Review [Previously Total Rewards]
Mychart Mercy Lutherville
Jesus Calling December 1 2022
Craigslist Parsippany Nj Rooms For Rent
Jesus Revolution Showtimes Near Chisholm Trail 8
Moe Gangat Age
Orlando Arrest and Public Records | Florida.StateRecords.org
Why Is Stemtox So Expensive
What Was D-Day Weegy
Sport Clip Hours
Pro Groom Prices – The Pet Centre
6th gen chevy camaro forumCamaro ZL1 Z28 SS LT Camaro forums, news, blog, reviews, wallpapers, pricing – Camaro5.com
Busty Bruce Lee
Non Sequitur
Razor Edge Gotti Pitbull Price
Obsidian Guard's Cutlass
Accident On May River Road Today
H12 Weidian
The Old Way Showtimes Near Regency Theatres Granada Hills
Busted Mcpherson Newspaper
Azur Lane High Efficiency Combat Logistics Plan
How to Grow and Care for Four O'Clock Plants
Lost Pizza Nutrition
Plost Dental
Jayme's Upscale Resale Abilene Photos
Log in or sign up to view
Eegees Gift Card Balance
Dumb Money, la recensione: Paul Dano e quel film biografico sul caso GameStop
Watchdocumentaries Gun Mayhem 2
Great Clips On Alameda
Dallas City Council Agenda
Elizaveta Viktorovna Bout
Publictributes
Restored Republic May 14 2023
Isabella Duan Ahn Stanford
Levi Ackerman Tattoo Ideas
Yakini Q Sj Photos
Powerboat P1 Unveils 2024 P1 Offshore And Class 1 Race Calendar
National Weather Service Richmond Va
How to Install JDownloader 2 on Your Synology NAS
9:00 A.m. Cdt
Mother Cabrini, the First American Saint of the Catholic Church
Unblocked Games - Gun Mayhem
Bonecrusher Upgrade Rs3
Fallout 76 Fox Locations
Frank 26 Forum
Ocean County Mugshots
La Fitness Oxford Valley Class Schedule
Latest Posts
learn about medicare prescription coverage
Philasd Zimbra
Article information

Author: Gregorio Kreiger

Last Updated:

Views: 6499

Rating: 4.7 / 5 (77 voted)

Reviews: 92% of readers found this page helpful

Author information

Name: Gregorio Kreiger

Birthday: 1994-12-18

Address: 89212 Tracey Ramp, Sunside, MT 08453-0951

Phone: +9014805370218

Job: Customer Designer

Hobby: Mountain biking, Orienteering, Hiking, Sewing, Backpacking, Mushroom hunting, Backpacking

Introduction: My name is Gregorio Kreiger, I am a tender, brainy, enthusiastic, combative, agreeable, gentle, gentle person who loves writing and wants to share my knowledge and understanding with you.