Esegui il deployment dei container (GKE, Distributed Cloud)

Questa pagina spiega come eseguire il deployment di un'immagine container in un cluster GKE (su Google Cloud o Google Distributed Cloud) in cui è abilitata 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 l'autorizzazione binaria.

Prima di iniziare

Assicurati di aver attivato l'API Binary Authorization nel tuo progetto e di avere un cluster GKE con l'autorizzazione binaria abilitata. Consulta: su Google Kubernetes Engine oppure configurazione su Distributed Cloud.

Installa kubectl per interagire con GKE.

Configura kubectl

Devi aggiornare il file kubeconfig locale per l'installazione di kubectl. Vengono fornite le credenziali e le informazioni sugli endpoint necessarie per accedere al cluster in GKE o Distributed Cloud.

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

Distributed Cloud 

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:

  1. Configura le variabili di ambiente:

    POD_NAME=POD_NAME
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=IMAGE_DIGEST

    Sostituisci quanto segue:

    • POD_NAME: il nome da utilizzare per Carico di lavoro GKE
    • IMAGE_PATH: percorso dell'immagine in Artifact Registry Container Registry o un altro registro di sistema.

    • 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
        • Digest: sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
      • Container Registry:
        • Percorso: gcr.io/google-samples/hello-app
        • Digest: sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

      Per scoprire come ottenere il digest di un'immagine in Artifact Registry, consulta Gestire le immagini; per un'immagine in Container Registry, consulta Elenco delle versioni di un'immagine.

  2. 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 o latest, poiché Autorizzazione binaria utilizza il digest per cercare le attestazioni.

    Per eseguire il deployment dell'immagine, esegui il seguente 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 riesce a raggiungere il server di Autorizzazione binaria o se il server restituisce un errore, GKE non può determinare se Autorizzazione binaria consentirebbe o meno l'immagine. In questo caso, l'apertura di GKE non riesce: per impostazione predefinita viene eseguito il deployment dell'immagine, ma viene creata una voce di log Cloud Audit Logs per registrare il motivo per cui l'immagine è stata consentita.

L'applicazione delle norme di GKE non va a buon fine a causa di un compromesso tra affidabilità e sicurezza. GKE invia una richiesta Autorizzazione binaria ogni volta che un pod viene creato o aggiornato. Sono inclusi scenari in cui i pod vengono creati o aggiornati automaticamente Controller per i carichi di lavoro Kubernetes, come ReplicaSet e StatefulSet. Se GKE non è stato chiuso invece che aperto, qualsiasi L'interruzione di Autorizzazione binaria arresterà l'esecuzione di questi pod. Inoltre, quando i pod vengono rifiutati, il failover può causare errori a cascata poiché il traffico reindirizzato sovraccarica i pod ancora in esecuzione. Qualsiasi interruzione dell'autorizzazione binaria potrebbe attivare un'interruzione completa del cluster, anche senza eseguire il deployment di nuove immagini.

Implementare immagini che violano le norme

Autorizzazione binaria supporta una funzionalità nota come breakglass che consente di eseguire il deployment di un'immagine anche se viola i criteri.

Per maggiori informazioni, consulta Utilizzo del deployment di emergenza

Esegui la pulizia

Per eseguire la pulizia, elimina il pod eseguendo il seguente comando:

  kubectl delete pod ${POD_NAME}

Passaggi successivi