Deployment in Google Kubernetes Engine

Questa guida descrive come eseguire il pull delle immagini da Artifact Registry per eseguirne il deployment su Google Kubernetes Engine. Se vuoi eseguire il deployment in servizi Kubernetes self-hosted o di terze parti, devi configurare l'autenticazione in Google Cloud prima di eseguire il pull delle immagini da Artifact Registry. Per eseguire l'autenticazione in Google Cloud da carichi di lavoro Kubernetes al di fuori di Google Cloud, consulta Configurare la federazione delle identità per i carichi di lavoro con Kubernetes.

Google Kubernetes Engine può eseguire il pull delle immagini direttamente dai repository Docker. Alcune versioni includono il supporto preconfigurato per il pull delle immagini dai repository Docker di Artifact Registry.

Requisiti

Questa sezione descrive i requisiti per l'integrazione con GKE.

Autorizzazioni

GKE utilizza i seguenti valori predefiniti quando crei pool di nodi o cluster:

• L'account di servizio predefinito di Compute Engine è l'identità per i nodi. Questo account di servizio predefinito ha il ruolo Lettore Artifact Registry (roles/artifactregistry.reader) se hai disabilitato la concessione del ruolo Editor di base.
• I nodi che crei con l'account di servizio predefinito dispongono degli ambiti di accesso predefiniti di Compute Engine, incluso l'accesso di sola lettura all'archiviazione. Non puoi modificare gli ambiti di accesso sui nodi esistenti.

Se utilizzi queste impostazioni predefinite, GKE può eseguire il pull delle immagini dai repository Artifact Registry nello stesso progetto Google Cloud. Se hai bisogno di eseguire il push delle immagini dai nodi, eseguire il pull o il push di immagini tra progetti, utilizzare un account di servizio fornito dall'utente o avere altre esigenze che le impostazioni predefinite non supportano, consulta la documentazione sul controllo dell'accesso per informazioni sulla configurazione dell'accesso.

Se si verificano errori di tipo "Autorizzazione negata", consulta Errore di autorizzazione negata.

Versione GKE

La tabella seguente elenca le versioni GKE minime richieste per creare cluster con autorizzazioni predefinite per eseguire il pull dei container dai repository Docker nello stesso progetto.

Versione	Patch minima richiesta
1,14	1.14.10-gke.22
1,15	1.15.9-gke.8

Se la tua versione di GKE è precedente alla versione minima, devi configurare Kubernetes imagePullSecrets per consentire a GKE di eseguire il pull delle immagini.

Se GKE si trova in un progetto diverso da Artifact Registry, concedi le autorizzazioni di Artifact Registry all'account di servizio utilizzato dal tuo nodo GKE. Per impostazione predefinita, i nodi utilizzano l'account di servizio predefinito di Compute Engine.

Esecuzione di un'immagine

Puoi eseguire un'immagine Artifact Registry su un cluster Google Kubernetes Engine utilizzando il seguente comando:

kubectl run [NAME] --image=LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

dove:

• LOCATION è la località a livello di una o più regioni del repository.
• PROJECT è l'ID progetto della console Google Cloud. Se l'ID progetto contiene i due punti (:), consulta Progetti con ambito dominio.
• REPOSITORY è il nome del repository in cui è archiviata l'immagine.
• IMAGE è il nome dell'immagine nel repository.
• TAG è il tag della versione dell'immagine di cui vuoi eseguire il pull.

Per ulteriori informazioni sui comandi Kubernetes, consulta Panoramica di kubectl.

Risoluzione dei problemi relativi alle immagini dei nodi containerd

A partire dalla versione 1.19 del nodo GKE, l'immagine del nodo predefinita per i nodi Linux è la variante Container-Optimized OS con la variante containerd (cos_containerd) anziché Container-Optimized OS con la variante Docker (cos).

Sebbene il programma binario Docker sia disponibile sui nodi Linux che utilizzano containerd come runtime, ti sconsigliamo di usarlo. Docker non gestisce i container che Kubernetes esegue sui nodi containerd, quindi non puoi utilizzarlo per visualizzare o interagire con i container Kubernetes in esecuzione utilizzando i comandi Docker o l'API Docker.

Per eseguire il debug o la risoluzione dei problemi sui nodi Linux, puoi interagire con i container usando lo strumento a riga di comando portatile creato per i runtime dei container Kubernetes: crictl. crictl supporta funzionalità comuni per visualizzare container e immagini, leggere i log ed eseguire comandi nei container.

Per ulteriori informazioni, consulta la guida dell'utente critico e la documentazione di GKE su containerd.

Per i nodi Windows Server, il daemon containerd viene eseguito come un servizio Windows denominato containerd. I log sono disponibili nella seguente directory dei log: C:\etc\kubernetes\logs\containerd.log e vengono visualizzati in Esplora log in LOG NAME: "container-runtime".

