Objektspeicher verwalten

Richtlinien für die Benennung von Storage-Buckets

Bucket-Namen müssen den folgenden Namenskonventionen entsprechen:

  • Sie muss innerhalb des Projekts eindeutig sein. Ein Projekt fügt dem Bucket-Namen ein eindeutiges Präfix hinzu, um Konflikte innerhalb der Organisation zu vermeiden. Im unwahrscheinlichen Fall, dass sich ein Präfix und ein Bucket-Name über Organisationen hinweg überschneiden, schlägt die Bucket-Erstellung mit einem bucket name in use-Fehler fehl.
  • Muss mindestens ein und darf höchstens 57 Zeichen enthalten.
  • Geben Sie keine personenidentifizierbaren Informationen an.
  • DNS-konform sein.
  • Muss mit einem Buchstaben beginnen und darf nur Buchstaben, Zahlen und Bindestriche enthalten.

s3cmd-Befehlszeile installieren

Das Tool s3cmd ist ein Befehlszeilentool zum Verwalten von Objektspeicher.

  1. Rufen Sie das Verzeichnis auf, aus dem das GDC-Bundle extrahiert wurde, um das Tool herunterzuladen.

  2. Führen Sie die folgenden Befehle aus, um das s3cmd-Image s3cmd.tar.tar.gz in ein leeres temporäres Verzeichnis zu extrahieren:

    tmpdir=$(mktemp -d)

gdcloud artifacts extract oci/ $tmpdir \
  --image-name=$(gdcloud artifacts tree oci | grep s3cmd.tar | sed 's/^.* //')

  3. scp Kopieren Sie die TAR-Datei auf einen Clientcomputer, auf dem Sie s3cmd für Objektvorgänge verwenden. Entpacken Sie das Image und installieren Sie es.

Wählen Sie eine der folgenden Installationsmethoden aus, um das s3cmd-Tool zu installieren:

Über eine TAR-Datei installieren

  1. Führen Sie die folgenden Befehle aus, um das Archiv zu entpacken und das s3cmd-Paket zu installieren. Sie benötigen das Python-Modul distutils, um das Paket zu installieren. Das Modul ist oft Teil des Python-Kernpakets oder Sie können es mit Ihrem Paketmanager installieren.

    tar xvf /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz
cd /tmp/gpc-system-tar-files/s3cmd
sudo python3 setup.py install

  2. Optional: Heruntergeladene Dateien bereinigen:

    rm /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz
rm -r /tmp/gpc-system-tar-files/s3cmd

Mit Docker-Image installieren

  1. Führen Sie die folgenden Befehle aus, um das s3cmd-Image zu installieren:

    docker load --input s3cmd-docker.tar
export S3CFG=/EMPTY_FOLDER_PATH/
alias s3cmd="docker run -it --net=host --mount=type=bind,source=/$S3CFG/,target=/g/
s3cmd-docker:latest -c /g/s3cfg"

  2. Optional: Heruntergeladene Dateien bereinigen:

    rm s3cmd-docker.tar

  3. Fügen Sie den Export und den Alias der Datei .bashrc hinzu, damit sie nach dem Neustart des Clients erhalten bleiben.

s3cmd-Tool konfigurieren

Verwenden Sie das Tool „s3cmd“ für objektbasierte Vorgänge.

Führen Sie den Befehl s3cmd --configure aus und geben Sie Folgendes an:

  1. Zugriffsschlüssel: Geben Sie den Zugriffsschlüssel ein, den Sie im Secret unter Zugriffsanmeldedaten abrufen erhalten haben.
  2. Geheimer Schlüssel: Geben Sie den geheimen Schlüssel ein, der aus dem Secret unter Zugriffsanmeldedaten abrufen abgerufen wurde.
  3. Standardregion: Drücken Sie ENTER.
  4. S3-Endpunkt: Geben Sie den Endpunkt ein, den Ihr Infrastrukturbetreiber (Infrastructure Operator, IO) bereitstellt.
  5. Geben Sie für die Bucket-Benennung im DNS-Stil s3://%(bucket) ein.
  6. Optional: Geben Sie ein Verschlüsselungspasswort ein, um Dateien während der Übertragung zu schützen.
  7. Geben Sie unter „Pfad zu GPG“ /usr/bin/gpg ein.
  8. Geben Sie Yes ein, um das HTTPS-Protokoll zu verwenden.
  9. Drücken Sie Enter, um die Eingabe des Proxyservernamens zu überspringen.

