GSP767

Panoramica

La struttura di base di un cluster Google Kubernetes Engine è composta di nodi che sono singole istanze di VM Compute. Questo lab mostra in che modo l'ottimizzazione dell'infrastruttura del cluster può aiutare a risparmiare sui costi e portare a un'architettura più efficiente per le tue applicazioni.

Apprenderai una strategia per massimizzare l'utilizzo (ed evitare il sottoutilizzo) delle tue preziose risorse di infrastruttura, selezionando tipi di macchine adeguati per un carico di lavoro di esempio. Oltre al tipo di infrastruttura che usi, anche la posizione geografica fisica dell'infrastruttura ha un impatto sui costi. Tramite questo esercizio, esplorerai il modo in cui creare una strategia economicamente conveniente per gestire i cluster a livello di regione e garantire una disponibilità più elevata.

Attività previste

• Esaminare l'utilizzo delle risorse da parte di un deployment
• Fare lo scale up di un deployment
• Eseguire la migrazione del tuo carico di lavoro a un pool di nodi con un tipo di macchina ottimizzato
• Esplorare le opzioni di località per il tuo cluster
• Monitorare i log di flusso tra i pod di zone diverse
• Spostare un pod a traffico intenso per ridurre al minimo il costo del traffico tra zone diverse

Prerequisiti

• È utile avere familiarità con le macchine virtuali

Configurazione

Prima di fare clic sul pulsante Avvia lab

Leggi le seguenti istruzioni. I lab sono a tempo e non possono essere messi in pausa. Il timer si avvia quando fai clic su Avvia lab e ti mostra per quanto tempo avrai a disposizione le risorse Google Cloud.

Con questo lab pratico avrai la possibilità di completare le attività in prima persona, in un ambiente cloud reale e non di simulazione o demo. Riceverai delle nuove credenziali temporanee che potrai utilizzare per accedere a Google Cloud per la durata del lab.

Per completare il lab, avrai bisogno di:

• Accesso a un browser internet standard (Chrome è il browser consigliato).

Nota: utilizza una finestra del browser in incognito o privata per eseguire questo lab. Ciò evita eventuali conflitti tra il tuo account personale e l'account Studente, che potrebbero causare addebiti aggiuntivi sul tuo account personale.

• È ora di completare il lab: ricorda che, una volta iniziato, non puoi metterlo in pausa.

Nota: se hai già un account o un progetto Google Cloud personale, non utilizzarlo per questo lab per evitare addebiti aggiuntivi al tuo account.

Come avviare il lab e accedere alla console Google Cloud

1. Fai clic sul pulsante Avvia lab. Se devi effettuare il pagamento per il lab, si apre una finestra popup per permetterti di selezionare il metodo di pagamento. A sinistra, trovi il riquadro Dettagli lab con le seguenti informazioni:

   • Pulsante Apri console Google
   • Tempo rimanente
   • Credenziali temporanee da utilizzare per il lab
   • Altre informazioni per seguire questo lab, se necessario

2. Fai clic su Apri console Google. Il lab avvia le risorse e apre un'altra scheda con la pagina di accesso.

   Suggerimento: disponi le schede in finestre separate posizionate fianco a fianco.

   Note: se visualizzi la finestra di dialogo Scegli un account, fai clic su Utilizza un altro account.

3. Se necessario, copia il Nome utente dal riquadro Dettagli lab e incollalo nella finestra di dialogo di accesso. Fai clic su Avanti.

4. Copia la Password dal riquadro Dettagli lab e incollala nella finestra di dialogo di benvenuto. Fai clic su Avanti.

   Importante: devi utilizzare le credenziali presenti nel riquadro di sinistra. Non utilizzare le tue credenziali Google Cloud Skills Boost. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.

5. Fai clic nelle pagine successive:

   • Accetta i termini e le condizioni.
   • Non inserire opzioni di recupero o l'autenticazione a due fattori, perché si tratta di un account temporaneo.
   • Non registrarti per le prove gratuite.

