View a markdown version of this page

Ripristina un cluster Amazon EKS - AWS Backup
Amazon EKS backups

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ripristina un cluster Amazon EKS

Puoi ripristinare i backup del cluster EKS utilizzando la AWS Backup console o la CLI. I backup EKS sono punti di ripristino compositi che includono sia backup dello stato del cluster EKS che backup persistenti dei volumi.

AWS Backup supporta diverse esperienze di ripristino, inclusi i ripristini granulari a livello di namespace. I ripristini non sono distruttivi e non sovrascriveranno alcun oggetto Kubernetes esistente nel cluster EKS di destinazione. I ripristini inoltre non sovrascriveranno le versioni Kubernetes del cluster EKS di destinazione.

I backup EKS devono essere ripristinati su un cluster EKS di destinazione, ovvero un cluster Amazon EKS che è stato predisposto. Come parte del flusso di lavoro di ripristino, puoi scegliere di creare un nuovo cluster EKS che AWS Backup verrà creato per tuo conto.

Nota

AWS Backup fornirà un set limitato di opzioni per la creazione di un nuovo cluster EKS come parte di un ripristino. Per tutte le funzionalità di creazione di cluster EKS, i clienti possono creare un nuovo cluster EKS utilizzando la console EKS o le API e selezionarlo come destinazione di ripristino.

Funzionalità di ripristino per Amazon EKS

Tipo di ripristino Obiettivo di ripristino Ripristina il comportamento
Ripristino del cluster esistente Ripristino nel cluster EKS di origine o nel cluster EKS esistente Ripristina tutte le risorse Kubernetes e i volumi persistenti nei cluster EKS esistenti. Tutti i ripristini non sono distruttivi e gli oggetti esistenti non vengono sovrascritti. Per gli oggetti che vengono ignorati, puoi abbonarti alle notifiche SNS https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html
Ripristino di un nuovo cluster Crea un nuovo cluster Amazon EKS come parte del ripristino EKS Restore crea un nuovo cluster EKS e ripristina tutte le risorse Kubernetes e i volumi persistenti nel cluster appena creato
Ripristino dello spazio dei nomi Cluster Amazon EKS esistente I ripristini solo gli spazi dei nomi specificati, le relative risorse Kubernetes e i corrispondenti ripristini dello storage persistente non sono distruttivi e gli oggetti esistenti non vengono sovrascritti. Per gli oggetti che vengono ignorati, puoi iscriverti alle notifiche SNS
Ripristino persistente dello storage Dipende dallo storage persistente Ripristina lo storage persistente individuale come ripristini autonomi. Vedi Restore Behavior of Amazon EBS, Amazon S3, Amazon EFS. https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-efs.html

Autorizzazioni

Le autorizzazioni richieste dipendono dal tipo di ripristino e dalla destinazione di destinazione.

  • AWS Backup la policy gestita di Amazon EKS AWSBackupServiceRolePolicyForRestores contiene le autorizzazioni necessarie per ripristinare il cluster Amazon EKS e lo storage persistente EBS ed EFS.

  • Se il tuo cluster EKS contiene un bucket S3 o stai ripristinando solo il punto di ripristino S3 secondario, dovrai assicurarti che le seguenti politiche o autorizzazioni all'interno siano assegnate al tuo ruolo. AWSBackupServiceRolePolicyForS3Restore

Considerazioni prima del ripristino