Storage-Buckets erstellen

Hinweise

In einem Projekt-Namespace werden Bucket-Ressourcen im Administrator-Stammcluster verwaltet. Sie benötigen ein Projekt, um einen Bucket zu erstellen. Informationen zum Erstellen eines neuen Projekts finden Sie unter Projekt erstellen. Sie benötigen die entsprechenden Bucket-Berechtigungen, um die folgenden Vorgänge auszuführen. Weitere Informationen finden Sie unter Bucket-Zugriff gewähren.

Bucket erstellen

Um einen Bucket zu erstellen, wenden Sie eine Bucket-Spezifikation auf Ihren Projekt-Namespace an:

    kubectl apply -f bucket.yaml

Hier ist ein Beispiel für eine Bucket-Spezifikation:

    apiVersion: object.gdc.goog/v1alpha1
    kind: Bucket
    metadata:
      name: BUCKET_NAME
      namespace: NAMESPACE_NAME
    spec:
      description: DESCRIPTION
      storageClass: standard-rwo
      bucketPolicy :
        lockingPolicy :
          defaultObjectRetentionDays: RETENTION_DAY_COUNT

Weitere Informationen finden Sie in der Bucket API-Referenz.

Storage-Buckets auflisten

Führen Sie die folgenden Schritte aus, um alle Buckets aufzulisten, auf die Sie in einem bestimmten Object Storage-Mandanten Zugriff haben:

  1. Führen Sie die folgenden Befehle aus, um alle Buckets aufzulisten:

    kubectl get buckets --all-namespaces
kubectl get buckets --namespace NAMESPACE_NAME

Storage-Buckets löschen

Sie können Speicher-Buckets mit der CLI löschen. Buckets müssen leer sein, bevor Sie sie löschen können.

  1. Verwenden Sie den Befehl GET oder DESCRIBE im Abschnitt Bucket-Konfiguration ansehen, um den voll qualifizierten Bucket-Namen abzurufen.

  2. Wenn der Bucket nicht leer ist, leeren Sie ihn:

    s3cmd rm --recursive -—force s3://FULLY_QUALIFIED_BUCKET_NAME

  3. Löschen Sie den leeren Bucket:

    kubectl delete buckets/BUCKET_NAME --namespace NAMESPACE_NAME

Bucket-Konfiguration ansehen

Verwenden Sie einen der beiden Befehle, um die Konfigurationsdetails für einen Bucket aufzurufen:

    kubectl describe buckets/BUCKET_NAME --namespace NAMESPACE_NAME

    kubectl get buckets/BUCKET_NAME --namespace NAMESPACE_NAME -o yaml

Aufbewahrungszeitraum für Objekte festlegen

Standardmäßig können Sie Objekte jederzeit löschen. Aktivieren Sie die Objektsperrung mit einem Aufbewahrungszeitraum, um zu verhindern, dass alle Objekte im Bucket für die angegebene Anzahl von Tagen gelöscht werden. Sie können einen Bucket erst löschen, wenn Sie alle Objekte nach Ablauf der Aufbewahrungsdauer gelöscht haben.

Sie müssen die Objektsperre beim Erstellen des Buckets aktivieren. Sie können die Objektsperrung nach dem Erstellen eines Buckets nicht mehr aktivieren oder deaktivieren. Sie können jedoch den Standardzeitraum für die Objektaufbewahrung ändern.

