데이터 이전

데이터 전송은 다음 간에 발생할 수 있습니다.

  1. 영구 볼륨 신청 (PVC) 및 객체 스토리지
  2. 객체 스토리지 및 객체 스토리지 (GDC 내)

GDC의 객체 스토리지는 S3와 호환되며 Kubernetes yaml에서 s3 유형으로 참조됩니다.

데이터 소스/대상 유형

  1. 객체 스토리지('s3'): GDC에 있는 객체 스토리지
  2. 로컬 스토리지('로컬'이라고 함): 연결된 PVC의 스토리지

객체 스토리지에서 객체 스토리지로 복사

다음 기본 요건이 충족되었는지 확인합니다.

  • 소스에 대한 읽기 권한이 있는 S3 엔드포인트와 대상에 대한 쓰기 권한이 있는 s3 엔드포인트
  • 사용자 인증 정보에 버킷 생성 권한이 없으면 대상 버킷이 없는 경우 전송이 실패합니다. 이 경우 대상 버킷이 있는지 확인합니다.
  • 클러스터 또는 네임스페이스 내에서 작업을 만들고 보안 비밀을 만들거나 읽을 수 있는 권한 권한에 관한 다음 예시를 참고하세요.

작업 만들기

작업을 만들려면 다음 단계를 따르세요.

  1. 네임스페이스를 만듭니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: transfer-ns
    
  2. 사용자 인증 정보를 만듭니다.

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

    이 사용자 인증 정보는 객체 스토리지 섹션에서 획득한 것과 동일합니다.

  3. 전송에서 사용하는 서비스 계정 (SA)을 만든 다음 역할 및 역할 바인딩을 사용하여 비밀을 읽고 쓸 수 있는 권한을 계정에 추가합니다. 기본 네임스페이스 SA 또는 커스텀 SA에 이미 이러한 권한이 있는 경우 권한을 추가할 필요가 없습니다.

    ---
    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
    
    ---
    
  4. 객체 스토리지 시스템의 CA 인증서를 가져옵니다. 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.
    
    ---
    
    
  5. 선택사항: Loki에서 전송 서비스 로그를 볼 수 있도록 LoggingTarget을 만듭니다.

    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
    
  6. 작업을 만듭니다.

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

데이터 전송 모니터링

작업을 인스턴스화한 후 kubectl describe과 같은 kubectl 명령어를 사용하여 상태를 모니터링할 수 있습니다. 전송을 확인하려면 대상 버킷 내의 객체를 나열하여 데이터가 전송되었는지 확인합니다. 데이터 전송 도구는 전송에 관련된 엔드포인트의 위치에 구애받지 않습니다.

다음을 실행합니다.

kubectl describe transfer-job -n transfer-ns

위 명령어는 작업 상태를 알려줍니다.

작업에서 데이터 전송을 위해 포드를 프롬프트합니다. 포드 이름을 가져와 로그를 확인하여 전송 중에 오류가 있는지 확인할 수 있습니다.

포드 로그를 보려면 다음을 실행하세요.

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

성공한 작업 로그:

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"

로그를 보면 사용된 대역폭, 이동된 바이트, 오류가 발생한 파일 수, 이동된 파일 수와는 다른 데이터 전송 속도를 확인할 수 있습니다.

블록 스토리지를 객체 스토리지에 복사

다음 기본 요건을 충족해야 합니다.

  • 데이터를 전송할 전용 버킷에 대한 쓰기 권한이 있는 S3 키 ID와 보안 비밀 액세스 키가 있는 S3 엔드포인트
  • S3 엔드포인트에 연결된 작동 중인 클러스터
  • 클러스터 내에서 작업 및 보안 비밀을 만들 권한
  • 블록 스토리지 복제의 경우 객체 스토리지에 백업할 PersistentVolumeClaim (PVC)가 연결된 포드와 실행 중인 작업 및 PVC를 검사할 권한이 필요합니다.
  • 블록 스토리지 복제의 경우 PersistentVolume (PV)에 쓰기가 발생하지 않는 기간입니다.
  • 객체 스토리지 엔드포인트에서 블록 스토리지를 복원하려면 충분한 용량으로 PV를 할당할 권한이 필요합니다.

PV를 객체 스토리지에 복제하려면 기존 포드에 볼륨을 연결해야 합니다. 전송 기간 동안 포드는 쓰기를 실행해서는 안 됩니다. 마운트된 PV가 작업에서 분리되지 않도록 데이터 전송 프로세스는 포드와 동일한 머신에서 전송 작업을 실행하고 hostPath 마운트를 사용하여 디스크의 볼륨을 노출하는 방식으로 작동합니다. 전송을 준비하려면 먼저 Pod가 실행 중인 노드와 노드에서 적절한 경로를 참조하는 Pod UID, PVC 유형과 같은 추가 메타데이터를 찾아야 합니다. 이 메타데이터를 다음 섹션에 설명된 샘플 YAML 파일에 대체해야 합니다.