Dopo qualche istante, la console Google Cloud si apre in questa scheda.

Nota: puoi visualizzare il menu con un elenco di prodotti e servizi Google Cloud facendo clic sul menu di navigazione in alto a sinistra.

Questo lab genera un piccolo cluster che utilizzerai. Il provisioning del cluster richiede circa 2-5 minuti.

Se hai premuto il pulsante Inizia lab e vedi il messaggio resources being provisioned con un cerchietto di caricamento, il cluster è ancora in fase di creazione.

Puoi iniziare a leggere le istruzioni e spiegazioni successive nell'attesa, ma eventuali comandi shell non funzioneranno fino al termine del provisioning delle risorse.

Attività 1: comprendi i tipi di macchine dei nodi

Panoramica generale

Un tipo di macchina è un insieme di risorse hardware virtualizzate disponibile per un'istanza di macchina virtuale (VM), tra cui dimensione della memoria di sistema, conteggio delle CPU virtuali (vCPU) e limiti del disco permanente. I tipi di macchine sono raggruppati e selezionati per famiglie, per i diversi carichi di lavoro.

Quando scegli un tipo di macchina per il tuo pool di nodi, la famiglia dei tipi di macchine per uso generico generalmente offre il rapporto prezzo/prestazioni migliore per diversi carichi di lavoro. I tipi di macchine per uso generico sono quelli delle serie N ed E2:

Le differenze tra i tipi di macchine possono essere più o meno utili per la tua app. In generale, le macchine della serie E2 hanno prestazioni simili a quelle della serie N1 ma sono ottimizzate in base al costo. Generalmente, utilizzare solo tipi di macchine della serie E2 può aiutare a risparmiare.

Tuttavia, per un cluster, la cosa più importante è che le risorse utilizzate siano ottimizzate in base alle esigenze della tua applicazione. Per le applicazioni o i deployment più grandi, che hanno bisogno di scalabilità elevata, può essere più economico riunire i tuoi carichi di lavoro su poche macchine ottimizzate piuttosto che sparpagliarli su molte macchine per uso generico.

Comprendere i dettagli della tua app è importante per il progresso del processo decisionale. Se la tua app ha esigenze specifiche, puoi assicurarti che il tipo di macchina sia adeguato per l'app.

Nella sezione che segue, visionerai un'app demo e ne eseguirai la migrazione in un pool di nodi con un tipo di macchina adeguato.

Attività 2: scegli il tipo di macchina corretto per Hello App

Ispeziona i requisiti del cluster della demo Hello

All'avvio, il lab ha generato un cluster della demo Hello con due nodi E2 medi (2vCPU, 4 GB di memoria). Il cluster esegue il deployment di una replica di una semplice applicazione web denominata Hello App, un server web scritto in Go che risponde a tutte le richieste con il messaggio "Hello, World!".

1. Una volta che il lab avrà terminato di eseguire il provisioning, nella console Cloud fai clic sul menu di navigazione, quindi su Kubernetes Engine.

2. Nella finestra Cluster Kubernetes, seleziona hello-demo-cluster.

3. Nella finestra che segue, seleziona la scheda Nodi:

Ora dovresti vedere un elenco dei nodi del tuo cluster:

Osserva in che modo GKE ha utilizzato le risorse del tuo cluster. Puoi vedere quanta CPU e quanta memoria vengono richieste per ogni nodo e quanti nodi potresti allocare.

4. Fai clic sul primo nodo del tuo cluster.

Guarda la sezione Pod. Dovresti vedere il tuo pod hello-server nello spazio dei nomi default. Se non vedi un pod hello-server, torna indietro e seleziona invece il secondo nodo del tuo cluster.

Noterai che il pod hello-server richiede 400 mCPU. Dovresti anche vedere alcuni altri pod kube-system in esecuzione. Questi pod vengono caricati per aiutare ad abilitare i servizi cluster di GKE, come il monitoraggio.

