In qualità di Cloud Engineer, ti viene affidato il compito di gestire un'applicazione critica che aggiunge frequentemente funzionalità. Devi implementare nuove funzionalità e aggiornamenti riducendo al minimo l'impatto sugli utenti e i tempi di inattività dell'applicazione. L'applicazione è containerizzata ed è stato eseguito il deployment in Kubernetes. A volte, devi fare lo scale up e lo scale down in risposta ai cambiamenti della domanda degli utenti. Vuoi anche controllare il traffico all'applicazione da internet. Quando gestisci e aggiorni l'applicazione, tieni presente quanto segue:

• Come si crea un manifest di deployment per il cluster?
• Come puoi scalare manualmente il numero di pod nel tuo deployment?
• Come puoi creare un servizio che controlli il traffico in entrata alla tua applicazione?
• Come puoi implementare gli aggiornamenti con interruzioni minime per gli utenti?
• Come si possono eseguire deployment canary per testare nuove funzionalità prima di portare a termine un'implementazione completa?

In qualità di professionista del cloud che ha familiarità con l'uso di Azure Kubernetes Service (AKS), probabilmente hai utilizzato file manifest YAML per eseguire deployment Kubernetes su AKS. Probabilmente hai utilizzato le pipeline DevOps per rendere il codice dell'applicazione e i container disponibili per i tuoi cluster Kubernetes.

Per scalare il numero di pod in risposta alla domanda, puoi modificare manualmente il file manifest o utilizzare i comandi kubectl. Per controllare il traffico in entrata verso la tua applicazione, devi creare il piano per il deployment del bilanciatore del carico nella pipeline DevOps ed eseguirlo. Quando devi aggiornare l'immagine container, devi eseguire la pipeline DevOps per rendere disponibile l'immagine container e poi utilizzare i comandi kubectl per attivare l'implementazione di un deployment.

Per eseguire un aggiornamento canary, devi installare Prometheus, configurare la pipeline, aggiungere il file manifest ed eseguire la pipeline di deployment.

Tenendo conto di questo, ora vedrai come creare manifest di deployment per Google Kubernetes Engine (GKE) per creare, scalare e aggiornare i deployment.

Panoramica

In questo lab esplorerai le nozioni di base sull'utilizzo dei manifest di deployment. I manifest sono file contenenti le configurazioni necessarie per un deployment che possono essere utilizzati in diversi pod. I manifest sono facili da modificare.

Obiettivi

In questo lab imparerai a:

• Creare manifest di deployment, eseguire il deployment nel cluster e verificare la ripianificazione dei pod quando i nodi sono disabilitati
• Attivare lo scale up e lo scale down manuale dei pod nei deployment
• Attivare l'implementazione (aggiornamento in sequenza a una nuova versione) e i rollback dei deployment
• Eseguire un deployment canary

Configurazione del lab

Accedi al lab

Per ciascun lab, riceverai un nuovo progetto Google Cloud e un insieme di risorse per un periodo di tempo limitato senza alcun costo aggiuntivo.

1. Accedi a Qwiklabs utilizzando una finestra di navigazione in incognito.

2. Tieni presente la durata dell'accesso al lab (ad esempio, 1:15:00) e assicurati di finire entro quell'intervallo di tempo.
   Non è disponibile una funzionalità di pausa. Se necessario, puoi riavviare il lab ma dovrai ricominciare dall'inizio.

3. Quando è tutto pronto, fai clic su Inizia lab.

4. Annota le tue credenziali del lab (Nome utente e Password). Le userai per accedere a Google Cloud Console.

5. Fai clic su Apri console Google.

6. Fai clic su Utilizza un altro account e copia/incolla le credenziali per questo lab nei prompt.
   Se utilizzi altre credenziali, compariranno errori oppure ti verranno addebitati dei costi.

7. Accetta i termini e salta la pagina di ripristino delle risorse.

Una volta completati i passaggi di accesso iniziali, viene visualizzata la dashboard del progetto.

Attiva Google Cloud Shell

Google 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.

Google Cloud Shell fornisce l'accesso da riga di comando alle risorse Google Cloud.

1. Nella barra degli strumenti in alto a destra della console Cloud, fai clic sul pulsante Apri Cloud Shell.

   

2. Fai clic su Continua.

Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Quando la connessione è attiva, l'autenticazione è già avvenuta e il progetto è impostato sul tuo PROJECT_ID. Ad esempio:

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

