Utilizzare gli oggetti Trident Protect AppVault per gestire i bucket
La risorsa personalizzata bucket (CR) per Trident Protect è nota come AppVault. Gli oggetti AppVault sono la rappresentazione dichiarativa del flusso di lavoro di Kubernetes di un bucket di storage. AppVault CR contiene le configurazioni necessarie per l'utilizzo di un bucket nelle operazioni di protezione, come backup, snapshot, operazioni di ripristino e replica SnapMirror. Solo gli amministratori possono creare AppVaults.
Quando si eseguono operazioni di protezione dei dati su un'applicazione, è necessario creare una CR di AppVault manualmente o dalla riga di comando. La CR di AppVault è specifica per il proprio ambiente e gli esempi in questa pagina possono essere utilizzati come guida per la creazione di CR di AppVault.
|
Assicurarsi che la CR di AppVault si trovi sul cluster in cui è installato Trident Protect. Se la CR di AppVault non esiste o non è possibile accedervi, la riga di comando mostrerà un errore. |
Configurare l'autenticazione e le password AppVault
Prima di creare una CR di AppVault, assicurati che AppVault e il data mover scelto possano autenticarsi con il provider e con tutte le risorse correlate.
Password del repository di spostamento dati
Quando si creano oggetti AppVault utilizzando le CR o il plugin Trident Protect CLI, è possibile specificare un segreto Kubernetes con password personalizzate per la crittografia Restic e Kopia. Se non si specifica un segreto, Trident Protect utilizza una password predefinita.
-
Quando si creano manualmente CR di AppVault, utilizzare il campo spec.dataMoverPasswordSecretRef per specificare il segreto.
-
Quando si creano oggetti AppVault utilizzando la CLI di Trident Protect, utilizzare
--data-mover-password-secret-ref
argomento per specificare il segreto.
Creare una password segreta dell'archivio di spostamento dati
Utilizzare gli esempi seguenti per creare la password segreta. Quando si creano oggetti AppVault, è possibile impostare Trident Protect per utilizzare questo segreto per l'autenticazione con l'archivio di spostamento dati.
|
|
---
apiVersion: v1
data:
KOPIA_PASSWORD: <base64-encoded-password>
RESTIC_PASSWORD: <base64-encoded-password>
kind: Secret
metadata:
name: my-optional-data-mover-secret
namespace: trident-protect
type: Opaque
kubectl create secret generic my-optional-data-mover-secret \
--from-literal=KOPIA_PASSWORD=<plain-text-password> \
--from-literal=RESTIC_PASSWORD=<plain-text-password> \
-n trident-protect
Autorizzazioni IAM per l'archiviazione compatibile con S3
Quando si accede a un archivio compatibile con S3 come Amazon S3, Generic S3, "StorageGRID S3" , O "ONTAP S3" Utilizzando Trident Protect, è necessario assicurarsi che le credenziali utente fornite dispongano delle autorizzazioni necessarie per accedere al bucket. Di seguito è riportato un esempio di policy che concede le autorizzazioni minime richieste per l'accesso con Trident Protect. È possibile applicare questa policy all'utente che gestisce le policy dei bucket compatibili con S3.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": "*"
}
]
}
Per ulteriori informazioni sulle policy di Amazon S3, fare riferimento agli esempi in "Documentazione di Amazon S3" .
Identità pod EKS per l'autenticazione Amazon S3 (AWS)
Trident Protect supporta EKS Pod Identity per le operazioni di spostamento dati Kopia. Questa funzionalità consente l'accesso sicuro ai bucket S3 senza dover archiviare le credenziali AWS nei segreti di Kubernetes.
*Requisiti per l'identità del pod EKS con protezione Trident *
Prima di utilizzare EKS Pod Identity con Trident Protect, accertarsi di quanto segue:
-
Il tuo cluster EKS ha l'identità Pod abilitata.
-
Hai creato un ruolo IAM con le autorizzazioni necessarie per il bucket S3. Per saperne di più, fare riferimento a"Autorizzazioni IAM per l'archiviazione compatibile con S3" .
-
Il ruolo IAM è associato ai seguenti account di servizio Trident Protect:
-
<trident-protect>-controller-manager
-
<trident-protect>-resource-backup
-
<trident-protect>-resource-restore
-
<trident-protect>-resource-delete
-
Per istruzioni dettagliate sull'abilitazione di Pod Identity e sull'associazione dei ruoli IAM agli account di servizio, fare riferimento a "Documentazione sull'identità del pod AWS EKS" .
Configurazione AppVault Quando si utilizza EKS Pod Identity, configurare il CR AppVault con useIAM: true
flag invece di credenziali esplicite:
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: eks-protect-vault
namespace: trident-protect
spec:
providerType: AWS
providerConfig:
s3:
bucketName: trident-protect-aws
endpoint: s3.example.com
useIAM: true
Esempi di generazione delle chiavi AppVault per i cloud provider
Quando si definisce un CR AppVault, è necessario includere le credenziali per accedere alle risorse ospitate dal provider, a meno che non si utilizzi l'autenticazione IAM. Il modo in cui vengono generate le chiavi per le credenziali varia a seconda del provider. Di seguito sono riportati esempi di generazione di chiavi da riga di comando per diversi provider. È possibile utilizzare gli esempi seguenti per creare chiavi per le credenziali di ciascun provider cloud.
kubectl create secret generic <secret-name> \
--from-file=credentials=<mycreds-file.json> \
-n trident-protect
kubectl create secret generic <secret-name> \
--from-literal=accessKeyID=<objectstorage-accesskey> \
--from-literal=secretAccessKey=<amazon-s3-trident-protect-src-bucket-secret> \
-n trident-protect
kubectl create secret generic <secret-name> \
--from-literal=accountKey=<secret-name> \
-n trident-protect
kubectl create secret generic <secret-name> \
--from-literal=accessKeyID=<objectstorage-accesskey> \
--from-literal=secretAccessKey=<generic-s3-trident-protect-src-bucket-secret> \
-n trident-protect
kubectl create secret generic <secret-name> \
--from-literal=accessKeyID=<objectstorage-accesskey> \
--from-literal=secretAccessKey=<ontap-s3-trident-protect-src-bucket-secret> \
-n trident-protect
kubectl create secret generic <secret-name> \
--from-literal=accessKeyID=<objectstorage-accesskey> \
--from-literal=secretAccessKey=<storagegrid-s3-trident-protect-src-bucket-secret> \
-n trident-protect
Esempi di creazione di AppVault
Di seguito sono riportate alcune definizioni AppVault di esempio per ogni provider.
Esempi di AppVault CR
È possibile utilizzare i seguenti esempi CR per creare oggetti AppVault per ciascun provider cloud.
|
|
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: gcp-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: GCP
providerConfig:
gcp:
bucketName: trident-protect-src-bucket
projectID: project-id
providerCredentials:
credentials:
valueFromSecret:
key: credentials
name: gcp-trident-protect-src-bucket-secret
---
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: amazon-s3-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: AWS
providerConfig:
s3:
bucketName: trident-protect-src-bucket
endpoint: s3.example.com
proxyURL: http://10.1.1.1:3128
providerCredentials:
accessKeyID:
valueFromSecret:
key: accessKeyID
name: s3-secret
secretAccessKey:
valueFromSecret:
key: secretAccessKey
name: s3-secret
sessionToken:
valueFromSecret:
key: sessionToken
name: s3-secret
|
Per gli ambienti EKS che utilizzano Pod Identity con Kopia Data Mover, è possibile rimuovere providerCredentials sezione e aggiungi useIAM: true sotto il s3 configurazione invece.
|
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: azure-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: Azure
providerConfig:
azure:
accountName: account-name
bucketName: trident-protect-src-bucket
providerCredentials:
accountKey:
valueFromSecret:
key: accountKey
name: azure-trident-protect-src-bucket-secret
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: generic-s3-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: GenericS3
providerConfig:
s3:
bucketName: trident-protect-src-bucket
endpoint: s3.example.com
proxyURL: http://10.1.1.1:3128
providerCredentials:
accessKeyID:
valueFromSecret:
key: accessKeyID
name: s3-secret
secretAccessKey:
valueFromSecret:
key: secretAccessKey
name: s3-secret
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: ontap-s3-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: OntapS3
providerConfig:
s3:
bucketName: trident-protect-src-bucket
endpoint: s3.example.com
proxyURL: http://10.1.1.1:3128
providerCredentials:
accessKeyID:
valueFromSecret:
key: accessKeyID
name: s3-secret
secretAccessKey:
valueFromSecret:
key: secretAccessKey
name: s3-secret
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
name: storagegrid-s3-trident-protect-src-bucket
namespace: trident-protect
spec:
dataMoverPasswordSecretRef: my-optional-data-mover-secret
providerType: StorageGridS3
providerConfig:
s3:
bucketName: trident-protect-src-bucket
endpoint: s3.example.com
proxyURL: http://10.1.1.1:3128
providerCredentials:
accessKeyID:
valueFromSecret:
key: accessKeyID
name: s3-secret
secretAccessKey:
valueFromSecret:
key: secretAccessKey
name: s3-secret
Esempi di creazione di AppVault utilizzando la CLI Trident Protect
È possibile utilizzare i seguenti esempi di comandi CLI per creare CRS AppVault per ciascun provider.
|
|
tridentctl-protect create vault GCP <vault-name> \
--bucket <mybucket> \
--project <my-gcp-project> \
--secret <secret-name>/credentials \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
tridentctl-protect create vault AWS <vault-name> \
--bucket <bucket-name> \
--secret <secret-name> \
--endpoint <s3-endpoint> \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
tridentctl-protect create vault Azure <vault-name> \
--account <account-name> \
--bucket <bucket-name> \
--secret <secret-name> \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
tridentctl-protect create vault GenericS3 <vault-name> \
--bucket <bucket-name> \
--secret <secret-name> \
--endpoint <s3-endpoint> \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
tridentctl-protect create vault OntapS3 <vault-name> \
--bucket <bucket-name> \
--secret <secret-name> \
--endpoint <s3-endpoint> \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
tridentctl-protect create vault StorageGridS3 <vault-name> \
--bucket <bucket-name> \
--secret <secret-name> \
--endpoint <s3-endpoint> \
--data-mover-password-secret-ref <my-optional-data-mover-secret> \
-n trident-protect
Visualizzare le informazioni AppVault
È possibile utilizzare il plug-in Trident Protect CLI per visualizzare informazioni sugli oggetti AppVault creati nel cluster.
-
Visualizzare il contenuto di un oggetto AppVault:
tridentctl-protect get appvaultcontent gcp-vault \ --show-resources all \ -n trident-protect
Output di esempio:
+-------------+-------+----------+-----------------------------+---------------------------+ | CLUSTER | APP | TYPE | NAME | TIMESTAMP | +-------------+-------+----------+-----------------------------+---------------------------+ | | mysql | snapshot | mysnap | 2024-08-09 21:02:11 (UTC) | | production1 | mysql | snapshot | hourly-e7db6-20240815180300 | 2024-08-15 18:03:06 (UTC) | | production1 | mysql | snapshot | hourly-e7db6-20240815190300 | 2024-08-15 19:03:06 (UTC) | | production1 | mysql | snapshot | hourly-e7db6-20240815200300 | 2024-08-15 20:03:06 (UTC) | | production1 | mysql | backup | hourly-e7db6-20240815180300 | 2024-08-15 18:04:25 (UTC) | | production1 | mysql | backup | hourly-e7db6-20240815190300 | 2024-08-15 19:03:30 (UTC) | | production1 | mysql | backup | hourly-e7db6-20240815200300 | 2024-08-15 20:04:21 (UTC) | | production1 | mysql | backup | mybackup5 | 2024-08-09 22:25:13 (UTC) | | | mysql | backup | mybackup | 2024-08-09 21:02:52 (UTC) | +-------------+-------+----------+-----------------------------+---------------------------+
-
Facoltativamente, per visualizzare AppVaultPath per ogni risorsa, utilizzare il flag
--show-paths
.Il nome del cluster nella prima colonna della tabella è disponibile solo se è stato specificato un nome cluster nell'installazione di Trident Protect helm. Ad esempio:
--set clusterName=production1
.
Rimuovere un AppVault
È possibile rimuovere un oggetto AppVault in qualsiasi momento.
|
Non rimuovere la finalizers chiave in AppVault CR prima di eliminare l'oggetto AppVault. In tal caso, i dati residui nel bucket AppVault e le risorse orfane nel cluster possono risultare.
|
Assicurarsi di aver eliminato tutti i CRS di backup e snapshot utilizzati dall'AppVault che si desidera eliminare.
-
Rimuovere l'oggetto AppVault, sostituendo
appvault-name
con il nome dell'oggetto AppVault da rimuovere:kubectl delete appvault <appvault-name> \ -n trident-protect
-
Rimuovere l'oggetto AppVault, sostituendo
appvault-name
con il nome dell'oggetto AppVault da rimuovere:tridentctl-protect delete appvault <appvault-name> \ -n trident-protect