Esegui la migrazione dell'applicazione x86 su GKE a multi-arch con ARM

Standard

---

Nota: questo tutorial fornisce istruzioni per lavorare con questa app: Docker. Le istruzioni potrebbero non rappresentare versioni più recenti dell'app. Per saperne di più, consulta la documentazione: Docker.

Questo tutorial descrive come eseguire la migrazione di un'applicazione creata per i nodi utilizzando processore x86 (Intel o AMD) in un cluster Google Kubernetes Engine (GKE) a un un'applicazione multiarchitettura (multi-arch) eseguita su nodi x86 o Arm. Il pubblico di destinazione di questo tutorial è costituito da amministratori di piattaforma, operatori di app e Sviluppatori di app che vogliono eseguire su ARM carichi di lavoro esistenti compatibili con x86.

Con i cluster GKE, puoi eseguire carichi di lavoro sui nodi ARM utilizzando Serie di macchine Tau T2A ARM. I nodi T2A possono essere eseguiti nel cluster GKE come qualsiasi altro nodo utilizzando processori x86 (Intel o AMD). Sono una buona scelta per lo scale out e lo scale out, ad alta intensità di calcolo.

Per scoprire di più, consulta Arma di carichi di lavoro su GKE.

Questo tutorial presuppone che tu abbia familiarità con Kubernetes e Docker. La usa Google Kubernetes Engine e Artifact Registry.

Obiettivi

In questo tutorial completerai le seguenti attività:

• Archiviare immagini container con Docker in Artifact Registry.
• Esegui il deployment di un carico di lavoro compatibile con x86 in un cluster GKE.
• Ricrea un carico di lavoro compatibile con x86 da eseguire su ARM.
• Aggiungi un pool di nodi Arm a un cluster esistente.
• Esegui il deployment di un carico di lavoro compatibile con Arm da eseguire su un nodo Arm.
• Crea un'immagine multi-arch per eseguire un carico di lavoro su più architetture.
• Esegui carichi di lavoro su più architetture in un unico cluster GKE.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• GKE
• Artifact Registry

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

Per abilitare l'API Kubernetes Engine, segui questi passaggi:

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

4. Abilita le API Artifact Registry and Google Kubernetes Engine.

   Abilita le API

5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

6. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

7. Abilita le API Artifact Registry and Google Kubernetes Engine.

   Abilita le API

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando il le risorse che hai creato. Consulta Pulizia per ulteriori dettagli.

Avvia Cloud Shell

In questo tutorial utilizzerai Cloud Shell, che è un ambiente shell per la gestione delle risorse in hosting in Google Cloud.

Cloud Shell è preinstallato Google Cloud CLI e kubectl a strumento a riga di comando. gcloud CLI fornisce la riga di comando per Google Cloud e kubectl fornisce la riga di comando per eseguire comandi sui cluster Kubernetes.

Avvia Cloud Shell:

1. Vai alla console Google Cloud.

   Console Google Cloud

2. Nell'angolo in alto a destra della console, fai clic sul pulsante Attiva Cloud Shell:

Nella console viene visualizzata una sessione di Cloud Shell. Utilizzerai questa shell per eseguire i comandi gcloud e kubectl.

prepara l'ambiente

In questa sezione, preparerai il tuo ambiente per seguire il tutorial.

Configura le impostazioni predefinite per gcloud CLI

Imposta le variabili di ambiente per l'ID progetto, la zona e il nome nel nuovo cluster.

Attenzione: le seguenti variabili di ambiente vengono utilizzate in tutti i comandi di questo tutorial. Se chiudi Cloud Shell, potresti dover impostare di nuovo le variabili di ambiente.

export PROJECT_ID=PROJECT_ID
export ZONE=us-central1-a
export CLUSTER_NAME=my-cluster

Sostituisci PROJECT_ID con l'ID progetto che hai scelto questo tutorial nella sezione Prima di iniziare.

In questo tutorial creerai risorse in us-central1-a. Per visualizzare un elenco completo per sapere dove è disponibile la serie di macchine Tau T2A, consulta Regioni e zone disponibili.

clona il repository Git

1. Clona il repository:

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   

