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

A restauração de um aplicativo resulta em tamanho PV maior do que o PV original

Se você redimensionar um volume persistente após criar um backup e restaurar a partir desse backup, o tamanho do volume persistente corresponderá ao novo tamanho do PV em vez de usar o tamanho do backup.

Os clones de aplicativos falham usando uma versão específica do PostgreSQL

Clones de aplicativos dentro do mesmo cluster falham consistentemente com o gráfico Bitnami PostgreSQL 11.5.0. Para clonar com sucesso, use uma versão anterior ou posterior do gráfico.

Os clones do aplicativo falham ao usar as restrições de contexto de segurança do OCP (SCC) no nível da conta de serviço

Um clone de aplicativo pode falhar se as restrições de contexto de segurança originais forem configuradas no nível da conta de serviço dentro do namespace no cluster OpenShift Container Platform. Quando o clone de aplicação falha, ele aparece na área de aplicações gerenciadas no Astra Control Center com status Removed. Consulte "artigo da base de conhecimento" para obter mais informações.

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 padrão 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.

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.

Os instantâneos podem falhar com o controlador de instantâneos versão 4.2.0

Quando você usa a controladora de snapshot do Kubernetes (também conhecida como Snapshotter externo) versão 4.2.0 com Kubernetes 1,20 ou 1,21, os snapshots podem começar a falhar. Para evitar isso, use uma ferramenta diferente "versão suportada" de snapshotter externo, como a versão 4,2.1, com as versões 1,20 ou 1,21 do Kubernetes.

  1. Execute uma chamada POST para adicionar um arquivo kubeconfig atualizado ao /credentials endpoint e recuperar o atribuído id do corpo de resposta.

  2. Execute uma chamada PUT do /clusters ponto de extremidade usando o ID de cluster apropriado e defina o credentialID para o id valor da etapa anterior.

Depois de concluir estas etapas, a credencial associada ao cluster é atualizada e o cluster deve se reconetar e atualizar seu estado para available.