Datenübertragungen können zwischen den folgenden Elementen erfolgen:
- PersistentVolumeClaim (PVC) und Objektspeicher
- Objektspeicher und Objektspeicher (innerhalb von GDC)
Objektspeicher in GDC ist S3-kompatibel und wird in Kubernetes-YAML-Dateien als Typ s3 bezeichnet.
Arten von Datenquellen und -zielen
- Objektspeicher (als „s3“ bezeichnet): Objektspeicher in GDC
- Lokaler Speicher (als „local“ bezeichnet): Speicher auf angehängten PVCs
Aus Objektspeicher in Objektspeicher kopieren
Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:
- Ein S3-Endpunkt mit Leseberechtigungen für die Quelle und ein S3-Endpunkt mit Schreibberechtigungen für das Ziel.
- Wenn Sie mit den Anmeldedaten keine Berechtigung zum Erstellen von Buckets haben, schlägt die Übertragung fehl, wenn der Ziel-Bucket nicht vorhanden ist. Prüfen Sie in diesem Fall, ob der Ziel-Bucket vorhanden ist.
- Berechtigungen zum Erstellen von Jobs und zum Erstellen oder Lesen von Secrets in Ihrem Cluster oder Namespace. Ein Beispiel für Berechtigungen finden Sie unten.
Datenübertragung einrichten
Führen Sie die folgenden Schritte aus, um die Datenübertragung einzurichten:
Namespace für die Übertragung erstellen
Erstellen Sie den Namespace, in dem der Übertragungsjob ausgeführt wird:
apiVersion: v1
kind: Namespace
metadata:
name: NAMESPACE
Anmeldedaten konfigurieren
Bereiten Sie Ihre Anmeldedaten für die Übertragung vor. Folgen Sie der Option, die am besten zu Ihrem Übertragungsszenario passt.
Übertragung von GDC zu GDC
Bei einer Übertragung, die vollständig innerhalb desselben GDC-Universums erfolgt, sind die Secrets bereits vorhanden. Diese Methode ist nur für Übertragungen innerhalb eines einzelnen Universums geeignet, nicht für Übertragungen zwischen verschiedenen Universen.
Folgen Sie der Anleitung zum Gewähren des Bucket-Zugriffs, um die S3-Anmeldedaten-Secrets abzurufen.
Erstellen Sie im Ziel-Namespace ein Dienstkonto für Ihren Übertragungsjob. Fügen Sie dann Berechtigungen hinzu, damit dieses Konto mit RoleBindings für mehrere Namespaces Secrets sowohl im Quell- als auch im Ziel-Namespace lesen kann.
--- apiVersion: v1 kind: ServiceAccount metadata: name: transfer-service-account namespace: DESTINATION_NAMESPACE --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-secrets-role namespace: SOURCE_NAMESPACE rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-source-secrets-rolebinding namespace: SOURCE_NAMESPACE subjects: - kind: ServiceAccount name: transfer-service-account namespace: DESTINATION_NAMESPACE roleRef: kind: Role name: read-secrets-role apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-secrets-role namespace: DESTINATION_NAMESPACE rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-dest-secrets-rolebinding namespace: DESTINATION_NAMESPACE subjects: - kind: ServiceAccount name: transfer-service-account namespace: DESTINATION_NAMESPACE roleRef: kind: Role name: read-secrets-role apiGroup: rbac.authorization.k8s.io ---
Übertragung von GDC zu einem System außerhalb von GDC
Bei einer Übertragung, an der ein externes System beteiligt ist, müssen Sie die Anmeldedaten explizit angeben.
Erstellen Sie Anmeldedaten im Ziel-Namespace:
--- apiVersion: v1 kind: Secret metadata: name: src-secret namespace: NAMESPACE 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: NAMESPACE data: access-key-id: NkFDTUg3WDBCVDlQMVpZMU5MWjU= # base 64 encoded version of key access-key: VkRkeWJsbFgzb2FZanMvOVpnSi83SU5YUjk3Y0Q2TUdxZ2d4Q3dpdw== # base 64 encoded version of secret key ---Erstellen Sie ein Dienstkonto, das für die Übertragung verwendet wird, und fügen Sie dem Konto dann Berechtigungen hinzu, um Secrets mithilfe von Rollen und Rollenbindungen zu lesen und zu schreiben. Sie müssen keine Berechtigungen hinzufügen, wenn Ihr Standard-Namespace-Dienstkonto oder benutzerdefiniertes Dienstkonto bereits über diese Berechtigungen verfügt.
--- 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 ---
CA-Zertifikate abrufen
Rufen Sie die CA-Zertifikate für Ihre Objektspeichersysteme ab. Sie können dieselben Zertifikate von Ihrem AO oder PA abrufen, indem Sie der Anleitung zum Abrufen von Trust-Bundles folgen.
---
apiVersion: v1
kind: Secret
metadata:
name: src-cert
namespace: NAMESPACE
data:
ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUpHM2psOFZhTU85a1FteGdXUFl3N3d3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF5TVRVd01USXlNakZhRncweQpNekExTVRZd01USXlNakZhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWI== # base 64 encoded version of certificate
---
apiVersion: v1
kind: Secret
metadata:
name: dst-cert
namespace: NAMESPACE
data:
ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBekNDQWV1Z0F3SUJBZ0lSQUtoaEJXWWo3VGZlUUZWUWo0U0RpckV3RFFZSktvWklodmNOQVFFTEJRQXcKR3pFWk1CY0dBMVVFQXhNUVltOXZkSE4wY21Gd0xYZGxZaTFqWVRBZUZ3MHlNekF6TURZeU16TTROVEJhRncweQpNekEyTURReU16TTROVEJhTUJzeEdUQVhCZ05WQkFNVEVHSnZiM1J6ZEhKaGNDMTNaV0l0WTJFd2dnRWlNQTBHCkNTcUdTSWIzRFFF== # base 64 encoded version of certificate. Can be same OR different than source certificate.
---
(Optional) LoggingTarget erstellen
Erstellen Sie ein LoggingTarget, um Logs des Übertragungsdienstes in Loki zu sehen.
apiVersion: logging.gdc.goog/v1
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:
- transfer-job # Choose the prefix here that matches your transfer job name
serviceName: transfer-service
Übertragungsarbeitslast erstellen
Sie können die Übertragung als einmaligen Vorgang mit einem Job ausführen oder sie mit einem CronJob wiederholt ausführen lassen.
Wählen Sie die Methode aus, die am besten zu Ihrem Anwendungsfall passt:
Einmaligen Job erstellen
Verwenden Sie diese Konfiguration für eine einmalige, manuelle Datenübertragung.
---
apiVersion: batch/v1
kind: Job
metadata:
name: transfer-job
namespace: NAMESPACE
spec:
template:
spec:
serviceAccountName: transfer-service-account # The service account created in the previous step
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
# The S3 endpoints for your source and destination
- '--src_endpoint=SRC_ENDPOINT'
- '--dst_endpoint=DST_ENDPOINT'
# The Fully Qualified Names (FQN) of the buckets
- '--src_path=SRC_BUCKET_FQN/'
- '--dst_path=DST_BUCKET_FQN/'
# Cross-namespace mapping: point directly to the live credentials using NAMESPACE/SECRET_NAME
- '--src_credentials=NAMESPACE/SRC_SECRET_NAME'
- '--dst_credentials=NAMESPACE/DST_SECRET_NAME'
# Point to the CA certificate Secret created in the destination namespace
- '--src_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--dst_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=BANDWIDTH_LIMIT' # Optional. Examples: '10K', '100M', '1G'
restartPolicy: OnFailure
---
Geplanten CronJob erstellen
Verwenden Sie diese Konfiguration, um Ihren Ziel-Bucket in einem festen Zeitplan kontinuierlich mit Ihrem Quell-Bucket zu synchronisieren.
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: transfer-cronjob
namespace: NAMESPACE
spec:
schedule: "0 * * * *" # Runs at the top of every hour. Adjust the cron schedule as needed.
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 5
jobTemplate:
spec:
template:
spec:
serviceAccountName: transfer-service-account # The service account created in the previous step
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
# The S3 endpoints for your source and destination
- '--src_endpoint=SRC_ENDPOINT'
- '--dst_endpoint=DST_ENDPOINT'
# The Fully Qualified Names (FQN) of the buckets
- '--src_path=SRC_BUCKET_FQN/'
- '--dst_path=DST_BUCKET_FQN/'
# Cross-namespace mapping: point directly to the live credentials using NAMESPACE/SECRET_NAME
- '--src_credentials=NAMESPACE/SRC_SECRET_NAME'
- '--dst_credentials=NAMESPACE/DST_SECRET_NAME'
# Point to the CA certificate Secret created in the destination namespace
- '--src_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--dst_ca_certificate_reference=NAMESPACE/CA_CERT_SECRET'
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=BANDWIDTH_LIMIT' # Optional. Examples: '10K', '100M', '1G'
restartPolicy: OnFailure
---
Datenübertragung überwachen
Nachdem Sie den Job instanziiert haben, können Sie seinen Status mit kubectl
Befehlen wie kubectl describe überwachen. Um die Übertragung zu prüfen, listen Sie die Objekte in Ihrem Ziel-Bucket auf, um zu bestätigen, dass Ihre Daten übertragen wurden. Das Datenübertragungstool ist unabhängig vom Standort der Endpunkte, die an der Übertragung beteiligt sind.
Führen Sie den folgenden Befehl aus, um den Status Ihrer Arbeitslast zu prüfen:
# If you created a one-time Job:
kubectl describe job transfer-job -n NAMESPACE
# If you created a scheduled CronJob:
kubectl describe cronjob transfer-cronjob -n NAMESPACE
Der vorherige Befehl gibt den Status des Jobs an.
Der Job fordert einen Pod auf, die Daten zu übertragen. Sie können den Namen des Pods abrufen und sich die Logs ansehen, um festzustellen, ob während der Übertragung Fehler aufgetreten sind.
So rufen Sie Pod-Logs auf:
# 1. First, find the exact pod name generated by your Job
kubectl get pods -n NAMESPACE | grep transfer
# 2. Then, view the logs for that specific pod
kubectl logs POD_NAME -n NAMESPACE
Logs erfolgreicher Jobs:
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"
In den Logs sehen Sie die Datenübertragungsgeschwindigkeit, die nicht mit der verwendeten Bandbreite, den verschobenen Byte, der Anzahl der fehlerhaften Dateien und den verschobenen Dateien identisch ist.
Blockspeicher in Objektspeicher kopieren
Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:
- Ein S3-Endpunkt mit einer S3-Schlüssel-ID und einem geheimen Zugriffsschlüssel mit mindestens Schreibberechtigungen für den dedizierten Bucket, in den Sie Daten übertragen möchten.
- Ein funktionierender Cluster mit Verbindung zum S3-Endpunkt.
- Berechtigungen zum Erstellen von Jobs und Secrets in Ihrem Cluster.
- Für die Replikation von Blockspeicher ein Pod mit einem angehängten
PersistentVolumeClaim(PVC), den Sie in Objektspeicher sichern möchten, und Berechtigungen zum Prüfen von laufenden Jobs und PVCs. - Für die Replikation des Blockspeichers ein Zeitraum, in dem keine Schreibvorgänge in das
PersistentVolume(PV) erfolgen. - Für die Wiederherstellung von Blockspeicher von einem Objektspeicherendpunkt Berechtigungen zum Zuweisen eines PV mit ausreichender Kapazität.
Um ein PV in Objektspeicher zu replizieren, müssen Sie ein Volume an einen vorhandenen Pod anhängen. Während des Übertragungszeitraums darf der Pod keine Schreibvorgänge ausführen. Um zu vermeiden, dass das bereitgestellte PV vom Job getrennt wird, werden die Datenübertragungsvorgänge ausgeführt, indem der Übertragungsjob auf demselben Computer wie der Pod ausgeführt wird und ein hostPath-Mount verwendet wird, um das Volume auf dem Laufwerk verfügbar zu machen. Zur Vorbereitung auf die Übertragung müssen Sie zuerst den Knoten suchen, auf dem der Pod ausgeführt wird, sowie zusätzliche Metadaten wie die Pod-UID und den PVC-Typ, um auf den entsprechenden Pfad auf dem Knoten zu verweisen. Sie müssen diese Metadaten in die YAML-Beispieldatei einfügen, die im folgenden Abschnitt beschrieben wird.
Metadaten erfassen
Führen Sie die folgenden Schritte aus, um die Metadaten zu erfassen, die zum Erstellen des Datenübertragungsjobs erforderlich sind:
Suchen Sie den Knoten mit dem geplanten Pod:
kubectl get pod POD_NAME -o jsonpath='{.spec.nodeName}'Notieren Sie sich die Ausgabe dieses Befehls als NODE_NAME, um sie in der YAML-Datei des Datenübertragungsjobs zu verwenden.
Suchen Sie die Pod-UID:
kubectl get pod POD_NAME -o 'jsonpath={.metadata.uid}'Notieren Sie sich die Ausgabe dieses Befehls als POD_UID, um sie in der YAML-Datei des Datenübertragungsjobs zu verwenden.
Suchen Sie den PVC-Namen:
kubectl get pvc www-web-0 -o 'jsonpath={.spec.volumeName}'Notieren Sie sich die Ausgabe dieses Befehls als PVC_NAME, um sie in der YAML-Datei des Datenübertragungsjobs zu verwenden.
Suchen Sie den PVC-Bereitsteller:
kubectl get pvc www-web-0 -o jsonpath='{.metadata.annotations.volume\.v1\.kubernetes\.io\/storage-provisioner}'Notieren Sie sich die Ausgabe dieses Befehls als die PROVISIONER_TYPE, die in der YAML -Datei des Datenübertragungsjobs verwendet werden soll.
Secrets erstellen
Um eine Datei clusterübergreifend in Objektspeicher zu replizieren, müssen Sie zuerst die Secrets in Ihrem Kubernetes-Cluster instanziieren. Sie müssen übereinstimmende Schlüssel für die Secret-Daten verwenden, damit das Tool die Anmeldedaten abrufen kann.
Ein Beispiel für die Ausführung der Übertragung in einem vorhandenen Namespace finden Sie unten. Hier werden Secrets in einem transfer-Namespace erstellt:
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
Job erstellen
Erstellen Sie mit den Daten, die Sie im vorherigen Abschnitt erfasst haben, einen Job mit dem Datenübertragungstool. Der Datenübertragungsjob hat einen hostPath-Mount, der auf den Pfad für das PV verweist, und einen nodeSelector für den relevanten Knoten.
Unten sehen Sie ein Beispiel für einen Datenübertragungsjob:
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
Wie bei der S3-Datenübertragung müssen Sie ein Secret
erstellen, das die Zugriffsschlüssel für den Zielendpunkt im Kubernetes
Cluster enthält. Der Datenübertragungsjob muss mit einem Dienstkonto mit
ausreichenden Berechtigungen ausgeführt werden, um das Secret vom API-Server zu lesen. Überwachen Sie den Status der Übertragung mit Standardbefehlen von kubectl, die für den Job ausgeführt werden.
Beachten Sie beim Übertragen von Blockspeicher in Objektspeicher die folgenden Details:
- Standardmäßig werden symbolische Links verfolgt und in den Objektspeicher repliziert. Dabei wird jedoch eine tiefe Kopie anstelle einer flachen Kopie erstellt. Bei der Wiederherstellung werden Symlinks zerstört.
- Wie bei der Replikation von Objektspeicher ist das Klonen in ein Unterverzeichnis des Buckets destruktiv. Achten Sie darauf, dass der Bucket ausschließlich für Ihr Volume verfügbar ist.
Aus Objektspeicher in Blockspeicher wiederherstellen
PV zuweisen
So stellen Sie Blockspeicher von einem Objektspeicherendpunkt wieder her:
Weisen Sie ein nichtflüchtiges Volume als Ziel für die Wiederherstellung zu. Verwenden Sie einen PVC, um das Volume zuzuweisen, wie im folgenden Beispiel gezeigt:
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.Prüfen Sie den Status des PVC:
kubectl get pvc restore-pvc -n restore-nsWenn der PVC den Status
Boundhat, kann er im Pod verwendet werden, der ihn rehydriert.Wenn ein StatefulSet das PV verwendet, müssen Sie die gerenderten PVCs des StatefulSet abgleichen. Die Pods, die vom StatefulSet erstellt werden, verwenden die rehydrierten Volumes. Das folgende Beispiel zeigt Volume-Claim-Vorlagen in einem StatefulSet mit dem Namen
ss.volumeClaimTemplates: - metadata: name: pvc-name spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "default" resources: requests: storage: 1GiWeisen Sie PVCs mit Namen wie
ss-pvc-name-0undss-pvc-name-1vorab zu, um sicherzustellen, dass die resultierenden Pods die vorab zugewiesenen Volumes verwenden.
PV rehydrieren
Nachdem der PVC an ein PV gebunden wurde, starten Sie den Job, um das PV zu füllen:
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
Nachdem der Job abgeschlossen ist, werden die Daten aus dem Objektspeicher-Bucket in das Volume eingefügt. Ein separater Pod kann die Daten mit denselben Standardmechanismen zum Bereitstellen eines Volumes verwenden.