Container Service for Kubernetes:FAQ sur la mise à l'échelle des charges de travail

Lorsque le champ HPA current affiche unknown, kube-controller-manager ne peut pas accéder à la source de données des métriques, ce qui entraîne l'échec de la mise à l'échelle HPA.

Name:                                                  kubernetes-tutorial-deployment
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           <none>
CreationTimestamp:                                     Mon, 10 Jun 2019 11:46:48  0530
Reference:                                             Deployment/kubernetes-tutorial-deployment
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 2%
Min replicas:                                          1
Max replicas:                                          4
Deployment pods:                                       1 current / 0 desired
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: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)
Events:
  Type     Reason                   Age                      From                       Message
  ----     ------                   ----                     ----                       -------
  Warning  FailedGetResourceMetric  3m3s (x1009 over 4h18m)  horizontal-pod-autoscaler  unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)

Cause 1 : La source de données des métriques de ressources n'est pas disponible

Exécutez kubectl top pod pour vérifier si des données sont renvoyées. Si aucun pod ne renvoie de données, exécutez kubectl get apiservice pour vérifier l'état de la source de données Resource Metrics. Exemple de sortie :

NAME                                   SERVICE                      AVAILABLE   AGE
v1.                                    Local                        True        29h
v1.admissionregistration.k8s.io        Local                        True        29h
v1.apiextensions.k8s.io                Local                        True        29h
v1.apps                                Local                        True        29h
v1.authentication.k8s.io               Local                        True        29h
v1.authorization.k8s.io                Local                        True        29h
v1.autoscaling                         Local                        True        29h
v1.batch                               Local                        True        29h
v1.coordination.k8s.io                 Local                        True        29h
v1.monitoring.coreos.com               Local                        True        29h
v1.networking.k8s.io                   Local                        True        29h
v1.rbac.authorization.k8s.io           Local                        True        29h
v1.scheduling.k8s.io                   Local                        True        29h
v1.storage.k8s.io                      Local                        True        29h
v1alpha1.argoproj.io                   Local                        True        29h
v1alpha1.fedlearner.k8s.io             Local                        True        5h11m
v1beta1.admissionregistration.k8s.io   Local                        True        29h
v1beta1.alicloud.com                   Local                        True        29h
v1beta1.apiextensions.k8s.io           Local                        True        29h
v1beta1.apps                           Local                        True        29h
v1beta1.authentication.k8s.io          Local                        True        29h
v1beta1.authorization.k8s.io           Local                        True        29h
v1beta1.batch                          Local                        True        29h
v1beta1.certificates.k8s.io            Local                        True        29h
v1beta1.coordination.k8s.io            Local                        True        29h
v1beta1.events.k8s.io                  Local                        True        29h
v1beta1.extensions                     Local                        True        29h
...
[v1beta1.metrics.k8s.io                 kube-system/metrics-server   True        29h]
...
v1beta1.networking.k8s.io              Local                        True        29h
v1beta1.node.k8s.io                    Local                        True        29h
v1beta1.policy                         Local                        True        29h
v1beta1.rbac.authorization.k8s.io      Local                        True        29h
v1beta1.scheduling.k8s.io              Local                        True        29h
v1beta1.storage.k8s.io                 Local                        True        29h
v1beta2.apps                           Local                        True        29h
v2beta1.autoscaling                    Local                        True        29h
v2beta2.autoscaling                    Local                        True        29h

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

Si ce n'est pas le problème, accédez à Operations > Add-ons pour votre cluster et vérifiez que metrics-server est installé.

Cause 2 : Les métriques ne peuvent pas être récupérées lors d'une mise à jour progressive ou d'une montée en puissance

Après la création ou la mise à jour d'un pod, metrics-server a besoin de temps pour collecter les métriques. Attendez environ deux minutes avant de vérifier à nouveau.

Cause 3 : Le champ request n'est pas configuré

Par défaut, HPA utilise actual utilization/request comme valeur d'utilisation. Vérifiez si le champ resource du pod contient le champ request.

Cause 4 : Le nom de la métrique est incorrect

Vérifiez que le nom de la métrique et sa casse sont corrects. Par exemple, écrire cpu sous la forme CPU entraîne l'affichage de unknown dans le champ current.

Lors d'une mise à jour progressive, controller-manager signale des valeurs nulles pour les pods sans métriques, ce qui peut amener HPA à créer des pods excédentaires (surdimensionnement). Utilisez les configurations suivantes pour éviter cela.

Configuration au niveau du cluster

# Add the following option to the metrics-server startup parameters.
--enable-hpa-rolling-update-skipped=true  

Configuration au niveau de la charge de travail

Pour éviter le surdimensionnement d'une charge de travail spécifique, utilisez l'une des méthodes suivantes.

• Suspendez l'évaluation HPA pendant les mises à jour progressives en ajoutant cette annotation au modèle de pod :

  # Add this annotation to spec.template.metadata.annotations of the workload to temporarily pause HPA evaluation during a rolling update.
  HPARollingUpdateSkipped: "true"

  Exemple de code

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment-basic
    labels:
      app: nginx
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: nginx
    template: 
      metadata:
        labels:
          app: nginx
        annotations:
          HPARollingUpdateSkipped: "true"  # Skips the HPA evaluation during a rolling update.
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
          - containerPort: 80