5. Premi il pulsante Indietro per tornare alla pagina Nodi precedente.

Noterai che sono necessari due nodi e2-medium per eseguire una replica della tua Hello-App insieme ai servizi kube-system essenziali. Inoltre, anche se stai utilizzando la maggior parte delle risorse CPU del cluster, stai utilizzando solo circa un terzo della sua memoria allocabile.

Se il carico di lavoro per quest'app fosse completamente statico, potresti creare un tipo di macchina con una configurazione personalizzata che abbia la quantità esatta di CPU e memoria necessarie. Facendo questo, risparmieresti sui costi di infrastruttura generali del tuo cluster.

Tuttavia, i cluster GKE spesso eseguono diversi carichi di lavoro per cui è generalmente necessario fare lo scale up e lo scale down.

Cosa succederebbe se fosse necessario fare lo scale up per Hello App?

Attiva Cloud Shell

Cloud Shell è una macchina virtuale in cui sono caricati strumenti per sviluppatori. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud. Cloud Shell fornisce l'accesso da riga di comando alle risorse Google Cloud.

1. Fai clic su Attiva Cloud Shell nella parte superiore della console Google Cloud.

Quando la connessione è attiva, l'autenticazione è già avvenuta e il progetto è impostato sul tuo PROJECT_ID. L'output contiene una riga che dichiara il PROJECT_ID per questa sessione:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud è lo strumento a riga di comando di Google Cloud. È preinstallato su Cloud Shell e supporta il completamento tramite tasto Tab.

2. (Facoltativo) Puoi visualizzare il nome dell'account attivo con questo comando:

gcloud auth list

3. Fai clic su Autorizza.

4. L'output dovrebbe avere ora il seguente aspetto:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facoltativo) Puoi elencare l'ID progetto con questo comando:

gcloud config list project

Output:

[core] project = <project_ID>

Output di esempio:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: per la documentazione completa di gcloud, in Google Cloud, fai riferimento alla Panoramica dell'interfaccia a riga di comando gcloud.

Fai lo scale up di Hello App

1. Accedi alle credenziali del tuo cluster:

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Fai lo scale up di Hello-Server:

kubectl scale deployment hello-server --replicas=2

Fai clic su Controlla i miei progressi per verificare l'attività eseguita. Fai lo scale up di Hello App

3. Torna nella console, seleziona Carichi di lavoro dal menu Kubernetes Engine a sinistra.

Dovresti vedere hello-server con lo stato di errore Non ha disponibilità minima.

Nota: nel tuo lab potresti non vedere l'errore. A seconda della versione di Kubernetes del tuo cluster, i pod kube-system possono avere richieste di risorse più piccole e il cluster potrebbe essere in grado di soddisfare il nuovo carico di lavoro. Se non vedi l'errore, non preoccuparti. L'errore non ha alcun effetto sul completamento di questo lab.

4. Fai clic sul messaggio di errore per ottenere dettagli sullo stato. Vedrai che la ragione è Insufficient cpu.

Questo è normale. Come ricorderai, il cluster aveva poche risorse CPU ancora disponibili e hai richiesto altri 400 mCPU con un'altra replica di hello-server.

5. Incrementa il tuo pool di nodi per gestire la tua nuova richiesta:

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. Quando ti viene chiesto di continuare, digita y e premi Invio.

7. Nella console, aggiorna la pagina Carichi di lavoro fino a quando non vedrai lo stato del carico di lavoro hello-server passare su OK:

Esamina il cluster

Una volta effettuato lo scale up del carico di lavoro, torna alla scheda dei nodi del cluster.

1. Fai clic su hello-demo-cluster:

2. Quindi, fai clic sulla scheda Nodi.

Il pool di nodi più ampio consente di gestire il carico di lavoro appesantito, ma guarda come sono utilizzate le risorse della tua infrastruttura.