• Puoi visualizzare il nome dell'account attivo con questo comando:

gcloud auth list

Output:

Credentialed accounts: - @.com (active)

Output di esempio:

Credentialed accounts: - google1623327_student@qwiklabs.net

• Puoi elencare l'ID progetto con questo comando:

gcloud config list project

Output:

[core] project =

Output di esempio:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: la documentazione completa di gcloud è disponibile nella guida Panoramica dell'interfaccia a riga di comando gcloud .

Attività 1: crea manifest di deployment ed esegui il deployment nel cluster

In quest'attività, creerai un manifest di deployment per un pod all'interno del cluster.

Connettiti al cluster GKE del lab

1. In Cloud Shell, digita questo comando per impostare la variabile di ambiente per il nome della zona e del cluster:

export my_zone={{{project_0.default_zone|Zone}}} export my_cluster=standard-cluster-1

2. Configura il completamento della scheda kubectl in Cloud Shell:

source <(kubectl completion bash)

3. In Cloud Shell, configura l'accesso al tuo cluster per lo strumento a riga di comando kubectl, utilizzando questo comando:

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. In Cloud Shell, inserisci questo comando per clonare il repository nella sessione di Cloud Shell del lab:

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. Crea un soft link da utilizzare come scorciatoia alla directory di lavoro:

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. Passa alla directory che contiene i file di esempio per questo lab:

cd ~/ak8s/Deployments/

Crea un manifest di deployment

Creerai un deployment mediante il manifest di deployment di esempio denominato nginx-deployment.yaml che ti è stato fornito. Questo deployment è configurato per eseguire tre repliche di pod con un singolo container nginx in ogni pod in ascolto sulla porta TCP 80:

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

1. Per sottoporre a deployment il manifest, esegui questo comando:

kubectl apply -f ./nginx-deployment.yaml

2. Per visualizzare un elenco di deployment, esegui questo comando:

kubectl get deployments

L'output dovrebbe essere simile all'esempio seguente.

Output:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 3 0 3s

3. Attendi qualche secondo e ripeti il comando finché il numero dei deployment CORRENTI riportato dal comando non corrisponde al numero di deployment DESIDERATI.

L'output finale dovrebbe essere simile all'esempio seguente.

Output:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 42s

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Crea e sottoponi a deployment il manifest del deployment nginx

Attività 2: fai lo scale up e lo scale down manuale del numero di pod nei deployment

A volte, hai la necessità di chiudere un'istanza pod. Altre volte, vuoi che siano in esecuzione dieci pod. In Kubernetes, puoi scalare un determinato pod fino al numero di istanze che preferisci. Per chiuderle, devi semplicemente scalarle fino a zero.

In questa attività, farai lo scale up e lo scale down dei pod nella console Google Cloud e in Cloud Shell.

Fai lo scale up e lo scale down dei pod nella console

1. Passa alla scheda della console Google Cloud.
2. Nel menu di navigazione (), fai clic su Kubernetes Engine > Carichi di lavoro.
3. Fai clic su nginx-deployment (il tuo deployment) per aprire la pagina Dettagli deployment.
4. In alto, fai clic su AZIONI > Scala> Modifica repliche.
5. Digita 1 e fai clic su SCALA.

Viene fatto lo scale down del tuo cluster. Dovresti visualizzare lo stato di aggiornamento del pod in Pod gestiti. Potrebbe essere necessario fare clic su Aggiorna.

Fai lo scale up e lo scale down dei pod nella shell

1. Torna alla scheda del browser di Cloud Shell.
2. In Cloud Shell, per visualizzare un elenco dei pod nei deployment, esegui questo comando:

kubectl get deployments

Output:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 3m

3. Per ripristinare lo scale up dei pod a tre repliche, esegui questo comando:

kubectl scale --replicas=3 deployment nginx-deployment

4. Per visualizzare un elenco dei pod nei deployment, esegui questo comando:

kubectl get deployments

Output:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 4m

Attività 3: attiva l'implementazione e il rollback di un deployment

L'implementazione di un deployment viene attivata solo nel caso in cui il modello di pod del deployment (ossia .spec.template) viene modificato, ad esempio se vengono aggiornate le etichette o le immagini container del modello. Altri aggiornamenti, ad esempio lo scale up o lo scale down del deployment, non attivano l'implementazione.

In questa attività, ti occuperai di attivare l'implementazione e poi il rollback del deployment.

