Autoscaling-jiriaf

Supporting Horizontal Pod Autoscaling (HPA) in Kubernetes

Introduction

This document provides essential insights and solutions for the effective implementation of Horizontal Pod Autoscaling (HPA) in Kubernetes, specifically for VK. It emphasizes the importance of VK establishing accurate pod conditions, crucial for the optimal functioning of HPA.

Understanding Autoscaling through Code Analysis

The HPA mechanism relies heavily on specific Kubernetes code to evaluate pod readiness, especially concerning CPU resource scaling. The following snippet from the [Kubernetes source code|https://github.com/kubernetes/kubernetes/blob/v1.29.3/pkg/controller/podautoscaler/replica_calculator.go#L378] illustrates this process:

if resource == v1.ResourceCPU {
    var unready bool
    _, condition := podutil.GetPodCondition(&pod.Status, v1.PodReady)
    if condition == nil || pod.Status.StartTime == nil {
        unready = true
    } else {
        if pod.Status.StartTime.Add(cpuInitializationPeriod).After(time.Now()) {
            unready = condition.Status == v1.ConditionFalse || metric.Timestamp.Before(condition.LastTransitionTime.Time.Add(metric.Window))
        } else {
            unready = condition.Status == v1.ConditionFalse && pod.Status.StartTime.Add(delayOfInitialReadinessStatus).After(condition.LastTransitionTime.Time)
        }
    }
    if unready {
        unreadyPods.Insert(pod.Name)
        continue
    }
}

This critical piece of logic helps ensure that only ready and appropriately initialized pods are considered for scaling actions based on CPU usage.

Implementing Correct Pod Conditions

For HPA to function as intended, it's crucial to correctly set pod conditions upon creation and update their status based on lifecycle events accurately.

Pod Creation (CreatePod)

The initial conditions for running and failed pods need to reflect their true state to avoid misinterpretation by the HPA logic.

• startTime is the time when the pod was created.
• The podReady status is determined by the current phase of the pod:
  • If a pod has failed, podReady is set to False.
  • If a pod is currently running, podReady is set to True.
• The conditions of the pod are updated as follows:

pod.Status.Conditions = []v1.PodCondition{
  {
    Type:               v1.PodScheduled,
    Status:             v1.ConditionTrue,
    LastTransitionTime: startTime,
  },
  {
    Type:               v1.PodReady,
    Status:             podReady,
    LastTransitionTime: startTime,
  },
  {
    Type:               v1.PodInitialized,
    Status:             v1.ConditionTrue,
    LastTransitionTime: startTime,
  },
}

Retrieving Pods (GetPods)

The operation of a pod is heavily dependent on its readiness status. This status is encapsulated by the podReady variable. Another significant attribute is LastTransitionTime, which records the time of the last status change.

• prevPodStartTime is equivalent to startTime in the CreatePod method.
• prevContainerStartTime[pod.Spec.Containers[0].Name] denotes the start time of the first container in the pod. This holds true even for multiple containers, as they all initiate simultaneously.

• The podReady status is determined by the current phase of the pod:
  • If a pod has either failed or succeeded, podReady is set to False.
  • If a pod is currently running, podReady is set to True.

• The conditions of the pod are updated as follows:

Conditions: []v1.PodCondition{
  {
    Type:   v1.PodScheduled,
    Status: v1.ConditionTrue,
    LastTransitionTime: *prevPodStartTime,
  },
  {
    Type:   v1.PodInitialized,
    Status: v1.ConditionTrue,
    LastTransitionTime: *prevPodStartTime,
  },
  {
    Type:   v1.PodReady,
    Status: podReady,
    LastTransitionTime: prevContainerStartTime[pod.Spec.Containers[0].Name],
  },
}

Conclusion

Understanding and implementing pod condition checks correctly is crucial for effective use of Horizontal Pod Autoscaling in Kubernetes. By ensuring accurate status and condition reporting, we can enhance the reliability and efficiency of autoscaled deployments.

Horizontal Pod Autoscaler (HPA) Formula Explanation

This provides an explanation of the formula used by Kubernetes' Horizontal Pod Autoscaler (HPA) to determine the desired number of pod replicas based on current metrics compared to target metrics.

HPA Replica Calculation Formula

The Horizontal Pod Autoscaler calculates the desired number of replicas using the following formula:

Desired Replicas = ceil[Current Replicas * (Current Metric / Target Metric)]

• Desired Replicas is the number of replicas HPA aims to maintain for a particular deployment or replication controller, based on the current load.
• Current Replicas is the current number of replicas in the deployment.
• Current Metric is the current value of the metric being used for autoscaling (e.g., CPU utilization, memory usage).
• Target Metric is the desired target value for that metric, as specified in the HPA configuration.

The formula adjusts the number of replicas dynamically to meet the target metric value, ensuring that the deployment scales up or down based on the actual demand.

Example

Assume you have an application deployed with HPA configured to maintain a CPU utilization of 50%. If the current CPU utilization is 100% and there are 4 current replicas, the formula for calculating the desired replicas would be:

Desired Replicas = ceil[4 * (100 / 50)] = ceil[8] = 8

This calculation suggests that to achieve the target CPU utilization of 50%, the number of replicas should be increased to 8.

Conclusion

Understanding this formula helps in configuring HPA appropriately and ensuring that your deployments are scaled efficiently according to the real-time demand or load on your application.