documentation.suse.com / Documentação do SUSE Edge / Solução de problemas / Solução de problemas de provisionamento de rede direcionado

49 Solução de problemas de provisionamento de rede direcionado

 

Os cenários de provisionamento de rede direcionado envolvem o uso de elementos do Metal3 e da CAPI para provisionar o cluster downstream. O EIB também é incluído para criar uma imagem do sistema operacional. Pode haver problemas quando o host é inicializado pela primeira vez ou durante os processos de inspeção ou provisionamento.

Problemas comuns
 

  • Firmware antigo: garanta que qualquer firmware diferente usado nos hosts físicos esteja atualizado. Isso inclui o firmware BMC, já que às vezes o Metal3 requer um específico/atualizado.

  • Falha no provisionamento com erros de SSL: se o servidor web que envia as imagens usa https, o Metal3 precisa ser configurado para injetar e confiar no certificado da imagem do IPA. Consulte a pasta do Kubernetes (Seção 40.3.4, “Pasta kubernetes”) para saber como incluir um arquivo ca-additional.crt no gráfico do Metal3.

  • Problemas no certificado ao inicializar os hosts com IPA: alguns fornecedores de servidor verificam a conexão SSL ao anexar imagens ISO de mídia virtual ao BMC, o que pode causar um problema porque os certificados gerados para a implantação do Metal3 são autoassinados. É possível que o host seja inicializado, mas acabe entrando em um shell UEFI. Consulte Desabilitando TLS para anexo de ISO de mídia virtual (Seção 1.6.2, “Desabilitando TLS para anexo de ISO de mídia virtual”) para saber como corrigir isso.

  • Referência a nome ou rótulo incorreto: se o cluster faz referência ao nome ou rótulo incorreto de um nó, ele aparece como implantado, mas o BMH continua como "Disponível". Revise as referências nos objetos envolvidos dos BMHs.

  • Problemas na comunicação com o BMC: certifique-se de que os pods do Metal3 executados no cluster de gerenciamento possam acessar o BMC dos hosts que estão sendo provisionados (normalmente, a rede do BMC é muito restrita).

  • Estado do host bare metal incorreto: o objeto BMH passa por diferentes estados (inspeção, preparação, provisionamento etc.) durante seu ciclo de vida Ciclo de vida da máquina de estado (em inglês). Se for detectado um estado incorreto, verifique o campo status do objeto BMH, pois ele contém mais informações, como kubectl get bmh <nome> -o jsonpath=’{.status}’| jq.

  • O host não é provisionado: em caso de falha no desprovisionamento de um host, é possível tentar removê-lo depois de adicionar a anotação "detached" ao objeto BMH desta forma: kubectl annotate bmh/<BMH> baremetalhost.metal3.io/detached=””.

  • Erros na imagem: verifique se a imagem que está sendo criada com o EIB para o cluster downstream está disponível, tem um checksum apropriado e não é grande demais para descompactar ou para o disco.

  • Incompatibilidade de tamanho de disco: por padrão, o disco não expande até se preencher por completo. Conforme explicado na seção do script growfs (Seção 1.3.4.1.2, “Script growfs”), é necessário incluir um script growfs na imagem que está sendo criada com o EIB para os hosts de cluster downstream.

  • Processo de limpeza travado: o processo de limpeza é repetido várias vezes. Se a limpeza não for mais possível devido a um problema com o host, desabilite primeiro a limpeza definindo o campo automatedCleanMode como disabled no objeto BMH.

    Atenção
    Atenção

    Não é recomendado remover manualmente o finalizador quando o processo de limpeza está falhando ou levando mais tempo do que o desejado. Se você fizer isso, o registro do host será removido do Kubernetes, mas ficará no Ironic. A ação executada no momento continua em segundo plano, e a tentativa de adicionar o host novamente pode falhar devido ao conflito.

  • Problemas nos pods do Metal3/Rancher Turtles/CAPI: o fluxo de implantação de todos os componentes obrigatórios é:

    • O controlador Rancher Turtles implanta o controlador do operador CAPI.

    • O controlador do operador CAPI depois implanta os controladores do provedor (núcleo CAPI, CAPM3 e plano de controle/inicialização RKE2).

Verifique se todos os pods estão sendo executados corretamente e consulte os registos caso não estejam.

Registros
 

  • Registros do Metal3: consulte os registros dos diferentes pods.

    kubectl logs -n metal3-system -l app.kubernetes.io/component=baremetal-operator
kubectl logs -n metal3-system -l app.kubernetes.io/component=ironic
    Nota
    Nota

    O pod metal3-ironic contém pelo menos 4 contêineres diferentes (ironic-httpd,` ironic-log-watch`, ironic & ironic-ipa-downloader (init)) no mesmo pod. Use o sinalizador -c ao usar o comando kubectl logs para verificar os registros de cada um dos contêineres.

    Nota
    Nota

    O contêiner ironic-log-watch expõe os registros do console dos hosts após a inspeção/provisionamento, desde que a conectividade de rede permita o envio desses registros de volta ao cluster de gerenciamento. Isso pode ser útil quando há erros de provisionamento, mas você não tem acesso direto aos registros do console do BMC.

  • Registros do Rancher Turtles: consulte os registros dos diferentes pods.

    kubectl logs -n rancher-turtles-system -l control-plane=controller-manager