메타데이터 수집

데이터 전송 작업을 만드는 데 필요한 메타데이터를 수집하려면 다음 단계를 따르세요.

  1. 예약된 포드가 있는 노드를 찾습니다.

    kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'
    

    이 명령어의 출력을 데이터 전송 작업 YAML 파일에서 사용할 NODE_NAME로 기록합니다.

  2. 포드 UID를 찾습니다.

    kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'
    

    이 명령어의 출력을 데이터 전송 작업 YAML 파일에서 사용할 POD_UID로 기록합니다.

  3. PVC 이름을 찾습니다.

    kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'
    

    이 명령어의 출력을 데이터 전송 작업 YAML 파일에서 사용할 PVC_NAME로 기록합니다.

  4. PVC 스토리지 프로비저너를 찾습니다.

    kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'
    

    이 명령어의 출력을 데이터 전송 작업 YAML 파일에서 사용할 PROVISIONER_TYPE로 기록합니다.

보안 비밀 만들기

클러스터 간에 객체 스토리지로 파일을 복제하려면 먼저 Kubernetes 클러스터 내에서 보안 비밀을 인스턴스화해야 합니다. 도구가 사용자 인증 정보를 가져오려면 Secret 데이터에 일치하는 키를 사용해야 합니다.

기존 네임스페이스에서 전송을 실행하려면 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

작업 만들기

이전 섹션에서 수집한 데이터를 사용하여 데이터 전송 도구로 작업을 만듭니다. 데이터 전송 작업에는 관심 있는 PV의 경로를 참조하는 hostPath 마운트와 관련 노드의 nodeSelector이 있습니다.

다음은 데이터 전송 작업의 예입니다.

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

S3 데이터 전송과 마찬가지로 Kubernetes 클러스터에서 대상 엔드포인트의 액세스 키가 포함된 보안 비밀을 만들어야 하며, 데이터 전송 작업은 API 서버에서 보안 비밀을 읽을 수 있는 적절한 권한이 있는 서비스 계정으로 실행해야 합니다. 작업에서 작동하는 표준 kubectl 명령어를 사용하여 전송 상태를 모니터링합니다.

블록 스토리지를 객체 스토리지로 전송할 때는 다음 세부정보를 고려하세요.

  • 기본적으로 심볼릭 링크는 객체 스토리지를 따르고 복제하지만 얕은 복사 대신 전체 복사가 실행됩니다. 복원 시 심볼릭 링크가 삭제됩니다.
  • 객체 스토리지 복제와 마찬가지로 버킷의 하위 디렉터리로 클로닝하면 파괴적입니다. 버킷이 볼륨에만 독점적으로 사용 가능한지 확인합니다.

객체 스토리지에서 블록 스토리지로 복원

PV 할당

객체 스토리지 엔드포인트에서 블록 스토리지를 복원하려면 다음 단계를 따르세요.

  1. 복원에서 타겟에 영구 볼륨을 할당합니다. 다음 예와 같이 PVC를 사용하여 볼륨을 할당합니다.

    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.
    
  2. PVC 상태를 확인합니다.

    kubectl get pvc restore-pvc -n restore-ns
    

    PVC가 Bound 상태가 되면 PVC를 다시 하이드레이션하는 포드 내에서 사용할 준비가 된 것입니다.

  3. Stateful 세트가 결국 PV를 사용하는 경우 렌더링된 StatefulSet PVC와 일치해야 합니다. StatefulSet에서 생성된 포드는 하이드레이션된 볼륨을 사용합니다. 다음 예시는 ss라는 StatefulSet의 볼륨 클레임 템플릿을 보여줍니다.

      volumeClaimTemplates:
      - metadata:
          name: pvc-name
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: "default"
          resources:
            requests:
              storage: 1Gi
    
  4. 결과 포드가 사전 할당된 볼륨을 사용하도록 ss-pvc-name-0ss-pvc-name-1과 같은 이름으로 PVC를 사전 할당합니다.

PV 하이드레이션

PVC가 PV에 바인딩된 후 작업을 시작하여 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

작업이 완료되면 객체 스토리지 버킷의 데이터가 볼륨에 채워집니다. 별도의 포드는 볼륨을 마운트하는 동일한 표준 메커니즘을 사용하여 데이터를 사용할 수 있습니다.