Cette page a été traduite par l'API Cloud Translation.

Transférer les données

Les transferts de données peuvent avoir lieu entre les éléments suivants :

PersistentVolumeClaim (PVC) et stockage d'objets
Stockage d'objets et stockage d'objets (dans GDC)

Le stockage d'objets sur GDC est compatible avec S3 et est appelé type s3 dans les fichiers YAML Kubernetes.

Types de sources/destinations de données

Stockage d'objets (appelé "s3") : stockage d'objets présent sur GDC
Stockage local (appelé "local") : stockage sur les PVC associés

Copier des données d'un stockage d'objets vers un autre

Assurez-vous de remplir les conditions préalables suivantes :

Un point de terminaison S3 avec des autorisations de lecture pour la source et un point de terminaison S3 avec des autorisations d'écriture pour la destination.
Si vous ne disposez pas de l'autorisation de créer des buckets avec les identifiants, le transfert échoue si le bucket de destination n'existe pas. Assurez-vous que le bucket de destination existe, le cas échéant.
Privilèges permettant de créer des jobs et de créer ou lire des secrets dans votre cluster ou espace de noms. Consultez l'exemple suivant pour les autorisations.

Créer un job

Pour créer un job, procédez comme suit :

Créez un espace de noms :

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

Créez des identifiants :

---

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
---

Ces identifiants sont les mêmes que ceux que vous avez obtenus dans la section sur le stockage d'objets.

Créez un compte de service (CS) utilisé par votre transfert, puis ajoutez-y des autorisations pour lire et écrire des secrets à l'aide de rôles et d'associations de rôles. Vous n'avez pas besoin d'ajouter d'autorisations si votre SA d'espace de noms par défaut ou votre SA personnalisé les possèdent déjà.

---
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

---

Obtenez les certificats CA pour vos systèmes de stockage d'objets. Vous pouvez obtenir les mêmes certificats auprès de votre 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.

---

Facultatif : Créez un LoggingTarget pour afficher les journaux du service de transfert dans 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

Créez la tâche suivante :

---

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.
---

Surveiller le transfert de vos données

Une fois le job instancié, vous pouvez surveiller son état à l'aide des commandes kubectl, telles que kubectl describe. Pour vérifier le transfert, listez les objets dans votre bucket de destination afin de valider le transfert de vos données. L'outil de transfert de données est indépendant de l'emplacement des points de terminaison impliqués dans le transfert.

Exécutez la commande suivante :

kubectl describe transfer-job -n transfer-ns

La commande précédente vous indique l'état du job.

Le job invite un pod à transférer les données. Vous pouvez obtenir le nom du pod et consulter les journaux pour voir si des erreurs se sont produites lors du transfert.

Pour afficher les journaux de pod, exécutez la commande suivante :

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

Journaux des jobs réussis :

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"

L'affichage des journaux vous permet de voir la vitesse de transfert des données, qui est différente de la bande passante utilisée, des octets déplacés, du nombre de fichiers en erreur et des fichiers déplacés.

Copier le stockage par blocs vers le stockage d'objets

Assurez-vous de remplir les conditions préalables suivantes :

Un point de terminaison S3 avec un ID de clé S3 et une clé d'accès secrète disposant au moins des autorisations WRITE pour le bucket dédié vers lequel vous souhaitez transférer les données.
Un cluster fonctionnel avec connectivité au point de terminaison S3.
Privilèges permettant de créer des Jobs et des Secrets dans votre cluster.
Pour la réplication du stockage par blocs, un pod avec un PersistentVolumeClaim (PVC) associé que vous souhaitez sauvegarder dans le stockage d'objets, ainsi que des droits permettant d'inspecter les jobs et les PVC en cours d'exécution.
Pour la réplication du stockage par blocs, une fenêtre pendant laquelle aucune écriture n'a lieu sur le PersistentVolume (PV).
Pour la restauration du stockage par blocs à partir d'un point de terminaison de stockage d'objets, privilégiez l'allocation d'un PV avec une capacité suffisante.