Sebbene GKE utilizzi le risorse di un cluster al meglio delle sue possibilità, in questo caso c'è qualche margine di ottimizzazione. Puoi vedere che uno dei tuoi nodi sta utilizzando la maggior parte della sua memoria, ma due altri nodi presentano una notevole quantità di memoria inutilizzata.

A questo punto, se hai continuato lo scale up dell'app, inizierai a vedere un pattern simile. Kubernetes tenterà di trovare un nodo per ciascuna nuova replica del deployment di hello-server, non riuscirà, quindi creerà un nuovo nodo con circa 600 mCPU.

Problema di bin packing

Un problema di bin packing si verifica quando devi inserire elementi di diversi volumi e forme in un numero finito di "bin" o container di forma regolare. Essenzialmente, la sfida consiste nell'inserire elementi nel numero minore possibile di bin, "pacchettizzandoli" nel modo più efficiente possibile.

Questa sfida è simile a quella fronteggiata quando si tenta di ottimizzare i cluster Kubernetes per le applicazioni che eseguono. Hai un certo numero di applicazioni, probabilmente con requisiti per le risorse diversi (ossia memoria e CPU). Devi provare a inserire queste applicazioni nelle risorse di infrastruttura che Kubernetes gestisce per te (dove probabilmente risiede la maggior parte del costo del tuo cluster) nel modo più efficiente possibile.

Il tuo cluster Hello Demo non impiega il bin packing in modo molto efficiente. Sarebbe più conveniente configurare Kubernetes in modo da utilizzare un tipo di macchina più adeguato a questo carico di lavoro.

Nota: per semplicità, questo lab è incentrato sull'ottimizzazione di una singola applicazione. In realtà, il tuo cluster Kubernetes probabilmente eseguirà molte applicazioni con diversi requisiti. Kubernetes ha strumenti per aiutarti ad associare i tuoi carichi di lavoro a diverse macchine a cui Kubernetes ha accesso. Puoi utilizzare più pool di nodi GKE in modo da avere un solo cluster Kubernetes che gestisce più tipi di macchine.

Esegui la migrazione a un pool di nodi ottimizzato

• Crea un nuovo pool di nodi con un tipo di macchina più grande:

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Fai clic su Controlla i miei progressi per verificare l'attività eseguita. Crea pool di nodi

Ora puoi eseguire la migrazione dei pod nel nuovo pool di nodi seguendo questa procedura:

1. Contrassegna il pool di nodi esistente come non pianificabile: questa operazione contrassegna i nodi del pool di nodi esistente (node) come non pianificabili. Quando li contrassegni come non pianificabili, Kubernetes smette di pianificare nuovi pod in questi nodi.
2. Svuota il pool di nodi esistente: questa operazione rimuove in modo controllato i carichi di lavoro in esecuzione sui nodi del pool di nodi esistente (node).

• In primo luogo, contrassegna il pool di nodi originale come non pianificabile:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl cordon "$node"; done

• Quindi svuota il pool:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl drain --force --ignore-daemonsets --delete-local-data --grace-period=10 "$node"; done

A questo punto, dovresti vedere che i tuoi pod sono in esecuzione sul nuovo pool di nodi, larger-pool:

kubectl get pods -o=wide

3. Una volta eseguita la migrazione dei pod, puoi eliminare il vecchio pool di nodi in sicurezza:

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. Quando ti viene chiesto di continuare, digita y e premi Invio.

L'eliminazione può richiedere circa 2 minuti. Leggi la sezione successiva durante l'attesa.

Analisi dei costi

Ora stai eseguendo lo stesso carico di lavoro che ha richiesto tre macchine e2-medium su una macchina e2-standard-2.

Dai un'occhiata al costo orario per avere in funzione tipi di macchine e2-standard e con core condivisi:

Standard:

Shared Core:

Il costo di tre macchine e2-medium sarebbe di circa 0,1 $ l'ora, mentre per una macchina e2-standard-2 il prezzo di listino è di circa 0,067 $ l'ora.