Avviso: Docker non può visualizzare o accedere ai container per i pool di nodi Linux e Windows che utilizzano containerd come runtime.

Pull da un repository pubblico Artifact Registry

Dopo aver eseguito il deployment e l'immagine in un cluster GKE contenente nodi containerd, puoi connetterti a un'istanza VM utilizzando SSH ed eseguire i comandi crictl per la risoluzione dei problemi.

I repository pubblici Artifact Registry non richiedono l'autenticazione. crictl può essere utilizzato anche per eseguire il pull di immagini nei repository Artifact Registry privati.

Console

1. Nella console Google Cloud, vai alla pagina Istanze VM.

   Vai a Istanze VM

2. Nell'elenco delle istanze di macchine virtuali, fai clic sulla freccia accanto a SSH nella riga dell'istanza a cui vuoi connetterti.

   

   Nota: quando ti connetti alle VM utilizzando la console Google Cloud, Compute Engine crea per te una chiave SSH temporanea. Per saperne di più sulle chiavi SSH, consulta Connessioni SSH alle VM Linux
   .

3. Seleziona "Apri in una finestra del browser" o il metodo di connessione che preferisci dalle opzioni del menu a discesa.

4. La console Google Cloud apre una nuova finestra del terminale. Usa crictl per estrarre un'immagine da Artifact Registry:

   crictl pull IMAGE_LOCATION:TAG
   

   L'output è simile al seguente:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   Quando esegui il pull di un'immagine da un repository privato Artifact Registry, devi eseguire l'autenticazione nel repository. Puoi usare un token di accesso per fornire le tue credenziali.

gcloud

1. Assicurati di avere la versione più recente di Google Cloud CLI

   gcloud components update
   

2. Connettiti alla VM:

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto che contiene la VM
   • ZONE: il nome della zona in cui si trova la VM
   • VM_NAME: il nome della VM

   Se hai impostato proprietà predefinite per Google Cloud CLI, puoi omettere i flag --project e --zone da questo comando. Ad esempio:

   gcloud compute ssh VM_NAME
   

3. Se non hai ancora creato una chiave SSH, la generazione della chiave SSH ne genererà una automaticamente. Inserisci una passphrase o lascia il campo vuoto quando richiesto.

4. Usa crictl per eseguire il pull di un'immagine da Artifact Registry:

   crictl pull IMAGE_LOCATION:TAG
   

5. L'output è simile al seguente:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   Quando esegui il pull di un'immagine da un repository privato Artifact Registry, devi eseguire l'autenticazione nel repository. Puoi usare un token di accesso per fornire le tue credenziali.

Pull da un repository Artifact Registry privato

Console

1. Nella console Google Cloud, vai alla pagina Istanze VM.

   Vai a Istanze VM

2. Nell'elenco delle istanze di macchine virtuali, fai clic sulla freccia accanto a SSH nella riga dell'istanza a cui vuoi connetterti.

   

   Nota: quando ti connetti alle VM utilizzando la console Google Cloud, Compute Engine crea per te una chiave SSH temporanea. Per saperne di più sulle chiavi SSH, consulta Connessioni SSH alle VM Linux
   .

3. Seleziona "Apri in una finestra del browser" dalle opzioni del menu a discesa.

4. La console Google Cloud apre una nuova finestra del terminale. Genera un token di accesso all'account di servizio Compute Engine utilizzando curl.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

   L'output è simile all'esempio seguente:

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. Copia il valore di access_token dall'output restituito senza le virgolette.

6. Esegui il pull dell'immagine utilizzando crictl pull --creds e il valore access_token copiato nel passaggio precedente.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

   L'output è simile al seguente:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

gcloud

1. Assicurati di avere la versione più recente di Google Cloud CLI

   gcloud components update
   

2. Connettiti alla VM:

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

   Sostituisci le seguenti variabili:

   • PROJECT_ID: l'ID del progetto che contiene la VM
   • ZONE: il nome della zona in cui si trova la VM
   • VM_NAME: il nome della VM

   Se hai impostato proprietà predefinite per Google Cloud CLI, puoi omettere i flag --project e --zone da questo comando. Ad esempio:

   gcloud compute ssh VM_NAME
   

3. Se non hai ancora creato una chiave SSH, la generazione della chiave SSH ne genererà una automaticamente. Inserisci una passphrase o lascia il campo vuoto quando richiesto.

4. Genera un token di accesso all'account di servizio Compute Engine utilizzando curl.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

   L'output è simile al seguente:

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. Copia il valore di access_token dall'output restituito senza le virgolette.

6. Esegui il pull dell'immagine utilizzando crictl pull --creds e il valore access_token copiato nel passaggio precedente.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

   L'output è simile al seguente:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

crictl consente agli sviluppatori di eseguire il debug del proprio runtime senza dover configurare i componenti di Kubernetes. Per un elenco completo dei comandi, consulta la documentazione di crictl e la documentazione sul debug di Kubernetes.