Prima di iniziare un processo di ripristino EKS, esaminate quanto segue. Se stai ripristinando un backup EKS che è stato copiato su più account o aree geografiche, assicurati di controllare queste considerazioni prima dei ripristini per evitare errori di ripristino.

  1. Ruoli IAM: quando si esegue il ripristino su un cluster diverso, i ruoli IAM utilizzati nel cluster di origine (ad esempio Pod identity, IRSA). Le configurazioni del provider OIDC (ecc.) devono essere presenti nell'account/regione come cluster di destinazione.

  2. Verifica la versione e la compatibilità di EKS: le versioni API degli oggetti che desideri ripristinare devono essere della stessa versione (o la più simile possibile) e supportate nel nuovo cluster. AWS Backup eseguirà al meglio il ripristino tra versioni EKS, anche se potrebbero sorgere problemi di compatibilità in caso di ripristino tra versioni significativamente diverse.

  3. Classi di archiviazione corrispondenti: per i ripristini su un cluster EKS esistente, assicuratevi che i componenti aggiuntivi CSI Storage Driver appropriati siano installati prima del ripristino

  4. Bucket S3: quando ripristini un cluster EKS con S3 Buckets, assicurati che il bucket S3 abbia una versione e sia accessibile nell'account o nella regione di destinazione.

  5. Archivio di immagini: quando ripristini un cluster EKS, assicurati che l'account o la regione del cluster EKS di destinazione abbiano accesso alle immagini a cui si fa riferimento come parte del ripristino. Verifica che il tuo registro disponga di sufficienti autorizzazioni interregionali/relative agli account.

  6. Gruppi di sicurezza: i gruppi di sicurezza devono essere pre-creati per ALB, Pod Identities, EKS Node Groups ecc. nell'account e nella regione di destinazione se si crea un nuovo cluster EKS come parte del ripristino

  7. Zone e nodi di disponibilità EBS: le zone di disponibilità in cui si ripristinano i volumi EBS devono essere mappate alla zona di disponibilità di un nodo EKS esistente

  8. Non-destructive ripristini: tutti i ripristini EKS saranno non distruttivi e non sovrascriveranno gli oggetti Kubernetes del ripristino di destinazione.

  9. Abilita EKS Audit Logs: Abilita EKS Audit Logs per ulteriori registrazioni e risoluzione dei problemi prima del ripristino. Puoi anche abbonarti alle notifiche SNS per notificare gli oggetti ignorati o non riusciti durante il ripristino.

  10. Nuovo buffer di ripristino per la creazione di un cluster EKS: quando si crea un nuovo cluster EKS durante il ripristino, AWS Backup introduce un buffer di 15 minuti dopo che il cluster EKS ha raggiunto lo stato disponibile ma prima di creare eventuali risorse EKS aggiuntive. Questo buffer assicura che tutti i componenti EKS sottostanti siano completamente inizializzati prima della creazione delle risorse dipendenti.

  11. Dati utente nel modello di avvio: quando si crea un gruppo di nodi utilizzando un modello di avvio, non specificarli spec.cluster nella sezione dei dati utente del modello di avvio. Amazon EKS inserisce automaticamente i parametri di identità del cluster (apiServerEndpointcertificateAuthority,, eserviceIpv4Cidr) e li unisce a qualsiasi configurazione aggiuntiva definita nei dati utente.

Configurazioni EKS

Quando ripristini l'Amazon composito AWS Backup, scegli il tipo di ripristino e la destinazione di destinazione. Puoi scegliere di ripristinare il cluster EKS di origine, un cluster EKS esistente o creare un nuovo cluster EKS come destinazione di ripristino. Per i nuovi cluster EKS, è possibile scegliere di utilizzare le stesse impostazioni di infrastruttura esistenti (ad esempio VPC, sottoreti) del cluster di cui è stato eseguito il backup o configurarne di nuove. AWS Backup è progettato per eseguire un ripristino non distruttivo che non sovrascrive le risorse esistenti.

Per i ripristini dei namespace, è possibile specificare fino a 5 namespace da ripristinare in modo selettivo. Vengono ripristinate solo le risorse con ambito di namespace, mentre le risorse con ambito cluster sono escluse ad eccezione dei volumi persistenti correlati.

Come impostazione avanzata, puoi scegliere di modificare l'ordine di ripristino degli oggetti Kubernetes. Per impostazione predefinita, AWS Backup ripristinerà tutti gli oggetti Kubernetes nel seguente ordine:

Risorse Kubernetes con ambito di cluster

  1. Definizioni di risorse personalizzate

  2. Namespace (il namespace stesso, non le risorse all'interno di tale namespace)

  3. StorageClasses

  4. PersistentVolumes

Namespace Scoped Kubernetes Resources

  1. PersistentVolumeClaims

  2. Segreti

  3. ConfigMaps

  4. ServiceAccounts

  5. LimitRanges

  6. Pod

  7. ReplicaSets

Configurazioni di archiviazione persistenti

Come parte del backup e ripristino composito di Amazon EKS, il secondo passaggio consisterà nella configurazione delle configurazioni di storage persistente. Questo varierà in base allo storage persistente di cui è stato eseguito il backup come parte del cluster EKS.

Per gli snapshot di Amazon EBS è necessario fornire una zona di disponibilità, in cui il volume Amazon EBS verrà ripristinato e creato. AWS Backup tenterà quindi di creare il pod EKS nella stessa zona di disponibilità selezionata in modo che il volume possa essere rimontato sul cluster EKS come parte del ripristino.

Come parte del ripristino, AWS Backup rimonterà i volumi Amazon EBS e i bucket Amazon S3 nel cluster EKS ripristinato. I file system Amazon EFS vengono ripristinati con prefissi casuali e richiedono la creazione manuale di punti di accesso dopo il ripristino per il rimontaggio nel cluster EKS. AWS Backup non crea punti di accesso né monta obiettivi per tuo conto, consulta le linee guida qui per i punti di accesso e gli obiettivi di montaggio. https://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-create-delete-mount-targets.html

Procedura di ripristino di Amazon EKS

Segui questi passaggi per ripristinare i backup di Amazon EKS utilizzando la AWS Backup console o AWS CLI:

Console
Per ripristinare il cluster Amazon EKS

  1. Apri la AWS Backup console all'indirizzo https://console.aws.amazon.com/backup.

  2. Nel riquadro di navigazione scegliere Backup vaults (Vault di backup).

  3. Scegli il vault di backup che contiene il tuo backup Amazon EKS, quindi seleziona il punto di ripristino per il tuo backup Amazon EKS.

  4. Scegli Restore (Ripristina).

  5. Nel riquadro delle opzioni di ripristino, scegli il tipo di ripristino:

    • Ripristina il cluster EKS completo: ripristina l'intero punto di ripristino composito di Amazon EKS

    • Seleziona i namespace da ripristinare: ripristina fino a cinque namespace specifici

  6. Configura la destinazione di destinazione:

    • Per il ripristino del cluster, scegli di creare un nuovo cluster o di utilizzare un cluster esistente

    • Per i nuovi cluster, specifica il nome del cluster, la versione Kubernetes, la configurazione VPC, i ruoli IAM, le sottoreti, i gruppi di sicurezza aggiuntivi, le impostazioni dei gruppi di nodi, i profili fargate e i ruoli IAM di identità Pod

    • Per i cluster esistenti, seleziona il cluster di destinazione dal menu a discesa

    • Per il ripristino dello spazio dei nomi, specifica i nomi del cluster e dello spazio dei nomi di destinazione

  7. Facoltativamente, configura le impostazioni avanzate per l'ordine di ripristino personalizzato per le risorse Kubernetes.

  8. Scegli il ruolo di ripristino IAM per il job. Se non utilizzi il ruolo predefinito, assicurati che il ruolo selezionato includa l'PassRole autorizzazione iam:.

  9. Scegli Restore backup (Ripristina backup).

AWS CLI

Usa il aws backup start-restore-job comando con i EKS-specific metadati Amazon.

I metadati richiesti dipendono dal tipo di ripristino. Tutte le operazioni di ripristino richiedono il parametro. clusterName

Ripristina i punti di ripristino di Amazon EKS tramite AWS CLI

Usa StartRestoreJob. Puoi specificare i seguenti metadati durante i ripristini di Amazon EKS:

Metadati obbligatori:

  • clusterName- Nome del cluster in cui eseguire il ripristino

Metadati opzionali:

  • newCluster- (true/false) Se dobbiamo creare un nuovo cluster EKS durante il ripristino. Se newCluster è «true», si applicano i seguenti campi di metadati:

    • eksClusterVersion- Versione K8s del cluster desiderata se si desidera aumentare la versione del cluster durante il ripristino

    • clusterRole- L'ARN del ruolo IAM da collegare al cluster EKS creato

    • encryptionConfigProviderKeyArn- Specificare l'ARN della chiave KMS per crittografare il cluster di destinazione. Può essere la chiave KMS del cluster di origine o una chiave KMS diversa. È necessario fornire una chiave KMS diversa quando si esegue il ripristino tra regioni o tra account. Ometti completamente questi metadati se il cluster di origine non è crittografato.

    • clusterVpcConfig- VPC/Networking configurazione per il cluster EKS creato. Questo campo ha i seguenti campi annidati:

      • vpcId- Il VPC associato al tuo cluster

      • subnetIds [Required]- Le sottoreti associate al cluster

      • securityGroupIds [Required]- I gruppi di sicurezza aggiuntivi associati al cluster

    • nodeGroups- I gruppi di nodi gestiti da creare sul cluster EKS. Il file NodeGroups per il ripristino deve avere tutti gli stessi gruppi di nodi presenti al momento del backup e avere un nodo corrispondenteGroupId.

      • nodeGroupId [Required]- L'ID del gruppo di nodi

      • subnetIds [Required]- Le sottoreti specificate per il gruppo Auto Scaling associato al gruppo di nodi

      • instanceTypes- Se il gruppo di nodi non è stato distribuito con un modello di avvio, questo è il tipo di istanza associato al gruppo di nodi

      • nodeRole [Required]- Il ruolo IAM associato al tuo gruppo di nodi

      • securityGroupIds- Gli ID dei gruppi di sicurezza a cui è consentito l'accesso SSH ai nodi

      • remoteAccessEc2SshKey- Il nome della chiave SSH di Amazon EC2 che fornisce l'accesso per la comunicazione SSH con i nodi del gruppo di nodi gestiti

      • launchTemplateId- Specifica l'ID del modello di avvio per creare il gruppo di nodi. Può essere l'ID del modello di avvio del cluster di origine o un ID del modello di avvio diverso. Se il modello di avvio del cluster di origine contiene un endpoint codificato che punta al cluster di origine stesso, è necessario fornire un ID del modello di avvio diverso. Ometti completamente questi metadati se il cluster di origine non utilizza un modello di avvio.

      • launchTemplateVersion- Versione del modello di avvio associata all'ID del modello di avvio specificato.

    • fargateProfiles- I profili Fargate da creare sul cluster EKS. I profili Fargate per il ripristino devono avere tutti gli stessi profili Fargate al momento del backup e avere un nome corrispondente.

      • name [Required]- Il nome del profilo Fargate

      • subnetIds- Gli ID delle sottoreti in cui lanciare un Pod

      • podExecutionRoleArn [Required]- L'ARN del ruolo IAM del ruolo di esecuzione del Pod da utilizzare per un Pod che corrisponde ai selettori nel profilo Fargate

    • podIdentityAssociations- Le associazioni di identità dei pod da creare sul cluster EKS

      • associationId- L'ID della Pod Identity Association

      • roleArn- L'ARN del ruolo IAM per la Pod Identity Association

  • kubernetesRestoreOrder- Ignora l'ordine in cui vengono ripristinati i manifesti di Kubernetes. Questo ordine avrà la precedenza sull'ordine di ripristino del servizio predefinito. Questo segue il formato: group/version /kind or version/kind

    Ad esempio: ["v1/persistentvolumes","v1/pods","customresource/v2/custom"]

  • namespaceLevelRestore- (true/false) Se desideri eseguire un ripristino a livello di namespace

  • namespaces- Un elenco di namespace da ripristinare se lo spazio dei nomi LevelRestore è «true». Può fornire fino a 5 namespace da ripristinare.

    Ad esempio: ["ns-1","ns-2","ns-3","ns-4","ns-5"]

  • restoreKubernetesManifestsOnly- (true/false) Se desideri ripristinare solo i file manifest di Kubernetes e nessun sistema di storage persistente (EBS, S3, EFS, ecc.)

  • nestedRestoreJobs- Ripristina la configurazione dei metadati di tutti i punti di ripristino annidati per i sistemi di storage nel punto di ripristino composito. PersistentVolume Questa è una mappa di RecoveryPointArn: di quel punto RestoreMetadata di ripristino

Ripristina su un cluster esistente 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false"}' \
    --resource-type "EKS"

Ripristina namespace specifici in un cluster esistente: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","namespaces":"[\"ns-1\",\"ns-2\",\"ns-3\",\"ns-4\",\"ns-5\"]"}' \
    --resource-type "EKS"

Ripristina i volumi persistenti annidati in un cluster esistente: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","nestedrestorejobs":"{\"arn:aws:ec2:us-west-2::snapshot/snap-abc123\":\"{\\\"AvailabilityZone\\\":\\\"us-west-2a\\\"}\",\"arn:aws:backup:us-west-2:123456789012:recovery-point:fa71a304-2555-4c37-8128-f154b9578032\":\"{\\\"DestinationBucketName\\\":\\\"bucket-name\\\"}\"}"}' \
    --resource-type "EKS"

Ripristina su un nuovo cluster 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"new-cluster","newCluster":"true","clusterRole":"arn:aws:iam::123456789012:role/EKSClusterRole","eksClusterVersion":"1.33","encryptionConfigProviderKeyArn":"arn:aws:kms:us-west-2:123456789012:key/ecb2b326-784d-4ec0-8d07-20ab826b5a13","clusterVpcConfig":"{\"vpcId\":\"vpc-1234\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"securityGroupIds\":[\"sg-123\"]}","nodeGroups":"[{\"nodeGroupId\":\"nodegroup-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"nodeRole\":\"arn:aws:iam::123456789012:role/EKSNodeGroupRole\",\"instanceTypes\":[\"t3.small\"],\"launchTemplateId\":\"lt-0b13949aae3f2b867\",\"launchTemplateVersion\":\"1\"}]","fargateProfiles":"[{\"name\":\"fargate-profile-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"podExecutionRoleArn\":\"arn:aws:iam::123456789012:role/EKSFargateProfileRole\"}]"}' \
    --resource-type "EKS"

