Quando abiliti l'agente Backup per GKE nel tuo cluster Google Kubernetes Engine,
Backup per GKE fornisce un CustomResourceDefinition
che introduce un nuovo tipo di Kubernetes
risorsa: ProtectedApplication
.
La composizione di un ProtectedApplication
prevede tre attività:
Seleziona l'insieme di risorse di cui vuoi eseguire il backup e il ripristino nell'ambito dell'applicazione.
Definisci regole di orchestrazione dettagliate per un sottoinsieme di queste risorse.
Convalida del
ProtectedApplication
per verificare se è pronto per il backup.
Le risorse di ProtectedApplication
ti offrono queste funzionalità quando
personalizzando la 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 LivelloNamespace
(selezionando allNamespaces o selectedNamespaces). Una logica simile si applica al ripristino delle risorse con spazio dei nomi. Creazione in corso... Le risorseProtectedApplication
ti consentono di assegnare un nome a un sottoinsieme di le risorse in unNamespace
. Puoi quindi eseguire il backup e il ripristino di questo sottoinsieme elencando selectedApplications nell'ambito del backup (e in modo simile per il ripristino).Orchestrazione dei dettagli granulari della procedura di backup o ripristino, tra cui:
I volumi selezionati vengono ignorati durante il backup.
Integrazione della topologia delle applicazioni nel backup e nel ripristino (ad eseguire il backup di un'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. Può essere usato, ad esempio, per eseguire il flush e la disattivazione di un carico di lavoro prima creare snapshot e riattivarli in seguito.
Puoi creare ProtectedApplication
tramite kubectl
come le altre risorse Kubernetes.
Sono completamente facoltativi. Se le risorse ProtectedApplication
non sono
presente, Backup per GKE crea backup del volume per tutti i volumi all'interno
nell'ambito di un backup e i backup del volume risultanti saranno coerenti con gli arresti anomali.
verranno acquisite tutte le scritture sottoposte a svuotamento sul disco in un determinato momento
(ovvero, nessuna scrittura parziale). Tuttavia, alcune applicazioni potrebbero conservare in memoria dati che non vengono svuotati sul disco, pertanto la possibilità o meno di recuperare correttamente un'applicazione da un backup coerente con gli arresti anomali dipende dalla logica dell'applicazione.
Selezione delle risorse
Il primo passaggio per creare la risorsa ProtectedApplication
è identificare le altre risorse nello stesso Namespace
che vuoi includere nell'applicazione. Questo è l'insieme di risorse di cui verrà eseguito il backup
ripristinato se fornisci
selectedApplications
di ambito nella configurazione BackupPlan
.
Le risorse sono identificate tramite un'etichetta
selettore
A questo scopo, devi etichettare tutte le risorse (utilizzando il campo metadata.label).
in ogni risorsa) con la stessa etichetta. Tieni presente che questo
si applica anche alle risorse create automaticamente dai controller. Questi
le risorse create automaticamente sono etichettate
con il modello corrispondente.
Tieni presente che capita di riutilizzare la stessa etichetta che stai già utilizzando
associare gli elementi Pods
e PersistentVolumeClaims
generati al relativo elemento padre
risorsa. L'esempio seguente mostra come applicare l'etichetta app: nginx
alle altre risorse oltre 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 risorse aggiuntive), puoi fare riferimento a queste risorse da un ProtectedApplication
. Ad esempio:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
name: nginx
namespace: webserver
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: nginx
...
Definisci le regole di orchestrazione
Una volta identificate tutte le risorse nel tuo ProtectedApplication
,
puoi scegliere di definire regole di orchestrazione dettagliate per un sottoinsieme di questi
Google Cloud. Queste regole possono essere applicate solo a due tipi di risorse:
deployment
e StatefulSet e sono
riferite nella sezione components
del ProtectedApplication
.
Panoramica dei componenti
La configurazione di un componente prevede quanto segue:
Seleziona una strategia di base per il funzionamento del backup e del ripristino per questo componente. Sono disponibili tre strategie:
BackupAllRestoreAll
: esegui il backup dei volumi associati a tutte le istanze il componente e ripristinarli tutti dai backup.BackupOneRestoreAll
: esegui il backup dei volumi da una sola istanza del componente e utilizza questi backup per ripristinare tutte le istanze.DumpAndLoad
: esporta i dati dall'applicazione a un unico volume al momento del backup e importare i dati nell'applicazione al momento del ripristino.
Definizione degli hook di esecuzione da eseguire durante il backup (ed eventualmente il ripristino, a seconda della strategia). Un hook è un comando che viene eseguito di container specifici.
Selezionare un sottoinsieme di volumi di cui eseguire il backup.
Hook di esecuzione
Un hook è un comando shell che Backup per GKE esegue in un container fase specifica del processo di backup o ripristino.
Esistono quattro diversi tipi di hook:
pre hooks
: questi comandi vengono eseguiti subito prima del backup dei volumi e in genere dovrebbero eseguire il flush di tutti i dati in memoria su disco quindi chiudere l'applicazione in modo che non vengano scritture nuove 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 di SNAPSHOTTING del processo di backup del volume (prima del passaggio di CARICAMENTO). In genere, il passaggio SNAPSHOTTING richiede solo pochi secondi. In genere, è previsto che risveglino l'applicazione (ovvero consentano di procedere con l'elaborazione normale e le scritture su disco). Questi ganci vengono utilizzati inBackupAllRestoreAll
,BackupOneRestoreAll
eDumpAndLoad
strategie.dump hooks
: questi comandi vengono eseguiti prima del backup del volume su la strategiaDumpAndLoad
e generalmente si prevede che esporti i dati dell'applicazione nel volume di backup designato.load hooks
: questi comandi vengono eseguiti al momento del ripristino dopo il ripristino del volume di backup nei casi di strategiaDumpAndLoad
. Sono si prevede che importi i dati dal volume di backup nell' un'applicazione.
Puoi fornire più di un hook per ogni tipo e Backup per GKE eseguirle nell'ordine in cui li definisci.
Definisci gli hook nella sezione dei componenti della specificaProtectedApplication
. Tutte le definizioni degli hook hanno lo stesso
campi disponibili:
name
: un nome assegnato all'hook.container
- (facoltativo) nome del contenitore in cui eseguire il comando. In caso contrario il container, Backup per GKE eseguirà l'hook nella prima contenitore definito per il/iPod
/i target.command
: si tratta del comando effettivo inviato al contenitore, costituito come un array di parole. La prima parola nell'array è il percorso del comando e le parole successive sono gli argomenti da passare al comando.timeoutSeconds
- (facoltativo) tempo prima dell'interruzione dell'esecuzione dell'hook. Se non specifichi questo valore, il valore predefinito sarà 30 secondi.onError
- (facoltativo) comportamento adottato in caso di errore dell'hook. Può essere impostato suIgnore
oFail
(valore predefinito). Se imposti questo valore suFail
, quando un hook non va a buon fine, il backup del volume non andrà a buon fine. Se imposti aIgnore
, gli errori di questo hook vengono ignorati.
Prima di applicare gli hook di 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 contenitore, 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 sono interessanti da ripristinare (ad esempio determinati volumi di log o scratch). 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 e poi lasciare questa etichetta disattivata per i volumi di cui non vuoi eseguire il backup. 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, qualsiasi altra
il provisioning dei volumi verrà eseguito come vuoti invece di essere ripristinati da un backup del volume.
Strategia: BackupAllRipristinaAll
Questa è la strategia più semplice e esegue il backup di tutti i volumi del componente al momento del backup e li ripristina tutti dai backup dei volumi al momento del ripristino.
È la scelta migliore quando l'applicazione non ha alcuna replica tra Pods
.
Questa strategia supporta i seguenti parametri:
backupPreHooks
: (facoltativo) un elenco ordinato di hook che sono appena prima del backup dei volumi. Questi comandi vengono eseguiti tutti gli elementiPods
nel componente.backupPostHooks
: (facoltativo) un elenco ordinato di hook che sono vengono eseguiti dopo che i backup del volume hanno raggiunto la fase di CARICAMENTO. Questi comandi sono eseguita su tutti gli elementiPods
del componente.volumeSelector
: logica (facoltativa) per associare un sottoinsieme di volumi a di backup.
Questo esempio crea una risorsa ProtectedApplication
che mette in stato di riposo il sistema di file prima di eseguire il backup del volume dei log e lo riattiva dopo il backup:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
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: BackupOneAndRestoreAll
Questa strategia esegue il backup di una copia di un pod selezionato. Questa singola copia è la fonte 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 un componente viene disegnato con un PersistentVolumeClaim
principale e più PersistentVolumeClaims
secondari.
Questa strategia supporta i seguenti parametri:
backupTargetName
- (obbligatorio) specifica il deployment o lo StatefulSet da utilizzare per eseguire il backup dei dati. Il pod migliore di cui eseguire il backup viene selezionato automaticamente. In una configurazione ad alta disponibilità, consigliamo di impostare questo valore su una delle repliche dell'applicazione.backupPreHooks
: (facoltativo) un elenco ordinato di hook che sono appena prima del backup dei volumi. Questi comandi vengono eseguiti solo sul backup selezionatoPod
.backupPostHooks
- (facoltativo) un elenco ordinato di hook che vengono eseguiti dopo che i backup dei volumi hanno raggiunto la fase di caricamento. Questi comandi vengono eseguiti sul backup selezionato:Pod
.volumeSelector
: logica (facoltativa) per associare un sottoinsieme di volumi a di backup.
Se un componente è configurato con più oggetti Deployment o StatefulSet, 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, che presuppone un'architettura di un StatefulSet principale e un StatefulSet secondario, mostra un backup dei volumi di un pod nel StatefulSet secondario e un successivo ripristino in tutti gli altri volumi:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
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 PersistentVolumeClaim
dedicato collegato a un componente che memorizza
i dati del dump.
Questa strategia supporta i seguenti parametri:
dumpTarget
: (obbligatorio) specifica il deployment o l'oggetto StatefulSet che vuoi utilizzare. per eseguire il backup dei dati. Il pod migliore di cui eseguire il backup viene selezionato automaticamente. Con un picco la 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 ha in modo che sia uguale al target di dump.dumpHooks
: (obbligatorio) un elenco ordinato di hook che sono per compilare il volume di backup dedicato. Questi comandi vengono eseguiti sul dump selezionatoPod
.backupPostHooks
: (facoltativo) un elenco ordinato di hook che sono vengono eseguiti dopo che i backup del volume hanno raggiunto la fase di CARICAMENTO. Questi comandi vengono eseguiti sul dump selezionatoPod
.loadHooks
- (obbligatorio) un elenco ordinato di hook che vengono 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 ripristinare (il volume "dump"). Anche se deve corrispondere a un solo volume, lo configuri nello stesso modo in cui configuri il sottoinsieme di volumi da eseguire il backup utilizzato da altre strategie.
Se l'applicazione consiste di deployment, ogni deployment deve avere esattamente una replica.
Questo esempio, che presuppone un'architettura di un StatefulSet principale e un StatefulSet secondario con PersistentVolumeClaims
dedicato sia per i StatefulSet principali che per quelli secondari, mostra una strategia DumpAndLoad
:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
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
Controllare se un ProtectedApplication
è pronto per il backup
Per verificare se un ProtectedApplication
è pronto per un backup, puoi eseguire
il seguente comando:
kubectl describe protectedapplication APPLICATION_NAME
Sostituisci APPLICATION_NAME
con il nome della tua applicazione.
Se è tutto pronto, la descrizione della richiesta 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/v1
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.