2. Cambia la tua directory di lavoro attuale con il repository clonato passaggio precedente:

   cd kubernetes-engine-samples/workloads/migrate-x86-app-to-multi-arch/
   

Crea un cluster GKE ed esegui il deployment dell'applicazione x86

Nella prima parte di questo tutorial, creerai un cluster con nodi x86 il deployment di un'applicazione x86. L'applicazione di esempio è un servizio che risponde alle richieste HTTP. È realizzato con il linguaggio di programmazione Golang.

Questa configurazione rappresenta l'aspetto di un tipico ambiente cluster, utilizzando compatibili con x86 e nodi x86.

Crea un cluster GKE

Per prima cosa, crea un GKE utilizzando nodi con processori x86. Con questo viene creato un tipico ambiente cluster per l'esecuzione di applicazioni x86.

Crea il cluster:

gcloud container clusters create $CLUSTER_NAME \
    --release-channel=rapid \
    --zone=$ZONE \
    --machine-type=e2-standard-2 \
    --num-nodes=1 \
    --async

La scalabilità automatica è disabilitata in questo cluster per dimostrare la funzionalità nei passaggi successivi.

Il processo di creazione del cluster potrebbe richiedere alcuni minuti. --async consente di eseguire l'operazione in background mentre passaggi.

Puoi creare cluster con solo nodi Arm, Tuttavia, per questo tutorial creerai prima un cluster con solo nodi x86 scopri il processo per rendere compatibili con ARM le applicazioni solo x86.

Crea il repository Docker di Artifact Registry

1. Crea un repository in Artifact Registry per archiviare le immagini Docker:

   gcloud artifacts repositories create docker-repo \
         --repository-format=docker \
         --location=us-central1 \
         --description="Docker repository"
   

2. Configura lo strumento a riga di comando Docker per eseguire l'autenticazione in questo repository in Artifact Registry:

   gcloud auth configure-docker us-central1-docker.pkg.dev
   

Crea l'immagine x86 ed eseguine il push in Artifact Registry

1. Crea la versione dell'applicazione compatibile con x86:

   docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/x86-hello:v0.0.1 . 
   

2. Esegui il push dell'immagine in Artifact Registry:

   docker push us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/x86-hello:v0.0.1
   

esegui il deployment dell'applicazione x86

1. Verifica che il cluster sia pronto eseguendo questo script:

   echo
   echo -ne "Waiting for GKE cluster to finish provisioning"
   gke_status=""
   while [ -z $gke_status ]; do
      sleep 2
      echo -ne '.'   
      gke_status=$(gcloud container clusters list --format="value(STATUS)" --filter="NAME=$CLUSTER_NAME AND STATUS=RUNNING")
   done
   echo
   echo "GKE Cluster '$CLUSTER_NAME' is $gke_status" 
   echo
   

   Quando il cluster è pronto, l'output dovrebbe essere simile al seguente:

   GKE Cluster 'my-cluster' is RUNNING
   

2. Recupera le credenziali del cluster in modo che kubectl possa connettersi API Kubernetes per il cluster:

   gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE --project $PROJECT_ID
   

3. Aggiorna l'immagine utilizzando kustomize ed esegui il deployment dell'applicazione x86:

   $(cd k8s/overlays/x86 && kustomize edit set image hello=us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/x86-hello:v0.0.1) 
   kubectl apply -k k8s/overlays/x86
   

4. Esegui il deployment di un servizio per esporre l'applicazione su internet:

   kubectl apply -f k8s/hello-service.yaml
   

5. Verifica che l'indirizzo IP esterno del servizio hello-service sia completato del provisioning:

   echo
   echo -ne "Waiting for External IP to be provisioned"
   external_ip=""
   while [ -z $external_ip ]; do
      sleep 2
      echo -ne '.'
      external_ip=$(kubectl get svc hello-service --template="{{range .status.loadBalancer.ingress}}{{.ip}}{{end}}")
   done
   echo
   echo "External IP: $external_ip"
   echo
   

   Una volta eseguito il provisioning dell'indirizzo IP esterno, l'output dovrebbe essere simile al seguente:

   External IP: 203.0.113.0
   