• Définissez une période de préchauffage après le démarrage de l'application en ajoutant cette annotation au modèle de pod :

  # Add this annotation to spec.template.metadata.annotations of the workload to skip a set warm-up period.
  HPAScaleUpDelay: 3m # 3m is an example. Set the period based on your requirements.

  Exemple de code

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment-basic
    labels:
      app: nginx
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: nginx
    template: 
      metadata:
        labels:
          app: nginx
        annotations:
          HPAScaleUpDelay: 3m  # 'm' stands for minutes. This setting makes the HPA effective 3 minutes after the pod is created. Supported units are s (seconds) and m (minutes).
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
          - containerPort: 80

Exemple de Deployment avec l'annotation :

## Example of a Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-basic
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        HPAScaleUpDelay: 3m # 'm' stands for minutes. This setting makes the HPA effective 3 minutes after the pod is created. Supported units are s (seconds) and m (minutes).
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9 # Replace it with your exact <image_name:tags>.
        ports:
        - containerPort: 80 

Cause

Horizontal Pod Autoscaler calcule le nombre souhaité de réplicas en fonction du rapport entre les métriques actuelles et souhaitées à l'aide de la formule suivante : desired number of replicas = ceil(current number of replicas × (current metric / desired metric)).

Le nombre de réplicas souhaité dépend du nombre actuel de réplicas, de la métrique actuelle et de la métrique souhaitée. Pour les métriques de ressources, HPA obtient la sous-ressource scale (subResources) de l'objet scaleTargetRef et convertit le Selector issu du statut (status) de l'objet scale en un labelselector pour faire correspondre les pods. Si les pods correspondants n'appartiennent pas tous à l'objet scaleTargetRef, le nombre de réplicas calculé peut être incorrect (par exemple, une montée en puissance alors que la métrique est inférieure au seuil).

Les raisons courantes d'un nombre de pods inexact incluent :

• Une mise à jour progressive est en cours.

• Des pods extérieurs à l'objet scaleTargetRef partagent le même libellé. Vérifiez leur présence :

  kubectl get pods -n {namespace_name} -l {value_of_scale_subresource_status.selector}

Solution

• Pour les problèmes liés aux mises à jour progressives, consultez la section Pourquoi HPA crée-t-il des pods supplémentaires lors d'une mise à jour progressive ?.

• Si d'autres pods partagent les mêmes libellés, localisez-les. S'ils sont encore utilisés, modifiez leurs libellés. S'ils ne sont plus nécessaires, supprimez-les.

Pour résoudre le problème :

1. Exécutez kubectl describe hpa <hpa_name> pour vérifier pourquoi HPA a échoué.

   • Si le champ Conditions indique que AbleToScale est False, vérifiez que le Deployment s'exécute correctement.

   • Si le champ Conditions indique que ScalingActive est False, passez à l'étape suivante.

2. Exécutez kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/". Si le message Error from server (NotFound): the server could not find the requested resource est renvoyé, vérifiez l'état de alibaba-cloud-metrics-adapter.

   Si alibaba-cloud-metrics-adapter s'exécute correctement, vérifiez si la métrique HPA est liée à Ingress. Si c'est le cas, déployez d'abord le composant SLS. Consultez la section Collecter et analyser les journaux d'accès Nginx Ingress.

3. Vérifiez que les métriques HPA sont saisies correctement. La valeur de sls.ingress.route est au format <namespace>-<svc>-<port>.

   • namespace : Le namespace de l'Ingress.

   • svc : Le nom du service Ingress.

   • port : Le nom du port du service Ingress.

Consultez la section Métriques HPA Alibaba Cloud pour obtenir la liste complète. Métriques courantes :

Pour utiliser les métriques SLS Ingress pour la mise à l'échelle horizontale des pods, consultez la section Mettre à l'échelle les pods en fonction des métriques Nginx Ingress. La collecte des journaux Nginx Ingress vers SLS doit être activée dans votre cluster.

Récupérez la métrique sls_ingress_qps :

kubectl get --raw  "/apis/external.metrics.k8s.io/v1beta1/namespaces/*/sls_ingress_qps?labelSelector=sls.project={{SLS_Project}},sls.logstore=nginx-ingress"

{{SLS_Project}} est le nom du projet SLS pour le cluster ACK. Par défaut : k8s-log-{{ClusterId}}, où {{ClusterId}} est l'ID du cluster.

Si cette erreur est renvoyée :

Error from server: {
    "httpCode": 400,
    "errorCode": "ParameterInvalid",
    "errorMessage": "key (slb_pool_name) is not config as key value config,if symbol : is  in your log,please wrap : with quotation mark \"",
    "requestID": "xxxxxxx"
}

Cela signifie qu'aucune donnée n'est disponible pour la métrique, ce qui se produit lors de l'interrogation d'une métrique ALB Ingress (telle que sls_alb_ingress_qps) sans ALB Ingress configuré.

Si un résultat similaire à celui-ci est renvoyé :

{
  "kind": "ExternalMetricValueList",
  "apiVersion": "external.metrics.k8s.io/v1beta1",
  "metadata": {},
  "items": [
    {
      "metricName": "sls_ingress_qps",
      "timestamp": "2025-02-26T16:45:00Z", 
      "value": "50",   # The QPS value
      "metricLabels": {
        "sls.project": "your-sls-project-name",
        "sls.logstore": "nginx-ingress"
      }
    }
  ]
}

Cela confirme que la métrique a été récupérée. value représente la valeur QPS.