Automatically scaling pods with the horizontal pod autoscaler

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

    After you create a horizontal pod autoscaler, OKD begins to query the CPU and/or memory resource metrics on the pods. When these metrics are available, the horizontal pod autoscaler computes the 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 replicas of the replication controller. For deployment configurations, scaling corresponds directly to the replica count of the deployment configuration. Note that autoscaling applies only to the latest deployment in the phase.

    OKD automatically accounts for resources and prevents unnecessary autoscaling during resource spikes, such as during start up. Pods in the unready state have 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 configure readiness checks to determine if a new pod is ready for use.

    To use horizontal pod autoscalers, your cluster administrator must have properly configured cluster metrics.

    The following metrics are supported by horizontal pod autoscalers:

    For memory-based autoscaling, memory usage must increase and decrease proportionally 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 memory usage.

    Use the OKD web console to check the memory behavior of your application and ensure that your application meets these requirements before using memory-based autoscaling.

    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%:

    Example output

    1. horizontalpodautoscaler.autoscaling/image-registry autoscaled

    Sample HPA for the image-registry DeploymentConfig object with minReplicas set to 3

    1. apiVersion: autoscaling/v1
    2. kind: HorizontalPodAutoscaler
    3. metadata:
    4.   name: image-registry
    5.   namespace: default
    6. spec:
    7.   maxReplicas: 7
    8.   minReplicas: 3
    9.   scaleTargetRef:
    10.     apiVersion: apps.openshift.io/v1
    11.     kind: DeploymentConfig
    12.     name: image-registry
    13.   targetCPUUtilizationPercentage: 75
    14. status:
    15.   currentReplicas: 5
    16.   desiredReplicas: 0

    1. View the new state of the deployment:

      1. $ oc get dc image-registry

      There are now 5 pods in the deployment:

      Example output

      1. NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
      2. image-registry   1          5         5         config

    The autoscaling/v2beta2 API allows you to add scaling policies to a horizontal pod autoscaler. A scaling policy controls how the OKD 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

    1. apiVersion: autoscaling/v2beta2
    2. kind: HorizontalPodAutoscaler
    3. metadata:
    4.   name: hpa-resource-metrics-memory
    5.   namespace: default
    6. spec:
    7.   behavior:
    8.     scaleDown: (1)
    9.       policies: (2)
    10.       - type: Pods (3)
    11.         value: 4 (4)
    12.         periodSeconds: 60 (5)
    13.       - type: Percent
    14.         value: 10 (6)
    15.         periodSeconds: 60
    16.       selectPolicy: Min (7)
    17.       stabilizationWindowSeconds: 300 (8)
    18.     scaleUp: (9)
    19.       policies:
    20.       - type: Pods
    21.         value: 5 (10)
    22.         periodSeconds: 70
    23.       - type: Percent
    24.         value: 12 (11)
    25.         periodSeconds: 80
    26.       selectPolicy: Max
    27.       stabilizationWindowSeconds: 0
    28. ...
    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

    1. apiVersion: autoscaling/v2beta2
    2. kind: HorizontalPodAutoscaler
    3. metadata:
    4.   name: hpa-resource-metrics-memory
    5.   namespace: default
    6. spec:
    7. ...
    8.   minReplicas: 20
    9. ...
    10.   behavior:
    11.     scaleDown:
    12.       stabilizationWindowSeconds: 300
    13.       policies:
    14.       - type: Pods
    15.         value: 4
    16.         periodSeconds: 30
    17.       - type: Percent
    18.         value: 10
    19.         periodSeconds: 60
    20.       selectPolicy: Max
    21.     scaleUp:
    22.       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:

    1. $ oc edit hpa hpa-resource-metrics-memory

    Example output

    1. apiVersion: autoscaling/v1
    2. kind: HorizontalPodAutoscaler
    3. metadata:
    4.   annotations:
    5.     autoscaling.alpha.kubernetes.io/behavior:\
    6. '{"ScaleUp":{"StabilizationWindowSeconds":0,"SelectPolicy":"Max","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":15},{"Type":"Percent","Value":100,"PeriodSeconds":15}]},\
    7. "ScaleDown":{"StabilizationWindowSeconds":300,"SelectPolicy":"Min","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":60},{"Type":"Percent","Value":10,"PeriodSeconds":60}]}}'
    8. ...

    Creating a horizontal pod autoscaler by using the web console

    From the web console, you can create a horizontal pod autoscaler (HPA) that specifies the minimum and maximum number of pods you want to run on a deployment. You can also define the amount of CPU or memory usage that your pods should target..

    An HPA cannot be added to deployments that are part of an Operator-backed service, Knative service, or Helm chart.

    Procedure

    To create an HPA in the web console:

    1. In the Topology view, click the node to reveal the side pane.

    2. From the Actions drop-down list, select Add HorizontalPodAutoscaler to open the Add HorizontalPodAutoscaler form.

      Figure 1. Add HorizontalPodAutoscaler

    3. From the Add HorizontalPodAutoscaler form, define the name, minimum and maximum pod limits, the CPU and memory usage, and click Save.

    To edit an HPA in the web console:

    1. In the Topology view, click the node to reveal the side pane.

    2. From the Actions drop-down list, select Edit HorizontalPodAutoscaler to open the Edit Horizontal Pod Autoscaler form.

    3. From the Edit Horizontal Pod Autoscaler form, edit the minimum and maximum pod limits and the CPU and memory usage, and click Save.

    While creating or editing the horizontal pod autoscaler in the web console, you can switch from Form view to YAML view.

    To remove an HPA in the web console:

    1. In the Topology view, click the node to reveal the side panel.

    2. From the Actions drop-down list, select Remove HorizontalPodAutoscaler.

    3. In the confirmation pop-up window, click Remove to remove the HPA.

    You can create a horizontal pod autoscaler (HPA) for an existing Deployment, DeploymentConfig, ReplicaSet, ReplicationController, or StatefulSet object that automatically scales the pods associated with that object 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 OKD server. To autoscale for a specific CPU value, create a HorizontalPodAutoscaler object with the target CPU and pod limits.

    Prerequisites

    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 are configured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

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

    Example output

    1. Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
    2. Namespace:    openshift-kube-scheduler
    3. Labels:       <none>
    4. Annotations:  <none>
    5. API Version:  metrics.k8s.io/v1beta1
    6. Containers:
    7.   Name:  wait-for-host-port
    8.   Usage:
    9.     Memory:  0
    10.   Name:      scheduler
    11.   Usage:
    12.     Cpu:     8m
    13.     Memory:  45440Ki
    14. Kind:        PodMetrics
    15. Metadata:
    16.   Creation Timestamp:  2019-05-23T18:47:56Z
    17.   Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
    18. Timestamp:             2019-05-23T18:47:56Z
    19. Events:                <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 object for an existing object:

        1. $ oc autoscale <object_type>/<name> \(1)
        2.   --min <number> \(2)
        3.   --max <number> \(3)
        4.   --cpu-percent=<percent> (4)
        1Specify the type and name of the object to autoscale. The object must exist and be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.
        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.

        For example, the following command 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%:

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

        1. Create a YAML file similar to the following:

          1. apiVersion: autoscaling/v2beta2 (1)
          2. kind: HorizontalPodAutoscaler
          3. metadata:
          4.   name: cpu-autoscale (2)
          5.   namespace: default
          6. spec:
          7.   scaleTargetRef:
          8.     apiVersion: v1 (3)
          9.     kind: ReplicaSet (4)
          10.     name: example (5)
          11.   minReplicas: 1 (6)
          12.   maxReplicas: 10 (7)
          13.   metrics: (8)
          14.   - type: Resource
          15.     resource:
          16.       name: cpu (9)
          17.       target:
          18.         type: AverageValue (10)
          19.         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 ReplicationController, use v1.

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

          • For a Deployment, ReplicaSet, Statefulset object, use apps/v1.

          4Specify the type of object. The object must be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.
          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:

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

    1. Verify that the horizontal pod autoscaler was created:

      1. $ oc get hpa cpu-autoscale

      Example output

      1. NAME            REFERENCE                       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
      2. cpu-autoscale   ReplicationController/example   173m/500m       1         10        1          20m

    Creating a horizontal pod autoscaler object for memory utilization by using the CLI

    You can create a horizontal pod autoscaler (HPA) for an existing DeploymentConfig object or ReplicationController object that automatically scales the pods associated with that object 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 maintain the specified memory utilization across all pods.

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

    Prerequisites

    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 are configured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

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

    Example output

    1. Name:         openshift-kube-scheduler-ip-10-0-129-223.compute.internal
    2. Namespace:    openshift-kube-scheduler
    3. Labels:       <none>
    4. Annotations:  <none>
    5. API Version:  metrics.k8s.io/v1beta1
    6. Containers:
    7.   Name:  scheduler
    8.   Usage:
    9.     Cpu:     2m
    10.     Memory:  41056Ki
    11.   Name:      wait-for-host-port
    12.   Usage:
    13.     Memory:  0
    14. Kind:        PodMetrics
    15. Metadata:
    16.   Creation Timestamp:  2020-02-14T22:21:14Z
    17.   Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-129-223.compute.internal
    18. Timestamp:             2020-02-14T22:21:14Z
    19. Window:                5m0s
    20. Events:                <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 ReplicationController object or replication controller:

        Example output

        1. apiVersion: autoscaling/v2beta2 (1)
        2. kind: HorizontalPodAutoscaler
        3. metadata:
        4.   name: hpa-resource-metrics-memory (2)
        5.   namespace: default
        6. spec:
        7.   scaleTargetRef:
        8.     apiVersion: v1 (3)
        9.     kind: ReplicationController (4)
        10.     name: example (5)
        11.   minReplicas: 1 (6)
        12.   maxReplicas: 10 (7)
        13.   metrics: (8)
        14.   - type: Resource
        15.     resource:
        16.       name: memory (9)
        17.       target:
        18.         type: AverageValue (10)
        19.         averageValue: 500Mi (11)
        20.   behavior: (12)
        21.     scaleDown:
        22.       stabilizationWindowSeconds: 300
        23.       policies:
        24.       - type: Pods
        25.         value: 4
        26.         periodSeconds: 60
        27.       - type: Percent
        28.         value: 10
        29.         periodSeconds: 60
        30.       selectPolicy: Max

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

        Example output

        1. apiVersion: autoscaling/v2beta2 (1)
        2. kind: HorizontalPodAutoscaler
        3. metadata:
        4.   name: memory-autoscale (2)
        5.   namespace: default
        6. spec:
        7.   scaleTargetRef:
        8.     apiVersion: apps.openshift.io/v1 (3)
        9.     kind: DeploymentConfig (4)
        10.     name: example (5)
        11.   minReplicas: 1 (6)
        12.   maxReplicas: 10 (7)
        13.   metrics: (8)
        14.   - type: Resource
        15.     resource:
        17.       target:
        18.         type: Utilization (10)
        19.         averageUtilization: 50 (11)
        20.   behavior: (12)
        21.     scaleUp:
        22.       stabilizationWindowSeconds: 180
        23.       policies:
        24.       - type: Pods
        25.         value: 6
        26.         periodSeconds: 120
        27.         value: 10
        28.         periodSeconds: 120
        29.       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:

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

      For example:

      1. $ oc create -f hpa.yaml

      Example output

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

    3. Verify that the horizontal pod autoscaler was created:

      Example output

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

      Example output

      1. Name:                        hpa-resource-metrics-memory
      2. Namespace:                   default
      3. Labels:                      <none>
      4. Annotations:                 <none>
      5. CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
      6. Reference:                   ReplicationController/example
      7. Metrics:                     ( current / target )
      8.   resource memory on pods:   2441216 / 500Mi
      9. Min replicas:                1
      10. Max replicas:                10
      11. ReplicationController pods:  1 current / 1 desired
      12. Conditions:
      13.   Type            Status  Reason              Message
      14.   ----            ------  ------              -------
      15.   AbleToScale     True    ReadyForNewScale    recommended size matches current size
      16.   ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
      17.   ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
      18. Events:
      19.   Type     Reason                   Age                 From                       Message
      20.   ----     ------                   ----                ----                       -------
      21.   Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

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

    The HPA status conditions are available with the v2beta1 version of the autoscaling 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.

        1. $ oc describe hpa cm-test

        Example output

        1. Name:                           cm-test
        2. Namespace:                      prom
        3. Labels:                         <none>
        4. Annotations:                    <none>
        5. CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
        6. Reference:                      ReplicationController/cm-test
        7. Metrics:                        ( current / target )
        8.   "http_requests" on pods:      66m / 500m
        9. Min replicas:                   1
        10. Max replicas:                   4
        11. ReplicationController pods:     1 current / 1 desired
        12. Conditions: (1)
        13.   Type              Status    Reason              Message
        14.   ----              ------    ------              -------
        15.   AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
        16.   ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
        17.   ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
        18. Events:
        1The horizontal pod autoscaler status messages.

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

    Example output

    1. Conditions:
    2.   Type         Status  Reason          Message
    3.   ----         ------  ------          -------
    4.   AbleToScale  False   FailedGetScale  the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"
    5. Events:
    6.   Type     Reason          Age               From                       Message
    7.   ----     ------          ----              ----                       -------
    8.   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

    1. Conditions:
    2.   Type                  Status    Reason                    Message
    3.   ----                  ------    ------                    -------
    4.   AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
    5.   ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API

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

    Example output

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

    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 the autoscaling API.

    Prerequisites

    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 are configured, the output appears similar to the following, with Cpu and Memory displayed under Usage.

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

    Example output

    1. Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
    2. Namespace:    openshift-kube-scheduler
    3. Labels:       <none>
    4. Annotations:  <none>
    5. API Version:  metrics.k8s.io/v1beta1
    6. Containers:
    7.   Name:  wait-for-host-port
    8.   Usage:
    9.     Memory:  0
    10.   Name:      scheduler
    11.   Usage:
    12.     Cpu:     8m
    13.     Memory:  45440Ki
    14. Kind:        PodMetrics
    15. Metadata:
    16.   Creation Timestamp:  2019-05-23T18:47:56Z
    17.   Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
    18. Timestamp:             2019-05-23T18:47:56Z
    19. Window:                1m0s
    20. Events:                <none>

    Procedure

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

    1. $ oc describe hpa <pod-name>

    For example:

    The conditions appear in the Conditions field in the output.

    1. Name:                           cm-test
    2. Namespace:                      prom
    3. Labels:                         <none>
    4. Annotations:                    <none>
    5. CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
    6. Reference:                      ReplicationController/cm-test
    7. Metrics:                        ( current / target )
    8.   "http_requests" on pods:      66m / 500m
    9. Min replicas:                   1
    10. Max replicas:                   4
    11. ReplicationController pods:     1 current / 1 desired
    12. Conditions: (1)
    13.   Type              Status    Reason              Message
    14.   ----              ------    ------              -------
    15.   AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
    16.   ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request

    Additional resources

    For more information on replication controllers and deployment controllers, see .