I trasferimenti di dati possono avvenire tra:
- PersistentVolumeClaim (PVC) e archiviazione di oggetti
- Archiviazione di oggetti e archiviazione di oggetti (all'interno di GDC)
L'archiviazione di oggetti su GDC è compatibile con S3 e viene definita di tipo s3 nei file YAML di Kubernetes.
Tipi di origini e destinazioni dei dati
- Archiviazione di oggetti (denominata "s3"): archiviazione di oggetti presente su GDC
- Archiviazione locale (denominata "local"): archiviazione su PVC collegati
Copia dall'archiviazione di oggetti all'archiviazione di oggetti
Assicurati di soddisfare i seguenti prerequisiti:
- Un endpoint S3 con autorizzazioni di lettura per l'origine e un endpoint s3 con autorizzazioni di scrittura per la destinazione.
- Se non hai l'autorizzazione per la creazione di bucket con le credenziali, il trasferimento non riesce se il bucket di destinazione non esiste. In questo caso, assicurati che il bucket di destinazione esista.
- Privilegi per creare job e creare o leggere secret all'interno del cluster o dello spazio dei nomi. Consulta l'esempio seguente per le autorizzazioni.
Configura il trasferimento dei dati
Per configurare il trasferimento dei dati, completa i seguenti passaggi:
Crea lo spazio dei nomi di trasferimento
Crea lo spazio dei nomi in cui verrà eseguito il job di trasferimento:
apiVersion: v1
kind: Namespace
metadata:
name: NAMESPACE
Configura le credenziali
Prepara le credenziali per il trasferimento. Scegli l'opzione più adatta al tuo scenario di trasferimento.
Trasferimento da GDC a GDC
Per un trasferimento che avviene completamente all'interno dello stesso universo GDC, i secret esistono già. Tieni presente che questo metodo è valido solo per i trasferimenti all'interno di un singolo universo, non per i trasferimenti tra universi diversi.
Per ottenere i secret delle credenziali S3, segui le istruzioni per concedere l'accesso al bucket.
Crea un account di servizio (SA) nello spazio dei nomi di destinazione per il job di trasferimento. Poi, aggiungi le autorizzazioni per consentire a questo account di leggere i secret negli spazi dei nomi di origine e di destinazione utilizzando RoleBinding tra spazi dei nomi.
--- apiVersion: v1 kind: ServiceAccount metadata: name: transfer-service-account namespace: DESTINATION_NAMESPACE --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-secrets-role namespace: SOURCE_NAMESPACE rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-source-secrets-rolebinding namespace: SOURCE_NAMESPACE subjects: - kind: ServiceAccount name: transfer-service-account namespace: DESTINATION_NAMESPACE roleRef: kind: Role name: read-secrets-role apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-secrets-role namespace: DESTINATION_NAMESPACE rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-dest-secrets-rolebinding namespace: DESTINATION_NAMESPACE subjects: - kind: ServiceAccount name: transfer-service-account namespace: DESTINATION_NAMESPACE roleRef: kind: Role name: read-secrets-role apiGroup: rbac.authorization.k8s.io ---
Trasferimento da GDC a non GDC
Per un trasferimento che coinvolge un sistema esterno, devi specificare esplicitamente le credenziali di accesso.
Crea le credenziali nello spazio dei nomi di destinazione:
--- apiVersion: v1 kind: Secret metadata: name: src-secret namespace: NAMESPACE data: access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key --- apiVersion: v1 kind: Secret metadata: name: dst-secret namespace: NAMESPACE data: access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key ---Crea un account di servizio (SA) utilizzato dal trasferimento, quindi aggiungi le autorizzazioni all'account per leggere e scrivere i secret utilizzando ruoli e RoleBinding. Non devi aggiungere autorizzazioni se il SA dello spazio dei nomi predefinito o il SA personalizzato dispone già di queste autorizzazioni.
--- apiVersion: v1 kind: ServiceAccount metadata: name: transfer-service-account namespace: NAMESPACE --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-secrets-role namespace: NAMESPACE rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-secrets-rolebinding namespace: NAMESPACE subjects: - kind: ServiceAccount name: transfer-service-account namespace: NAMESPACE roleRef: kind: Role name: read-secrets-role apiGroup: rbac.authorization.k8s.io ---
Ottieni i certificati CA
Ottieni i certificati CA per i sistemi di archiviazione di oggetti. Puoi ottenere gli stessi certificati dal tuo AO o PA seguendo le istruzioni per recuperare i bundle di attendibilità.
---
apiVersion: v1
kind: Secret
metadata:
name: src-cert
namespace: NAMESPACE
data:
ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUpHM2psOFZhTU85a1FteGdXUFl3N3d3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF5TVRVd01USXlNakZhRncweQpNekExTVRZd01USXlNakZhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWI== # base 64 encoded version of certificate
---
apiVersion: v1
kind: Secret
metadata:
name: dst-cert
namespace: NAMESPACE
data:
ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUtoaEJXWWo3VGZlUUZWUWo0U0RpckV3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF6TURZeU16TTROVEJhRncweQpNekEyTURReU16TTROVEJhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWIzRFFF== # base 64 encoded version of certificate. Can be same OR different than source certificate.
---
(Facoltativo) Crea un LoggingTarget
Crea un LoggingTarget per visualizzare i log del servizio di trasferimento in Loki.
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
namespace: NAMESPACE # Same namespace as your transfer job
name: logtarg1
spec:
# Choose matching pattern that identifies pods for this job
# Optional
# Relationship between different selectors: AND
selector:
# Choose pod name prefix(es) to consider for this job
# Observability platform will scrape all pods
# where names start with specified prefix(es)
# Should contain [a-z0-9-] characters only
# Relationship between different list elements: OR
matchPodNames:
- transfer-job # Choose the prefix here that matches your transfer job name
serviceName: transfer-service
Crea il workload di trasferimento
Puoi eseguire il trasferimento come operazione una tantum utilizzando un Job o pianificarlo per l'esecuzione ripetuta utilizzando un CronJob.
Scegli il metodo più adatto al tuo caso d'uso:
Crea un job una tantum
Utilizza questa configurazione per un singolo trasferimento di dati manuale.
---
apiVersion: batch/v1
kind: Job
metadata:
name: transfer-job
namespace: NAMESPACE
spec:
template:
spec:
serviceAccountName: transfer-service-account # The service account created in the previous step
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
# The S3 endpoints for your source and destination
- '--src_endpoint=SRC_ENDPOINT'
- '--dst_endpoint=DST_ENDPOINT'
# The Fully Qualified Names (FQN) of the buckets
- '--src_path=SRC_BUCKET_FQN/'
- '--dst_path=DST_BUCKET_FQN/'
# Cross-namespace mapping: point directly to the live credentials using NAMESPACE/SECRET_NAME
- '--src_credentials=NAMESPACE/SRC_SECRET_NAME'
- '--dst_credentials=NAMESPACE/DST_SECRET_NAME'
# Point to the CA certificate Secret created in the destination namespace
- '--src_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--dst_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=BANDWIDTH_LIMIT' # Optional. Examples: '10K', '100M', '1G'
restartPolicy: OnFailure
---
Crea un CronJob pianificato
Utilizza questa configurazione per mantenere il bucket di destinazione sincronizzato continuamente con il bucket di origine in base a una pianificazione fissa.
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: transfer-cronjob
namespace: NAMESPACE
spec:
schedule: "0 * * * *" # Runs at the top of every hour. Adjust the cron schedule as needed.
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 5
jobTemplate:
spec:
template:
spec:
serviceAccountName: transfer-service-account # The service account created in the previous step
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
# The S3 endpoints for your source and destination
- '--src_endpoint=SRC_ENDPOINT'
- '--dst_endpoint=DST_ENDPOINT'
# The Fully Qualified Names (FQN) of the buckets
- '--src_path=SRC_BUCKET_FQN/'
- '--dst_path=DST_BUCKET_FQN/'
# Cross-namespace mapping: point directly to the live credentials using NAMESPACE/SECRET_NAME
- '--src_credentials=NAMESPACE/SRC_SECRET_NAME'
- '--dst_credentials=NAMESPACE/DST_SECRET_NAME'
# Point to the CA certificate Secret created in the destination namespace
- '--src_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--dst_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=BANDWIDTH_LIMIT' # Optional. Examples: '10K', '100M', '1G'
restartPolicy: OnFailure
---
Monitora il trasferimento dei dati
Dopo aver creato un'istanza del job, puoi monitorarne lo stato utilizzando kubectl
comandi, ad esempio kubectl describe. Per verificare il trasferimento, elenca gli oggetti all'interno del bucket di destinazione per convalidare il trasferimento dei dati. Lo strumento di trasferimento dei dati è indipendente dalla posizione degli endpoint coinvolti nel trasferimento.
Esegui il comando seguente per controllare lo stato del workload:
# If you created a one-time Job:
kubectl describe job transfer-job -n NAMESPACE
# If you created a scheduled CronJob:
kubectl describe cronjob transfer-cronjob -n NAMESPACE
Il comando precedente indica lo stato del job.
Il job richiede a un pod di trasferire i dati. Puoi recuperare il nome del pod e consultare i log per verificare la presenza di errori durante il trasferimento.
Per visualizzare i log dei pod, esegui il comando seguente:
# 1. First, find the exact pod name generated by your Job
kubectl get pods -n NAMESPACE | grep transfer
# 2. Then, view the logs for that specific pod
kubectl logs POD_NAME -n NAMESPACE
Log dei job riusciti:
DEBUG : Starting main for transfer
I0607 21:34:39.183106 1 transfer.go:103] "msg"="Starting transfer " "destination"="sample-bucket" "source"="/data"
2023/06/07 21:34:39 NOTICE: Bandwidth limit set to {100Mi 100Mi}
I0607 21:34:49.238901 1 transfer.go:305] "msg"="Job finished polling " "Finished"=true "Number of Attempts"=2 "Success"=true
I0607 21:34:49.239675 1 transfer.go:153] "msg"="Transfer completed." "AvgSpeed"="10 KB/s" "Bytes Moved"="10.0 kB" "Errors"=0 "Files Moved"=10 "FilesComparedAtSourceAndDest"=3 "Time since beginning of transfer"="1.0s"
La visualizzazione dei log consente di vedere la velocità di trasferimento dei dati, che non è la stessa della larghezza di banda utilizzata, dei byte spostati, del numero di file con errori e dei file spostati.
Copia l'archiviazione a blocchi nell'archiviazione di oggetti
Assicurati di soddisfare i seguenti prerequisiti:
- Un endpoint S3 con un ID chiave S3 e una chiave di accesso segreta con almeno le autorizzazioni di SCRITTURA per il bucket dedicato in cui vuoi trasferire i dati.
- Un cluster funzionante con connettività all'endpoint S3.
- Privilegi per creare job e secret all'interno del cluster.
- Per la replica dell'archiviazione a blocchi, un pod con un
PersistentVolumeClaim(PVC) collegato di cui vuoi eseguire il backup nell'archiviazione di oggetti e privilegi per controllare i job e i PVC in esecuzione. - Per la replica dell'archiviazione a blocchi, una finestra durante la quale non vengono eseguite scritture nel
PersistentVolume(PV). - Per il ripristino dell'archiviazione a blocchi da un endpoint di archiviazione di oggetti, privilegi per allocare un PV con capacità sufficiente.
Per replicare un PV nell'archiviazione di oggetti, devi collegare un volume a un pod esistente. Durante la finestra di trasferimento, il pod non deve eseguire alcuna scrittura. Per evitare di scollegare il PV montato dal job, la procedura di trasferimento dei dati funziona eseguendo il job di trasferimento sulla stessa macchina del pod e utilizzando un mount hostPath per esporre il volume sul disco. In preparazione al trasferimento, devi prima trovare il nodo su cui è in esecuzione il pod e metadati aggiuntivi come l'UID del pod e il tipo di PVC per fare riferimento al percorso appropriato sul nodo. Devi sostituire questi metadati nel file YAML di esempio descritto nella sezione seguente.
Raccogli i metadati
Per raccogliere i metadati necessari per creare il job di trasferimento dei dati, segui questi passaggi:
Trova il nodo con il pod pianificato:
kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'Registra l'output di questo comando come NODE_NAME da utilizzare nel file YAML del job di trasferimento dei dati.
Trova l'UID del pod:
kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'Registra l'output di questo comando come POD_UID da utilizzare nel file YAML del job di trasferimento dei dati.
Trova il nome del PVC:
kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'Registra l'output di questo comando come PVC_NAME da utilizzare nel file YAML del job di trasferimento dei dati.
Trova il provisioner di archiviazione PVC:
kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'Registra l'output di questo comando come il PROVISIONER_TYPE da utilizzare nel file YAML del job di trasferimento dei dati.
Crea i secret
Per replicare i file nell'archiviazione di oggetti tra i cluster, devi prima creare un'istanza dei secret all'interno del cluster Kubernetes. Per consentire allo strumento di recuperare le credenziali, devi utilizzare chiavi corrispondenti per i dati dei secret.
Per eseguire il trasferimento in uno spazio dei nomi esistente, consulta l'esempio seguente di creazione di secret in uno spazio dei nomi transfer:
apiVersion: v1
kind: Secret
metadata:
name: src-secret
namespace: transfer
data:
access-key-id: c3JjLWtleQ== # echo -n src-key| base64 -w0
access-key: c3JjLXNlY3JldA== # echo -n src-secret| base64 -w0
---
apiVersion: v1
kind: Secret
metadata:
name: dst-secret
namespace: transfer
data:
access-key-id: ZHN0LWtleQ== # echo -n dst-key| base64 -w0
access-key: ZHN0LXNlY3JldA== # echo -n dst-secret| base64 -w0
Crea il job
Con i dati raccolti nella sezione precedente, crea un job con lo strumento di trasferimento dei dati. Il job di trasferimento dei dati ha un mount hostPath che fa riferimento al percorso del PV di interesse e un nodeSelector per il nodo pertinente.
Di seguito è riportato un esempio di job di trasferimento dei dati:
apiVersion: batch/v1
kind: Job
metadata:
name: transfer-job
namespace: transfer
spec:
template:
spec:
nodeSelector: NODE_NAME
serviceAccountName: data-transfer-sa
containers:
- name: storage-transfer-pod
image: storage-transfer
command:
- /storage-transfer
args:
- --dst_endpoint=https://your-dst-endpoint.com
- --src_path=/pvc-data
- --dst_path=transfer-dst-bucket
- --dst_credentials=transfer/dst-secret
- --src_type=local
- --dst_type=s3
volumeMounts:
- mountPath: /pvc-data
name: pvc-volume
volumes:
- name: pvc-volume
hostPath:
path: /var/lib/kubelet/pods/POD_UID/volumes/PROVISIONER_TYPE/PVC_NAME
restartPolicy: Never
Come per il trasferimento dei dati S3, devi creare un secret
contenente le chiavi di accesso per l'endpoint di destinazione nel cluster Kubernetes
e il job di trasferimento dei dati deve essere eseguito con un account di servizio con
privilegi sufficienti per leggere il secret dal server API. Monitora lo stato del trasferimento con i comandi kubectl standard che operano sul job.
Quando trasferisci l'archiviazione a blocchi nell'archiviazione di oggetti, tieni presente i seguenti dettagli:
- Per impostazione predefinita, i link simbolici vengono seguiti e replicati nell'archiviazione di oggetti, ma viene eseguita una copia approfondita anziché superficiale. Al momento del ripristino, i link simbolici vengono eliminati.
- Come per la replica dell'archiviazione di oggetti, la clonazione in una sottodirectory del bucket è distruttiva. Assicurati che il bucket sia disponibile esclusivamente per il tuo volume.
Ripristina dall'archiviazione di oggetti all'archiviazione a blocchi
Alloca un PV
Per ripristinare l'archiviazione a blocchi da un endpoint di archiviazione di oggetti:
Alloca un volume permanente come destinazione del ripristino. Utilizza un PVC per allocare il volume, come mostrato nell'esempio seguente:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: restore-pvc namespace: restore-ns spec: storageClassName: "default" accessModes: ReadWriteOnce resources: requests: storage: 1Gi # Need sufficient capacity for full restoration.Controlla lo stato del PVC:
kubectl get pvc restore-pvc -n restore-nsQuando il PVC è nello stato
Bound, è pronto per essere utilizzato all'interno del pod che lo reidrata.Se un set con stato utilizza il PV, devi abbinare i PVC del set con stato sottoposti a rendering. I pod prodotti dal set con stato utilizzano i volumi idratati. L'esempio seguente mostra i modelli di rivendicazione del volume in un set con stato denominato
ss.volumeClaimTemplates: - metadata: name: pvc-name spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "default" resources: requests: storage: 1GiPrealloca i PVC con nomi come
ss-pvc-name-0ess-pvc-name-1per assicurarti che i pod risultanti utilizzino i volumi preallocati.
Idrata il PV
Dopo che il PVC è associato a un PV, avvia il job per popolare il PV:
apiVersion: batch/v1
kind: Job
metadata:
name: transfer-job
namespace: transfer
spec:
template:
spec:
serviceAccountName: data-transfer-sa
volumes:
- name: data-transfer-restore-volume
persistentVolumeClaim:
claimName: restore-pvc
containers:
- name: storage-transfer-pod
image: storage-transfer
command:
- /storage-transfer
args:
- --src_endpoint=https://your-src-endpoint.com
- --src_path=/your-src-bucket
- --src_credentials=transfer/src-secret
- --dst_path=/restore-pv-mnt-path
- --src_type=s3
- --dst_type=local
volumeMounts:
- mountPath: /restore-pv-mnt-path
name: data-transfer-restore-volume
Al termine dell'esecuzione del job, i dati del bucket di archiviazione di oggetti vengono inseriti nel volume. Un pod separato può utilizzare i dati utilizzando gli stessi meccanismi standard per il montaggio di un volume.