Sie können einen Bucket erstellen, ohne die Objektsperrung zu aktivieren. Wenn Sie die Objektverriegelung aktiviert haben, ist die Angabe einer Standardaufbewahrungsdauer optional.

Wenn Sie die Aufbewahrungsdauer ändern möchten, aktualisieren Sie das Feld Bucket.spec.bucketPolicy.lockingPolicy.defaultObjectRetentionDays in der Bucket-Ressource.

Das folgende Beispiel zeigt, wie das Feld in der Bucket-Ressource aktualisiert wird:

apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This bucket has a default retention period specified."
  storageClass: standard-rwo
  bucketPolicy :
    lockingPolicy :
      defaultObjectRetentionDays: RETENTION_DAY_COUNT
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This would enable object locking but not specify a default retention period."
  storageClass: standard-rwo
  bucketPolicy :
    lockingPolicy :
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: NAMESPACE_NAME
spec:
  description: "This bucket does not have locking or retention enabled."
  storageClass: standard-rwo

Alle Aktualisierungen der Aufbewahrungsdauer gelten für Objekte, die nach der Aktualisierung im Bucket erstellt wurden. Für bereits vorhandene Objekte ändert sich die Aufbewahrungsdauer nicht.

Wenn Sie die Objektsperrung aktiviert haben und versuchen, ein Objekt zu überschreiben, wird eine neue Version des Objekts hinzugefügt. Sie können beide Objektversionen abrufen. Weitere Informationen zum Auflisten von Objektversionen finden Sie in der Amazon Web Services-Dokumentation unter ListObjectVersions: https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html

Informationen zum Erstellen eines WORM-Buckets (Write-Once, Read-Many) finden Sie im Abschnitt WORM-Bucket.

Bucket-Zugriff gewähren

Sie können anderen Nutzern oder Dienstkonten Bucket-Zugriff gewähren, indem Sie RoleBindings mit vordefinierten Rollen erstellen und anwenden.

Vordefinierte Rollen

  • project-bucket-object-viewer::Mit dieser Rolle kann ein Nutzer alle Buckets im Projekt auflisten, Objekte in diesen Buckets auflisten sowie Objekte und Objektmetadaten lesen. Mit dieser Rolle können Sie keine Schreibvorgänge für Objekte ausführen, z. B. Hochladen, Überschreiben oder Löschen.

  • project-bucket-object-admin::Mit dieser Rolle kann ein Nutzer alle Buckets im Projekt auflisten sowie Schreib- und Lesevorgänge für Objekte ausführen, z. B. Hochladen, Überschreiben oder Löschen.

  • project-bucket-admin::Mit dieser Rolle können Nutzer alle Buckets im angegebenen Namespace sowie alle Objekte in diesen Buckets verwalten.

