Daten übertragen

Das Air-Gapped-Gerät von Google Distributed Cloud (GDC) überträgt beliebige Daten in und aus einer Air-Gapped-Umgebung von Google Distributed Cloud. Übertragungen können manuell gestartet oder so eingerichtet werden, dass sie in einem festgelegten Intervall automatisch erfolgen.

Beispielübertragungen:

• Softwareupdates oder aktualisierte Kundenarbeitslasten herunterladen
• Kundendaten, Gerätemesswerte oder Geräteprotokolle zu Sicherheit, Audit und Betrieb hochladen
• Snapshots von Sicherungsdaten

Das Storage Transfer-Tool überträgt Daten und wird auf einem Image für die Verwendung in laufenden Containern im Cluster verteilt.

Datenquellen

Das Tool für die Speicherübertragung bietet Flexibilität bei den Betriebsbedingungen der GDC-Air-Gap-Appliance. S3-kompatible APIs können auf extern bereitgestellte und interne Speicherziele zugreifen. Das Tool unterstützt auch lokale Dateisysteme und Cloud Storage-Quellen.

Der Betreiber ist dafür verantwortlich, die Kontrolle über Zugriffsschlüssel und alle anderen Anmeldedaten, Secrets oder vertraulichen Daten zu behalten, die für die Authentifizierung erforderlich sind, um die GDC-Air-Gap-Appliance mit externen Netzwerken zu verbinden. Der Betreiber ist auch für die Konfiguration des externen Netzwerks verantwortlich.

Informationen zum Erstellen und Zugreifen auf externen Speicher finden Sie unter Storage-Buckets erstellen.

Lokaler Speicher

Der lokale Speicher befindet sich in der Containerumgebung des Pods und umfasst das temporäre Dateisystem oder bereitgestellte Volumes. Das an den Pod gebundene ServiceAccount muss beim Bereitstellen von Volumes Zugriff auf alle Bereitstellungsziele haben.

S3-Speicher

Auf den im Netzwerk verfügbaren Speicher kann über die S3-kompatible API zugegriffen werden. Der Dienst kann entweder extern sein oder nur im Clusternetzwerk verfügbar gemacht werden. Sie müssen eine zugängliche URL und standardisierte Anmeldedaten angeben, die über ein Kubernetes-Secret bereitgestellt werden.

Auf Daten, die in Multi-Node- und Objektspeichern definiert sind, wird über die S3 API zugegriffen. Informationen zum Einrichten von Speicher mit mehreren Knoten und Objektspeicher in der GDC-Appliance mit „Luftspalt“ finden Sie in den entsprechenden Abschnitten.

Cloud-Speicher

Sie müssen eine zugängliche URL und standardisierte Anmeldedaten angeben, die mit einem Secret bereitgestellt werden.

Wenn Sie auf einen Cloud Storage-Bucket mit einheitlichen Zugriffssteuerungen zugreifen, müssen Sie das Flag --bucket-policy-only auf true setzen.

Anmeldedaten

Ein Kubernetes-Secret ist erforderlich, um den Storage Transfer Service für S3- oder GCS-Quell- oder ‑Zieldefinitionen zu verwenden. Diese können mit einem Remote-Dienstkonto oder einem Nutzerkonto bereitgestellt werden.

Wenn Sie Secrets in einer Job- oder CronJob-Definition verwenden, muss der JobSpec an ein Kubernetes-Dienstkonto angehängt werden, das Zugriff auf die Secrets hat.

Erstellen Sie ein ServiceAccount, das für den Transfer verwendet wird, und fügen Sie dem ServiceAccount dann Berechtigungen zum Lesen und Schreiben von Secrets mithilfe von Rollen und Rollenbindungen hinzu. Sie können die Erstellung eines ServiceAccount überspringen, wenn Ihr Standard-Namespace-ServiceAccount oder Ihr benutzerdefiniertes ServiceAccount bereits Berechtigungen hat.

  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

Remote-Dienstkonten

