Esta página foi traduzida pela API Cloud Translation.

Transferir dados

As transferências de dados podem ocorrer entre:

Reivindicação de volume permanente (PVC) e armazenamento de objetos
Armazenamento de objetos e armazenamento de objetos (no GDC)

O armazenamento de objetos no GDC é compatível com S3 e é chamado de tipo s3 em yamls do Kubernetes.

Tipos de origens/destinos de dados

Armazenamento de objetos (chamado de "s3"): armazenamento de objetos presente no GDC
Armazenamento local (chamado de "local"): armazenamento em PVCs anexados

Como copiar do armazenamento de objetos para o armazenamento de objetos

Verifique se você atende aos seguintes pré-requisitos:

Um endpoint do S3 com permissões de leitura para a origem e um endpoint do S3 com permissões de gravação para o destino.
Se você não tiver permissão para criar um bucket com as credenciais, a transferência vai falhar se o bucket de destino não existir. Verifique se o bucket de destino existe.
Privilégios para criar jobs e criar ou ler secrets no cluster ou namespace. Confira o exemplo a seguir para permissões.

Criar um job

Para criar um job, siga estas etapas:

Para criar um namespace:

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

Crie credenciais:

---

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

Essas credenciais são as mesmas que você recebeu na seção de armazenamento de objetos.

Crie uma conta de serviço (SA) usada pela transferência e adicione permissões a ela para ler e gravar secrets usando papéis e vinculações de papéis. Não é necessário adicionar permissões se a SA padrão ou personalizada do namespace já tiver essas permissões.

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

---

Consiga os certificados de CA para seus sistemas de armazenamento de objetos. Você pode conseguir os mesmos certificados com seu 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.

---

Opcional: crie um LoggingTarget para ver os registros do serviço de transferência no 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

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

Monitore sua transferência de dados

Depois de instanciar o job, é possível monitorar o status dele usando comandos kubectl, como kubectl describe. Para verificar a transferência, liste os objetos no bucket de destino e valide se os dados foram transferidos. A ferramenta de transferência de dados não depende da localização dos endpoints envolvidos na transferência.

Execute o comando a seguir:

kubectl describe transfer-job -n transfer-ns

O comando anterior informa o status do job.

O job solicita que um pod transfira os dados. Você pode conferir o nome do pod e analisar os registros para verificar se há erros durante a transferência.

Para ver os registros do pod, execute o seguinte comando:

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

Registros de jobs concluídos:

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"

Com a visualização de registros, é possível conferir a velocidade de transferência de dados, que não é a mesma coisa que largura de banda usada, bytes movidos, número de arquivos com erros e arquivos movidos.

Copiar armazenamento em blocos para armazenamento de objetos

Verifique se você atende aos seguintes pré-requisitos:

Um endpoint do S3 com um ID de chave do S3 e uma chave de acesso secreta com pelo menos permissões de GRAVAÇÃO no bucket dedicado para onde você quer transferir os dados.
Um cluster em funcionamento com conectividade ao endpoint do S3.
Privilégios para criar jobs e secrets no cluster.
Para replicação de armazenamento em blocos, um pod com um PersistentVolumeClaim (PVC) anexado que você quer fazer backup para armazenamento de objetos e privilégios para inspecionar jobs e PVCs em execução.
Para a replicação do armazenamento em blocos, uma janela em que não há gravações no PersistentVolume (PV).
Para a restauração do armazenamento em blocos de um endpoint de armazenamento de objetos, privilégios para alocar um PV com capacidade suficiente.

Para replicar um PV no armazenamento de objetos, anexe um volume a um pod existente. Durante a janela de transferência, o pod não pode realizar nenhuma gravação. Para evitar a separação do PV montado do job, o processo de transferência de dados executa o job de transferência na mesma máquina do pod e usa uma montagem hostPath para expor o volume no disco. Antes da transferência, primeiro encontre o nó em que o pod está sendo executado e outros metadados, como o UID do pod e o tipo de PVC, para referenciar o caminho adequado no nó. Substitua esses metadados no arquivo YAML de exemplo descrito na seção a seguir.