Eine vollständige Liste der für diese Rollen gewährten Berechtigungen finden Sie im Abschnitt Berechtigungen für voreingestellte Rollen.

Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen die Rolle „Projekt-IAM-Administrator“ (project-iam-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Projektrollenbindungen benötigen.

Das folgende Beispiel zeigt, wie Sie eine RoleBinding erstellen, um einem Nutzer und einem Dienstkonto Zugriff zu gewähren:

  1. Erstellen Sie auf Ihrem System eine YAML-Datei, z. B. rolebinding-object-admin-all-buckets.yaml.

     apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
 metadata:
   namespace: NAMESPACE_NAME
   name: readwrite-all-buckets
 roleRef:
   kind: Role
   name: project-bucket-object-admin
   apiGroup: rbac.authorization.k8s.io
 subjects:
 - kind: ServiceAccount
   namespace: NAMESPACE_NAME
   name: SA_NAME
 - kind: User
   namespace: NAMESPACE_NAME
   name: bob@example.com  # Could be bob or bob@example.com based on your organization settings.
   apiGroup: rbac.authorization.k8s.io
 ```

  2. Wenden Sie die YAML-Datei an:

    kubectl apply \
-f rolebinding-object-admin-all-buckets.yaml

Anmeldedaten für den Bucket-Zugriff abrufen

Wenn Sie Zugriff auf einen Bucket gewähren, werden die Anmeldedaten für den Zugriff in einem Secret erstellt.

Das Format des Secret-Namens ist object-storage-key-SUBJECT_TYPE-SUBJECT_HASH.

  • Für SUBJECT_TYPE sind folgende Werte möglich:
    • user: der Nutzer.
    • sa: die ServiceAccount.
  • SUBJECT_HASH ist der base32-codierte SHA256-Hash des Betreffnamens.

Beispiel: Der Nutzer bob@foo.com hat das Secret mit dem Namen:

object-storage-key-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

Nutzer-Secret aufrufen

Für ein Nutzer-Subjekt befindet sich das Secret im Namespace object-storage-access-keys im Administratorcluster des Stammclusters.

  1. Suchen Sie den Secret-Namen:

    kubectl auth can-i --list --namespace object-storage-access-keys | grep object-storage-key-

    Die Ausgabe sollte in etwa so aussehen:

    secrets        []        [object-storage-key-nl-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja,object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja]        [get]

  2. Rufen Sie den Inhalt des entsprechenden Secrets ab, um auf Buckets zuzugreifen:

    kubectl get -o yaml --namespace object-storage-access-keys secret
object-storage-key-rm-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

    Die Ausgabe sollte in etwa so aussehen:

    data:
  access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
  create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
  secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==

  3. Decodieren Sie die Zugriffsschlüssel-ID und das Secret:

    echo "MEhYM08wWUMySjcyMkVKTFBKRU8=" | base64 -d \
    && echo \
    && echo "Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==" | base64 -d

    Die Ausgabe sollte in etwa so aussehen:

    0HX3O0YC2J722EJLPJEO
Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT

  4. Folgen Sie dem Abschnitt s3cmd konfigurieren mit den resultierenden Informationen.

Auf das Secret des Dienstkontos zugreifen

Bei einem Dienstkonto-Subjekt befindet sich das Secret im selben Namespace wie der Bucket. Führen Sie Folgendes aus, um den Namen zu ermitteln:

  kubectl get --namespace NAMESPACE_NAME secrets -o=jsonpath=
  '{.items[?(@.metadata.annotations.object\.gdc\.goog/subject=="SA_NAME")].metadata.name}'

Die Ausgabe sollte in etwa so aussehen:

  object-storage-key-rm-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq

Sie können im Pod als Umgebungsvariablen (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables) oder Dateien (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) auf das Secret verweisen.

Voreingestellte Rollenberechtigungen

Berechtigungen für „Projekt-Bucket-Objekt-Betrachter“

Diese Rolle gewährt Berechtigungen zum Abrufen und Auflisten von Objekten und Objektmetadaten im Bucket.

Die Rolle project-bucket-object-viewer hat die folgenden Berechtigungen:

  • Bucket-API-Berechtigungen:

    1. Get
    2. Liste
    3. Ansehen

  • Berechtigungen für S3-Objektspeicher:

    1. GetObject
    2. GetObjectAcl
    3. GetObjectVersion
    4. ListBucket
    5. ListBucketVersions
    6. ListBucketMultipartUploads
    7. ListMultipartUploadParts

Berechtigungen vom Typ „Projekt-Bucket-Objekt-Administrator“

Diese Rolle gewährt Berechtigungen zum Einfügen und Löschen von Objekten, Objektversionen und Tags im Bucket. Außerdem werden damit alle Berechtigungen in der project-bucket-object-viewer gewährt.

Die Rolle project-bucket-object-admin hat die folgenden Berechtigungen für den Objektspeicher:

  • Berechtigungen für S3-Objektspeicher:

    1. AbortMultipartUpload
    2. DeleteObject
    3. DeleteObjectVersion
    4. PutObject
    5. RestoreObject

Berechtigungen als Projekt-Bucket-Administrator

Mit dieser Rolle werden Berechtigungen zum Erstellen, Aktualisieren oder Löschen von Bucket-Ressourcen im Projekt-Namespace erteilt. Außerdem werden alle Berechtigungen in project-bucket-object-admin gewährt.

Die Rolle project-bucket-object-admin hat die folgenden Berechtigungen:

  • Bucket-API-Berechtigungen:

    1. Erstellen
    2. Aktualisieren
    3. Löschen

WORM-Bucket erstellen

Ein WORM-Bucket sorgt dafür, dass Objekte nicht überschrieben werden und für einen Mindestzeitraum aufbewahrt werden. Die Audit-Protokollierung ist ein Beispiel für einen WORM-Bucket.

So erstellen Sie einen WORM-Bucket:

  1. Legen Sie beim Erstellen des Buckets einen Aufbewahrungszeitraum fest. Der folgende Beispiel-Bucket hat beispielsweise eine Aufbewahrungsdauer von 365 Tagen.

    apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
  name: foo logging-bucket
  namespace: foo-service
spec:
  description: "Audit logs for foo"
  storageClass: standard-rwo
  bucketPolicy :
    lockingPolicy :
      defaultObjectRetentionDays: 365

  2. Weisen Sie allen Nutzern, die Lesezugriff benötigen, die Rolle project-bucket-object-viewer zu:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: foo-service
  name: object-readonly-access
roleRef:
  kind: Role
  name: project-bucket-object-viewer
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  namespace: foo-service
  name: foo-log-processor
- kind: User
  name: bob@example.com
  apiGroup: rbac.authorization.k8s.io

  3. Weisen Sie Nutzern, die Inhalte in den Bucket schreiben müssen, die Rolle project-bucket-object-admin zu:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: foo-service
  name: object-write-access
roleRef:
  kind: Role
  name: project-bucket-object-viewer
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  namespace: foo-service
  name: foo-service-account

Aus Objektspeicher in Dateisystem auf Blockspeicher wiederherstellen

Nichtflüchtiges Volume zuweisen

So stellen Sie Dateien von einem Objektspeicher-Endpunkt wieder her:

  1. Weisen Sie dem Ziel der Wiederherstellung ein nichtflüchtiges Volume (PV) zu. Verwenden Sie einen PersistentVolumeClaim (PVC), um das Volume zuzuweisen, wie im folgenden Beispiel gezeigt:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
  namespace: restore-ns
spec:
  storageClassName: standard-rwo
  accessModes:
ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Need sufficient capacity for full restoration.

  2. Prüfen Sie den Status des PVC:

    kubectl get pvc restore-pvc -n restore-ns

    Sobald sich der PVC im Status Bound befindet, kann er im Pod verwendet werden, in dem er rehydriert wird.

  3. Wenn ein Stateful-Set das PV schließlich verwendet, müssen Sie die gerenderten StatefulSet-PVCs abgleichen. Die von StatefulSet erstellten Pods verwenden die hydrierten Volumes. Das folgende Beispiel zeigt Vorlagen für Volume-Ansprüche in einem StatefulSet namens ss.

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

  4. Weisen Sie PVCs mit Namen wie ss-pvc-name-0 und ss-pvc-name-1 vorab zu, damit die resultierenden Pods die vorab zugewiesenen Volumes verwenden.

Nichtflüchtiges Volume (Persistent Volume, PV) initialisieren

Nachdem der PVC an ein PV gebunden wurde, starten Sie 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: gcr.io/private-cloud-staging/storage-transfer:latest
        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 Job abgeschlossen ist, werden die Daten aus dem Object Storage-Bucket in das Volume übertragen. Ein separater Pod kann die Daten mit denselben Standardmechanismen zum Mounten eines Volumes nutzen.