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 lavori 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

Scarica ed estrai un archivio del bundle della CLI gdcloud seguendo le istruzioni riportate in Scarica la CLI gdcloud. Non utilizzare un file binario autonomo della CLI gdcloud che non includa la directory bin/component_bundles/.

Installa la CLI gdcloud

Per utilizzare il gruppo di comandi gdcloud storage, installa il componente storage-cli-dependencies da un bundle CLI gdcloud estratto:

  1. Segui le istruzioni riportate in Installa la CLI gdcloud per aggiungere la directory bin del bundle estratto alla directory PATH.

  2. Per installare il componente storage-cli-dependencies, esegui questo comando:

    gdcloud components install storage-cli-dependencies

    Questo comando installa storage-cli-dependencies dalla directory bin/component_bundles/ nel bundle dell'interfaccia a riga di comando gdcloud estratto. Se esegui questo comando da un file binario autonomo della CLI gdcloud privo di bin/component_bundles/, il comando non va a buon fine e viene visualizzato un errore component_registry.yaml: no such file or directory. Per risolvere questo errore, scarica ed estrai un bundle da Scarica l'interfaccia a riga di comando gdcloud ed esegui bin/gdcloud dalla directory del bundle estratto.

    Per ulteriori informazioni sul comando components install, consulta Installa i componenti.

Configura la CLI gdcloud per l'archiviazione di oggetti

Per utilizzare l'interfaccia a riga di comando 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 di infrastruttura (IO):

    gdcloud config set storage/s3_endpoint ENDPOINT

    Questo passaggio è leggermente diverso per i bucket a due regioni. 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 dalla zona 2. 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 della zona 2.
    • Endpoint globale: questo endpoint fa sì che la richiesta venga indirizzata alla zona1 o alla zona2. 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