Container Service for Kubernetes:Workload scaling FAQ

Quando o campo current do HPA exibe unknown, o kube-controller-manager não consegue acessar a fonte de dados de métricas, causando falha no dimensionamento do 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)

Causa 1: A fonte de dados de métricas de recursos está indisponível

Execute kubectl top pod para verificar se há retorno de dados. Caso nenhum pod retorne dados, execute kubectl get apiservice para verificar o status da fonte de dados Resource Metrics. Exemplo de saída:

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

Se esse não for o problema, acesse Operations > Add-ons do cluster e verifique se o metrics-server está instalado.

Causa 2: As métricas não podem ser obtidas durante uma atualização contínua ou expansão

Após a criação ou atualização de um pod, o metrics-server precisa de tempo para coletar as métricas. Aguarde cerca de dois minutos antes de verificar novamente.

Causa 3: O campo request não está configurado

Por padrão, o HPA usa actual utilization/request como valor de utilização. Verifique se o campo resource do pod contém o campo request.

Causa 4: O nome da métrica está incorreto

Verifique se o nome da métrica e a capitalização estão corretos. Por exemplo, escrever cpu como CPU faz com que o campo current exiba unknown.

Durante uma atualização contínua, o controller-manager relata valores zero para pods sem métricas, o que pode levar o HPA a criar pods em excesso (dimensionamento excessivo). Use as configurações a seguir para evitar isso.

Configuração no nível do cluster

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

Configuração no nível do workload

Para evitar dimensionamento excessivo em um workload específico, use um dos métodos a seguir.

• Pause a avaliação do HPA durante atualizações contínuas adicionando esta anotação ao modelo de pod:

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

  Código de exemplo

  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

• Defina um período de aquecimento após o início da aplicação adicionando esta anotação ao modelo 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.

  Código de exemplo

  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

Exemplo de Deployment com a anotação:

## 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 

Causa

O Horizontal Pod Autoscaler calcula o número desejado de réplicas com base na razão entre as métricas atuais e desejadas, usando a seguinte fórmula: desired number of replicas = ceil(current number of replicas × (current metric / desired metric)).

A contagem desejada de réplicas depende da contagem atual de réplicas, da métrica atual e da métrica desejada. Para métricas de recursos, o HPA obtém o sub-recurso scale (subResources) do objeto scaleTargetRef e converte o Selector do status do objeto scale em um labelselector para corresponder aos pods. Se os pods correspondentes não pertencerem todos ao objeto scaleTargetRef, a contagem de réplicas calculada pode estar incorreta (por exemplo, expandindo quando a métrica está abaixo do limiar).

Motivos comuns para uma contagem imprecisa de pods incluem:

• Uma atualização contínua está em andamento.

• Pods fora do objeto scaleTargetRef compartilham o mesmo rótulo. Verifique sua existência:

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

Solução

• Para problemas relacionados a atualizações contínuas, consulte Por que o HPA cria pods extras durante uma atualização contínua?.

• Se outros pods compartilharem os mesmos rótulos, localize-os. Caso ainda estejam em uso, altere seus rótulos. Se não forem mais necessários, exclua-os.

Para solucionar o problema:

1. Execute kubectl describe hpa <hpa_name> para verificar o motivo da falha do HPA.

   • Se o campo Conditions indicar que AbleToScale é False, verifique se o Deployment está executando corretamente.

   • Se o campo Conditions indicar que ScalingActive é False, prossiga para a próxima etapa.

2. Execute kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/". Se Error from server (NotFound): the server could not find the requested resource for retornado, verifique o status do alibaba-cloud-metrics-adapter.

   Se o alibaba-cloud-metrics-adapter estiver executando corretamente, verifique se a métrica do HPA está relacionada ao Ingress. Nesse caso, implante primeiro o componente SLS. Consulte Collect and analyze Nginx Ingress access logs.

3. Verifique se as métricas do HPA foram inseridas corretamente. O valor de sls.ingress.route segue o formato <namespace>-<svc>-<port>.

   • namespace: O namespace do Ingress.

   • svc: O nome do Service do Ingress.

   • port: O nome da porta do Service do Ingress.

Consulte Métricas do HPA da Alibaba Cloud para obter a lista completa. Métricas comuns:

Para usar métricas de Ingress do SLS no dimensionamento horizontal de pods, consulte Scale pods based on Nginx Ingress metrics. A coleta de logs do Nginx Ingress para o SLS deve estar ativada no cluster.

Obtenha a métrica 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}} é o nome do SLS Project do cluster ACK. Padrão: k8s-log-{{ClusterId}}, onde {{ClusterId}} é o ID do cluster.

Se este erro for retornado:

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"
}

Isso significa que não há dados disponíveis para a métrica, o que ocorre ao consultar uma métrica de ALB Ingress (como sls_alb_ingress_qps) sem um ALB Ingress configurado.

Se um resultado como este for retornado:

{
  "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"
      }
    }
  ]
}

Isso confirma que a métrica foi obtida. value representa o valor de QPS.