Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Problemas conhecidos

Colaboradores

Backups e snapshots de aplicativos falharão se a volumesnapshotclass for adicionada após o gerenciamento de um cluster

Backups e snapshots falham UI 500 error nesse cenário. Como solução alternativa, atualize a lista de aplicativos.

Os clones do aplicativo falham após a implantação de uma aplicação com uma classe de storage definida

Depois que um aplicativo é implantado com uma classe de armazenamento explicitamente definida (por exemplo, helm install …​-set global.storageClass=netapp-cvs-perf-extreme), as tentativas subsequentes de clonar o aplicativo exigem que o cluster de destino tenha a classe de armazenamento especificada originalmente. Clonar um aplicativo com uma classe de storage definida explicitamente para um cluster que não tenha a mesma classe de storage falhará. Não há etapas de recuperação neste cenário.

O gerenciamento de um cluster com Astra Control Center falha quando o arquivo kubeconfig contém mais de um contexto

Você não pode usar um kubeconfig com mais de um cluster e contexto nele. Consulte "artigo da base de conhecimento" para obter mais informações.

Um pod de monitoramento pode falhar em ambientes do Istio

Se você emparelhar o Astra Control Center com o Cloud Insights em um ambiente Istio, o telegraf-rs pod poderá falhar. Como solução alternativa, execute as seguintes etapas:

  1. Encontre o pod avariado:

    kubectl -n netapp-monitoring get pod | grep Error

    Você deve ver saída semelhante ao seguinte:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
  2. Reinicie o pod avariado, substituindo <pod_name_from_output> pelo nome do pod afetado:

    kubectl -n netapp-monitoring delete pod <pod_name_from_output>

    Você deve ver saída semelhante ao seguinte:

    pod "telegraf-rs-fhhrh" deleted
  3. Verifique se o pod foi reiniciado e não está em um estado de erro:

    kubectl -n netapp-monitoring get pod

    Você deve ver saída semelhante ao seguinte:

    NAME READY STATUS RESTARTS AGE
    telegraf-rs-rrnsb 2/2 Running 0 11s

As operações de gerenciamento de dados da aplicação falham com erro de serviço interno (500) quando o Astra Trident está off-line

Se o Astra Trident em um cluster de aplicações ficar offline (e for colocado novamente online) e se forem encontrados 500 erros de serviço interno ao tentar o gerenciamento de dados de aplicações, reinicie todos os nós do Kubernetes no cluster de aplicações para restaurar a funcionalidade.

Encontre mais informações