6. Effettua una richiesta HTTP per verificare che il deployment funzioni come previsto:

   curl -w '\n' http://$external_ip
   

   L'output è simile al seguente:

   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-mwfkd, CPU PLATFORM:linux/amd64
   

   L'output mostra che questo deployment compatibile con x86 è in esecuzione su un nodo in pool di nodi predefinito nell'architettura amd64. I nodi nel nodo predefinito del tuo cluster hanno processori x86 (Intel o AMD).

Aggiungi nodi Arm al cluster

Nella parte successiva di questo tutorial, aggiungi nodi Arm al cluster esistente. Questi i nodi sono i punti in cui viene eseguito il deployment della versione compatibile con Arm dell'applicazione viene ricostruita per funzionare su ARM.

Check Point

Finora hai raggiunto i seguenti obiettivi:

• un cluster GKE utilizzando i nodi x86.
• archiviare un'immagine container compatibile con x86 con Docker in Artifact Registry.
• il deployment di un carico di lavoro compatibile con x86 in un cluster GKE.

Hai configurato un ambiente cluster con nodi x86 e un server carico di lavoro. Questa configurazione è simile agli ambienti cluster esistenti se al momento non utilizzi nodi e carichi di lavoro compatibili con Arm.

Aggiungi un pool di nodi Arm al tuo cluster

Aggiungi un pool di nodi Arm al cluster esistente:

gcloud container node-pools create arm-pool \
    --cluster $CLUSTER_NAME \
    --zone $ZONE \
    --machine-type=t2a-standard-2 \
    --num-nodes=1

Il tipo di macchina t2a-standard-2 è una VM ARM della serie di macchine Tau T2A (anteprima).

Crei un pool di nodi con nodi Arm come faresti per creare un pool di nodi con nodi x86. Dopo aver creato questo pool di nodi, avrete entrambi i nodi x86 e i nodi ARM in esecuzione in questo cluster.

Per saperne di più sull'aggiunta di pool di nodi Arm ai cluster esistenti, consulta Aggiungere un pool di nodi Arm a un cluster GKE.

Fai lo scale up dell'applicazione esistente in esecuzione su nodi basati su x86

I nodi di diversi tipi di architettura possono funzionare perfettamente insieme in uno in un cluster Kubernetes. GKE non pianifica i carichi di lavoro esistenti in esecuzione su x86 ai nodi Arm nel cluster perché un'incompatibilità viene posizionata automaticamente su ARM nodi. Puoi verificarlo facendo lo scale up dell'applicazione esistente.

1. Aggiorna il carico di lavoro, scalandolo fino a 6 repliche:

   $(cd k8s/overlays/x86_increase_replicas && kustomize edit set image hello=us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/x86-hello:v0.0.1) 
   kubectl apply -k k8s/overlays/x86_increase_replicas/
   

2. Attendi 30 secondi, quindi esegui questo comando per verificare lo stato della richiesta deployment:

   kubectl get pods -l="app=hello" --field-selector="status.phase=Pending"
   

   L'output dovrebbe essere simile al seguente:

   NAME                                    READY   STATUS    RESTARTS   AGE
   x86-hello-deployment-6b7b456dd5-6tkxd   0/1     Pending   0          40s
   x86-hello-deployment-6b7b456dd5-k95b7   0/1     Pending   0          40s
   x86-hello-deployment-6b7b456dd5-kc876   0/1     Pending   0          40s
   

   Questo output mostra i pod con stato In attesa perché non c'è più spazio nella basati su x86. Poiché il gestore della scalabilità automatica del cluster è disabilitato e i nodi ARM incompatibile, il deployment dei carichi di lavoro non verrà eseguito su nessuno degli ARM disponibili nodi. Questa incompatibilità impedisce a GKE di pianificare carichi di lavoro x86 sui nodi ARM. Per eseguire il deployment sui nodi ARM, devi indicare che il deployment è compatibile con i nodi ARM.

