Depurando o autoscaler de cluster

Revise as opções que você tem para depurar seu autoscaler de cluster e localize as causas raiz para falhas.

Antes de começar: acesse o seu cluster do Red Hat OpenShift.

Etapa 1: Verificar a versão

  1. Verifique se o complemento de autoescalonamento do cluster está instalado e pronto para uso.
    ibmcloud oc cluster addon ls --cluster CLUSTER_NAME
    Saída de exemplo
    Name                 Version   Health State   Health Status   
cluster-autoscaler   1.0.4     normal         Addon Ready
  2. Compare a versão que é executada em seu cluster com a versão mais recente no log de mudanças do escalador automático de cluster.
  3. Se a versão estiver desatualizada, implemente a versão mais recente do escalador automático de cluster para o cluster.

Etapa 2: Verificar a configuração

Verifique se o autoscaler do cluster está configurado corretamente.

  1. Obtenha o arquivo de configuração YAML do configmap autoscaler do cluster.

    oc get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml

  2. No campo data.workerPoolsConfig.json, verifique se os conjuntos de trabalhadores corretos estão ativados com o tamanho mínimo e máximo por conjunto de trabalhadores.

    • "name": "<worker_pool_name>": o nome do conjunto de trabalhadores no configmap deve ser exatamente o mesmo que o nome do conjunto de trabalhadores no cluster. Múltiplos conjuntos de trabalhadores devem ser separados por vírgula. Para verificar o nome dos conjuntos de trabalhadores de cluster, execute ibmcloud oc worker-pool ls -c <cluster_name_or_ID>.
    • "minSize": 2: em geral, o minSize deve ser 2 ou maior.
    • "maxSize": 3: O maxSize deve ser igual ou maior do que o minSize.
    • "enabled": true: configure o valor como true para ativar o ajuste automático de escala do conjunto de trabalhadores.
    data:
    workerPoolsConfig.json: |
        [{"name": "default", "minSize": 2, "maxSize": 3, "enabled": true }]

  3. No campo metadata.annotations.workerPoolsConfigStatus, verifique se há uma mensagem de erro FAILED CODE. Siga qualquer etapa de recuperação que esteja na mensagem de erro. Por exemplo, é possível obter uma mensagem semelhante à seguinte, indicando que deve-se ter as permissões corretas para o grupo de recursos no qual o cluster está.

    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.\"}"}'

Etapa 3: Revisar o status do escalador automático de cluster

Revise o status do autoscaler de cluster.

oc describe cm -n kube-system cluster-autoscaler-status
  • status: revise a mensagem de status para obter mais informações de resolução de problemas, se houver.
  • Health: revise o funcionamento geral do autoscaler de cluster em busca de quaisquer erros ou falhas.
  • ScaleUp: Analisar o andamento das atividades de ampliação. Em geral, se o número de nós de trabalho que estão prontos e registrados for o mesmo, o aumento de escala não tem um NoActivity, pois seu conjunto de nós de trabalho já possui nós de trabalho suficientes.
  • ScaleDown: Verifique o andamento das atividades de redução de escala. Se o autoscalador de cluster identificar NoCandidates, seu conjunto de trabalhadores não será escalonado para baixo porque nenhum dos nós do trabalhador pode ser removido sem tirar recursos solicitados de suas cargas de trabalho.
  • Events: revise os eventos para obter mais informações de resolução de problemas, se houver.

Exemplo de um status funcional do escalador automático de cluster

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

Etapa 4: Verificar o pod do escalador automático de cluster

Verifique o funcionamento do pod de autoscaler de cluster.

  1. Obtenha o pod de autoscaler de cluster. Se o status não for Em execução, descreva o pod.

    oc get pods -n kube-system | grep ibm-iks-cluster-autoscaler

  2. Descreva o pod de autoscaler de cluster. Revise a seção Eventos para obter mais informações de resolução de problemas.

    oc describe pod -n kube-system <pod_name>

  3. Revise a seção Comando para verificar se a configuração de autoscaler de cluster customizada corresponde ao que você espera, como o 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

Etapa 5: Procurar os logs de pod

Procure mensagens relevantes nos logs do pod de escalador automático de cluster, como mensagens de falha como lastScaleDownFailTime, o Final scale-up plan ou eventos do escalador automático de cluster.

Se o pod do autoscaler do seu cluster estiver com o estado “inactive” e não conseguir transmitir logs, verifique os logs do pod na sua instância do IBM Cloud Logs. Note que se o seu administrador de cluster não ativou IBM Cloud Logs para o seu cluster, você pode não ter nenhum logs para revisar.

oc logs -n kube-system <pod_name> -c ibm-iks-cluster-autoscaler > logs.txt

Etapa 6: Reinicie o pod

Se você não localizar nenhuma falha ou mensagem de erro e já tiver ativado a criação de log, reinicie o pod do escalador automático de cluster. A implementação recria o pod.

oc delete pod -n kube-system <pod_name>

Etapa 6: Desativar e ativar novamente

Opcional: se você tiver concluído as etapas de depuração e o seu cluster ainda não for escalado, será possível desativar e reativar o ajustador automático de escala editando o mapa de configuração.

  1. Edite iks-ca-configmap.

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

    Saída de exemplo:

    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. Configure o parâmetro enabled para false e salve as suas mudanças.

  3. Edite iks-ca-configmap novamente. Configure o parâmetro ativado para true e salve suas mudanças.

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

  4. Se o seu cluster ainda não estiver sendo escalado depois de desativar e ativar novamente o ajustador automático de escala de cluster, será possível editar os parâmetros minSize ou maxSize no iks-ca-configmap. Às vezes, a edição dos parâmetros do trabalhador minSize e maxSize reinicia o escalador automático de cluster com êxito.

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

  5. Edite os parâmetros minSize ou maxSize e salve suas mudanças.

Etapa 7: Verifique se o problema foi resolvido

Monitore as atividades de autoscaler do cluster em seu cluster para ver se o problema está resolvido. Se você ainda experimentar problemas, consulte Feedback, perguntas e suporte.