Installa e configura la CLI di archiviazione per i progetti

Questa pagina spiega come installare e configurare la CLI gdcloud per la gestione dell'archiviazione di oggetti quando si lavora con progetti Google Distributed Cloud (GDC) con air gap. Vengono trattati il download, l'installazione e la configurazione dei componenti e delle impostazioni necessari per utilizzare in modo efficace i bucket e gli oggetti di archiviazione in questo ambiente isolato.

Questa pagina è rivolta a segmenti di pubblico come gli amministratori IT del gruppo di operatori dell'infrastruttura o gli sviluppatori del gruppo di operatori delle applicazioni che vogliono eseguire il provisioning e gestire i bucket di archiviazione di oggetti per i progetti negli ambienti GDC con air gap. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC con air gap.

Prima di iniziare

Per installare e configurare l'interfaccia a riga di comando di archiviazione, contatta l'amministratore dell'organizzazione IAM per richiedere il ruolo Amministratore delle policy di rete dell'organizzazione (org-network-policy-admin), che ti consente di creare, modificare ed eliminare le policy di rete dell'organizzazione.

Scarica l'interfaccia a riga di comando gdcloud

Segui le istruzioni per scaricare la CLI gdcloud.

Installa la CLI gdcloud

Per utilizzare l'albero dei comandi di archiviazione, è necessario installare il componente delle dipendenze di archiviazione.

  1. Segui le istruzioni riportate in Installa la CLI gdcloud.

  2. Per installare il componente delle dipendenze di archiviazione, esegui questi comandi:

    gdcloud components install storage-cli-dependencies

    Per saperne di più sul comando components install, consulta Installa la CLI gdcloud.

Configura la CLI gdcloud per l'archiviazione di oggetti

Per utilizzare la CLI gdcloud per l'archiviazione di oggetti, è necessario impostare le seguenti configurazioni.

  1. Sostituisci ACCESS_KEY_ID con l'ID chiave di accesso ottenuto dal secret in Ottenere le credenziali di accesso:

    gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID

  2. Sostituisci SECRET_ACCESS_KEY con la chiave segreta ottenuta dal secret in Ottenere le credenziali di accesso:

    gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY

  3. Sostituisci CA_BUNDLE_FILE con il percorso del certificato CA. Si tratta di un certificato digitale che appartiene a un'autorità di certificazione (CA), un'organizzazione attendibile che garantisce le identità. Puoi richiedere il bundle di attendibilità della CA GDC a un membro del tuo gruppo di operatori dell'infrastruttura (IO). Per saperne di più su come ottenere i certificati CA di GDC, consulta Recupera i bundle di attendibilità GDC.

    gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE

  4. Sostituisci ENDPOINT con l'endpoint fornito dall'operatore dell'infrastruttura (IO):

    gdcloud config set storage/s3_endpoint ENDPOINT

    Questo passaggio è leggermente diverso per i bucket con doppia regione. Ogni bucket a doppia regione fornisce tre endpoint che puoi scegliere per accedere al bucket. Nella maggior parte dei casi, l'endpoint globale è appropriato per sfruttare i failover automatici:

    • Endpoint Zone1: questo endpoint viene sempre ricevuto da zone1. Se utilizzi questo endpoint, hai la coerenza read-after-write per tutti gli oggetti scritti in zone1. Tuttavia, se zone1 non è disponibile, un client deve passare all'utilizzo dell'endpoint zone2 o globale per continuare a leggere/scrivere in questo bucket. Se il client proviene da un cluster utente, questo endpoint sarà accessibile solo dall'interno di zone1.
    • Endpoint Zone2: questo endpoint viene sempre ricevuto da zone2. Se utilizzi questo endpoint, hai la coerenza read-after-write per tutti gli oggetti scritti in zone2. Tuttavia, se zone2 non è disponibile, un client deve passare all'utilizzo dell'endpoint zone1 o globale per continuare a leggere/scrivere in questo bucket. Se il client proviene da un cluster utente, questo endpoint sarà accessibile solo dall'interno di zone2.
    • Endpoint globale: questo endpoint comporta il routing della richiesta alla zona 1 o alla zona 2. Questa opzione non fornisce l'affinità sessione, il che significa che le richieste effettuate utilizzando la stessa sessione possono arrivare nella zona 1 o nella zona 2. Ciò significa che non esiste alcuna garanzia di lettura dopo la scrittura per le richieste effettuate all'endpoint globale. L'endpoint globale fornisce il failover automatico nel caso in cui una zona non sia disponibile, in modo che gli utenti non debbano modificare gli endpoint nei loro workload come dovrebbero fare se utilizzassero l'endpoint di zona. Inoltre, questo endpoint è accessibile dai cluster utente in tutte le zone.

    Esegui i seguenti comandi sul server API di gestione per visualizzare gli endpoint globali e di zona per il tuo bucket e scegli quello che vuoi utilizzare:

    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