IBM Cloud Docs
Depuración del programa de escalado automático de clústeres

Depuración del programa de escalado automático de clústeres

Revise las opciones que tiene para depurar el programa de escalado automático de clústeres y localice las causas raíz de los errores.

Antes de empezar: Inicie una sesión en su cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

Paso 1: Comprobar la versión

  1. Compruebe que el complemento de autoescalado de clúster está instalado y listo.
    ibmcloud oc cluster addon ls --cluster <CLUSTER_NAME>
    
    Salida de ejemplo
    Name                 Version   Health State   Health Status   
    cluster-autoscaler   1.0.4     normal         Addon Ready
    
  2. Compare la versión que se ejecuta en el clúster con la versión más reciente del registro de cambios del complemento del programa de escalado automático de clústeres.
  3. Si la versión está obsoleta, despliegue la última versión del programa de escalado automático de clúster en su clúster.

Paso 2: Comprobar la configuración

Compruebe que el programa de escalado automático de clústeres está configurado correctamente.

  1. Obtenga el archivo de configuración de YAML del mapa de configuración del programa de escalado automático de clústeres.

    kubectl get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml
    
  2. En el campo data.workerPoolsConfig.json, compruebe que las agrupaciones de nodos trabajadores correctas están habilitadas con el tamaño mínimo y máximo por agrupación de nodos trabajadores.

    • "name": "<worker_pool_name>": el nombre de la agrupación de trabajadores en el mapa de configuración debe ser exactamente el mismo que el nombre de la agrupación de trabajadores en el clúster. Si se especifican varias agrupaciones de nodos trabajadores, se deben separar con comas. Para comprobar el nombre de las agrupaciones de trabajadores del clúster, ejecute ibmcloud ks worker-pool ls -c <cluster_name_or_ID>.
    • "minSize": 2: en general, el valor de minSize debe ser 2 o mayor. Recuerde que el valor de minSize no puede ser 0, y solo puede tener un minSize de 1 si inhabilita los ALB públicos.
    • "maxSize": 3: el valor de maxSize debe ser igual o mayor que el valor de minSize.
    • "enabled": true: establezca este valor en true para habilitar el escalado automático de la agrupación de nodos trabajadores.
    data:
        workerPoolsConfig.json: |
            [{"name": "default", "minSize": 2, "maxSize": 3, "enabled": true }]
    
  3. En el campo metadata.annotations.workerPoolsConfigStatus, compruebe si hay un mensaje de error FAILED CODE. Siga los pasos de recuperación que se incluyen en el mensaje de error. Por ejemplo, es posible que reciba un mensaje parecido al siguiente, que indica que debe tener los permisos correctos sobre el grupo de recursos en el que se encuentra el clúster.

    annotations:
        workerPoolsConfigStatus: '{"1:3:default":"FAILED CODE: 400
        ...
        \"description\":\"Unable
        to validate the request with resource group manager.\",\"type\":\"Authentication\\"recoveryCLI\":\"To
        list available resource groups, run ''ibmcloud resource groups''. Make sure
        that your cluster and the other IBM Cloud resources that you are trying to use
        are in the same resource group. Verify that you have permissions to work with
        the resource group. If you think that the resource group is set up correctly
        and you still can't use it, contact IBM Cloud support.\"}"}'
    

Paso 3: Revisar el estado de autoescalado del clúster

Revise el estado del programa de escalado automático de clústeres.

kubectl describe cm -n kube-system cluster-autoscaler-status
  • status: revise el mensaje de estado para obtener más información sobre resolución de problemas, si hay alguno.
  • Health: revise el estado general del programa de escalado automático de clústeres para ver si hay algún error.
  • ScaleUp: Revisar el estado de la actividad de ampliación. En general, si el número de nodos de trabajador que están listos y registrados coinciden, el escalado tiene NoActivity porque tu pool de trabajadores tiene suficientes nodos de trabajador.
  • ScaleDown: Revisar el estado de la actividad de reducción de escala. Si el programa de escalado automático de clústeres identifica NoCandidates, la agrupación de trabajadores no se reduce porque no se puede eliminar ninguno de los nodos trabajadores sin retirar recursos solicitados de las cargas de trabajo.
  • Events: revise los sucesos para obtener más información sobre resolución de problemas, si hay alguno.

Ejemplo de un estado de programa de escalado automático de clúster en buen estado