3. Controlla i pod in stato In esecuzione:

   kubectl get pods -l="app=hello" --field-selector="status.phase=Running" -o wide
   

   L'output dovrebbe essere simile al seguente:

   NAME                                    READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
   x86-hello-deployment-6b7b456dd5-cjclz   1/1     Running   0          62s   10.100.0.17   gke-my-cluster-default-pool-32019863-b41t   <none>           <none>
   x86-hello-deployment-6b7b456dd5-mwfkd   1/1     Running   0          34m   10.100.0.11   gke-my-cluster-default-pool-32019863-b41t   <none>           <none>
   x86-hello-deployment-6b7b456dd5-n56rg   1/1     Running   0          62s   10.100.0.16   gke-my-cluster-default-pool-32019863-b41t   <none>           <none>
   

   In questo output, la colonna NODE indica che tutti i pod vengono eseguiti solo nel pool default-pool, pertanto I pod compatibili con x86 sono pianificati solo per i nodi x86. Il pod originale già pianificato prima che la creazione del pool di nodi ARM sia ancora in esecuzione sullo stesso nodo.

4. Esegui questo comando per accedere al servizio e visualizzare l'output:

   for i in $(seq 1 6); do curl -w '\n' http://$external_ip; done
   

   L'output è simile al seguente:

   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-cjclz, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-cjclz, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-n56rg, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-n56rg, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-cjclz, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-cjclz, CPU PLATFORM:linux/amd64
   

   Questo output mostra che tutte le richieste di gestione dei pod sono in esecuzione su nodi x86. Alcuni pod non possono rispondere perché sono ancora nello stato In attesa perché non c'è spazio sui nodi x86 esistenti e questi non saranno pianificati per essere abilitati nodi.

Ricrea l'applicazione per eseguirla su ARM

Nella sezione precedente, hai aggiunto un pool di nodi Arm al cluster esistente. Tuttavia, quando hai fatto lo scale up dell'applicazione x86 esistente, l'applicazione non è stata pianificata tra i carichi di lavoro e i nodi ARM. In questa sezione, creerai nuovamente la tua applicazione per essere compatibile con Arm, in modo che questa applicazione possa essere eseguita sui nodi ARM in un cluster Kubernetes.

Per questo esempio, esegui questi passaggi utilizzando docker build. Questo approccio in due fasi include:

• Prima fase: crea il codice per ARM.
• Seconda fase: copia l'eseguibile in un container lean.

Dopo aver seguito questi passaggi, avrai anche un'immagine compatibile con Arm all'immagine compatibile con x86.

Il secondo passaggio per la copia dell'eseguibile in un altro container segue uno dei best practice per la creazione di un container, ovvero la creazione dell'immagine più piccola possibile.

Questo tutorial utilizza un'applicazione di esempio creata con la programmazione Golang lingua. Con Golang, puoi eseguire la compilazione incrociata di un'applicazione sistemi operativi e piattaforme CPU fornendo variabili di ambiente, GOOS e rispettivamente GOARCH.

1. Esegui cat Dockerfile_arm per vedere il Dockerfile scritto per Arm:

   #
   # Build: 1st stage
   #
   FROM golang:1.18-alpine as builder 
   WORKDIR /app
   COPY go.mod .
   COPY hello.go .
   RUN GOARCH=arm64 go build -o /hello && \
      apk add --update --no-cache file && \
      file /hello
   

   Lo snippet mostrato qui mostra solo la prima fase. Entrambe le fasi del file sono inclusi.

   In questo file, l'impostazione di GOARCH=arm64 indica al compilatore Go di creare per il set di istruzioni ARM. Non è necessario impostare GOOS perché l'immagine di base nella prima fase è un'immagine alpina di Linux.

2. Crea il codice per Arm ed esegui il push su Artifact Registry:

   docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/arm-hello:v0.0.1 -f Dockerfile_arm .
   docker push us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/arm-hello:v0.0.1
   

Esegui il deployment della versione ARM dell'applicazione

Ora che l'applicazione è stata creata per essere eseguita su nodi Arm, puoi eseguirne il deployment Arma i nodi nel tuo cluster.

