Skip to content

Components

Jump to bottom
Luca Terracciano edited this page Dec 31, 2020 · 5 revisions

Components

PodScale Controller

ALERT

  • Pods to be scaled must have a Service associated, otherwise the controller will not discover them and no PodScale will be created.
  • In order to work, Pods must have QOS class guaranteed since those classes can not be modified after the Pod has been deployed.

The PodScale Controller watches the ServiceLevelAgreement resource. On resource creation, it retrieves the Pod and PodScales inside the namepsace and acts upon the latter to make the two sets coincide. The controller's purpose is to keep one PodScale resource per Pod matched. To stop the tracking there are actually two ways:

  • Delete the Service Level Agreement: removing the resource from the namespace will delete all PodScale inside the namespace.
  • Delete the Deployment: the controller notices the Pods deletion and removes the associated PodScales. Deleting only the Service is not enough because the controller will not be able to retrieve its Pods and their PodScales will be undetectable.

Pod Autoscaler

Pod Autoscaler is the main system component. Under the hood it handles the vertical autoscaling logic responsible of computing and applying the resources to assign for each Pod.

Recommender

The Recommender component polls the metrics from the metrics server. For each pod metric, it computes the new resources to allocate for the pod taking into account also the agreement defined in the ServiceLevelAgreement matched by the Pod. It writes this value in the PodScale.Desired resource field.

The available logics are:

  • Control Theory: the amount of resources is assigned through control theory.

Contention manager

The Contention Manager receives from the chan the Podscales grouped by Node. It computes the amount of Node resources to be distributed among the Pods tracked by System Autoscaler. After that, the component calculates the amount of the Desired resources and compares them with the actual Node capacity. If the Desired resources does not fit into the Node, they are rescaled according to a given policy. This step is necessary in order to always make feasible resource patch to Kubernetes, leaving the Scheduler out from this process.

The available policies are:

  • Proportional: the quota requested by a Pod is maintained during the rescaling process.
    i.e. Having a Node capacity of 100m and the folliwing Desired resources:

    • Pod A: 50m
    • Pod B: 150m

    The rescaled resources will be the following:

    • Pod A: 25m
    • Pod B: 75m

Therefore, the result is written to another chan and sent to the Pod Resource Updater

Pod Resource Updater

The component reads from the chan where the Contention Manager has written the Pod resources to patch and applies the changes to both the Pod resource and Podscale.Status.ActualResources. The updated resources are then logged to /var/podscale.json for testing purposes.

Pod Replicas Updater

The horizontal autoscaler watches the PodScale and if horizontal scaling condition is met (for example, the PodScale.Desired has been higher than the PodScale.Actual for a certain amount of time) it increases/decreases the number of pod replicas by editing the resource Pod.Replica.

Clone this wiki locally