Pour répliquer un PV dans le stockage d'objets, vous devez associer un volume à un pod existant. Pendant la période de transfert, le pod ne doit effectuer aucune écriture. Pour éviter de détacher le PV monté du Job, le processus de transfert de données consiste à exécuter le Job de transfert sur la même machine que le Pod et à utiliser un montage hostPath pour exposer le volume sur le disque. Avant le transfert, vous devez d'abord trouver le nœud sur lequel le pod s'exécute, ainsi que des métadonnées supplémentaires telles que l'UID du pod et le type de PVC pour référencer le chemin d'accès approprié sur le nœud. Vous devez remplacer ces métadonnées dans l'exemple de fichier YAML décrit dans la section suivante.

Collecter des métadonnées

Pour collecter les métadonnées requises pour créer le job de transfert de données, suivez ces étapes :

Recherchez le nœud sur lequel le pod est planifié :
```
kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'
```
Enregistrez la sortie de cette commande en tant que NODE_NAME à utiliser dans le fichier YAML du job de transfert de données.
Recherchez le Pod UID :
```
kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'
```
Enregistrez la sortie de cette commande en tant que POD_UID à utiliser dans le fichier YAML du job de transfert de données.
Recherchez le nom de la PVC :
```
kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'
```
Enregistrez la sortie de cette commande en tant que PVC_NAME à utiliser dans le fichier YAML du job de transfert de données.
Recherchez le provisionneur de stockage PVC :
```
kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'
```
Enregistrez le résultat de cette commande en tant que PROVISIONER_TYPE à utiliser dans le fichier YAML du job de transfert de données.

Créer des secrets

Pour répliquer des fichiers dans le stockage d'objets sur plusieurs clusters, vous devez d'abord instancier les secrets dans votre cluster Kubernetes. Vous devez utiliser des clés correspondantes pour les données secrètes afin que l'outil puisse extraire les identifiants.

Pour effectuer le transfert dans un espace de noms existant, consultez l'exemple suivant de création de secrets dans un espace de noms 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

Créer la tâche

À l'aide des données que vous avez collectées dans la section précédente, créez un job avec l'outil de transfert de données. La tâche de transfert de données comporte un montage hostPath faisant référence au chemin d'accès au PV qui vous intéresse et un nodeSelector pour le nœud concerné.

Voici un exemple de job de transfert de données :

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

Comme pour le transfert de données S3, vous devez créer un secret contenant les clés d'accès au point de terminaison de destination dans le cluster Kubernetes. Le job de transfert de données doit s'exécuter avec un compte de service disposant des droits d'accès suffisants pour lire le secret à partir du serveur d'API. Surveillez l'état du transfert à l'aide des commandes kubectl standards fonctionnant sur le job.

Tenez compte des points suivants lorsque vous transférez le stockage de blocs vers le stockage d'objets :

Par défaut, les liens symboliques sont suivis et répliqués dans le stockage d'objets, mais une copie profonde plutôt que superficielle est effectuée. Lors de la restauration, il détruit les liens symboliques.
Comme pour la réplication du stockage d'objets, le clonage dans un sous-répertoire du bucket est destructif. Assurez-vous que le bucket est disponible exclusivement pour votre volume.

Restaurer depuis le stockage d'objets vers le stockage par blocs

Allouer un PV

Pour restaurer le stockage par blocs à partir d'un point de terminaison de stockage d'objets, procédez comme suit :

Attribuez un volume persistant à cibler lors de la restauration. Utilisez une PVC pour allouer le volume, comme indiqué dans l'exemple suivant :

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.

Vérifiez l'état du PVC :
```
kubectl get pvc restore-pvc -n restore-ns
```
Une fois que le PVC est à l'état Bound, il est prêt à être utilisé dans le pod qui le réhydrate.
Si un StatefulSet consomme finalement le PV, vous devez faire correspondre les PVC StatefulSet affichés. Les pods produits par StatefulSet consomment les volumes hydratés. L'exemple suivant montre des modèles de revendication de volume dans un StatefulSet nommé ss.
```
  volumeClaimTemplates:
  - metadata:
      name: pvc-name
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "default"
      resources:
        requests:
          storage: 1Gi
```
Préallouez des PVC avec des noms tels que ss-pvc-name-0 et ss-pvc-name-1 pour vous assurer que les pods résultants consomment les volumes préalloués.

Hydrater le PV

Une fois le PVC lié à un PV, démarrez le Job pour remplir le 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

Une fois le job terminé, les données du bucket de stockage d'objets remplissent le volume. Un autre pod peut consommer les données en utilisant les mêmes mécanismes standards pour monter un volume.

Transférer les données Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.