Coletar metadados

Para coletar os metadados necessários para criar o job de transferência de dados, siga estas etapas:

Encontre o nó que tem o pod programado:
```
kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'
```
Registre a saída desse comando como o NODE_NAME para usar no arquivo YAML do job de transferência de dados.
Encontre o UID do pod:
```
kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'
```
Registre a saída desse comando como o POD_UID para usar no arquivo YAML do job de transferência de dados.
Encontre o nome do PVC:
```
kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'
```
Registre a saída desse comando como o PVC_NAME para usar no arquivo YAML do job de transferência de dados.
Encontre o provisionador de armazenamento de PVC:
```
kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'
```
Registre a saída desse comando como o PROVISIONER_TYPE para usar no arquivo YAML do job de transferência de dados.

Criar secrets

Para replicar arquivos no armazenamento de objetos em clusters, primeiro instancie os secrets no cluster do Kubernetes. Você precisa usar chaves correspondentes para os dados secretos para que a ferramenta extraia as credenciais.

Para realizar a transferência em um namespace atual, consulte o exemplo a seguir de criação de secrets em um namespace 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

Crie o job

Com os dados coletados na seção anterior, crie um job com a ferramenta de transferência de dados. O job de transferência de dados tem uma montagem hostPath que faz referência ao caminho do PV de interesse e um nodeSelector para o nó relevante.

Confira a seguir um exemplo de job de transferência de dados:

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

Assim como na transferência de dados do S3, é necessário criar um Secret que contenha as chaves de acesso do endpoint de destino no cluster do Kubernetes. Além disso, o Job de transferência de dados precisa ser executado com uma conta de serviço com privilégios adequados para ler o Secret do servidor da API. Monitore o status da transferência com comandos kubectl padrão que operam no job.

Considere os seguintes detalhes ao transferir armazenamento em blocos para armazenamento de objetos:

Por padrão, os links simbólicos seguem e são replicados para o armazenamento de objetos, mas uma cópia detalhada é realizada em vez de uma cópia superficial. Após a restauração, ele destrói os links simbólicos.
Assim como na replicação de armazenamento de objetos, a clonagem em um subdiretório do bucket é destrutiva. Verifique se o bucket está disponível exclusivamente para seu volume.

Restaurar do armazenamento de objetos para o armazenamento em blocos

Alocar um PV

Para restaurar o armazenamento em blocos de um endpoint de armazenamento de objetos, siga estas etapas:

Alocar um volume permanente para o destino na restauração. Use um PVC para alocar o volume, conforme mostrado no exemplo a seguir:

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.

Verifique o status da PVC:
```
kubectl get pvc restore-pvc -n restore-ns
```
Depois que o PVC estiver no estado Bound, ele estará pronto para ser consumido no pod que o reidrata.

Se um conjunto de estado consumir o PV, você precisará corresponder aos PVCs renderizados do StatefulSet. Os pods que o StatefulSet produz consomem os volumes hidratados. O exemplo a seguir mostra modelos de reivindicação de volume em um StatefulSet chamado ss.

  volumeClaimTemplates:
  - metadata:
      name: pvc-name
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "default"
      resources:
        requests:
          storage: 1Gi

Pré-aloque PVCs com nomes como ss-pvc-name-0 e ss-pvc-name-1 para garantir que os pods resultantes consumam os volumes pré-alocados.

Hidratar o PV

Depois que o PVC for vinculado a um PV, inicie o job para preencher o 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

Depois que o job terminar de ser executado, os dados do bucket de armazenamento de objetos vão preencher o volume. Um pod separado pode consumir os dados usando os mesmos mecanismos padrão para montar um volume.

Transferir dados Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.