Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È possibile usare Backup di Azure per proteggere il servizio Azure Kubernetes. Questo articolo riepiloga la disponibilità a livello di area, gli scenari supportati e le limitazioni.
Aree geografiche supportate
- Backup di Azure per il servizio Azure Kubernetes supporta l'archiviazione dei dati di backup sia nei livelli vault che operativi (snapshot) nelle aree di Azure seguenti:
Australia centrale, Australia centrale 2, Australia orientale, Australia sud-orientale, Brasile meridionale, Brasile sud-orientale, Canada centrale, Canada orientale, India centrale, Stati Uniti centrali, Asia orientale, Stati Uniti orientali 2, Francia centrale, Francia meridionale, Germania settentrionale, Germania settentrionale, Italia settentrionale, Italia settentrionale, Giappone orientale, Giappone occidentale, Jio India occidentale, Corea centrale, Corea meridionale, Stati Uniti centro-settentrionali, Europa settentrionale, Norvegia orientale, Norvegia occidentale, Sudafrica settentrionale, Sudafrica occidentale, Stati Uniti centro-meridionali, India meridionale, Asia sud-orientale, Svezia centrale, Svizzera settentrionale, Svizzera occidentale, Emirati Arabi Uniti settentrionali, Regno Unito meridionale, Regno Unito occidentale, Stati Uniti centro-occidentali, Europa occidentale, Stati Uniti occidentali 2, Stati Uniti occidentali 3
- Le aree seguenti supportano solo il livello operativo (snapshot):
Cina orientale 2, Cina orientale 3, Cina settentrionale 2, Cina settentrionale 3, US GOV Arizona, US GOV Texas, US GOV Virginia, Israele centrale, Polonia centrale e Spagna centrale
Nota
Se sono necessari backup con ridondanza geografica con la possibilità di eseguire il ripristino su richiesta, archiviare i backup nel livello Insieme di credenziali e abilitare il ripristino tra aree nell'insieme di credenziali di backup. In questo modo si garantisce che i backup siano disponibili anche nell'area di Azure abbinata, consentendo di eseguire ripristini anche se l'area primaria non è disponibile. Vedere l'elenco delle aree di Azure associate.
Scenari supportati
Backup di Azure per il servizio Azure Kubernetes supporta solo i cluster che eseguono versioni di Kubernetes supportate. Ecco l'elenco delle versioni di Kubernetes supportate. Se il cluster si trova in una versione non supportata, le operazioni di backup possono comunque essere eseguite, ma gli errori durante il backup o il ripristino non sono coperti. Per garantire il supporto completo e l'affidabilità, eseguire l'aggiornamento a una versione supportata, convalidare i backup e contattare il supporto in caso di problemi persistenti.
Backup di Azure per il servizio Azure Kubernetes supporta solo volumi persistenti basati su driver CSI (Dischi di Azure). I plug-in del volume nell'albero non sono supportati. Assicurarsi che il driver e lo snapshot CSI siano abilitati per il cluster. Se sono disabilitate, abilitare queste impostazioni. Inoltre, se i carichi di lavoro usano volumi ad albero, eseguirne la migrazione ai volumi basati su CSI per abilitare il supporto per il backup.
Backup di Azure per il servizio Azure Kubernetes supporta attualmente solo i volumi persistenti basati su disco di Azure di cui è stato effettuato il provisioning usando il driver CSI. Gli SKU del disco supportati includono HDD Standard, SSD Standard e SSD Premium.
Sono supportati sia volumi di cui è stato eseguito il provisioning in modo dinamico che statico; Tuttavia, per i volumi statici, la classe di archiviazione deve essere definita in modo esplicito nella specifica YAML . In caso contrario, il volume verrà ignorato durante il backup.
Backup di Azure per il servizio Azure Kubernetes supporta i cluster che usano un'identità gestita assegnata dal sistema o assegnata dall'utente. I cluster configurati con un'entità servizio non sono supportati. Per abilitare il backup, aggiornare il cluster per usare un'identità gestita assegnata dal sistema o un'identità gestita assegnata dall'utente.
Backup di Azure per il servizio Azure Kubernetes offre backup del livello operativo e del livello insieme di credenziali. I backup del livello operativo sono costituiti da snapshot di tipi di volumi permanenti supportati, insieme ai metadati archiviati nel contenitore BLOB specificato durante l'installazione dell'estensione di backup. I backup del livello dell'insieme di credenziali, d'altra parte, vengono archiviati fuori sede, in modo sicuro e all'esterno del tenant. Usando i criteri di backup, è possibile scegliere di abilitare i backup del livello operativo e dell'insieme di credenziali oppure usare solo il livello operativo.
Gli snapshot del volume permanente acquisiti come parte del backup del livello operativo sono coerenti con l'arresto anomalo del sistema per natura. Anche se Backup di Azure per il servizio Azure Kubernetes attualmente non supporta l'acquisizione di snapshot di tutti i PVS nello stesso millisecondo per ottenere snapshot coerenti tra volumi.
La frequenza minima di backup supportata in Backup di Azure per il servizio Azure Kubernetes è ogni 4 ore, con opzioni aggiuntive per intervalli di 6, 8, 12 e 24 ore. È previsto che i backup vengano completati entro un intervallo di 2 ore dall'ora di inizio pianificata. Queste frequenze si applicano ai backup del livello operativo, consentendo più backup al giorno. Tuttavia, solo il primo backup riuscito in un periodo di 24 ore è idoneo per essere trasferito al livello dell'insieme di credenziali. Dopo aver creato un backup nel livello operativo, possono essere necessarie fino a quattro ore perché venga spostato nel livello dell'insieme di credenziali.
L'insieme di credenziali di backup e il cluster del servizio Azure Kubernetes devono trovarsi nella stessa area. Tuttavia, possono risiedere in sottoscrizioni diverse purché si trovino all'interno dello stesso tenant.
Backup di Azure per il servizio Azure Kubernetes supporta il ripristino dei backup nello stesso cluster del servizio Azure Kubernetes o in un altro cluster del servizio Azure Kubernetes usando backup a livello operativo e di insieme di credenziali. Il cluster del servizio Azure Kubernetes di destinazione può trovarsi nella stessa sottoscrizione o in una sottoscrizione diversa, nota come ripristino tra sottoscrizioni.
Quando si esegue il ripristino dal livello operativo, il cluster del servizio Azure Kubernetes di destinazione deve trovarsi nella stessa area dei backup. Tuttavia, se i backup vengono archiviati nel livello insieme di credenziali con l'impostazione di archiviazione con ridondanza geografica e ripristino tra aree abilitato nell'insieme di credenziali di backup, è possibile eseguire il ripristino in un'area diversa all'interno di un'area abbinata di Azure.
Per abilitare Backup di Azure per il servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure, assicurarsi di usare la versione 2.41.0 o successiva. È possibile aggiornare l'interfaccia della riga di comando eseguendo il comando az upgrade.
Per abilitare Backup di Azure per il servizio Azure Kubernetes con Terraform, usare la versione 3.99.0 o successiva.
Backup di Azure per il servizio Azure Kubernetes richiede l'installazione di un'estensione di backup. Questa estensione richiede un account di archiviazione e preferibilmente un contenitore BLOB vuoto al suo interno come input durante l'installazione. Non usare un contenitore BLOB con file non correlati al backup.
L'account di archiviazione specificato durante l'installazione dell'estensione di backup deve trovarsi nella stessa area del cluster del servizio Azure Kubernetes. Sono supportati solo gli account di archiviazione per utilizzo generico v2; Gli account di archiviazione Premium non sono supportati.
Se il cluster del servizio Azure Kubernetes viene distribuito all'interno di una rete virtuale privata, è necessario configurare un endpoint privato per abilitare le operazioni di backup.
L'estensione di backup può essere installata solo nei pool di nodi che usano processori basati su x86 ed eseguire Ubuntu o Azure Linux come sistema operativo.
Sia il cluster del servizio Azure Kubernetes che i pod dell'estensione di backup devono trovarsi in uno stato in esecuzione e integro prima di eseguire qualsiasi operazione di backup o ripristino, inclusa l'eliminazione dei punti di ripristino scaduti.
Backup di Azure per il servizio Azure Kubernetes fornisce avvisi tramite Monitoraggio di Azure che consente di avere un'esperienza coerente per la gestione degli avvisi in diversi servizi di Azure, tra cui avvisi classici, avvisi predefiniti di Monitoraggio di Azure e avvisi di log personalizzati per le notifiche degli errori di backup. Gli avvisi di backup supportati sono disponibili qui
Backup di Azure per il servizio Azure Kubernetes supporta vari report correlati al backup. Attualmente, i dati di backup possono essere visualizzati solo selezionando "Tutti" per il tipo di carico di lavoro nei filtri del report. I report di backup supportati sono disponibili qui
Backup di Azure per il servizio Azure Kubernetes supporta l'eliminazione temporanea avanzata per i backup archiviati nel livello insieme di credenziali, offrendo protezione da eliminazioni accidentali o dannose. Per i backup archiviati nel livello operativo, gli snapshot sottostanti non sono protetti dall'eliminazione temporanea e possono essere eliminati definitivamente.
Backup di Azure per il servizio Azure Kubernetes supporta l'autorizzazione multiutente (MUA) che consente di aggiungere un ulteriore livello di protezione alle operazioni critiche sugli insiemi di credenziali di backup in cui sono configurati i backup.
Backup di Azure per il servizio Azure Kubernetes supporta l'insieme di credenziali non modificabile, che consente di proteggere i dati di backup impedendo operazioni che potrebbero causare la perdita di punti di ripristino. Tuttavia, l'archiviazione WORM (Write Once, Read Many) per i backup non è attualmente supportata.
Backup di Azure per il servizio Azure Kubernetes supporta la crittografia della chiave diCustomer-Managed, ma è applicabile solo ai backup archiviati nel livello dell'insieme di credenziali.
Per le operazioni di backup e ripristino riuscite, l'identità gestita dell'insieme di credenziali di backup richiede assegnazioni di ruolo. Se non si dispone delle autorizzazioni necessarie, potrebbero verificarsi problemi di autorizzazione durante le operazioni di configurazione o ripristino del backup subito dopo l'assegnazione dei ruoli, in quanto l'applicazione delle assegnazioni di ruolo richiede alcuni minuti. Informazioni sulle definizioni dei ruoli.
Scenari e limitazioni non supportati
Backup di Azure per il servizio Azure Kubernetes non supporta i seguenti SKU del disco di Azure: SSD Premium v2 e Ultra Disks.
Condivisioni file di Azure, Archiviazione BLOB di Azure e Volumi permanenti basati su Archiviazione contenitori di Azure non sono supportate dal backup del servizio Azure Kubernetes. Se si usano questi tipi di volumi permanenti nei cluster del servizio Azure Kubernetes, è possibile eseguirne il backup separatamente usando soluzioni di Backup di Azure dedicate. Per altre informazioni, vedere Backup delle condivisioni file di Azure e Backup di Archiviazione BLOB di Azure.
Tutti i tipi di volumi persistenti non supportati vengono ignorati automaticamente durante il processo di backup per il cluster del servizio Azure Kubernetes.
L'estensione di backup non può essere installata nei pool di nodi basati su Windows o nei pool di nodi basati su ARM64. I cluster del servizio Azure Kubernetes che usano tali nodi devono effettuare il provisioning di un pool di nodi basato su Linux separato (preferibilmente un pool di nodi di sistema con processori basati su x86) per supportare l'installazione dell'estensione di backup.
Backup di Azure per il servizio Azure Kubernetes non è attualmente supportato per i cluster del servizio Azure Kubernetes isolati di rete.
Non installare l'estensione di backup del servizio Azure Kubernetes insieme a Velero o a qualsiasi soluzione di backup basata su Velero, in quanto ciò può causare conflitti durante le operazioni di backup e ripristino. Assicurarsi inoltre che le risorse Kubernetes non usino etichette o annotazioni contenenti il prefisso
velero.io
, a meno che non siano esplicitamente richieste da uno scenario supportato. La presenza di tali metadati può causare un comportamento imprevisto.La modifica della configurazione di backup o del gruppo di risorse snapshot assegnato a un'istanza di backup durante l'installazione del backup del cluster del servizio Azure Kubernetes non è supportata.
Gli spazi dei nomi seguenti vengono ignorati dalla configurazione di backup e non possono essere configurati per i backup:
kube-system
,kube-node-lease
,kube-public
.Backup di Azure non aumenta automaticamente il numero di nodi del servizio Azure Kubernetes, ma ripristina solo i dati e le risorse associate. La scalabilità automatica viene gestita dal servizio Azure Kubernetes stesso, usando funzionalità come Il ridimensionamento automatico del cluster. Se la scalabilità automatica è abilitata nel cluster di destinazione, deve gestire automaticamente il ridimensionamento delle risorse. Prima del ripristino, assicurarsi che il cluster di destinazione disponga di risorse sufficienti per evitare errori di ripristino o problemi di prestazioni.
Ecco i limiti di backup del servizio Azure Kubernetes:
Impostazione Limite Numero di criteri di backup per insieme di credenziali di backup 5.000 Numero di istanze di backup per ogni insieme di credenziali di backup 5.000 Numero di backup su richiesta consentiti in un giorno per ogni istanza di backup 10 Numero di spazi dei nomi per ogni istanza di backup 800 Numero di ripristini consentiti per ogni istanza di backup in un giorno 10
Limitazioni specifiche per il backup con insieme di credenziali e il ripristino tra aree
Attualmente, i dischi di Azure con volumi persistenti di dimensioni <= 1 TB sono idonei per essere spostati nel livello dell'insieme di credenziali. I dischi con dimensioni maggiori vengono ignorati nei dati di backup spostati nel livello dell'insieme di credenziali.
Attualmente, sono supportate le istanze di backup con <= 100 dischi collegati come volume permanente. Le operazioni di backup e ripristino potrebbero non riuscire se il numero di dischi è superiore al limite.
Solo i dischi di Azure con accesso pubblico abilitato da tutte le reti sono idonei per essere spostati al livello dell'insieme di credenziali; se sono presenti dischi con accesso di rete diverso dall'accesso pubblico, l'operazione di suddivisione in livelli ha esito negativo.
La funzionalità di ripristino di emergenza è disponibile solo tra aree abbinate di Azure (se il backup è configurato in un insieme di credenziali di backup con ridondanza geografica con ripristino tra aree abilitato in tali aree). I dati di backup sono disponibili solo in un'area abbinata di Azure. Ad esempio, se si dispone di un cluster del servizio Azure Kubernetes negli Stati Uniti orientali di cui è stato eseguito il backup in un insieme di credenziali di backup con ridondanza geografica con ripristino tra aree abilitate, i dati di backup sono disponibili anche negli Stati Uniti occidentali per il ripristino.
Nel livello insieme di credenziali viene creato un solo punto di ripristino pianificato al giorno, fornendo un obiettivo del punto di ripristino (RPO) di 24 ore nell'area primaria. Nell'area secondaria la replica di questo punto di ripristino può richiedere fino a 12 ore aggiuntive, generando un RPO effettivo fino a 36 ore.
Quando un backup viene creato nel livello operativo e diventa idoneo per il livello insieme di credenziali, l'avvio del processo di suddivisione in livelli può richiedere fino a quattro ore.
Quando si spostano i backup dal livello operativo al livello Vault, la logica di eliminazione mantiene gli snapshot essenziali per garantire la corretta esecuzione delle operazioni di suddivisione in livelli e l'integrità dei dati. In particolare, durante la suddivisione in livelli del punto di ripristino (RP) più recente nell'archivio di origine (livello operativo), sono necessari gli snapshot di entrambi gli elementi seguenti:
- Il punto di ripristino più recente nel livello operativo (archivio di origine).
- L'obiettivo di protezione avanzata precedente nel livello Vault (archivio di destinazione).
Di conseguenza, due punti di ripristino nel livello operativo vengono mantenuti intenzionalmente e non eliminati:
- Il punto di ripristino del ruolo di ripristino più recente nel livello operativo.
- Il punto di ripristino nel livello operativo collegato alla versione più recente del livello di insieme di credenziali.
Questo comportamento impedisce la perdita accidentale dei dati e garantisce backup coerenti. Di conseguenza, è possibile notare che alcuni backup operativi persistono più a lungo dei criteri di conservazione giornalieri configurati a causa di queste dipendenze di suddivisione in livelli.
Quando si spostano i backup dal livello operativo al livello Vault, l'account di archiviazione fornito all'estensione di backup deve preferibilmente avere l'accesso alla rete pubblica abilitato. Se l'account di archiviazione si trova dietro un firewall o ha accesso privato abilitato, assicurarsi che l'insieme di credenziali di backup venga aggiunto come servizio attendibile nelle impostazioni di rete dell'account di archiviazione per consentire il trasferimento dei dati senza problemi.
Durante il ripristino dal livello dell'insieme di credenziali, le risorse idratate nel percorso di gestione temporanea che includono un account di archiviazione e un gruppo di risorse non vengono pulite dopo il ripristino. Devono essere eliminati manualmente.
Durante il ripristino, l'account di archiviazione di staging deve disporre dell'accesso alla rete pubblica abilitato per consentire al servizio di backup di accedere e trasferire i dati. Senza accesso pubblico, l'operazione di ripristino potrebbe non riuscire a causa di restrizioni di connettività.
Durante il ripristino, se il cluster del servizio Azure Kubernetes di destinazione viene distribuito all'interno di una rete virtuale privata, è necessario abilitare un endpoint privato tra il cluster e l'account di archiviazione di staging per garantire il trasferimento sicuro e corretto dei dati.
Se la versione del cluster del servizio Azure Kubernetes di destinazione è diversa dalla versione usata durante il backup, l'operazione di ripristino potrebbe non riuscire o completare con avvisi per vari scenari come le risorse deprecate nella versione più recente del cluster. In caso di ripristino dal livello Vault, è possibile usare le risorse idratate nel percorso di gestione temporanea per ripristinare le risorse dell'applicazione nel cluster di destinazione.
Attualmente il backup basato su livelli dell'insieme di credenziali non è supportato con la distribuzione di Terraform.
Passaggi successivi
- Informazioni sul backup del cluster del servizio Azure Kubernetes.
- Eseguire il backup del cluster del servizio Azure Kubernetes usando il portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell, Azure Resource Manager, Bicep, Terraform.
- Ripristinare il cluster del servizio Azure Kubernetes usando il portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell.
- Gestire i backup del servizio Azure Kubernetes usando Backup di Azure.