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
- Compruebe que el complemento de autoescalado de clúster está instalado y listo.
Salida de ejemploibmcloud oc cluster addon ls --cluster <CLUSTER_NAME>
Name Version Health State Health Status cluster-autoscaler 1.0.4 normal Addon Ready
- 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.
- 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.
-
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
-
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, ejecuteibmcloud ks worker-pool ls -c <cluster_name_or_ID>
."minSize": 2
: en general, el valor deminSize
debe ser2
o mayor. Recuerde que el valor deminSize
no puede ser0
, y solo puede tener unminSize
de 1 si inhabilita los ALB públicos."maxSize": 3
: el valor demaxSize
debe ser igual o mayor que el valor deminSize
."enabled": true
: establezca este valor entrue
para habilitar el escalado automático de la agrupación de nodos trabajadores.
data: workerPoolsConfig.json: | [{"name": "default", "minSize": 2, "maxSize": 3, "enabled": true }]
-
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 tieneNoActivity
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 identificaNoCandidates
, 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.
-
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
-
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>
-
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.
-
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
-
Establezca el parámetro
enabled
enfalse
y guarde los cambios. -
Vuelva a editar el archivo
iks-ca-configmap
. Establezca el parámetro enabled entrue
y guarde los cambios.kubectl edit cm iks-ca-configmap -n kube-system
-
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
omaxSize
en eliks-ca-configmap
. A veces, la edición de los parámetros de de nodo de trabajadorminSize
ymaxSize
reinicia correctamente el programa de escalado automático del clúster.kubectl edit cm iks-ca-configmap -n kube-system
-
Edite los parámetros
minSize
omaxSize
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.