Questa pagina è stata tradotta dall'API Cloud Translation.

Trasferimento dei dati

I trasferimenti di dati possono avvenire tra:

Persistent Volume Claim (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 tipo s3 nei file YAML di Kubernetes.

Tipi di origini/destinazioni dati

Archiviazione di oggetti (indicata come "s3"): archiviazione di oggetti presente su GDC
Archiviazione locale (denominata "locale"): spazio di 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 disponi dell'autorizzazione per creare bucket con le credenziali, il trasferimento non riesce se il bucket di destinazione non esiste. Assicurati che il bucket di destinazione esista, se è questo il caso.
Privilegi per creare job e creare o leggere secret all'interno del cluster o dello spazio dei nomi. Per le autorizzazioni, vedi l'esempio seguente.

Crea un job

Per creare un job, segui questi passaggi:

Creare uno spazio dei nomi:

apiVersion: v1
kind: Namespace
metadata:
  name: transfer-ns

Crea credenziali:

---

apiVersion: v1
kind: Secret
metadata:
  name: src-secret
  namespace: transfer-ns
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: transfer-ns
data:
  access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key
  access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key
---

Queste credenziali sono le stesse che hai ottenuto nella sezione di archiviazione di oggetti.

Crea un account di servizio (SA) utilizzato dal trasferimento, quindi aggiungi le autorizzazioni all'account per leggere e scrivere i secret utilizzando ruoli e associazioni di ruoli. Non devi aggiungere autorizzazioni se la SA dello spazio dei nomi predefinito o la SA personalizzata le dispone già.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: transfer-service-account
  namespace: transfer-ns
---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-secrets-role
  namespace: transfer-ns
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets-rolebinding
  namespace: transfer-ns
subjects:
- kind: ServiceAccount
  name: transfer-service-account
  namespace: transfer-ns
roleRef:
  kind: Role
  name: read-secrets-role
  apiGroup: rbac.authorization.k8s.io

---

Ottieni i certificati CA per i tuoi sistemi di archiviazione degli oggetti. Puoi ottenere gli stessi certificati dal tuo AO/PA.

---

apiVersion: v1
kind: Secret
metadata:
  name: src-cert
  namespace: transfer-ns
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUpHM2psOFZhTU85a1FteGdXUFl3N3d3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF5TVRVd01USXlNakZhRncweQpNekExTVRZd01USXlNakZhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWI== # base 64 encoded version of certificate

---

apiVersion: v1
kind: Secret
metadata:
  name: dst-cert
  namespace: transfer-ns
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUtoaEJXWWo3VGZlUUZWUWo0U0RpckV3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF6TURZeU16TTROVEJhRncweQpNekEyTURReU16TTROVEJhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWIzRFFF== # base 64 encoded version of certificate. Can be same OR different than source certificate.

---

(Facoltativo) Crea un LoggingTarget per visualizzare i log del servizio di trasferimento in Loki.

apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  namespace: transfer-ns # 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 job:

---

apiVersion: batch/v1
kind: Job
metadata:
  name: transfer-job
  namespace: transfer-ns
spec:
  template:
    spec:
      serviceAccountName: transfer-service-account #service account created earlier
      containers:
        - name: storage-transfer-pod #
          image: gcr.io/private-cloud-staging/storage-transfer:latest
          imagePullPolicy: Always #will always pull the latest image
          command:
            - /storage-transfer
          args:
            - '--src_endpoint=objectstorage.zone1.google.gdch.test' #Your endpoint here
            - '--dst_endpoint=objectstorage.zone1.google.gdch.test' #Your endpoint here
            - '--src_path=aecvd-bucket1' #Please use Fully Qualified Name
            - '--dst_path=aklow-bucket2' #Please use Fully Qualified Name
            - '--src_credentials=transfer-ns/src-secret' #Created earlier
            - '--dst_credentials=transfer-ns/dst-secret' #Created earlier
            - '--dst_ca_certificate_reference=transfer-ns/dst-cert' #Created earlier
            - '--src_ca_certificate_reference=transfer-ns/src-cert' #Created earlier
            - '--src_type=s3'
            - '--dst_type=s3'
            - '--bandwidth_limit=10M' #Optional of the form '10K', '100M', '1G' bytes per second
      restartPolicy: OnFailure #Will restart on failure.
---

Monitorare il trasferimento dei dati

Dopo aver creato un'istanza del job, puoi monitorarne lo stato utilizzando i comandi kubectl, 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 questo comando:

kubectl describe transfer-job -n transfer-ns

Il comando precedente indica lo stato del job.

Il job richiede a un pod di trasferire i dati. Puoi ottenere il nome del pod e consultare i log per verificare la presenza di errori durante il trasferimento.

Per visualizzare i log dei pod, esegui questo comando:

kubectl logs transfer-job-<pod_id_suffix_obtained_from_describe_operation_on_job> -n transfer-ns

Log 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 ti 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 l'autorizzazione WRITE al bucket dedicato a 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 una PersistentVolumeClaim (PVC) collegata di cui vuoi eseguire il backup nell'archiviazione di oggetti e privilegi per esaminare i job e le 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 nello spazio di archiviazione 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 la PV montata dal job, il processo di trasferimento dei dati funziona eseguendo il job di trasferimento sulla stessa macchina del pod e utilizzando un montaggio 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.

Raccogliere i metadati

Per raccogliere i metadati necessari per creare il job di trasferimento dei dati, segui questi passaggi:

Trova il nodo che contiene 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 PROVISIONER_TYPE da utilizzare nel file YAML del job di trasferimento dei dati.

Crea secret

Per replicare il file nell'object storage tra i cluster, devi prima creare un'istanza dei secret all'interno del cluster Kubernetes. Devi utilizzare chiavi corrispondenti per i dati secret affinché lo strumento estragga le credenziali.

Per eseguire il trasferimento in uno spazio dei nomi esistente, consulta il seguente esempio 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 montaggio 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 uaccount di serviziont con privilegi adeguati per leggere il secret dal server API. Monitora lo stato del trasferimento con i comandi standard kubectl che operano sul job.

Quando trasferisci l'archiviazione a blocchi all'archiviazione di oggetti, tieni presenti i seguenti dettagli:

Per impostazione predefinita, i link simbolici vengono seguiti e replicati nell'archiviazione oggetti, ma viene eseguita una copia completa anziché superficiale. Al ripristino, distrugge i link simbolici.
Come per la replica dell'archiviazione degli oggetti, la clonazione in una sottodirectory del bucket è distruttiva. Assicurati che il bucket sia disponibile esclusivamente per il tuo volume.

Ripristinare dall'archiviazione di oggetti all'archiviazione a blocchi

Assegnare un PV

Per ripristinare l'archiviazione a blocchi da un endpoint di archiviazione di oggetti:

Assegna un volume permanente alla destinazione del ripristino. Utilizza una 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-ns
```
Una volta che la PVC è nello stato Bound, è pronta per essere utilizzata all'interno del pod che la reidrata.
Se un oggetto StatefulSet alla fine utilizza il PV, devi abbinare le PVC di StatefulSet sottoposte a rendering. I pod prodotti da StatefulSet utilizzano i volumi idratati. L'esempio seguente mostra i modelli di rivendicazione del volume in un StatefulSet denominato ss.
```
  volumeClaimTemplates:
  - metadata:
      name: pvc-name
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "default"
      resources:
        requests:
          storage: 1Gi
```
Prealloca i PVC con nomi come ss-pvc-name-0 e ss-pvc-name-1 per assicurarti che i pod risultanti utilizzino i volumi preallocati.

Idrata il PV

Dopo che il PVC è stato 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 degli oggetti vengono inseriti nel volume. Un pod separato può utilizzare i dati utilizzando gli stessi meccanismi standard per il montaggio di un volume.

Trasferimento dei dati Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.