Storage CLI 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 Zielgruppen für die Dokumentation zu 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 Organization 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

Laden Sie ein gdcloud CLI-Bundle-Archiv herunter und extrahieren Sie es. Folgen Sie dazu der Anleitung unter gdcloud CLI herunterladen. Verwenden Sie keine eigenständige gdcloud CLI-Binärdatei, die das Verzeichnis bin/component_bundles/ nicht enthält.

gdcloud CLI installieren

Wenn Sie die Befehlsgruppe gdcloud storage verwenden möchten, installieren Sie die Komponente storage-cli-dependencies aus einem extrahierten gdcloud CLI-Bundle:

  1. Folgen Sie der Anleitung unter gdcloud CLI installieren, um das Verzeichnis bin des extrahierten Bundles zu Ihrem PATH hinzuzufügen.

  2. Führen Sie den folgenden Befehl aus, um die Komponente storage-cli-dependencies zu installieren:

    gdcloud components install storage-cli-dependencies

    Mit diesem Befehl wird storage-cli-dependencies aus dem Verzeichnis bin/component_bundles/ in Ihrem extrahierten gdcloud CLI-Bundle installiert. Wenn Sie diesen Befehl über eine eigenständige gdcloud CLI-Binärdatei ausführen, die nicht über bin/component_bundles/ verfügt, schlägt der Befehl mit dem Fehler component_registry.yaml: no such file or directory fehl. Laden Sie zur Behebung dieses Fehlers ein Bundle unter gdcloud CLI herunterladen herunter, extrahieren Sie es und führen Sie bin/gdcloud im extrahierten Bundle-Verzeichnis aus.

    Weitere Informationen zum Befehl components install finden Sie unter Komponenten 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 Zone 1 jedoch ausfällt, muss ein Client entweder den Endpunkt von Zone 2 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 Zone 1 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 Zone 2 jedoch ausfällt, muss ein Client entweder den Endpunkt von Zone 1 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, falls eine Zone ausfällt. Nutzer müssen die Endpunkte in ihren Arbeitslasten also 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