1. Controlla add_arm_support.yaml eseguendo cat k8s/overlays/arm/add_arm_support.yaml:

   L'output è simile al seguente:

      nodeSelector:
         kubernetes.io/arch: arm64
   

   Questo nodeSelector specifica che il carico di lavoro deve essere eseguito solo su ARM nodi. Quando utilizzi nodeSelector, GKE aggiunge una tolleranza che corrisponde all'incompatibilità sui nodi ARM, consentendo a GKE di pianificare carico di lavoro sui nodi. Per scoprire di più sull'impostazione di questo campo, consulta Preparare un carico di lavoro ARM per il deployment.

2. Esegui il deployment di una replica della versione dell'applicazione compatibile con Arm:

   $(cd k8s/overlays/arm && kustomize edit set image hello=us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/arm-hello:v0.0.1) 
   kubectl apply -k k8s/overlays/arm
   

3. Attendi 5 secondi, quindi verifica che il deployment ARM risponda alle richieste di curl:

   for i in $(seq 1 6); do curl -w '\n' http://$external_ip; done
   

   L'output è simile al seguente:

   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-n56rg, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-n56rg, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-mwfkd, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-mwfkd, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:arm-hello-deployment-69b4b6bdcc-n5l28, CPU PLATFORM:linux/arm64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:x86-hello-deployment-6b7b456dd5-n56rg, CPU PLATFORM:linux/amd64
   

   Questo output deve includere le risposte sia della macchina virtuale compatibili con ARM e rispondono alla richiesta curl.

Crea un'immagine con più architetture per eseguire un carico di lavoro su più architetture

Puoi usare la strategia descritta nella sezione precedente ed eseguire il deployment carichi di lavoro separati per x86 e Arm. È necessario mantenere e due processi di build e due immagini container.

Idealmente, vuoi creare ed eseguire l'applicazione senza problemi sia su x86 e ARM. Consigliamo questo approccio. Per eseguire l'applicazione con uno manifest su più piattaforme di architettura, devi usare (multi-architettura). Per saperne di più sull'architettura multi-architettura immagini, consulta Crea immagini multi-arch per i carichi di lavoro ARM.

Per usare immagini con più architetture, devi assicurarti che l'applicazione soddisfi i requisiti i seguenti prerequisiti:

• L'applicazione non ha dipendenze specifiche della piattaforma dell'architettura.
• Tutte le dipendenze devono essere create per: multi-architettura o, come minimo, le piattaforme prese di mira.

L'applicazione di esempio utilizzata in questo tutorial soddisfa entrambi questi prerequisiti. Tuttavia, ti consigliamo di testare le tue applicazioni quando crei di immagini multi-arch prima di eseguirne il deployment in produzione.

Crea ed esegui il push di immagini con più architetture

Puoi creare immagini multi-arch con Docker Buildx se il carico di lavoro soddisfa i seguenti prerequisiti:

• L'immagine di base supporta più architetture. Per verificarlo, esegui docker manifest inspect sull'immagine di base e controllando l'elenco delle piattaforme di architettura. Consulta un esempio di come ispezionare un'immagine alla fine di questa sezione.
• L'applicazione non richiede passi di build speciali per ogni architettura completamente gestita. Se fossero necessari passaggi speciali, Buildx potrebbe non essere sufficiente. Tu avere un Dockerfile separato per ogni piattaforma e creare manualmente con docker manifest create.

L'immagine di base dell'applicazione di esempio è Alps, che supporta più diverse architetture. Inoltre, non sono previsti passaggi specifici per ogni piattaforma, puoi creare l'immagine multi-arch con Buildx.

1. Controlla il Dockerfile eseguendo cat Dockerfile:

   # This is a multi-stage Dockerfile. 
   # 1st stage builds the app in the target platform
   # 2nd stage create a lean image coping the binary from the 1st stage
   
   #
   # Build: 1st stage
   #
   FROM golang:1.18-alpine as builder 
   ARG BUILDPLATFORM    
   ARG TARGETPLATFORM
   RUN echo "I am running on $BUILDPLATFORM, building for $TARGETPLATFORM"  
   WORKDIR /app
   COPY go.mod .
   COPY hello.go .
   RUN go build -o /hello && \
      apk add --update --no-cache file && \
      file /hello   
   
   #
   # Release: 2nd stage
   #
   FROM alpine
   WORKDIR /
   COPY --from=builder /hello /hello
   CMD [ "/hello" ]
   

   Questo Dockerfile definisce due fasi: la fase di build e quella di rilascio. Tu usa lo stesso Dockerfile usato per creare l'applicazione x86.