kubectl logs -n rancher-turtles-system -l app.kubernetes.io/name=cluster-api-operator
kubectl logs -n rke2-bootstrap-system -l cluster.x-k8s.io/provider=bootstrap-rke2
kubectl logs -n rke2-control-plane-system -l cluster.x-k8s.io/provider=control-plane-rke2
kubectl logs -n capi-system -l cluster.x-k8s.io/provider=cluster-api
kubectl logs -n capm3-system -l cluster.x-k8s.io/provider=infrastructure-metal3

  • Registros do BMC: em geral, os BMCs têm uma IU em que é possível realizar grande parte da interação. Normalmente, há uma seção "registros" na qual observar possíveis problemas (imagem inacessível, falhas de hardware etc.).

  • Registros do console: conecte-se ao console BMC (pela IU da web do BMC, série etc.) e verifique se há erros nos registros gravados.

Etapas da solução de problemas
 

  1. Verifique o status de BareMetalHost:

    • kubectl get bmh -A mostra o estado atual. Procure por provisioning, ready, error, registering.

    • kubectl describe bmh -n <namespace> <nome_do_bmh> retorna os eventos detalhados e as condições que explicam o motivo da paralisação do BMH.

  2. Teste a conectividade do RedFish:

    • Use curl no plano de controle do Metal3 para testar a conectividade com os BMCs pelo Redfish.

    • Garanta que as credenciais corretas do BMC sejam fornecidas na definição de BareMetalHost-Secret.

  3. Verifique o status dos pods turtles/CAPI/metal3: garanta que os contêineres no cluster de gerenciamento estejam em funcionamento: kubectl get pods -n metal3-system e kubectl get pods -n rancher-turtles-system (veja também capi-system, capm3-system, rke2-bootstrap-system e rke2-control-plane-system).

  4. Verifique se o endpoint do Ironic é acessível ao host provisionado: o host provisionado precisa acessar o endpoint do Ironic para retornar os relatórios ao Metal3. Verifique o IP com kubectl get svc -n metal3-system metal3-metal3-ironic e tente acessá-lo via curl/nc.

  5. Verifique se a imagem do IPA é acessível ao BMC: o IPA é fornecido pelo endpoint do Ironic e precisa ser acessível ao BMC porque é usado como CD virtual.

  6. Verifique se a imagem do sistema operacional é acessível ao host provisionado: a imagem usada para provisionar o host precisa ser acessível ao próprio host (ao executar o IPA) já que ela será baixada temporariamente e gravada no disco.

  7. Examine os registros do componente Metal3: veja acima.

  8. Acione novamente a inspeção do BMH: se houver falha em uma inspeção ou se o hardware de um host disponível for modificado, um novo processo de inspeção poderá ser acionado anotando o objeto BMH com inspect.metal3.io: "". Consulte o guia Metal3 Controlling inspection (Inspeção de controle do Metal³) para obter mais informações.

  9. Console do IPA bare metal: para solucionar problemas do IPA, há algumas alternativas:

    • Habilite o "login automático". Isso habilita o login automático do usuário root ao se conectar ao console do IPA.

      Atenção
      Atenção

      Isso é apenas para fins de depuração, já que concede acesso total ao host.

      Para habilitar o login automático, o valor global.ironicKernelParams do Helm do Metal3 deve ser assim: console=ttyS0 suse.autologin=ttyS0 (dependendo do console, ttyS0 pode ser alterado). Em seguida, é necessário reimplantar o gráfico do Metal3. (Observe que ttyS0 é um exemplo, ele deve corresponder ao terminal real, por exemplo, em muitos casos, pode ser tty1 em bare metal. Para confirmar isso, observe a saída do console do ramdisk IPA na inicialização, em que /etc/issue mostra o nome do console).

      Outra maneira de fazer isso é alterar o parâmetro IRONIC_KERNEL_PARAMS no mapa de configuração ironic-bmo do namespace metal3-system. Isso pode ser mais fácil porque é feito pela edição de kubectl, mas será substituído ao atualizar o gráfico. Depois disso, o pod do Metal3 precisará ser reiniciado com kubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic.

    • Injete uma chave SSH para o usuário root no IPA.

      Atenção
      Atenção

      Isso é apenas para fins de depuração, já que concede acesso total ao host.

      Para injetar a chave SSH para o usuário root, o valor debug.ironicRamdiskSshKey do Helm do Metal3 deve ser usado. Em seguida, reimplante o gráfico do Metal3.

      Outra maneira de fazer isso é alterar o parâmetro IRONIC_RAMDISK_SSH_KEY no ironic-bmo configmap do namespace metal3-system. Isso pode ser mais fácil porque é feito pela edição de kubectl, mas será substituído durante a atualização do gráfico. Em seguida, o pod do Metal3 precisa ser reiniciado com kubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic

Documentation survey