Un risparmio di 0,04 $ l'ora può sembrare poco, ma questo costo va sommandosi per tutta la durata di vita di un'applicazione in esecuzione. Sarebbe ancora più notevole su scala più ampia. Poiché il tipo di macchina e2-standard-2 può pacchettizzare il tuo carico di lavoro in modo più efficiente e vi è meno spazio inutilizzato, il costo dello scale up cresce meno rapidamente.

Questo è interessante perché e2-medium è un tipo di macchina con core condivisi progettata per essere economicamente conveniente per le applicazioni piccole, che non richiedono un uso intensivo delle risorse. Tuttavia, per il carico di lavoro attuale di Hello-App, puoi vedere che utilizzare un pool di nodi con un tipo di macchina più grande si rivela una strategia più conveniente.

Nella console Cloud, dovresti essere ancora sulla scheda Nodi del tuo cluster hello-demo. Aggiorna questa scheda ed esamina i campi CPU Requested e CPU Allocatable per il tuo nodo larger-pool.

Tieni presente che c'è spazio per un'ulteriore ottimizzazione. Il nuovo nodo potrebbe accogliere un'altra replica del tuo carico di lavoro senza la necessità di eseguire il provisioning di un altro nodo. Oppure, ancora, potresti scegliere un tipo di macchina di dimensioni personalizzate adeguato alle esigenze di CPU e memoria dell'applicazione risparmiando ancora più risorse.

È bene ricordare che questi prezzi varieranno in base alla località del cluster. La parte successiva di questo lab sarà incentrata sulla selezione della regione migliore e sulla gestione di un cluster a livello di regione.

Selezione della località appropriata per un cluster

Panoramica su regioni e zone

Le risorse Compute Engine, utilizzate per i nodi del tuo cluster, sono ospitate in diverse località in tutto il mondo. Queste località sono composte di regioni e zone. Una regione rappresenta una località geografica specifica in cui puoi ospitare le tue risorse. Le regioni includono tre o più zone.

Le risorse che risiedono in una zona, come istanze di macchine virtuali o dischi permanenti a livello di zona, sono definite risorse di zona. Altre risorse, come indirizzi IP esterni statici, sono a livello di regione. Le risorse a livello di regione possono essere utilizzate da qualsiasi risorsa di quella regione, indipendentemente dalla zona, mentre le risorse di zona possono essere utilizzate solo da altre risorse della stessa zona.

Quando si sceglie una regione o una zona, è importante pensare a:

1. Gestione degli errori - Se le risorse per la tua app sono distribuite in una singola zona, che diviene non disponibile, anche la tua app non sarà disponibile. Per le app a domanda elevata, su scala più ampia, è generalmente una best practice distribuire le risorse su più zone o regioni in modo da gestire gli errori.
2. Riduzione della latenza della rete - Per ridurre la latenza della rete, potresti voler scegliere una regione o una zona vicina al tuo punto di servizio. Ad esempio, se hai prevalentemente clienti sulla costa orientale degli Stati Uniti, potresti voler scegliere una zona e una regione principali vicine a quell'ubicazione.

Best practice per i cluster

I costi variano tra regioni in base a diversi fattori. Ad esempio, le risorse nella regione us-west2 tendono a essere più costose di quelle in us-central1.

Quando selezioni una regione o una zona per il tuo cluster, esamina il comportamento della tua app. Per un ambiente di produzione sensibile alla latenza, posizionare la tua app in una regione o una zona con minore latenza di rete e maggiore efficienza ti offrirebbe probabilmente il miglior rapporto costo/prestazioni.

Tuttavia, un ambiente di sviluppo non sensibile alla latenza potrebbe essere posizionato in una regione meno costosa per ridurre le spese.

Nota: per saperne di più sulle VM e sui prezzi per regione, consulta la documentazione sui prezzi delle istanze VM.

Gestione della disponibilità dei cluster

I tipi di cluster disponibili in GKE includono quelli a livello di zona (a zona singola o multi-zona) e a livello di regione. Apparentemente, un cluster a zona singola sarà l'opzione meno costosa. Tuttavia, per garantire la disponibilità elevata per le tue applicazioni, la cosa migliore è distribuire le risorse di infrastruttura del tuo cluster su più zone.

