Quando abiliti l'agente Backup for GKE nel tuo cluster Google Kubernetes Engine, Backup per GKE fornisce un CustomResourceDefinition
che introduce un nuovo tipo di risorsa Kubernetes: ProtectedApplication
.
La scrittura di un ProtectedApplication
prevede tre attività:
Selezionare il set di risorse di cui vuoi eseguire il backup e il ripristino come parte dell'applicazione.
Definizione di regole di orchestrazione dettagliate per un sottoinsieme di queste risorse.
Convalida di
ProtectedApplication
per verificare se è pronto per il backup.
Le risorse ProtectedApplication
offrono le seguenti funzionalità durante la personalizzazione della logica di backup e ripristino a livello di applicazione:
Operazioni di backup e ripristino più granulari. Senza
ProtectedApplications
, l'ambito dei backup deve essere definito a livello diNamespace
(selezionando allNamespaces o selectedNamespaces). Una logica simile si applica al ripristino delle risorse con spazio dei nomi. La creazione di risorseProtectedApplication
consente di assegnare un nome a un sottoinsieme delle risorse in unNamespace
. Puoi quindi eseguire il backup e il ripristino di tale sottoinsieme elencando selectedApplications nel tuo ambito di backup (e analogamente per il ripristino).Orchestrare dettagli granulari del processo di backup o ripristino, tra cui:
I volumi selezionati vengono ignorati durante il backup.
Integrazione della topologia delle applicazioni nel backup e ripristino (ad esempio, eseguire il backup di un'unica istanza di un database replicato e utilizzarlo per ripristinare più istanze).
Esecuzione di hook definiti dall'utente prima e dopo l'acquisizione di snapshot dei volumi. Puoi usarle, ad esempio, per fare svuotare e disattivare un carico di lavoro prima di eseguire lo snapshot e riattivarlo in seguito.
Puoi creare ProtectedApplication
tramite kubectl
come le altre risorse Kubernetes.
Sono completamente facoltativi. Se le risorse ProtectedApplication
non sono presenti, Backup per GKE crea backup del volume per tutti i volumi nell'ambito di un backup e i backup dei volumi risultanti saranno coerenti con l'arresto anomalo. Tutte le scritture sottoposte a svuotamento sul disco in un determinato momento verranno acquisite (ovvero senza scritture parziali). Tuttavia, alcune applicazioni potrebbero conservare i dati che non vengono scaricati su disco, quindi la riuscita di un ripristino da un backup coerente con un arresto anomalo dipende dalla logica dell'applicazione.
Selezione delle risorse
Il primo passaggio per la creazione della risorsa ProtectedApplication
consiste nell'identificare
le altre risorse nella stessa risorsa Namespace
che vuoi includere
nell'applicazione. Questo è l'insieme di risorse di cui verrà eseguito il backup o il ripristino se fornisci l'opzione di ambito selectedApplications
nella configurazione di BackupPlan
.
Le risorse sono identificate mediante un selettore
di etichette
È necessario etichettare tutte le risorse (utilizzando il campo metadata.label in ogni risorsa) con la stessa etichetta. Tieni presente che questo
vale anche per le risorse create automaticamente dai controller. Queste risorse create automaticamente sono etichettate utilizzando il modello corrispondente.
Tieni presente che è pratica comune riutilizzare la stessa etichetta che già utilizzi per associare Pods
e PersistentVolumeClaims
generati alla relativa risorsa padre. L'esempio seguente mostra come applicare l'etichetta app: nginx
alle
altre risorse oltre che a Deployment
.
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-vars
namespace: webserver
labels:
app: nginx
data:
...
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nginx-logs
namespace: webserver
labels:
app: nginx
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Mi
storageClassName: standard-rwo
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: webserver
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
- name: nginx-logs
persistentVolumeClaim:
claimName: nginx-logs
containers:
...
Dopo aver applicato l'etichetta selezionata a tutte le risorse di destinazione (e ai modelli da cui vengono generate le risorse aggiuntive), puoi fare riferimento a queste risorse da un ProtectedApplication
. Ad esempio:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1alpha2
metadata:
name: nginx
namespace: webserver
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: nginx
...
Definisci le regole di orchestrazione
Una volta identificate tutte le risorse in ProtectedApplication
, puoi scegliere di definire le regole di orchestrazione dettagliate per un sottoinsieme di queste risorse. Queste regole possono essere applicate solo a due tipi di risorse:
Deployment
e StatefulSets e sono
citate nella sezione components
di ProtectedApplication
.
Panoramica dei componenti
La configurazione di un componente prevede quanto segue:
La selezione di una strategia fondamentale per il funzionamento di backup e ripristino per questo componente. Sono disponibili tre strategie:
BackupAllRestoreAll
: esegui il backup dei volumi associati a tutte le istanze del componente e ripristinali tutti dai backup.BackupOneRestoreAll
: esegui il backup dei volumi di una sola istanza del componente e utilizza questi backup per ripristinare tutte le istanzeDumpAndLoad
: esporta i dati dall'applicazione in un unico volume al momento del backup e importali nell'applicazione al momento del ripristino
Definizione degli hook di esecuzione da eseguire durante il backup (ed eventualmente ripristinare, a seconda della strategia). Un hook è un comando eseguito in container specifici.
Selezionare un sottoinsieme di volumi di cui eseguire il backup.
Hook di esecuzione
Un hook è un comando shell eseguito da Backup per GKE in un container in una fase specifica del processo di backup o ripristino.
Esistono quattro diversi tipi di hook:
pre hooks
: questi comandi vengono eseguiti immediatamente prima del backup dei volumi. Di solito, si prevede che tutti i dati in memoria vengano svuotati su disco per poi chiudere l'applicazione in modo che non vengano eseguite nuove scritture su disco. Questi hook vengono utilizzati nelle strategieBackupAllRestoreAll
eBackupOneRestoreAll
.post hooks
: questi comandi vengono eseguiti durante il processo di backup del volume subito dopo il passaggio SNAPSHOTTING del processo di backup del volume (prima del passaggio di CARICAMENTO). In genere, la procedura di ISTANTANEO richiede solo pochi secondi. In genere si prevede che non disattivino l'applicazione (ovvero consentono la normale elaborazione e le scritture su disco). Questi hook vengono utilizzati nelle strategieBackupAllRestoreAll
,BackupOneRestoreAll
eDumpAndLoad
.dump hooks
: questi comandi vengono eseguiti prima del backup del volume nella strategiaDumpAndLoad
e in genere dovrebbero esportare i dati dall'applicazione nel volume di backup designato.load hooks
: questi comandi vengono eseguiti al momento del ripristino, dopo il ripristino del volume del backup nei casi di strategiaDumpAndLoad
. Di solito, si prevede che importi i dati dal volume di backup nell'applicazione.
Puoi fornire più di un hook per ogni tipo e Backup per GKE li eseguirà nell'ordine in cui li definisci.
Devi definire gli hook come parte della sezione dei componenti della
specifica ProtectedApplication
. Tutte le definizioni degli hook hanno
gli stessi campi disponibili:
name
: un nome che assegni all'hook.container
: nome (facoltativo) del container in cui eseguire il comando. Se non fornisci il container, Backup per GKE eseguirà l'hook nel primo container definito per iPod
di destinazione.command
: il comando effettivo inviato al container, costruito come un array di parole. La prima parola dell'array è il percorso del comando, mentre le parole successive sono gli argomenti da passare al comando.timeoutSeconds
: (facoltativo) tempo prima che l'esecuzione dell'hook venga interrotta. Se non specifichi questo valore, il valore predefinito sarà 30 secondi.onError
: (facoltativo) comportamento adottato quando l'hook non riesce. Può essere impostato suIgnore
oFail
(valore predefinito). Se la imposti suFail
, quando un hook non riesce, il backup del volume non andrà a buon fine. Se lo imposti suIgnore
, gli errori di questo hook vengono ignorati.
Prima di applicare gli hook ProtectedApplication
all'applicazione, devi testare il comando utilizzando kubectl exec
per assicurarti che gli hook si comportino come previsto:
kubectl exec POD_NAME -- COMMAND
Sostituisci quanto segue:
POD_NAME
: il nome del pod che contiene la risorsaProtectedApplication
.COMMAND
: l'array contenente il comando da eseguire nel container, ad esempio/sbin/fsfreeze, -f, /var/log/nginx
.
Selezione di un sottoinsieme di volumi di cui eseguire il backup
A volte, le applicazioni scrivono in volumi che non è interessante ripristinare (ad esempio, alcuni volumi di log o di zero). Puoi eliminare il backup di questi volumi utilizzando un selettore di volume.
Per utilizzare questa funzionalità, devi prima applicare un'etichetta comune ai volumi di cui vuoi eseguire il backup, quindi lasciarla disattivata sui volumi di cui non vuoi eseguire il backup. Quindi includi una clausola volumeSelector
nella definizione del componente, come segue:
spec:
...
components:
...
strategy:
...
volumeSelector:
matchLabels:
label_name: label_value
Se fornisci un volumeSelector
per un componente, verrà eseguito il backup e il ripristino solo dei volumi che
hanno l'etichetta specificata. Al momento del ripristino, verrà eseguito il provisioning di tutti gli altri volumi come vuoti invece di essere ripristinati da un backup del volume.
Strategia: BackupAllRipristinaAll
Questa è la strategia più semplice ed esegue il backup di tutti i volumi del componente al momento del backup e li ripristina tutti dai rispettivi backup del volume al momento del ripristino.
È la scelta migliore quando la tua applicazione non ha replica tra Pods
.
Questa strategia supporta i seguenti parametri:
backupPreHooks
(facoltativo): un elenco ordinato di hook eseguiti subito prima del backup dei volumi. Questi comandi vengono eseguiti su tutti iPods
nel componente.backupPostHooks
(facoltativo): un elenco ordinato di hook eseguiti dopo che i backup del volume hanno raggiunto la fase di CARICAMENTO. Questi comandi vengono eseguiti su tutti gli elementiPods
nel componente.volumeSelector
: logica (facoltativa) per la corrispondenza di un sottoinsieme di volumi da backup.
In questo esempio viene creata una risorsa ProtectedApplication
che disattiva il file system prima di eseguire il backup del volume dei log e annulla l'acquisizione dopo il backup:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1alpha2
metadata:
name: nginx
namespace: sales
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: nginx
components:
- name: nginx-app
resourceKind: Deployment
resourceNames: ["nginx"]
strategy:
type: BackupAllRestoreAll
backupAllRestoreAll:
backupPreHooks:
- name: fsfreeze
container: nginx
command: [ /sbin/fsfreeze, -f, /var/log/nginx ]
backupPostHooks:
- name: fsunfreeze
container: nginx
command: [ /sbin/fsfreeze, -u, /var/log/nginx ]
Strategia: BackupOneAndRipristinaAll
Questa strategia esegue il backup di una copia di un pod selezionato. Questa singola copia è l'origine per il ripristino di tutti i pod durante un ripristino. Questo metodo consente di ridurre
i costi di archiviazione e i tempi di backup. Questa strategia funziona in una configurazione ad alta disponibilità
quando viene eseguito il deployment di un componente con un PersistentVolumeClaim
principale e più PersistentVolumeClaims
secondari.
Questa strategia supporta i seguenti parametri:
backupTargetName
(obbligatorio): specifica quale deployment o StatefulSet vuoi utilizzare per eseguire il backup dei dati. Il pod migliore di cui eseguire il backup viene selezionato automaticamente. In una configurazione ad alta disponibilità, ti consigliamo di impostarla su una delle repliche dell'applicazione.backupPreHooks
(facoltativo): un elenco ordinato di hook eseguiti subito prima del backup dei volumi. Questi comandi vengono eseguiti solo sulPod
di backup selezionato.backupPostHooks
(facoltativo): un elenco ordinato di hook eseguiti dopo che i backup del volume hanno raggiunto la fase di CARICAMENTO. Questi comandi vengono eseguiti solo sulPod
di backup selezionato.volumeSelector
: logica (facoltativa) per la corrispondenza di un sottoinsieme di volumi da backup.
Se un componente è configurato con più oggetti Deployment o StatefulSet, tutte le risorse devono avere la stessa struttura PersistentVolume, ovvero seguire queste regole:
- Il numero di
PersistentVolumeClaims
utilizzato da tutti gli oggetti StatefulSet o Deployment deve essere lo stesso. - Lo scopo di
PersistentVolumeClaims
nello stesso indice deve essere lo stesso. Per gli StatefulSet, l'indice è definito involumeClaimTemplate
. Per i deployment, l'indice è definito inVolumes
e tutti i volumi non persistenti vengono ignorati. - Se il componente dell'applicazione è costituito da deployment, ogni deployment deve avere esattamente una replica.
Alla luce di queste considerazioni, è possibile selezionare più set di volumi per il backup, ma verrà selezionato un solo volume da ogni set di volumi.
Questo esempio, presupponendo un'architettura di uno StatefulSet primario e uno StatefulSet secondario, mostra un backup dei volumi di un pod nello StatefulSet secondario e quindi un ripristino in tutti gli altri volumi:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1alpha2
metadata:
name: mariadb
namespace: mariadb
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: mariadb
components:
- name: mariadb
resourceKind: StatefulSet
resourceNames: ["mariadb-primary", "mariadb-secondary"]
strategy:
type: BackupOneRestoreAll
backupOneRestoreAll:
backupTargetName: mariadb-secondary
backupPreHooks:
- name: quiesce
container: mariadb
command: [...]
backupPostHooks:
- name: unquiesce
container: mariadb
command: [...]
Strategia: DumpAndLoad
Questa strategia utilizza un volume dedicato per i processi di backup e ripristino
e richiede un valore PersistentVolumeClaim
dedicato collegato a un componente in cui sono archiviati
i dati di dump.
Questa strategia supporta i seguenti parametri:
dumpTarget
(obbligatorio): specifica quale deployment o StatefulSet vuoi utilizzare per eseguire il backup dei dati. Il pod migliore di cui eseguire il backup viene selezionato automaticamente. In una configurazione ad alta disponibilità, ti consigliamo di impostarla su una delle repliche dell'applicazione.loadTarget
(obbligatorio): specifica quale deployment o StatefulSet deve essere utilizzato per caricare i dati. Il pod migliore di cui eseguire il backup viene selezionato automaticamente. Il target di carico non deve necessariamente essere uguale al target di dump.dumpHooks
(obbligatorio): un elenco ordinato di hook eseguiti per compilare il volume di backup dedicato. Questi comandi vengono eseguiti solo sul dump selezionatoPod
.backupPostHooks
(facoltativo): un elenco ordinato di hook eseguiti dopo che i backup del volume hanno raggiunto la fase di CARICAMENTO. Questi comandi vengono eseguiti solo sul dump selezionatoPod
.loadHooks
(obbligatorio): un elenco ordinato di hook eseguiti per caricare i dati dal volume ripristinato dopo l'avvio dell'applicazione. Questi comandi vengono eseguiti solo sul caricamento selezionatoPod
.volumeSelector
(obbligatoria) logica per far corrispondere un singolo volume al backup e al ripristino (il volume "dump"). Anche se deve corrispondere a un solo volume, la configurazione viene eseguita nello stesso modo in cui viene configurato il sottoinsieme di volumi di cui eseguire il backup utilizzato da altre strategie.
Se l'applicazione consiste di deployment, ogni deployment deve avere esattamente una replica.
Questo esempio, presupponendo un'architettura di uno StatefulSet principale e uno StatefulSet secondario
con PersistentVolumeClaims
dedicato sia per gli StatefulSet primari che secondari,
mostra una strategia DumpAndLoad
:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1alpha2
metadata:
name: mariadb
namespace: mariadb
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: mariadb
components:
- name: mariadb-dump
resourceKind: StatefulSet
resourceNames: ["mariadb-primary", "mariadb-secondary"]
strategy:
type: DumpAndLoad
dumpAndLoad:
loadTarget: mariadb-primary
dumpTarget: mariadb-secondary
dumpHooks:
- name: db_dump
container: mariadb
command:
- bash
- "-c"
- |
mysqldump -u root --all-databases > /backup/mysql_backup.dump
loadHooks:
- name: db_load
container: mariadb
command:
- bash
- "-c"
- |
mysql -u root < /backup/mysql_backup.sql
volumeSelector:
matchLabels:
gkebackup.gke.io/backup: dedicated-volume
Controlla se un ProtectedApplication
è pronto per il backup
Puoi verificare se un ProtectedApplication
è pronto per un backup eseguendo questo comando:
kubectl describe protectedapplication APPLICATION_NAME
Sostituisci APPLICATION_NAME
con il nome della tua applicazione.
Se è pronta, la descrizione dell'applicazione mostrerà lo stato Ready to backup
come true
,
come in questo esempio:
% kubectl describe protectedapplication nginx
Name: nginx
Namespace: default
API Version: gkebackup.gke.io/v1alpha2
Kind: ProtectedApplication
Metadata:
UID: 90c04a86-9dcd-48f2-abbf-5d84f979b2c2
Spec:
Components:
Name: nginx
Resource Kind: Deployment
Resource Names:
nginx
Strategy:
Backup All Restore All:
Backup Pre Hooks:
Command:
/sbin/fsfreeze
-f
/var/log/nginx
Container: nginx
Name: freeze
Backup Post Hooks:
Command:
/sbin/fsfreeze
-u
/var/log/nginx
Container: nginx
Name: unfreeze
Type: BackupAllRestoreAll
Resource Selection:
Selector:
Match Labels:
app: nginx
Type: Selector
Status:
Ready To Backup: true
Events: <none>
Passaggi successivi
- Scopri di più sulla pianificazione di un insieme di backup.