Attiva l'implementazione di un deployment

1. Per aggiornare la versione di nginx nel deployment, esegui questo comando:

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record

In questo modo, l'immagine container del tuo deployment viene aggiornata a nginx v1.9.1.

2. Per visualizzare lo stato dell'implementazione, esegui questo comando:

kubectl rollout status deployment.v1.apps/nginx-deployment

L'output dovrebbe essere simile all'esempio seguente.

Output:

Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 1 old replicas pending termination... Waiting for rollout to finish: 1 old replicas pending termination... deployment "nginx-deployment" successfully rolled out

3. Per verificare la modifica, recupera l'elenco dei deployment:

kubectl get deployments

L'output dovrebbe essere simile all'esempio seguente.

Output:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 6m

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Aggiorna la versione di nginx nel deployment

4. Visualizza la cronologia dell'implementazione del deployment:

kubectl rollout history deployment nginx-deployment

L'output dovrebbe essere simile all'esempio seguente, ma potrebbe non corrispondere in modo esatto.

Output:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true

Attiva il rollback di un deployment

Per eseguire il rollback dell'implementazione di un oggetto, puoi utilizzare il comando kubectl rollout undo.

1. Per eseguire il rollback alla versione precedente del deployment nginx, esegui questo comando:

kubectl rollout undo deployments nginx-deployment

2. Visualizza la cronologia aggiornata dell'implementazione del deployment:

kubectl rollout history deployment nginx-deployment

L'output dovrebbe essere simile all'esempio seguente, ma potrebbe non corrispondere in modo esatto.

Output:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true 3

3. Visualizza i dettagli dell'ultima revisione del deployment:

kubectl rollout history deployment/nginx-deployment --revision=3

L'output dovrebbe essere simile all'esempio seguente. Potrebbe non corrispondere in modo esatto, ma mostrerà che è stato eseguito il rollback della revisione corrente a nginx:1.7.9.

Output:

deployments "nginx-deployment" with revision #3 Pod Template: Labels: app=nginx pod-template-hash=3123191453 Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

Attività 4: definisci il tipo di servizio nel manifest

In questa attività, creerai e verificherai un servizio che controlla il traffico in entrata verso la tua applicazione. I servizi possono essere configurati come tipi ClusterIP, NodePort o LoadBalancer. In questo lab, configurerai un servizio LoadBalancer.

Definisci i tipi di servizi nel manifest

Ti è stato fornito un file manifest denominato service-nginx.yaml che esegue il deployment di un tipo di servizio LoadBalancer. Questo servizio è configurato per distribuire il traffico in entrata dalla porta TCP 60000 alla porta 80 in tutti i container che hanno l'etichetta app: nginx.

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

• In Cloud Shell, per eseguire il deployment del manifest, esegui questo comando:

kubectl apply -f ./service-nginx.yaml

Questo manifest definisce un servizio e lo applica ai pod che corrispondono al selettore. In questo caso, il manifest viene applicato al container nginx di cui è stato eseguito il deployment nell'attività 1. Questo servizio viene anche applicato a qualsiasi altro pod con l'etichetta app: nginx, compresi quelli creati dopo il servizio.

Verifica la creazione del servizio LoadBalancer

1. Per visualizzare i dettagli del servizio nginx, esegui questo comando:

kubectl get service nginx

L'output dovrebbe essere simile all'esempio seguente.

Output:

NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE nginx 10.X.X.X X.X.X.X 60000/TCP run=nginx 1m

2. Quando compare l'IP esterno, apri http://[EXTERNAL_IP]:60000/ in una nuova scheda del browser per visualizzare il server fornito mediante il bilanciamento del carico di rete.

Nota: potrebbero volerci alcuni secondi prima che il campo ExternalIP venga completato per il tuo servizio. È normale. Esegui nuovamente il comando kubectl get services nginx a intervalli regolari di alcuni secondi fino a quando il campo non viene completato.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui il deployment del file manifest che esegue il deployment del tipo di servizio LoadBalancer

Attività 5: esegui un deployment canary

Un deployment canary è un deployment separato, utilizzato per testare una nuova versione dell'applicazione. Un singolo servizio ha come destinazione sia i deployment canary che quelli normali. E può indirizzare un sottoinsieme di utenti alla versione canary per ridurre il rischio per le nuove release.

