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.

Limitações conhecidas

Colaboradores
PDFs

As limitações conhecidas identificam plataformas, dispositivos ou funções que não são suportadas por esta versão do produto ou que não interoperam corretamente com ele. Revise essas limitações com cuidado.

O mesmo cluster não pode ser gerenciado por duas instâncias do Astra Control Center

Se você quiser gerenciar um cluster em outra instância do Astra Control Center, primeiro você deve "desgerenciar o cluster"usar a instância na qual ele é gerenciado antes de gerenciá-lo em outra instância. Depois de remover o cluster do gerenciamento, verifique se o cluster não é gerenciado executando este comando:

oc get pods n -netapp-monitoring

Não deve haver pods em execução nesse namespace ou o namespace não deve existir. Se qualquer um deles for verdadeiro, o cluster não será gerenciado.

O Astra Control Center não pode gerenciar dois clusters com nomes idênticos na mesma nuvem

Se você tentar adicionar um cluster com o mesmo nome de um cluster que já existe na nuvem, a operação falhará. Esse problema ocorre na maioria das vezes em um ambiente padrão do Kubernetes se você não tiver alterado o nome padrão do cluster nos arquivos de configuração do Kubernetes.

Como solução alternativa, faça o seguinte:

  1. Edite seu kubeadm-config ConfigMap:

    kubectl edit configmaps -n kube-system kubeadm-config

  2. Altere o clusterName valor do campo kubernetes de (o nome padrão do Kubernetes) para um nome personalizado exclusivo.

  3. Editar kubeconfig (.kube/config).

  4. Atualizar nome do cluster de kubernetes para um nome personalizado exclusivo (xyz-cluster`é usado nos exemplos abaixo). Faça a atualização em ambas `clusters as seções e contexts, conforme mostrado neste exemplo:

    apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: ExAmPLERb2tCcjZ5K3E2Njk4eQotLExAMpLEORCBDRVJUSUZJQ0FURS0txxxxXX==
    server: https://x.x.x.x:6443
  name: xyz-cluster
contexts:
- context:
    cluster: xyz-cluster
    namespace: default
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes

Clones de aplicativos instalados usando operadores de referência pass by podem falhar

O Astra Control é compatível com aplicativos instalados com operadores com escopo de namespace. Esses operadores são geralmente projetados com uma arquitetura "pass-by-value" em vez de "pass-by-reference". A seguir estão alguns aplicativos de operador que seguem estes padrões:

Observe que o Astra Control pode não ser capaz de clonar um operador projetado com uma arquitetura "pass-by-reference" (por exemplo, o operador CockroachDB). Durante esses tipos de operações de clonagem, o operador clonado tenta consultar os segredos do Kubernetes do operador de origem, apesar de ter seu próprio novo segredo como parte do processo de clonagem. A operação de clone pode falhar porque o Astra Control não conhece os segredos do Kubernetes no operador de origem.

O cluster está removed no estado, embora o cluster e a rede estejam funcionando conforme esperado

Se um cluster ainda estiver removed no estado de cluster e a conetividade de rede parecer saudável (tentativas externas de acessar o cluster usando APIs do Kubernetes são bem-sucedidas), o kubeconfig que você forneceu ao Astra Control pode não ser mais válido. Isto pode dever-se à rotação ou expiração do certificado no cluster. Para corrigir esse problema, atualize as credenciais associadas ao cluster no Astra Control usando o "API Astra Control":

  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.

O operador habilitado para OLM e com escopo de cluster implantaram aplicativos não suportados

O Astra Control Center não oferece suporte a aplicativos que são implantados com operadores habilitados para o Operator Lifecycle Manager (OLM) ou operadores com escopo de cluster.

A clonagem de aplicações só pode ser feita com a mesma distribuição do K8s

Se você clonar uma aplicação entre clusters, os clusters de origem e destino precisam ser a mesma distribuição do Kubernetes. Por exemplo, se você clonar um aplicativo de um cluster OpenShift 4,7, use um cluster de destino que também é OpenShift 4,7.

Os buckets do S3 no Astra Control Center não relatam a capacidade disponível

Antes de fazer backup ou clonar aplicativos gerenciados pelo Astra Control Center, verifique as informações do bucket no sistema de gerenciamento ONTAP ou StorageGRID.

MetalLB 0.11.0 não é suportado

O metalLB 0.11.0 não é um balanceador de carga compatível para o Astra Control Center. Para obter mais informações sobre balanceadores de carga suportados, "Requisitos do Astra Control Center"consulte .

As aplicações implementadas com o Helm 2 não são suportadas

Se você usar o Helm para implantar aplicativos, o Astra Control Center precisará do Helm versão 3. O gerenciamento e clonagem de aplicativos implantados com o Helm 3 (ou atualizados do Helm 2 para o Helm 3) é totalmente compatível. Para obter mais informações, "Requisitos do Astra Control Center"consulte .

O Astra Control Center não valida os detalhes inseridos para o servidor proxy

Certifique-se de que você "introduza os valores corretos" ao estabelecer uma conexão.

Proteção de dados para Astra Control Center como aplicação ainda não disponível

Esta versão não é compatível com a capacidade de gerenciar o Astra como aplicativo usando opções de snapshot, backup ou restauração.

Pods pouco saudáveis afetam o gerenciamento de aplicativos

Se um aplicativo gerenciado tiver pods em um estado de integridade, o Astra Control não poderá criar novos backups e clones.

As conexões existentes com um pod Postgres causam falhas

Quando você executa operações nos pods Postgres, você não deve se conetar diretamente dentro do pod para usar o comando psql. O Astra Control requer acesso psql para congelar e descongelar os bancos de dados. Se houver uma conexão pré-existente, o snapshot, o backup ou o clone falhará.

O Trident não é desinstalado de um cluster

Quando você desgerencia um cluster do Astra Control Center, o Trident não é desinstalado automaticamente do cluster. Para desinstalar o Trident, você precisará "Siga estas etapas na documentação do Trident".

Encontre mais informações