In molti casi, dare la priorità alla disponibilità nel tuo cluster tramite un cluster multi-zona o a livello di regione ha come risultato la migliore architettura costo/prestazioni.

Nota: un cluster multi-zona ha almeno una zona aggiuntiva definita ma solo un'unica replica del piano di controllo in esecuzione in un'unica zona. I carichi di lavoro possono comunque essere eseguiti durante un'interruzione della zona del piano di controllo ma non possono essere effettuate configurazioni del cluster finché non è disponibile il piano di controllo.

Un cluster a livello di regione include più repliche del piano di controllo, in esecuzione in più zone all'interno di una data regione. I nodi inoltre sono in esecuzione in ciascuna zona in cui è eseguita una replica del piano di controllo. I cluster a livello di regione utilizzano il massimo delle risorse ma offrono la migliore disponibilità.

Scopri di più nell'articolo Tipi di cluster.

Attività 3: gestisci un cluster a livello di regione

Configurazione

La gestione delle risorse del tuo cluster su più zone diviene un poco più complessa. Se non fai attenzione, potresti accumulare costi extra derivanti da comunicazioni non necessarie tra i tuoi pod situati in zone diverse.

In questa sezione, osserverai il traffico di rete del tuo cluster e sposterai due pod a traffico intenso, che generano molto traffico l'uno verso l'altro, nella stessa zona.

1. Nella tua scheda Cloud Shell, crea un nuovo cluster a livello di regione (il completamento di questo comando richiederà alcuni minuti):

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Per dimostrare il traffico tra i tuoi pod e nodi, creerai due pod su nodi separati nel tuo cluster a livello di regione. Utilizzeremo il comando ping per generare traffico da un pod all'altro, in modo da poterlo monitorare.

2. Esegui questo comando per creare un manifest per il tuo primo pod:

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. Crea il primo pod in Kubernetes utilizzando questo comando:

kubectl apply -f pod-1.yaml

4. Quindi, esegui questo comando per creare un manifest per il tuo secondo pod:

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. Crea il secondo pod in Kubernetes:

kubectl apply -f pod-2.yaml

Fai clic su Controlla i miei progressi per verificare l'attività eseguita. Check Pod Creation

I pod che hai creato utilizzano il container node-hello e restituiscono il messaggio Hello Kubernetes quando ricevono una richiesta.

Se torni a guardare il file pod-2.yaml che hai creato, puoi vedere che Pod Anti Affinity è una regola definita. Ciò ti consente di assicurare che il pod non sia pianificato sullo stesso nodo di pod-1. Questo si ottiene associando un'espressione basata sull'etichetta security:demo di pod-1. La regola Pod Affinity è utilizzata per assicurarsi che i pod siano pianificati sullo stesso nodo, mentre la regola Pod Anti Affinity è utilizzata per assicurarsi che i pod non siano pianificati sullo stesso nodo.

Nota: Kubernetes ha inoltre un concetto di Affinità dei nodi, che può aiutarti a ottimizzare quali applicazioni eseguire su quali tipi di macchine.

In questo caso, la regola Pod Anti Affinity viene utilizzata per illustrare il traffico tra nodi, ma un uso intelligente delle regole Pod Anti Affinity e Pod Affinity può aiutarti a utilizzare ancora meglio le risorse del tuo cluster a livello di regione.

6. Visualizza i pod che hai creato:

kubectl get pod pod-1 pod-2 --output wide

Vedrai entrambi i pod restituiti con uno stato Running e IP interni.

Esempio di output: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

Prendi nota dell'indirizzo IP di pod-2. Lo utilizzerai nel comando seguente.

Simula il traffico

1. Recupera una shell per il tuo container pod-1:

kubectl exec -it pod-1 -- sh