Il file manifest nginx-canary.yaml fornito sottopone a deployment un unico pod che esegue una versione di nginx più nuova rispetto al tuo deployment principale. In questa attività, creerai un deployment canary utilizzando questo nuovo file di deployment:

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-canary labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx track: canary Version: 1.9.1 spec: containers: - name: nginx image: nginx:1.9.1 ports: - containerPort: 80

Il manifest per il servizio nginx di cui hai eseguito il deployment nell'attività precedente utilizza un selettore etichetta per avere come destinazione i pod con l'etichetta app: nginx. Sia il deployment normale che questo nuovo deployment canary hanno l'etichetta app: nginx. Le connessioni in entrata verranno distribuite dal servizio ai pod del deployment canary e di quello normale. Il deployment canary ha meno repliche (pod) rispetto a quello normale, pertanto è disponibile per un numero inferiore di utenti rispetto a quest'ultimo.

1. Crea il deployment canary in base al file di configurazione:

kubectl apply -f nginx-canary.yaml

2. Una volta completato il deployment, verifica che siano presenti entrambi i deployment: nginx e nginx-canary:

kubectl get deployments

3. Torna alla scheda del browser collegata all'IP del servizio LoadBalancer esterno e aggiorna la pagina. Dovresti continuare a vedere la pagina Welcome to nginx standard.
4. Torna a Cloud Shell e fai lo scale down del deployment principale a 0 repliche:

kubectl scale --replicas=0 deployment nginx-deployment

5. Verifica che ora l'unica replica in esecuzione sia il deployment canary:

kubectl get deployments

6. Torna alla scheda del browser collegata all'IP del servizio LoadBalancer esterno e aggiorna la pagina. Dovresti continuare a vedere la pagina Welcome to nginx standard, che indica che il servizio esegue il bilanciamento automatico del traffico verso il deployment canary.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Crea un deployment canary

Affinità sessione

La configurazione del servizio utilizzata nel lab non garantisce che tutte le richieste provenienti da un unico client si connettano sempre allo stesso pod. Ogni richiesta viene trattata separatamente e può connettersi al deployment nginx normale o al deployment nginx-canary.

Questa possibilità di passare da una versione all'altra può causare problemi in caso di modifiche significative alle funzionalità della versione canary. Per evitare questo problema, puoi impostare il campo sessionAffinity su ClientIP nella specifica del servizio qualora sia necessaria una prima richiesta da parte del client per determinare quale pod verrà utilizzato per tutte le connessioni successive.

Ad esempio:

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer sessionAffinity: ClientIP selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

Riepilogo

In questo lab hai scoperto in che modo GKE utilizza il file manifest per eseguire il deployment, scalare ed eseguire un aggiornamento canary dell'applicazione. Ecco alcune delle principali analogie e differenze tra GKE e AKS.

Analogie:

GKE e AKS sono entrambi servizi Kubernetes gestiti che consentono agli sviluppatori di eseguire il deployment, gestire e scalare le applicazioni containerizzate.

• La struttura e la sintassi di base dei file YAML per i deployment Kubernetes sono uguali per GKE e AKS.
• AKS e GKE usano entrambi i comandi kubectl.

Differenze:

• In GKE puoi specificare gli attributi di cluster, pod e gestione senza dover creare una pipeline DevOps, come faresti per i deployment AKS. Questo perché GKE dispone dell'infrastruttura di backend necessaria per eseguire le attività di provisioning utilizzando il file manifest.

Termina il lab

Una volta completato il lab, fai clic su Termina lab. Google Cloud Skills Boost rimuove le risorse che hai utilizzato ed esegue la pulizia dell'account.

Avrai la possibilità di inserire una valutazione in merito alla tua esperienza. Seleziona il numero di stelle applicabile, inserisci un commento, quindi fai clic su Invia.

Il numero di stelle corrisponde alle seguenti valutazioni:

• 1 stella = molto insoddisfatto
• 2 stelle = insoddisfatto
• 3 stelle = esperienza neutra
• 4 stelle = soddisfatto
• 5 stelle = molto soddisfatto

Se non vuoi lasciare un feedback, chiudi la finestra di dialogo.

Per feedback, suggerimenti o correzioni, utilizza la scheda Assistenza.

Copyright 2020 Google LLC Tutti i diritti riservati. Google e il logo Google sono marchi di Google LLC. Tutti gli altri nomi di società e prodotti sono marchi delle rispettive società a cui sono associati.