Dopo aver avviato il processo di ripristino, utilizza describe-restore-job per monitorare l'avanzamento:

aws backup describe-restore-job --restore-job-id restore-job-id

È possibile sottoscrivere gli eventi di notifica per gli oggetti non riusciti e ignorati per il ripristino. Per ulteriori informazioni, consulta Opzioni di notifica con AWS Backup.

Messaggi di stato di ripristino di Amazon EKS

Al termine di un processo di ripristino, potresti visualizzare i seguenti messaggi di stato. La tabella mostra i possibili scenari e i corrispondenti valori di stato del processo:

Scenario Stato di un processo Messaggio di esempio
Tutti gli oggetti sono stati ripristinati con successo COMPLETED —
Impossibile ripristinare uno o più oggetti COMPLETED «Il ripristino di uno o più oggetti Kubernetes non è stato possibile. Per ricevere una notifica di questi errori, abilita le notifiche degli eventi SNS».
Impossibile completare il ripristino NON RIUSCITO (dettagli dell'errore)

Oggetti saltati durante il ripristino

I seguenti oggetti Kubernetes vengono ripristinati nel migliore dei modi. Se non riescono a ripristinare, vengono spostati nell'elenco ignorato. Questi oggetti sono gestiti dal sistema e ricreati da Kubernetes o Amazon EKS:

  • FlowSchemas con l'annotazione apf.kubernetes.io/autoupdate-spec: "true"

  • PriorityLevelConfigurations con l'annotazione apf.kubernetes.io/autoupdate-spec: "true"

  • La eks-exempt FlowSchema (EKS-managed, fa riferimento all'esenzione PriorityLevelConfiguration protetta)

  • Il kubernetes servizio nel default namespace (endpoint del server API)

  • Il kube-dns servizio nel kube-system namespace (CoreDNS)

I seguenti oggetti Kubernetes vengono sempre ignorati durante un ripristino. Questi oggetti includono l'infrastruttura dei nodi e i componenti di rete. Fanno riferimento allo stato specifico del cluster. I controller Kubernetes ricreano automaticamente questi oggetti quando nodi e servizi diventano attivi nel cluster di destinazione. Se ripristini questi oggetti da un backup, potrebbero causare conflitti o errori. Questi conflitti si verificano perché gli oggetti ripristinati fanno riferimento a risorse che non esistono nel cluster di destinazione.

  • Endpoints (v1/endpoints): endpoint di rete che definiscono gli indirizzi IP per i servizi. Il controller Endpoints li gestisce automaticamente in base ai selettori di servizio.

  • EndpointSlices (discovery.k8s.io/v1/endpointslices) - Il EndpointSlice controller gestisce automaticamente questi oggetti.

  • Indirizzi IP (networking.k8s.io/v1/ipaddresses) - La rete Kubernetes gestisce queste allocazioni IP interne al cluster.

  • csNodes (storage.k8s.io/v1/csinodes) - Il kubelet crea automaticamente questi oggetti quando i driver CSI si registrano su un nodo.

  • VolumeAttachments (storage.k8s.io/v1/volumeattachments) - Il attach/detach controller crea automaticamente questi oggetti quando i pod richiedono volumi.

Anche gli oggetti già esistenti nel cluster di destinazione vengono ignorati. I ripristini EKS non sono distruttivi: gli oggetti esistenti non vengono mai sovrascritti o eliminati.

Per ricevere notifiche sugli oggetti ignorati o non riusciti durante il ripristino, abbonati alle notifiche degli eventi SNS. https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html Per ulteriori informazioni, consulta Opzioni di notifica con. AWS Backup

Considerazioni su OIDC e IRSA per il ripristino tra cluster

Quando si ripristina un backup di Amazon EKS su un cluster diverso da quello di origine, gli oggetti Kubernetes che fanno riferimento a IAM Roles for Service Accounts (IRSA) mantengono l'endpoint del provider OIDC del cluster di origine. Questi riferimenti sono presenti nelle annotazioni degli account di servizio e nelle politiche di fiducia IAM. AWS Backup non li aggiorna automaticamente durante il ripristino.

Se i carichi di lavoro utilizzano IRSA, un ripristino tra cluster richiede:

  • Il cluster di destinazione deve avere un provider OIDC configurato.

  • Tutti i ruoli IAM a cui fanno riferimento gli account del servizio Kubernetes devono avere le loro politiche di fiducia aggiornate per includere l'endpoint del provider OIDC del cluster di destinazione.

  • Le annotazioni degli account di servizio (eks.amazonaws.com/role-arn) faranno comunque riferimento ai ruoli originali: verifica che corrispondano ai ruoli validi nell'account di destinazione.

Se queste dipendenze non sono soddisfatte, i pod non riusciranno ad assumere i ruoli IAM dopo il ripristino e i job di ripristino potrebbero segnalare errori durante la convalida.

Raccomandazione: per i carichi di lavoro che richiedono la portabilità del ripristino su più cluster o più account, consigliamo di utilizzare EKS Pod Identity anziché IRSA. https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html EKS Pod Identity non dipende da provider OIDC specifici del cluster e semplifica gli scenari di ripristino tra cluster.