Wichtig :Um auf die URLs auf dieser Seite zuzugreifen, müssen Sie mit dem Internet verbunden sein. Die URLs sind für die Verwendung vorgesehen, wenn Sie einen solchen Zugriff haben.

Informationen zum Abrufen von Anmeldedaten für das Cloud Storage-Dienstkonto für die Durchführung einer Übertragung finden Sie unter https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account. Diese Anmeldedaten müssen in einem Secret im Feld service-account-key gespeichert werden.

Hier ein Beispiel:

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

Nutzerkonten

Sie können ein Nutzerkonto für die Authentifizierung mit S3-kompatiblen Buckets, aber nicht mit Cloud Storage-Buckets verwenden. Sie müssen das Argument --src_type oder --dst_type als s3 angeben.

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

Ersetzen Sie Folgendes:

• NAMESPACE: der Name des Namespaces, in dem Sie die Jobdefinition erstellen.
• SECRET_NAME: Der Name des Secrets, das Sie erstellen.
• ACCESS_KEY_ID: Der Wert, der im Feld Access Key in der Google Cloud -Konsole zu finden ist. Bei der Konfiguration für Object Storage wird dies als access-key-id bezeichnet.
• ACCESS_KEY: Der Wert, der im Feld Secret in der Google Cloud -Konsole gefunden wurde. Bei der Konfiguration für Object Storage ist dies der secret-key oder das Secret.

Zertifikate

Stellen Sie Zertifikate für die Validierung im Job mit einem Kubernetes-Secret bereit, das einen ca.crt-Datenschlüssel enthält.

  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.

Zertifikate können durch Verweis auf das Tool mit den Argumenten src_ca_certificate_reference und dst_ca_certificate_reference im Format NAMESPACE/SECRET_NAME bereitgestellt werden. Beispiel:

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

Für den S3-Speicher in der Appliance können Sie das trust-store-root-ext-Secret direkt als CA-Zertifikat verwenden. Beispiel:

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

Optional: LoggingTarget definieren, um Logs in Loki zu sehen

Standardmäßig sind Logs aus Jobs nur in den Kubernetes-Ressourcen sichtbar. Sie sind nicht im Observability-Stack verfügbar und müssen mit einem LoggingTarget konfiguriert werden, damit sie sichtbar sind.

  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

Integrierte Jobs definieren

Nutzer verwalten ihre eigenen Job-Ressourcen. Für einmalige Datenübertragungen definieren Sie einen Job. Mit dem Job wird ein Pod erstellt, in dem der Storage Transfer Service-Container ausgeführt wird.

Beispiel für einen 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

Einen integrierten CronJob definieren

Nutzer verwalten ihre eigenen definierten CronJob-Ressourcen. Mit einem integrierten CronJob lassen sich Datenübertragungen regelmäßig planen.

Beispiel für einen CronJob, mit dem eine automatische Datenübertragung erreicht wird:

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

Google empfiehlt, concurrencyPolicy auf Forbid zu setzen, um Datenkonflikte zu vermeiden. Der CronJob, das Secret und der PersistentVolumeClaim müssen sich im selben Namespace befinden.

Data-Jobs priorisieren

Die Priorität von Datenjobs kann auf verschiedene Arten festgelegt werden, die sich nicht gegenseitig ausschließen. Sie können weniger häufige Jobzeitpläne in der CronJob-Definition festlegen.

Jobs können auch mit InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) angeordnet werden, die immer in der Reihenfolge ihrer Definition ausgeführt werden. Alle Container müssen jedoch erfolgreich ausgeführt werden. Mit InitContainers können Sie einem Job eine höhere Priorität zuweisen oder Datenkonflikte verwalten, indem Sie zwei oder mehr InitContainers mit gespiegelten Quell- und Zieldefinitionen definieren.

Ein Beispiel für jobTemplate, mit dem eine geordnete Datenübertragung erreicht wird:

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

Container A-to-B wird vor B-to-A ausgeführt. In diesem Beispiel werden sowohl die bidirektionale Synchronisierung als auch die Jobreihenfolge erreicht.