2. Esegui questo comando per creare e utilizzare un nuovo builder docker buildx:

   docker buildx create --name multiarch --use --bootstrap
   

   Ora che hai creato il nuovo builder, puoi creare un'immagine ed eseguirne il push che sia compatibile con linux/amd64 e linux/arm64 utilizzando il Flag --platform. Per ogni piattaforma fornita con il flag, Buildx crea un nella piattaforma di destinazione. Quando Buildx crea l'immagine linux/arm64, scarica arm64 immagini di base. Nella prima fase, crea il file binario l'immagine arm64 golang:1.18-alpine di arm64. Nella seconda fase, arm64 L'immagine di Alpine Linux viene scaricata e il file binario viene copiato in un livello dell'immagine.

3. Crea ed esegui il push dell'immagine:

   docker buildx build -t us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/multiarch-hello:v0.0.1 -f Dockerfile --platform linux/amd64,linux/arm64 --push .
   

   L'output è simile al seguente:

   => [linux/arm64 builder x/x] ..
   => [linux/amd64 builder x/x] ..
   

   Questo output mostra che vengono generate due immagini, una per linux/arm64 e una per linux/amd64.

4. Controlla il manifest della tua nuova immagine multi-arch:

   docker manifest inspect us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/multiarch-hello:v0.0.1
   

   L'output è simile al seguente:

   {
      "schemaVersion": 2,
      "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
      "manifests": [
         {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "size": 739,
            "digest": "sha256:dfcf8febd94d61809bca8313850a5af9113ad7d4741edec1362099c9b7d423fc",
            "platform": {
               "architecture": "amd64",
               "os": "linux"
            }
         },
         {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "size": 739,
            "digest": "sha256:90b637d85a93c3dc03fc7a97d1fd640013c3f98c7c362d1156560bbd01f6a419",
            "platform": {
               "architecture": "arm64",
               "os": "linux"
            }
         }
      ]
   

   In questo output, la sezione manifests include due manifest, uno con amd64 e l'altra con la piattaforma arm64 dell'architettura.

   Quando esegui il deployment di questa immagine container GKE scarica automaticamente solo l'immagine corrisponde all'architettura del nodo.

Esegui il deployment della versione multi-arch della tua applicazione

1. Prima di eseguire il deployment dell'immagine multi-arch, elimina i carichi di lavoro originali:

   kubectl delete deploy x86-hello-deployment arm-hello-deployment
   

2. Ispeziona l'overlay di kustomize add_multiarch_support.yaml eseguendo cat k8s/overlays/multiarch/add_multiarch_support.yaml:

   L'output include il seguente set di tolleranze:

      tolerations:
         - key: kubernetes.io/arch
            operator: Equal
            value: arm64
            effect: NoSchedule
   

   Questa tolleranza consente l'esecuzione del carico di lavoro sui nodi Arm nel tuo cluster, poiché la tolleranza corrisponde all'incompatibilità impostata su tutti i nodi Arm. Poiché questo carico di lavoro ora può essere eseguita su qualsiasi nodo nel cluster, è necessaria solo la tolleranza. Con solo per la tolleranza, GKE può pianificare il carico di lavoro su e i nodi ARM. Se vuoi specificare dove GKE può pianificare per i carichi di lavoro, utilizzano selettori dei nodi e le regole di affinità dei nodi. Per scoprire di più su l'impostazione di questi campi, consulta Preparare un carico di lavoro ARM per il deployment.

3. Esegui il deployment dell'immagine container multi-arch con 6 repliche:

   $(cd k8s/overlays/multiarch && kustomize edit set image hello=us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/multiarch-hello:v0.0.1) 
   kubectl apply -k k8s/overlays/multiarch
   

4. Attendi 10 secondi, poi verifica che tutte le repliche dell'applicazione siano in esecuzione:

   kubectl get pods -l="app=hello" -o wide
   

   L'output è simile al seguente:

   NAME                                         READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
   multiarch-hello-deployment-65bfd784d-5xrrr   1/1     Running   0          95s   10.100.1.5    gke-my-cluster-arm-pool-e172cff7-shwc       <none>           <none>
   multiarch-hello-deployment-65bfd784d-7h94b   1/1     Running   0          95s   10.100.1.4    gke-my-cluster-arm-pool-e172cff7-shwc       <none>           <none>
   multiarch-hello-deployment-65bfd784d-7qbkz   1/1     Running   0          95s   10.100.1.7    gke-my-cluster-arm-pool-e172cff7-shwc       <none>           <none>
   multiarch-hello-deployment-65bfd784d-7wqb6   1/1     Running   0          95s   10.100.1.6    gke-my-cluster-arm-pool-e172cff7-shwc       <none>           <none>
   multiarch-hello-deployment-65bfd784d-h2g2k   1/1     Running   0          95s   10.100.0.19   gke-my-cluster-default-pool-32019863-b41t   <none>           <none>
   multiarch-hello-deployment-65bfd784d-lc9dc   1/1     Running   0          95s   10.100.0.18   gke-my-cluster-default-pool-32019863-b41t   <none>           <none>
   

   Questo output include una colonna NODE che indica che i pod sono in esecuzione sia i nodi nel pool di nodi Arm sia gli altri nel pool di nodi predefinito (x86).

5. Esegui questo comando per accedere al servizio e visualizzare l'output:

   for i in $(seq 1 6); do curl -w '\n' http://$external_ip; done
   

   L'output è simile al seguente:

   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:multiarch-hello-deployment-65bfd784d-7qbkz, CPU PLATFORM:linux/arm64
   Hello from NODE:gke-my-cluster-default-pool-32019863-b41t, POD:multiarch-hello-deployment-65bfd784d-lc9dc, CPU PLATFORM:linux/amd64
   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:multiarch-hello-deployment-65bfd784d-5xrrr, CPU PLATFORM:linux/arm64
   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:multiarch-hello-deployment-65bfd784d-7wqb6, CPU PLATFORM:linux/arm64
   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:multiarch-hello-deployment-65bfd784d-7h94b, CPU PLATFORM:linux/arm64
   Hello from NODE:gke-my-cluster-arm-pool-e172cff7-shwc, POD:multiarch-hello-deployment-65bfd784d-7wqb6, CPU PLATFORM:linux/arm64
   

   Dovresti vedere che i pod in esecuzione su piattaforme di architettura rispondono richieste.

   Nota: è possibile che tu esegua questo comando e riceva solo risposte da pod in esecuzione su una piattaforma di architettura. In questo caso, esegui il comando comando altre una o due volte e dovresti rispondere da entrambe le architetture piattaforme.

Hai creato ed eseguito il deployment di un'immagine multi-arch per eseguire senza problemi un carico di lavoro su con varie architetture.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Dopo aver completato il tutorial, puoi eseguire la pulizia delle risorse che hai creato per ridurre l'utilizzo delle quote e interrompere gli addebiti. Le seguenti sezioni e descrivere come eliminare o disattivare queste risorse.

Elimina il progetto

Il modo più semplice per eliminare la fatturazione creato per il tutorial.

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina il servizio, il cluster e il repository

Se non vuoi eliminare l'intero progetto, elimina il cluster e che hai creato per il tutorial:

1. Elimina il servizio dell'applicazione eseguendo kubectl delete:

   kubectl delete service hello-service
   

   Questo comando elimina il bilanciatore del carico di Compute Engine che hai creato quando hai esposto il deployment.

2. Elimina il cluster eseguendo gcloud container clusters delete:

   gcloud container clusters delete $CLUSTER_NAME --zone $ZONE
   

3. Elimina il repository:

   gcloud artifacts repositories delete docker-repo —location=us-central1 --async
   

Passaggi successivi

• Abilita i carichi di lavoro su GKE
• Crea cluster e pool di nodi con i nodi Arm
• Crea immagini con più architetture per i carichi di lavoro ARM
• Preparare un carico di lavoro ARM per il deployment
• Prepara i carichi di lavoro Autopilot sull'architettura ARM
• Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.