Data
====
status:
----
Cluster-autoscaler status at 2020-02-04 19:51:50.326683568 +0000 UTC:
Cluster-wide:
Health:      Healthy (ready=2 unready=0 notStarted=0 longNotStarted=0 registered=2longUnregistered=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleUp:     NoActivity (ready=2 registered=2)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleDown:   NoCandidates (candidates=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
Events:  none

Paso 4: Compruebe el pod del programa de escalado automático de clústeres

Compruebe el estado del pod del programa de escalado automático de clústeres.

  1. Obtenga el pod del programa de escalado automático de clústeres. Si el estado no es Running, describa el pod.

    kubectl get pods -n kube-system | grep ibm-iks-cluster-autoscaler
    
  2. Describa el pod del programa de escalado automático de clústeres. Revise la sección Events para obtener más información sobre la resolución de problemas.

    kubectl describe pod -n kube-system <pod_name>
    
  3. Revise la sección Command para comprobar que la configuración personalizada del programa de escalado automático de clústeres coincide con lo que espera, como por ejemplo en el valor scale-down-delay-after-add.

    Command:
        ./cluster-autoscaler
        --v=4
        --balance-similar-node-groups=true
        --alsologtostderr=true
        --stderrthreshold=info
        --cloud-provider=IKS
        --skip-nodes-with-local-storage=true
        --skip-nodes-with-system-pods=true
        --scale-down-unneeded-time=10m
        --scale-down-delay-after-add=10m
        --scale-down-delay-after-delete=10m
        --scale-down-utilization-threshold=0.5
        --scan-interval=1m
        --expander=random
        --leader-elect=false
        --max-node-provision-time=120m
    

Paso 5: Buscar en los registros del pod

Busque en los registros del pod del escalador automático del clúster mensajes relevantes, como mensajes de error como lastScaleDownFailTime, el Final scale-up plan, o eventos del escalador automático de clúster.

Si el pod de autoescalado de su clúster no está en buen estado y no puede transmitir registros, compruebe su instancia IBM Cloud Logs para ver los registros del pod. Tenga en cuenta que, si el administrador del clúster no ha habilitado IBM Cloud Logs para el clúster, es posible que no tenga ningún registro que revisar.

kubectl logs -n kube-system <pod_name> > logs.txt

Paso 5: Reiniciar el pod

Si no encuentra anomalías ni mensajes de error y ya ha habilitado el registro, reinicie el pod de programa de escalado automático del clúster. El despliegue vuelve a crear el pod.

kubectl delete pod -n kube-system <pod_name>

Paso 6: Inhabilitar y volver a habilitar

Opcional: si ha seguido los pasos de depuración y el clúster sigue sin escalarse, puede inhabilitar y volver a habilitar el programa de escalado automático del clúster editando el mapa de configuración.

  1. Edite el archivo iks-ca-configmap.

    kubectl edit cm iks-ca-configmap -n kube-system
    

    Salida de ejemplo:

    apiVersion: v1
    data:
    workerPoolsConfig.json: |
        [{"name": "default", "minSize": 2, "maxSize": 5, "enabled": true }]
    kind: ConfigMap
    metadata:
    annotations:
        workerPoolsConfigStatus: '{"2:5:default":"SUCCESS"}'
    creationTimestamp: "2020-03-24T17:44:35Z"
    name: iks-ca-configmap
    namespace: kube-system
    resourceVersion: "40964517"
    selfLink: /api/v1/namespaces/kube-system/configmaps/iks-ca-configmap
    uid: 11a1111a-aaaa-1a11-aaa1-aa1aaaa11111
    
  2. Establezca el parámetro enabled en false y guarde los cambios.

  3. Vuelva a editar el archivo iks-ca-configmap. Establezca el parámetro enabled en true y guarde los cambios.

    kubectl edit cm iks-ca-configmap -n kube-system
    
  4. Si el clúster todavía no se escala después de inhabilitar y volver a habilitar el programa de escalado automático del clúster, puede editar los parámetros minSize o maxSize en el iks-ca-configmap. A veces, la edición de los parámetros de de nodo de trabajador minSize y maxSize reinicia correctamente el programa de escalado automático del clúster.

    kubectl edit cm iks-ca-configmap -n kube-system
    
  5. Edite los parámetros minSize o maxSize y guarde los cambios.

Paso 8: Comprobar si se ha resuelto el problema

Supervise las actividades del programa de escalado automático de clústeres en el clúster para ver si se ha resuelto el problema. Si sigue teniendo problemas, consulte Comentarios, preguntas y soporte.