2. Nella tua shell, invia una richiesta a pod-2 sostituendo [POD-2-IP] con l'IP interno visualizzato per pod-2:

ping [POD-2-IP]

Prendi nota della latenza media necessaria per il ping da pod-1 a pod-2.

Esamina i log di flusso

Con il ping da pod-1 a pod-2, puoi abilitare log di flusso sulla subnet del VPC su cui è stato creato il cluster per osservare il traffico.

1. Nella console Cloud, apri il menu di navigazione e seleziona Rete VPC nella sezione Networking.

2. Individua la subnet default nella regione e fai clic su questa.

3. Fai clic su Modifica nella parte superiore della schermata.

4. Imposta Log di flusso su On.

5. Quindi, fai clic su Salva.

6. Quindi, fai clic su Visualizza log di flusso.

Ora vedrai un elenco di log che visualizzano una grande quantità di informazioni ogni volta che qualcosa viene inviato o ricevuto da una delle istanze.

Se i log non vengono generati, sostituisci / prima di vpc_flows con %2F, come vedi nello screenshot riportato sopra.

Questi possono essere un po' difficili da leggere. Quindi, esportali in una tabella BigQuery in modo da poter eseguire query sulle informazioni pertinenti.

7. Fai clic su Altre azioni > Crea sink.

8. Denomina il tuo sink FlowLogsSample.

9. Tocca Avanti.

Destinazione sink

• Per Seleziona servizio sink, seleziona Set di dati BigQuery.
• Per il tuo Set di dati BigQuery, seleziona Crea nuovo set di dati BigQuery.
• Denomina il set di dati 'us_flow_logs' e fai clic su CREA SET DI DATI.

Puoi lasciare invariati gli altri valori.

1. Fai clic su Crea sink.

2. Ora ispeziona il set di dati che hai appena creato. Nella console Cloud, nella sezione Analisi del menu di navigazione, fai clic su BigQuery.

3. Fai clic su Fine.

4. Seleziona il nome del progetto, quindi seleziona us_flow_logs per visualizzare la tabella appena creata. Se non c'è alcuna tabella, potresti dover aggiornare fino a quando non sarà stata creata.

5. Fai clic sulla tabella compute_googleapis_com_vpc_flows_xxx sotto il set di dati us_flow_logs.

6. Fai clic su Query > In una nuova scheda.

7. Nell'Editor di BigQuery, incolla questo tra SELECT e FROM:

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. Fai clic su Esegui.

Vedrai i log di flusso di prima ma filtrati in base a source zone, source vm, destination zone e destination vm.

Individua alcune righe in cui sono presenti chiamate effettuate tra due diverse zone nel cluster regional-demo.

Nota: i tuoi log non corrisponderanno numericamente all'immagine di esempio.

Osservando i log di flusso, puoi vedere che c'è traffico frequente tra zone diverse.

Quindi, sposterai i pod nella stessa zona e osserverai i vantaggi.

Sposta un pod a traffico intenso per ridurre al minimo il costo del traffico tra zone diverse

1. Torna quindi in Cloud Shell e premi Ctrl + C per annullare il comando ping.

2. Digita il comando exit per uscire dalla shell di pod-1:

exit

3. Esegui questo comando per modificare il manifest di pod-2:

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

In questo modo, la regola Pod Anti Affinity viene modificata in una regola Pod Affinity utilizzando comunque la stessa logica. Ora pod-2 verrà pianificato sullo stesso nodo di pod-1.

4. Elimina il pod-2 attualmente in esecuzione:

kubectl delete pod pod-2

5. Una volta eliminato pod-2, ricrealo utilizzando il manifest appena modificato:

kubectl create -f pod-2.yaml

Fai clic su Controlla i miei progressi per verificare l'attività eseguita. Simula il traffico

6. Visualizza i pod creati e assicurati che siano entrambi in stato Running:

kubectl get pod pod-1 pod-2 --output wide

Dall'output, puoi vedere che Pod-1 e Pod-2 sono ora in esecuzione sullo stesso nodo.

