====== Horizontal Pod Autoscaler ======
La fonctionnalité de HPA permet de redimensionner les replica en fonction des performances demandés par les pods afin de répondre à une plus forte charge sur un pod donné. Ce système requis que le monitoring des pods soit fonctionnel.

Les métriques sont récupérés toutes __les une à deux minutes__. La cible du HPA peut être un replicationController, dans ce cas il va agir sur le nombre de replica. La cible peut aussi être un deploymentConfig, dans ce cas, c'est le replica count du deploymentConfig qui sera modifié.

Au niveau de la version Kubernetes utilisé chez Stonecode, deux métriques sont supportés :
  * CPU avec les API :
    * autoscaling/v1
    * autoscaling/v2beta1
  * Mémoire avec l'API :
    * autoscaling/v2beta1

===== Scaling avec API v1 =====
<note>Ce modèle de scaling ne prend en charge que le scaling CPU.</note>

Prenons l'exemple suivant :
<code yaml>
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend 
spec:
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1 
    kind: DeploymentConfig 
    name: frontend 
    subresource: scale
  minReplicas: 1 
  maxReplicas: 10 
  targetCPUUtilizationPercentage: 80 
</code>

Voici la description des éléments :
^ Chemin YAML ^ Description ^
| metadata.name | Nom du HPA. |
| spec.scaleTargetRef.apiVersion | Version de l'objet à redimensionner. v1 pour ReplicationController ou apps.openshift.io/v1 pour un DeploymentConfig. |
| spec.scaleTargetRef.kind | Type d'objet à redimensionner. Peut être ReplicationController ou DeploymentConfig. |
| spec.scaleTargetRef.name | Le nom de l'objet à redimensionner. |
| spec.minReplicas | Nombre minimum de pods qui doivent être présents. |
| spec.maxReplicas | Nombre maximum de pods. |
| spec.targetCPUUtilizationPercentage | Le pourcentage de CPU que chaque pod doit idéalement utiliser. |


===== Scaling avec API v2beta1 =====

<note important>Ce type n'est pas pris en charge par Stonecode.</note>

Il manque la configuration suivante dans le fichier ''master-config.yaml'' afin d'être pris en charge sur les clusters stonecode :
<code yaml>
...
apiServerArguments:
  runtime-config:
  - apis/autoscaling/v2beta1=true
...
</code>

Ce fonctionnement ne fonctionne qu'avec la version 2 beta1 de l'API d'autoscaling. Voici un exemple pour la ressource CPU :

<code yaml>
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory 
spec:
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1 
    kind: DeploymentConfig 
    name: frontend 
  minReplicas: 2 
  maxReplicas: 10 
  metrics:
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 50 
</code>

Pour la partie mémoire, le ''spec.metrics'' va changer pour le code suivant :
<code yaml>
spec:
  metrics:
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 50 
</code>

<note important>Ce type de scaling est à utiliser avec prudence. Il faut bien que l'application libère la mémoire quand elle a moins de charge. Dans le cas contraire, le redimensionnement peut rester bloqué sur sa valeur haute, notamment en cas de memory leak.</note>

====== Monitoring ======
Afin d'avoir une vue d'ensemble des HPA, il est possible d'utiliser la commande suivante :
<code>
oc get hpa/hpa-resource-metrics-cpu
</code>

La commande affichera un tableau comme le suivant :
<code>
NAME                         REFERENCE                                 TARGET    CURRENT  MINPODS        MAXPODS    AGE
hpa-resource-metrics-cpu     DeploymentConfig/default/frontend/scale   80%       79%      1              10         8d
</code>

Pour plus de détails, la commande suivante permet de voir les conditions de scaling :
<code>
oc describe hpa/hpa-resource-metrics-cpu
</code>

La commande affichera les détails comme suit :
<code>
Name:                           hpa-resource-metrics-cpu
Namespace:                      default
Labels:                         <none>
CreationTimestamp:              Mon, 26 Oct 2015 21:13:47 -0400
Reference:                      DeploymentConfig/default/frontend/scale
Target CPU utilization:         80% 
Current CPU utilization:        79% 
Min replicas:                   1 
Max replicas:                   4 
ReplicationController pods:     1 current / 1 desired
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_requests
  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
Events:
</code>

On peut facilement identifier la limite de CPU, l'usage CPU courant, le minimum et maximum de replicas ainsi que le nombre actuel de replicas désiré et en ligne. Les conditions affichés correspondent à l'état actuel du système de redimentionnement.

^ Condition ^ Signification ^
| AbleToScale | Indique si le HPA peut actuellement effectuer le redimentionnement. La valeur doit être vrai. En cas de problème, la raison est indiquée. |
| ScalingActive | Indique si le scaling est activé (replica count supérieur à 0 et il est possible de calculer le nombre de pods nécessaires). Une valeur à faux indique généralement un problème de récupération des metrics. |
| ScalingLimited | Indique si le maximum ou le minimum de replica est atteint, empêchant de continuer le redimensionement. |