Skip to main content
È disponibile una versione più recente di questo prodotto.
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Limitazioni note

Collaboratori
PDF

Le limitazioni note identificano piattaforme, dispositivi o funzioni non supportate da questa versione del prodotto o che non interagiscono correttamente con esso. Esaminare attentamente queste limitazioni.

Lo stesso cluster non può essere gestito da due istanze di Astra Control Center

Se si desidera gestire un cluster su un’altra istanza di Astra Control Center, è necessario innanzitutto "annullare la gestione del cluster" dall’istanza in cui viene gestito prima di gestirlo su un’altra istanza. Dopo aver rimosso il cluster dalla gestione, verificare che il cluster non sia gestito eseguendo questo comando:

oc get pods n -netapp-monitoring

Non devono essere presenti pod in esecuzione nello spazio dei nomi, altrimenti lo spazio dei nomi non dovrebbe esistere. Se uno di questi è vero, il cluster non viene gestito.

Astra Control Center non è in grado di gestire due cluster con lo stesso nome nello stesso cloud

Se si tenta di aggiungere un cluster con lo stesso nome di un cluster già esistente nel cloud, l’operazione non riesce. Questo problema si verifica più spesso in un ambiente Kubernetes standard se non è stato modificato il nome predefinito del cluster nei file di configurazione Kubernetes.

Per risolvere il problema, procedere come segue:

  1. Modifica la configurazione di kubeadm-config:

    kubectl edit configmaps -n kube-system kubeadm-config

  2. Modificare il clusterName valore campo da kubernetes (Il nome predefinito di Kubernetes) con un nome personalizzato univoco.

  3. Modifica kubeconfig (.kube/config).

  4. Aggiorna il nome del cluster da kubernetes su un nome personalizzato univoco (xyz-cluster viene utilizzato negli esempi seguenti). Eseguire l’aggiornamento in entrambi clusters e. contexts sezioni come mostrato in questo esempio:

    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

I cloni delle applicazioni installate utilizzando gli operatori di riferimento pass-by possono fallire

Astra Control supporta le applicazioni installate con operatori con ambito namespace. Questi operatori sono generalmente progettati con un’architettura "pass-by-value" piuttosto che "pass-by-reference". Di seguito sono riportate alcune applicazioni per operatori che seguono questi modelli:

Si noti che Astra Control potrebbe non essere in grado di clonare un operatore progettato con un’architettura "pass-by-reference" (ad esempio, l’operatore CockroachDB). Durante questi tipi di operazioni di cloning, l’operatore clonato tenta di fare riferimento ai segreti di Kubernetes dall’operatore di origine, nonostante abbia il proprio nuovo segreto come parte del processo di cloning. L’operazione di clonazione potrebbe non riuscire perché Astra Control non è a conoscenza dei segreti di Kubernetes nell’operatore di origine.

Il cluster è in removed stato anche se il cluster e la rete funzionano in modo diverso come previsto

Se un cluster si trova in removed state Yet la connettività di rete e del cluster sembra sana (i tentativi esterni di accesso al cluster utilizzando le API di Kubernetes sono riusciti), il kubeconfig che hai fornito ad Astra Control potrebbe non essere più valido. Ciò può essere dovuto alla rotazione o alla scadenza del certificato sul cluster. Per risolvere questo problema, aggiornare le credenziali associate al cluster in Astra Control utilizzando "API di controllo Astra":

  1. Eseguire UNA CHIAMATA POST per aggiungere un file kubeconfig aggiornato a /credentials endpoint e recuperare l’assegnato id dal corpo di risposta.

  2. Eseguire una chiamata PUT da /clusters Endpoint utilizzando l’ID cluster appropriato e impostare credentialID al id valore dal passo precedente.

Una volta completata questa procedura, la credenziale associata al cluster viene aggiornata e il cluster si riconnetterà e aggiornerà il proprio stato a. available.

Le applicazioni implementate dall’operatore CON ambito cluster e abilitato OLM non sono supportate

Astra Control Center non supporta le applicazioni implementate con operatori abilitati per Operator Lifecycle Manager (OLM) o con gli operatori con ambito cluster.

La clonazione delle applicazioni può essere eseguita solo con la stessa distribuzione K8s

Se clonate un’applicazione tra cluster, i cluster di origine e di destinazione devono essere la stessa distribuzione di Kubernetes. Ad esempio, se clonate un’applicazione da un cluster OpenShift 4.7, utilizzate un cluster di destinazione che è anche OpenShift 4.7.

I bucket S3 in Astra Control Center non riportano la capacità disponibile

Prima di eseguire il backup o la clonazione delle applicazioni gestite da Astra Control Center, controllare le informazioni del bucket nel sistema di gestione ONTAP o StorageGRID.

MetalLB 0.11.0 non è supportato

MetalLB 0.11.0 non è un bilanciamento del carico supportato per Astra Control Center. Per ulteriori informazioni sui bilanciatori di carico supportati, vedere "Requisiti di Astra Control Center".

Le app implementate con Helm 2 non sono supportate

Se utilizzi Helm per implementare le app, Astra Control Center richiede Helm versione 3. La gestione e la clonazione delle applicazioni implementate con Helm 3 (o aggiornate da Helm 2 a Helm 3) sono completamente supportate. Per ulteriori informazioni, vedere "Requisiti di Astra Control Center".

Astra Control Center non convalida i dati immessi per il server proxy

Assicurati di "inserire i valori corretti" quando si stabilisce una connessione.

Data Protection per Astra Control Center come applicazione non ancora disponibile

Questa release non supporta la possibilità di gestire Astra come applicazione utilizzando opzioni di snapshot, backup o ripristino.

I pod non integri influiscono sulla gestione delle applicazioni

Se un’applicazione gestita ha dei pod in uno stato non integro, Astra Control non può creare nuovi backup e cloni.

Le connessioni esistenti a un pod Postgres causano errori

Quando si eseguono operazioni su POD Postgres, non si dovrebbe connettersi direttamente all’interno del pod per utilizzare il comando psql. Astra Control richiede l’accesso a psql per bloccare e scongelare i database. Se è presente una connessione preesistente, lo snapshot, il backup o il clone non avranno esito positivo.

Trident non viene disinstallato da un cluster

Quando si disgestisce un cluster da Astra Control Center, Trident non viene disinstallato automaticamente dal cluster. Per disinstallare Trident, è necessario "Seguire questa procedura nella documentazione di Trident".

Trova ulteriori informazioni