Prendi nota dell'indirizzo IP di pod-2. Lo utilizzerai nel comando seguente.

7. Recupera una shell per il tuo container pod-1:

kubectl exec -it pod-1 -- sh

8. Nella shell, invia una richiesta a pod-2 sostituendo [POD-2-IP] con l'IP interno per pod-2 dal comando precedente:

ping [POD-2-IP]

Noterai che il tempo medio di ping tra questi pod è molto più rapido ora.

A questo punto, puoi tornare al tuo set di dati BigQuery dei log di flusso e controllare i log recenti per verificare che non siano presenti altre comunicazioni indesiderate tra zone diverse.

Analisi dei costi

Consulta i prezzi del traffico in uscita tra VM in Google Cloud:

Quando i pod si stavano inviando ping da zone diverse, il costo era di 0,01 $ per GB. Sebbene sembri una cifra irrilevante, potrebbe crescere molto rapidamente per un cluster su vasta scala con più servizi che effettuano chiamate frequenti tra una zona e un'altra.

Quando hai spostato i pod nella stessa zona, il ping è divenuto privo di costi aggiuntivi.

Complimenti!

Hai esplorato l'ottimizzazione dei costi per le macchine virtuali che fanno parte di un cluster GKE. In primo luogo, hai eseguito la migrazione di un carico di lavoro a un pool di nodi con un tipo di macchine più adeguato. Quindi hai compreso i pro e i contro dell'utilizzo di regioni diverse e infine hai spostato un pod a traffico elevato all'interno di un cluster a livello di regione perché sia sempre nella stessa zona del pod con cui comunicava.

In questo lab, hai sperimentato strumenti e strategie economicamente convenienti per le VM GKE, ma ottimizzare le macchine virtuali significa prima di tutto comprendere la tua applicazione e le relative esigenze. Sapere quali tipi di carichi di lavoro eseguirai e stimare la domanda delle tue applicazioni quasi sempre influenzerà la decisione circa la località e il tipo di macchina più efficaci per le macchine virtuali di base per il tuo cluster GKE.

Un utilizzo efficiente dell'infrastruttura del tuo cluster sarà determinante per l'ottimizzazione dei costi.

Completa la Quest

Questo self-paced lab fa parte della Quest Optimize Costs for Google Kubernetes Engine. Una Quest è una serie di lab collegati tra loro che formano un percorso di apprendimento. Il completamento della Quest ti permette di ottenere un badge come riconoscimento dell'obiettivo raggiunto. Puoi rendere pubblici i tuoi badge inserendone i link nel tuo CV online o sui social media.
Iscriviti alla Quest e ricevi subito un riconoscimento per aver completato questo lab.
Fai riferimento al catalogo Google Cloud Skills Boost per tutte le Quest disponibili.

Segui il prossimo lab

Continua la Quest con Optimize Costs for Google Kubernetes Engine o dai un'occhiata a questi suggerimenti:

• Gestione di un cluster GKE multi-tenant con gli spazi dei nomi
• Ottimizzazione dei carichi di lavoro di GKE

Passaggi successivi/Scopri di più

• Documentazione relativa ai tipi di macchine
• Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE: scegli il tipo di macchina giusto
• Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE: scegli la regione più appropriata

Formazione e certificazione Google Cloud

… per utilizzare al meglio le tecnologie Google Cloud. I nostri corsi ti consentono di sviluppare competenze tecniche e best practice per aiutarti a metterti subito al passo e avanzare nel tuo percorso di apprendimento. Offriamo vari livelli di formazione, dal livello base a quello avanzato, con opzioni di corsi on demand, dal vivo e virtuali, in modo da poter scegliere il più adatto in base ai tuoi impegni. Le certificazioni ti permettono di confermare e dimostrare le tue abilità e competenze relative alle tecnologie Google Cloud.

Ultimo aggiornamento del manuale: 20 settembre 2023

Ultimo test del lab: 20 settembre 2023 ![[/fragments/copyright]]