Questo tutorial descrive come eseguire la migrazione di un'applicazione creata per i nodi utilizzando un processore x86 (Intel o AMD) in un cluster Google Kubernetes Engine (GKE) a un'applicazione multi-architettura (multi-arch) in esecuzione su nodi x86 o ARM. Il pubblico di destinazione di questo tutorial è composto da amministratori di piattaforma, operatori di app e sviluppatori di app che vogliono eseguire i carichi di lavoro esistenti compatibili con x86 su ARM.
Con i cluster GKE, puoi eseguire carichi di lavoro sui nodi ARM utilizzando la serie di macchine ARM Tau T2A. I nodi T2A possono essere eseguiti nel cluster GKE come qualsiasi altro nodo utilizzando i processori x86 (Intel o AMD). Sono un'ottima scelta per carichi di lavoro con scale out e ad alta intensità di calcolo.
Per saperne di più, consulta Arm Workloads su GKE.
Questo tutorial presuppone che tu conosca Kubernetes e Docker. Il tutorial utilizza 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-arco per eseguire un carico di lavoro su più architetture.
- Esegui i carichi di lavoro su più architetture in un unico cluster GKE.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
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
Segui questi passaggi per abilitare l'API Kubernetes Engine:- 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.
-
Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Artifact Registry and Google Kubernetes Engine.
-
Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Artifact Registry and Google Kubernetes Engine.
Al termine di questo tutorial, puoi evitare di continuare la fatturazione eliminando le risorse che hai creato. Per ulteriori dettagli, consulta Pulizia.
Avvia Cloud Shell
In questo tutorial utilizzerai Cloud Shell, un ambiente shell per la gestione delle risorse ospitate su Google Cloud.
In Cloud Shell sono preinstallati
Google Cloud CLI
e lo strumento a riga di comando kubectl
. Gcloud CLI fornisce la prima interfaccia a riga di comando per Google Cloud, mentre kubectl
quella a riga di comando principale per l'esecuzione di comandi sui cluster Kubernetes.
Avvia Cloud Shell:
Vai alla console Google Cloud.
Nell'angolo in alto a destra della console, fai clic sul pulsante Attiva Cloud Shell:
Nella console viene visualizzata una sessione di Cloud Shell.
Utilizza questa shell per eseguire i comandi gcloud
e kubectl
.
prepara l'ambiente
In questa sezione preparerai l'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 del nuovo cluster.
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 per questo tutorial nella sezione Prima di iniziare.
In questo tutorial, creerai risorse in us-central1-a. Per un elenco completo delle località in cui è disponibile la serie di macchine Tau T2A, consulta Regioni e zone disponibili.
Clona il repository Git
Questo tutorial utilizza risorse del repository GitHub di Arm su GKE.
Clona il repository:
git clone https://github.com/GoogleCloudPlatform/gke-arm
Cambia la directory di lavoro attuale in
gke-arm/migrate-x86-app-to-multi-arch/
dal repository clonato nel passaggio precedente:cd gke-arm/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 ed eseguirai 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 applicazioni compatibili con x86 e nodi x86.
crea un cluster GKE
Per prima cosa, crea un GKE utilizzando nodi con processori x86. Con questa configurazione, crei un tipico ambiente cluster per eseguire 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 funzionalità specifiche nei passaggi successivi.
Il processo di creazione del cluster potrebbe richiedere alcuni minuti. Il flag --async
consente di eseguire questa operazione in background mentre completi i passaggi successivi.
Puoi creare cluster solo con nodi ARM, ma in questo tutorial creerai prima un cluster con solo nodi x86 per conoscere il processo di compatibilità delle applicazioni x86 solo con ARM.
Crea il repository Docker di Artifact Registry
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"
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 su Artifact Registry
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 .
Esegui il push dell'immagine ad Artifact Registry:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/docker-repo/x86-hello:v0.0.1
Deployment dell'applicazione x86
Verifica che il cluster sia pronto eseguendo lo script seguente:
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
Recupera le credenziali del cluster in modo che
kubectl
possa connettersi all'API Kubernetes per il cluster:gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE --project $PROJECT_ID
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
Esegui il deployment di un servizio per esporre l'applicazione su internet:
kubectl apply -f k8s/hello-service.yaml
Verifica che l'indirizzo IP esterno del servizio,
hello-service
, abbia terminato il 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
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 nel pool di nodi predefinito nell'architettura
amd64
. I nodi nel pool di nodi predefinito del 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 nodi sono i punti in cui viene eseguito il deployment della versione compatibile con Arm della tua applicazione quando viene ricreata per l'esecuzione su ARM.
Check Point
Finora hai raggiunto i seguenti obiettivi:
- creare un cluster GKE utilizzando nodi x86.
- archiviare un'immagine container compatibile con x86 con Docker in Artifact Registry.
- Eseguire il deployment di un carico di lavoro compatibile con x86 in un cluster GKE.
Hai configurato un ambiente cluster con nodi x86 e un carico di lavoro compatibile con x86. Questa configurazione è simile agli ambienti cluster esistenti, se attualmente non utilizzi nodi e carichi di lavoro compatibili con Arm.
Aggiungi un pool di nodi ARM al 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).
Puoi creare un pool di nodi con nodi ARM nello stesso modo in cui crei un pool di nodi con nodi x86. Dopo aver creato questo pool di nodi, avrai nodi x86 e 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 sui nodi basati su x86
I nodi con diversi tipi di architettura possono operare perfettamente in un unico cluster. GKE non pianifica i carichi di lavoro esistenti in esecuzione su nodi x86 per i nodi Arm nel cluster perché un'incompatibilità viene posizionata automaticamente sui nodi Arm. Per farlo, puoi fare lo scale up della tua applicazione esistente.
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/
Attendi 30 secondi, quindi esegui il comando seguente per verificare lo stato del 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 è rimasta più stanza sui nodi basati su x86. Poiché il gestore della scalabilità automatica dei cluster è disabilitato e i nodi ARM sono incompatibili, il deployment dei carichi di lavoro non verrà eseguito su nessuno dei nodi Arm disponibili. Questa incompatibilità impedisce a GKE di pianificare carichi di lavoro x86 sui nodi ARM. Per eseguire il deployment nei nodi ARM, devi indicare che il deployment è compatibile con i nodi ARM.
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 del deployment vengono eseguiti solo nel pool predefinito, il che significa che i pod compatibili con x86 vengono pianificati solo per i nodi x86. Il pod originale, già pianificato prima della creazione del pool di nodi Arm, è ancora in esecuzione sullo stesso nodo.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 in stato In attesa perché non c'è spazio sui nodi x86 esistenti e non saranno pianificati per i nodi Arm.
Ricrea l'applicazione per l'esecuzione 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, non ha pianificato alcun carico di lavoro sui nodi ARM. In questa sezione ricreerai l'applicazione in modo che sia compatibile con Arm, in modo che possa essere eseguita sui nodi ARM nel cluster.
Per questo esempio, esegui questi passaggi utilizzando docker build
.
Questo approccio in due passaggi include:
- Prima fase: crea il codice per ARM.
- Seconda fase: copia l'eseguibile in un container lean.
Dopo aver seguito questi passaggi, oltre a quella compatibile con x86 avrai un'immagine compatibile con Arm.
Il secondo passaggio della copia dell'eseguibile in un altro container segue una delle 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 il linguaggio di programmazione
Golang. Con Golang puoi eseguire la compilazione incrociata di un'applicazione con diversi sistemi operativi e piattaforme CPU fornendo le variabili di ambiente, rispettivamente, GOOS
e GOARCH
.
Esegui
cat Dockerfile_arm
per visualizzare 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. Nel file sono incluse entrambe le fasi.
In questo file, l'impostazione
GOARCH=arm64
indica al compilatore Go di creare l'applicazione per il set di istruzioni ARM. Non è necessario impostareGOOS
perché l'immagine di base nella prima fase è un'immagine Linux Alpine.Crea il codice per Arm ed eseguine il push in 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 sui nodi Arm, puoi eseguirne il deployment nei nodi Arm nel cluster.
Esamina
add_arm_support.yaml
eseguendocat 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 sui nodi ARM. Quando utilizzinodeSelector
, GKE aggiunge una tolleranza che corrisponde all'incompatibilità sui nodi ARM, consentendo a GKE di pianificare il carico di lavoro su questi nodi. Per saperne di più sull'impostazione di questo campo, consulta Preparare un carico di lavoro ARM per il deployment.Esegui il deployment di una replica della versione compatibile con Arm dell'applicazione:
$(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
Attendi 5 secondi, quindi verifica che il deployment ARM risponda a
curl
richieste: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 delle applicazioni compatibili con x86 e Arm che rispondono alla richiesta
curl
.
Crea un'immagine multi-architettura per eseguire un carico di lavoro tra architetture
Sebbene sia possibile utilizzare la strategia descritta nella sezione precedente ed eseguire il deployment di carichi di lavoro separati per x86 e ARM, questo richiede la manutenzione e l'organizzazione di due processi di build e due immagini container.
Idealmente, vuoi creare ed eseguire la tua applicazione senza problemi su entrambe le piattaforme x86 e ARM. Consigliamo questo approccio. Per eseguire l'applicazione con un solo manifest su più piattaforme di architettura, devi utilizzare immagini multi-architettura (multi-arch). Per scoprire di più sulle immagini multi-architettura, consulta Creazione di immagini multi-architettura per carichi di lavoro ARM.
Per utilizzare immagini multi-architettura, devi assicurarti che l'applicazione soddisfi i seguenti prerequisiti:
- L'applicazione non ha dipendenze specifiche della piattaforma di architettura.
- Tutte le dipendenze devono essere create per una multiarchitettura o, come minimo, per le piattaforme target.
L'applicazione di esempio utilizzata in questo tutorial soddisfa entrambi i prerequisiti. Tuttavia, ti consigliamo di testare le tue applicazioni quando crei le immagini multi-archetto prima di eseguirne il deployment in produzione.
Crea ed esegui il push di immagini multi-architettura
Puoi creare immagini multi-archetto con Docker Buildx se il tuo carico di lavoro soddisfa i prerequisiti seguenti:
- L'immagine di base supporta più architetture. Per verificarlo, esegui
docker manifest inspect
sull'immagine di base e consulta l'elenco delle piattaforme di architettura. Vedi un esempio di come ispezionare un'immagine alla fine di questa sezione. - L'applicazione non richiede passaggi di creazione speciali per ogni piattaforma di architettura. Se fossero necessari passaggi speciali, Buildx potrebbe non essere sufficiente. Devi disporre di un Dockerfile separato per ogni piattaforma e creare il manifest manualmente con
docker manifest create
.
L'immagine di base dell'applicazione di esempio è Alpine, che supporta più architetture. Inoltre, non esistono passaggi specifici della piattaforma per l'architettura, quindi puoi creare un'immagine multi-arch con Buildx.
Ispeziona 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 creazione e quella di rilascio. Devi usare lo stesso Dockerfile usato per creare l'applicazione x86. Se segui le best practice per la creazione dei container, potresti essere in grado di ricreare le tue immagini container senza apportare modifiche.
Esegui questo comando per creare e utilizzare un nuovo builder
docker buildx
:docker buildx create --name multiarch --use --bootstrap
Ora che hai creato questo nuovo builder, puoi creare ed eseguire il push di un'immagine compatibile con
linux/amd64
elinux/arm64
utilizzando il flag--platform
. Per ogni piattaforma fornita con il flag, Buildx crea un'immagine nella piattaforma di destinazione. Quando Buildx crea l'immaginelinux/arm64
, scarica le immagini di basearm64
. Nella prima fase, crea il programma binario sull'immaginearm64 golang:1.18-alpine
perarm64
. Nella seconda fase, l'immaginearm64
di Alpine Linux viene scaricata e il programma binario viene copiato in un livello dell'immagine.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 perlinux/amd64
.Esamina 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 l'architettura della piattaformaamd64
e l'altro con l'architettura della piattaformaarm64
.Quando esegui il deployment di questa immagine container nel cluster, GKE scarica automaticamente solo l'immagine che corrisponde all'architettura del nodo.
Esegui il deployment della versione multi-arch della tua applicazione
Prima di eseguire il deployment dell'immagine multi-arch, elimina i carichi di lavoro originali:
kubectl delete deploy x86-hello-deployment arm-hello-deployment
Esamina l'overlay di Kustomize
add_multiarch_support.yaml
eseguendocat k8s/overlays/multiarch/add_multiarch_support.yaml
:L'output include il seguente set di tolleranza:
tolerations: - key: kubernetes.io/arch operator: Equal value: arm64 effect: NoSchedule
Questa tolleranza consente l'esecuzione del carico di lavoro sui nodi ARM nel cluster, poiché la tolleranza corrisponde a quella impostata su tutti i nodi ARM. Poiché ora questo carico di lavoro può essere eseguito su qualsiasi nodo nel cluster, è necessaria solo la tolleranza. Con la sola tolleranza, GKE può pianificare il carico di lavoro sia sui nodi x86 che su quelli ARM. Per specificare dove GKE può pianificare i carichi di lavoro, usa i selettori dei nodi e le regole di affinità dei nodi. Per scoprire di più sull'impostazione di questi campi, consulta Preparare un carico di lavoro ARM per il deployment.
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
Attendi 10 secondi, quindi conferma 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 su entrambi i nodi nel pool di nodi Arm e su altri nodi nel pool predefinito (x86).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 alle richieste.
Hai creato ed eseguito il deployment di un'immagine multi-architettura per eseguire senza problemi un carico di lavoro su più 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.
Al termine del tutorial, puoi eseguire la pulizia delle risorse che hai creato per ridurre l'utilizzo della quota e interrompere gli addebiti. Le sezioni seguenti descrivono come eliminare o disattivare queste risorse.
Elimina il progetto
Il modo più semplice per eliminare la fatturazione è eliminare il progetto che hai creato per il tutorial.
Per eliminare il progetto:
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Elimina servizio, cluster e repository
Se non vuoi eliminare l'intero progetto, elimina il cluster e il repository che hai creato per il tutorial:
Elimina il servizio dell'applicazione eseguendo
kubectl delete
:kubectl delete service hello-service
Questo comando elimina il bilanciatore del carico Compute Engine che hai creato quando hai esposto il deployment.
Elimina il cluster eseguendo
gcloud container clusters delete
:gcloud container clusters delete $CLUSTER_NAME --zone $ZONE
Elimina il repository:
gcloud artifacts repositories delete docker-repo —location=us-central1 --async
Passaggi successivi
- Carichi di lavoro Arm su GKE
- Crea cluster e pool di nodi con i nodi ARM
- Crea immagini multi-architettura per i carichi di lavoro ARM
- Prepara 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 Cloud Architecture Center.