Storage-Befehlszeile für Projekte installieren und konfigurieren

Auf dieser Seite erfahren Sie, wie Sie die gdcloud CLI für die Verwaltung des Objektspeichers installieren und konfigurieren, wenn Sie mit GDC-Projekten (Google Distributed Cloud) mit Air Gap arbeiten. Es wird beschrieben, wie Sie die erforderlichen Komponenten und Einstellungen herunterladen, installieren und konfigurieren, die für die effektive Verwendung von Storage-Buckets und ‑Objekten in dieser isolierten Umgebung erforderlich sind.

Diese Seite richtet sich an IT-Administratoren in der Gruppe der Infrastrukturbetreiber oder Entwickler in der Gruppe der Anwendungsoperatoren, die Objektspeicher-Buckets für Projekte in GDC-Umgebungen mit Air Gap bereitstellen und verwalten möchten. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweis

Wenn Sie die Storage-CLI installieren und konfigurieren möchten, wenden Sie sich an Ihren IAM-Organisationsadministrator, um die Rolle Org Network Policy Admin (org-network-policy-admin) anzufordern. Mit dieser Rolle können Sie Netzwerkrichtlinien für die Organisation erstellen, bearbeiten und löschen.

gdcloud CLI herunterladen

Folgen Sie der Anleitung zum Herunterladen der gdcloud CLI.

gdcloud CLI installieren

Wenn Sie die Speicherbefehlsstruktur verwenden möchten, muss die Komponente für Speicherabhängigkeiten installiert sein.

  1. Folgen Sie der Anleitung unter gdcloud CLI installieren.

  2. Führen Sie die folgenden Befehle aus, um die Komponente für Speicherabhängigkeiten zu installieren:

    gdcloud components install storage-cli-dependencies

    Weitere Informationen zum Befehl components install finden Sie unter gdcloud CLI installieren.

gdcloud CLI für Objektspeicher konfigurieren

Die folgenden Konfigurationen müssen festgelegt werden, um die gdcloud CLI für den Objektspeicher zu verwenden.

  1. Ersetzen Sie ACCESS_KEY_ID durch die Zugriffsschlüssel-ID, die Sie aus dem Secret unter Zugriffsanmeldedaten abrufen erhalten haben:

    gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID

  2. Ersetzen Sie SECRET_ACCESS_KEY durch den geheimen Schlüssel, den Sie aus dem Secret in Zugriffsanmeldedaten abrufen erhalten haben:

    gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY

  3. Ersetzen Sie CA_BUNDLE_FILE durch den Pfad zum CA-Zertifikat. Dies ist ein digitales Zertifikat, das zu einer Zertifizierungsstelle (Certificate Authority, CA) gehört, einer vertrauenswürdigen Organisation, die für Identitäten bürgt. Sie können das GDC-CA-Trust-Bundle von einem Mitglied Ihrer Infrastrukturoperatorgruppe (IO) anfordern. Weitere Informationen zum Abrufen von GDC-CA-Zertifikaten finden Sie unter GDC-Trust-Bundles abrufen.

    gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE

  4. Ersetzen Sie ENDPOINT durch den Endpunkt, den Ihr Infrastruktur-Operator (IO) bereitstellt:

    gdcloud config set storage/s3_endpoint ENDPOINT

    Dieser Schritt unterscheidet sich bei Dual-Region-Buckets geringfügig. Jeder Dual-Region-Bucket bietet drei Endpunkte, über die Sie auf den Bucket zugreifen können. In den meisten Fällen ist der globale Endpunkt geeignet, um automatische Failover zu nutzen:

    • Zone1-Endpunkt: Dieser Endpunkt wird immer von Zone1 empfangen. Wenn Sie diesen Endpunkt verwenden, haben Sie Read-after-write Consistency für alle Objekte, die in zone1 geschrieben werden. Wenn zone1 jedoch ausfällt, muss ein Client entweder den zone2- oder den globalen Endpunkt verwenden, um weiterhin in diesem Bucket lesen/schreiben zu können. Wenn der Client von einem Nutzercluster stammt, ist dieser Endpunkt nur innerhalb von zone1 zugänglich.
    • Zone2-Endpunkt: Dieser Endpunkt wird immer von Zone2 empfangen. Wenn Sie diesen Endpunkt verwenden, haben Sie Read-after-write Consistency für alle Objekte, die in zone2 geschrieben werden. Wenn jedoch zone2 ausfällt, muss ein Client entweder den zone1- oder den globalen Endpunkt verwenden, um weiterhin in diesem Bucket lesen/schreiben zu können. Wenn der Client von einem Nutzercluster stammt, ist dieser Endpunkt nur innerhalb von zone2 zugänglich.
    • Globaler Endpunkt: Dieser Endpunkt führt dazu, dass Ihre Anfrage entweder an Zone 1 oder Zone 2 weitergeleitet wird. Diese Option bietet keine Sitzungsaffinität. Das bedeutet, dass Anfragen, die mit derselben Sitzung gestellt werden, entweder in Zone 1 oder Zone 2 ankommen können. Das bedeutet, dass es für Anfragen an den globalen Endpunkt keine Read-after-Write-Garantie gibt. Der globale Endpunkt bietet ein automatisches Failover für den Fall, dass eine Zone ausfällt. Nutzer müssen also die Endpunkte in ihren Arbeitslasten nicht ändern, wie es bei der Verwendung des zonalen Endpunkts der Fall wäre. Außerdem ist dieser Endpunkt von Nutzerclustern in allen Zonen aus zugänglich.

    Führen Sie die folgenden Befehle auf dem Management API-Server aus, um die globalen und zonalen Endpunkte für Ihren Bucket aufzurufen und den gewünschten auszuwählen:

    kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.globalEndpoint}" --kubeconfig MANAGEMENT_API_SERVER

kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.zonalEndpoints}" --kubeconfig MANAGEMENT_API_SERVER