Questa pagina spiega come eseguire il deployment di un'immagine container in un cluster Google Kubernetes Engine (GKE) o in un cluster GKE in cui è abilitata l'Autorizzazione binaria. I comandi kubectl
che utilizzi per eseguire il deployment dell'immagine sono gli stessi che utilizzi per eseguire il deployment delle immagini in cluster che non utilizzano Autorizzazione binaria.
Prima di iniziare
Assicurati che l'API Binary Authorization sia abilitata nel tuo progetto e di un cluster GKE con Autorizzazione binaria abilitata. Consulta la sezione Configurazione su Google Kubernetes Engine o Configurazione su cluster GKE.
Installa kubectl
per interagire con GKE.
Configura kubectl
Devi aggiornare il file kubeconfig
locale per l'installazione di kubectl
.
Fornisce le credenziali e le informazioni dell'endpoint necessarie per accedere al cluster nei cluster GKE o GKE.
Per configurare kubectl
, esegui questo comando gcloud
:
GKE
gcloud container clusters get-credentials \ --zone ZONE \ CLUSTER_NAME
Sostituisci quanto segue:
- ZONE: il nome della zona GKE in cui
è in esecuzione il cluster, ad esempio
us-central1-a
- CLUSTER_NAME: il nome del cluster
Cluster GKE
gcloud container fleet memberships get-credentials \ --location LOCATION \ MEMBERSHIP_NAME
Sostituisci quanto segue:
- LOCATION: la località dell'appartenenza al parco risorse del cluster GKE, ad esempio
global
- MEMBERSHIP_NAME: il nome dell'appartenenza al parco risorse del cluster GKE
Esegui il deployment dell'immagine container
Esegui il deployment dell'immagine container nel seguente modo:
Configura le variabili di ambiente:
POD_NAME=POD_NAME IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=IMAGE_DIGEST
Sostituisci quanto segue:
- POD_NAME: il nome che vuoi utilizzare per il carico di lavoro GKE
- IMAGE_PATH: percorso dell'immagine in Artifact Registry, Container Registry o in un altro registro.
IMAGE_DIGEST: il digest del file manifest dell'immagine. Ecco alcuni esempi:
- Artifact Registry:
- Percorso:
us-docker.pkg.dev/google-samples/containers/gke/hello-app
- Sintesi:
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
- Percorso:
- Container Registry:
- Percorso:
gcr.io/google-samples/hello-app
- Sintesi:
sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
- Percorso:
Per scoprire come ottenere il digest di un'immagine in Artifact Registry, consulta Gestione delle immagini; per un'immagine in Container Registry, consulta Elenco delle versioni di un'immagine.
- Artifact Registry:
Esegui il deployment dell'immagine utilizzando il comando
kubectl run
.Devi eseguire il deployment dell'immagine utilizzando il digest anziché un tag come
1.0
olatest
, poiché Autorizzazione binaria utilizza il digest per cercare le attestations.Per eseguire il deployment dell'immagine, esegui questo comando
kubectl
:kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}
Ora verifica che il deployment sia stato bloccato da Autorizzazione binaria:
kubectl get pods
Vedrai il tuo pod nell'elenco.
Fail open
Se per qualsiasi motivo GKE non è in grado di raggiungere il server di Autorizzazione binaria o se il server restituisce un errore, GKE non può determinare se Autorizzazione binaria consentire o nega l'immagine. In questo caso, l'apertura di GKE non riesce: per impostazione predefinita viene eseguito il deployment dell'immagine, ma in Cloud Audit Logs viene creata una voce di log per registrare il motivo per cui l'immagine è stata consentita.
L'applicazione forzata di GKE si apre a causa di un compromesso tra affidabilità e sicurezza. GKE invia una richiesta ad Autorizzazione binaria ogni volta che un pod viene creato o aggiornato. Ciò include scenari in cui i pod vengono creati o aggiornati automaticamente dai controller dei carichi di lavoro Kubernetes di livello superiore, come ReplicaSet e StatefulSet. Se GKE non è stato chiuso invece che aperto, qualsiasi interruzione di Autorizzazione binaria interromperà l'esecuzione di questi pod. Inoltre, quando i pod vengono negati, il failover può causare errori a cascata in quanto il traffico reindirizzato sovraccarica i pod ancora in esecuzione. Qualsiasi interruzione di Autorizzazione binaria potrebbe attivare un'interruzione completa del cluster, anche senza eseguire il deployment di nuove immagini.
Esegui il deployment di immagini che violano le norme
Autorizzazione binaria supporta una funzionalità nota come deployment di emergenza che consente il deployment di un'immagine, anche se viola il criterio.
Per maggiori informazioni, consulta Utilizzo del deployment di emergenza
Esegui la pulizia
Per eseguire la pulizia, elimina il pod eseguendo questo comando:
kubectl delete pod ${POD_NAME}
Passaggi successivi
- Scopri di più sulla modalità dry run.
- Scopri come utilizzare il CV.
- Scopri come utilizzare la convalida continua legacy (ritirata).
- Scopri come utilizzare le sintesi delle immagini nei manifest di Kubernetes.