このページは Cloud Translation API によって翻訳されました。

データ転送

Google Distributed Cloud（GDC）エアギャップアプライアンスデバイスは、Google Distributed Cloud エアギャップ環境との間で任意のデータを転送します。転送は手動で開始することも、設定された間隔で自動的に実行されるように設定することもできます。

転送の例:

ソフトウェアアップデートまたは更新された顧客ワークロードをダウンロードする
顧客データ、デバイス指標、デバイスのセキュリティ、監査、オペレーションログをアップロードする
バックアップデータのスナップショット

storage-transfer ツールはデータを転送し、クラスタで実行中のコンテナで使用するイメージに分散されます。

データソース

storage-transfer ツールを使用すると、GDC エアギャップアプライアンスの動作条件を柔軟に設定できます。S3 互換 API は、外部に公開されたストレージターゲットと内部ストレージターゲットにアクセスできます。このツールは、ローカルファイルシステムと Cloud Storage のソースもサポートしています。

オペレーターは、GDC エアギャップアプライアンスを外部ネットワークに接続するための認証に必要なアクセスキー、その他の認証情報、シークレット、機密データの制御を維持する責任を負います。オペレーターは、外部ネットワークの構成も担当します。

外部ストレージの作成とアクセスについては、ストレージバケットの作成を参照してください。

ローカルストレージ

ローカルストレージは Pod のコンテナ環境に含まれており、一時ファイルシステムやマウントされたボリュームが含まれます。ボリュームをマウントするときに、Pod にバインドされた ServiceAccount がすべてのマウントターゲットにアクセスできる必要があります。

S3 ストレージ

ネットワークで使用可能なストレージには、S3 互換 API を介してアクセスできます。サービスは、外部に公開することも、クラスタネットワーク内でのみ公開することもできます。アクセス可能な URL と、Kubernetes Secret を使用してマウントされた標準化された認証情報を提供する必要があります。

マルチノードとオブジェクトストレージで定義されたデータには、S3 API を介してアクセスします。GDC エアギャップアプライアンス内でのマルチノードストレージとオブジェクトストレージの設定については、関連するセクションをご覧ください。

クラウドストレージ

Secret を使用してマウントされたアクセス可能な URL と標準化された認証情報を指定する必要があります。

均一なアクセス制御で Cloud Storage バケットにアクセスする場合は、--bucket-policy-only フラグを true に設定する必要があります。

認証情報

S3 または GCS の移行元または移行先の定義に storage-transfer サービスを使用するには、Kubernetes Secret が必要です。これらは、リモートサービスアカウントまたはユーザーアカウントで指定できます。

Job または CronJob の定義で Secret を使用する場合は、JobSpec を Secret にアクセスできる Kubernetes ServiceAccount に関連付ける必要があります。

転送で使用される ServiceAccount を作成し、ロールとロールバインディングを使用してシークレットの読み取りと書き込みを行う権限を ServiceAccount に追加します。デフォルトの Namespace の ServiceAccount またはカスタム ServiceAccount にすでに権限が付与されている場合は、ServiceAccount を作成しないように選択できます。

  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

リモートサービスアカウント

転送を行うための Cloud Storage サービスアカウントの認証情報を取得するには、https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account をご覧ください。これらの認証情報は、service-account-key フィールドのシークレットに保存する必要があります。

以下に例を示します。

apiVersion: v1
data:
  service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
  name: gcs-secret
  namespace: NAMESPACE
type: Opaque

ユーザーアカウント

Cloud Storage バケットではなく、S3 互換バケットで認証にユーザーアカウントを使用できます。--src_type 引数または --dst_type 引数を s3 として指定する必要があります。

kubectl create secret -n NAMESPACE generic S3_CREDENTIAL_SECRET_NAME \
    --from-literal=access-key-id=ACCESS_KEY_ID
    --from-literal=access-key=ACCESS_KEY

次のように置き換えます。

NAMESPACE: Job 定義を作成する Namespace の名前。
SECRET_NAME: 作成する Secret の名前。
ACCESS_KEY_ID: Google Cloud コンソールの [アクセスキー] フィールドに表示される値。Object Storage 用に構成する場合、これは access-key-id と呼ばれます。
ACCESS_KEY: Google Cloud コンソールの Secret フィールドにある値。Object Storage 用に構成する場合、これは secret-key または Secret です。

証明書

ca.crt データキーを含む Kubernetes Secret を使用して、ジョブの検証用の証明書を提供します。

  apiVersion: v1
  kind: Secret
  metadata:
    name: SRC_CERTIFICATE_SECRET_NAME
    namespace: NAMESPACE
  data:
    ca.crt : BASE_64_ENCODED_SOURCE_CERTIFICATE
  ---
  apiVersion: v1
  kind: Secret
  metadata:
    name: DST_CERTIFICATE_SECRET_NAME
    namespace: NAMESPACE
  data:
    ca.crt : BASE_64_ENCODED_DESTINATION_CERTIFICATE # Can be same OR different than source certificate.

証明書は、NAMESPACE/SECRET_NAME 形式の引数 src_ca_certificate_reference と dst_ca_certificate_reference を使用してツールを参照することで提供できます。次に例を示します。

...
      containers:
      - name: storage-transfer-pod
        image: gcr.io/private-cloud-staging/storage-transfer:latest
        command:
        - /storage-transfer
        args:
        ...
        - --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
        - --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME

アプライアンスの S3 ストレージでは、trust-store-root-ext シークレットを CA 証明書として直接使用できます。次に例を示します。

containers:
      - name: storage-transfer-pod
        image: gcr.io/private-cloud-staging/storage-transfer:latest
        command:
        - /storage-transfer
        args:
        - --src_type=s3
        - --src_ca_certificate_reference=NAMESPACE/trust-store-root-ext

省略可: Loki でログを表示するように LoggingTarget を定義する

デフォルトでは、Job のログは Kubernetes リソースでのみ表示され、オブザーバビリティスタックでは使用できません。表示するには、LoggingTarget を使用して構成する必要があります。

  apiVersion: logging.gdc.goog/v1alpha1
  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:
        - data-transfer-job # Choose the prefix here that matches your transfer job name
    serviceName: transfer-service

組み込み Job を定義する

ユーザーは独自のジョブリソースを管理します。1 回限りのデータ転送の場合は、Job を定義します。Job は、storage-transfer コンテナを実行する Pod を作成します。

Job の例:

apiVersion: batch/v1
kind: Job
metadata:
  name: data-transfer-job
  namespace: NAMESPACE
spec:
  template:
    spec:
      restartPolicy: Never
      serviceAccountName: transfer-service-account,
      containers:
      - name: storage-transfer-pod
        image: gcr.io/private-cloud-staging/storage-transfer:latest
        command:
        - /storage-transfer
        args:
        - --src_path=/src
        - --src_type=local
        - --dst_endpoint=https://your-dst-endpoint.com
        - --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
        - --dst_path=/FULLY_QUALIFIED_BUCKET_NAME/BUCKET_PATH
        - --dst_type=gcs
        - --bucket_policy_only=true
        - --bandwidth_limit=10M #Optional of the form '10K', '100M', '1G' bytes per second
        volumeMounts:
        - mountPath: /src
          name: data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: data-transfer-source

組み込み CronJob を定義する

ユーザーは、自分で定義した CronJob リソースを管理します。組み込みの CronJob を使用すると、データ転送を定期的にスケジュールできます。

データ転送を自動化する CronJob の例:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: data-transfer-cronjob
  namespace: NAMESPACE
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: transfer-service-account
          containers:
          - name: storage-transfer-pod
            image: gcr.io/private-cloud-staging/storage-transfer:latest
            command:
            - /storage-transfer
            args:
            - --src_path=LOCAL_PATH
            - --src_type=local
            - --dst_endpoint=https://your-dst-endpoint.com
            - --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
            - --dst_path=/FULLY_QUALIFIED_BUCKET_NAME/BUCKET_PATH
            - --dst_type=gcs
            - --bucket_policy_only=true
            volumeMounts:
            - mountPath: LOCAL_PATH
              name: source
          restartPolicy: Never
          volumes:
          - name: source
            persistentVolumeClaim:
              claimName: data-transfer-source

データ競合を防ぐため、concurrencyPolicy を Forbid に設定することをおすすめします。CronJob、Secret、PersistentVolumeClaim は同じ Namespace に存在する必要があります。

データジョブの優先順位を設定する

データジョブの優先度を設定する方法は複数あり、相互に排他的ではありません。CronJob 定義で、ジョブスケジュールの頻度を低く設定できます。

ジョブは、定義順に常に実行される InitContainers（https://kubernetes.io/docs/concepts/workloads/pods/init-containers/）を使用して順序付けすることもできます。ただし、すべてのコンテナが正常に実行される必要があります。InitContainers を使用して、1 つのジョブに高い優先度を付与するか、ミラーリングされたソースと宛先の定義を持つ 2 つ以上の InitContainers を定義してデータ競合を管理します。

順序付きデータ転送を実現する jobTemplate の例:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: ordered-data-transfer-cronjob
  namespace: NAMESPACE
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: job-complete
            image: whalesay
            command: ["sh", "-c", "echo Job Completed."]
          initContainers:
          - name: A-to-B
            image: gcr.io/private-cloud-staging/storage-transfer:latest
            command: [/storage-transfer]
            args:
            - --src_type=s3
            - --src_endpoint=ENDPOINT_A
            - --src_path=/example-bucket
            - --src_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
            - --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
            - --dst_type=s3
            - --dst_endpoint=ENDPOINT_B
            - --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
            - --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME
            - --dst_path=/example-bucket
          - name: B-to-A
            image: gcr.io/private-cloud-staging/storage-transfer:latest
            command: [/storage-transfer]
            args:
            - --src_type=s3
            - --src_endpoint=ENDPOINT_B
            - --src_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
            - --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
            - --src_path=/example-bucket
            - --dst_type=s3
            - --dst_endpoint=ENDPOINT_A
            - --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
            - --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME
            - --dst_path=/example-bucket

コンテナ A-to-B は B-to-A の前に実行されます。この例では、bisync とジョブの順序付けの両方を実現しています。