
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Create a Kubernetes cluster and deployments (Auth, Hello, and Frontend)
/ 50
Canary Deployment
/ 50
Le best practice DevOps utilizzeranno regolarmente più deployment per gestire gli scenari di deployment delle applicazioni quali "Deployment continuo", "Deployment blu/verde", "Deployment canary" e altri. Questo lab ti insegnerà come scalare e gestire i container in modo da poter realizzare questi scenari comuni in cui vengono utilizzate più deployment eterogenei.
In questo lab imparerai a:
kubectl
yaml
per i deploymentPer massimizzare il tuo apprendimento, per questo lab si consiglia quanto segue.
I deployment eterogenei in genere implicano il collegamento di due o più ambienti infrastrutturali o regioni differenti per soddisfare una specifica esigenza tecnica o operativa. I deployment eterogenei vengono chiamati "ibridi", "multi-cloud" o "pubblici-privati", a seconda delle specifiche dei deployment.
Per questo lab, i deployment eterogenei includono quelli che interessano più regioni all'interno di un singolo ambiente cloud, più ambienti cloud pubblici (multi-cloud) o una combinazione di ambienti on-premise e cloud pubblici (ibridi o pubblici-privati).
Nei deployment limitati a un solo ambiente o una sola regione, possono sorgere diverse sfide aziendali e tecniche:
I deployment eterogenei possono aiutare ad affrontare queste sfide, ma devono essere progettati utilizzando processi e procedure programmatici e deterministici. Le procedure di deployment una tantum o ad hoc possono rendere i deployment o i processi precari e intolleranti agli errori. I processi ad hoc possono provocare la perdita di dati o un calo del traffico. I processi di deployment efficaci devono essere ripetibili e utilizzare approcci comprovati per la gestione del provisioning, della configurazione e della manutenzione.
Tre scenari comuni per il deployment eterogeneo sono:
Gli esercizi seguenti consentono di fare pratica con alcuni casi d'uso comuni relativi ai deployment eterogenei e con approcci ben strutturati che utilizzano Kubernetes e altre risorse dell'infrastruttura per realizzarli.
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:
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:
Fai clic su Apri console Google Cloud (o fai clic con il tasto destro del mouse e seleziona Apri link in finestra di navigazione in incognito se utilizzi il browser Chrome).
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.
Se necessario, copia il Nome utente di seguito e incollalo nella finestra di dialogo di accesso.
Puoi trovare il Nome utente anche nel riquadro Dettagli lab.
Fai clic su Avanti.
Copia la Password di seguito e incollala nella finestra di dialogo di benvenuto.
Puoi trovare la Password anche nel riquadro Dettagli lab.
Fai clic su Avanti.
Fai clic nelle pagine successive:
Dopo qualche istante, la console Google Cloud si apre in questa scheda.
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.
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:
gcloud
è lo strumento a riga di comando di Google Cloud. È preinstallato su Cloud Shell e supporta il completamento tramite tasto Tab.
Fai clic su Autorizza.
L'output dovrebbe avere ora il seguente aspetto:
Output:
Output:
Output di esempio:
gcloud
, in Google Cloud, fai riferimento alla Panoramica dell'interfaccia a riga di comando gcloud.
Imposta la tua zona Google Cloud di lavoro eseguendo questo comando, sostituendo la zona locale con
Per iniziare, dai un'occhiata all'oggetto deployment.
explain
in kubectl
può fornire informazioni sull'oggetto deployment:--recursive
:deployments/auth.yaml
:image
come segue:auth.yaml
: premi <Esc>
quindi digita:<Invio>
. Ora crea un deployment semplice. Esamina il file di configurazione del deployment:Output:
Nota che l'oggetto deployment sta creando una replica e sta utilizzando la versione 1.0.0 del container auth.
Quando esegui il comando kubectl create
per creare il deployment auth, viene creato un pod conforme ai dati nel manifest del deployment. Ciò significa che puoi scalare il numero di pod modificando il valore specificato nel campo replicas
.
kubectl create
:ReplicaSet
per il deployment. È possibile verificare che sia stato creato un ReplicaSet
per il deployment:Dovresti vedere un ReplicaSet
con un nome simile a auth-xxxxxxx
ReplicaSet
:Ora creerai un servizio per il deployment auth. Hai già visto i file manifest dei servizi, quindi non entreremo in dettaglio qui.
kubectl create
per creare il servizio auth:hello
:frontend
:ConfigMap
per il frontend.In questo modo ottieni la risposta hello.
kubectl
per usare curl come one-liner:Fai clic su Controlla i miei progressi qui sotto per verificare lo stato di avanzamento del lab. Se hai creato correttamente il cluster Kubernetes e i deployment auth, hello e frontend, visualizzerai un punteggio di valutazione.
Ora che hai creato un deployment, puoi scalarlo. Per farlo, aggiorna il campo spec.replicas
.
kubectl explain
:kubectl scale
:Una volta aggiornato il deployment, Kubernetes aggiornerà automaticamente il ReplicaSet
associato e avvierà nuovi pod per raggiungere un numero totale di pod pari a 5.
hello
in esecuzione:Ora sai cosa sono i deployment Kubernetes e come gestire e scalare un gruppo di pod.
I deployment supportano l'aggiornamento delle immagini a una nuova versione tramite un meccanismo di aggiornamento in sequenza. Quando un deployment viene aggiornato con una nuova versione, crea un nuovo ReplicaSet
e aumenta lentamente il numero di repliche nel nuovo ReplicaSet
mentre diminuisce le repliche nel precedente ReplicaSet
.
image
come segue:Il deployment aggiornato verrà salvato nel tuo cluster e Kubernetes inizierà un aggiornamento in sequenza.
ReplicaSet
creato da Kubernetes:Se rilevi problemi con un'implementazione in esecuzione, mettila in pausa per interrompere l'aggiornamento.
L'implementazione è in pausa, il che significa che alcuni pod sono nella nuova versione, mentre altri pod sono nella versione precedente.
resume
:status
:Output:
Supponiamo che sia stato rilevato un bug nella tua nuova versione. Poiché si presume che la nuova versione abbia problemi, tutti gli utenti collegati ai nuovi pod riscontreranno gli stessi problemi.
Ti consigliamo di eseguire il rollback alla versione precedente in modo da poter esaminare e quindi rilasciare una versione corretta.
rollout
per eseguire il rollback alla versione precedente:Bene. Hai imparato come eseguire un aggiornamento in sequenza per i deployment Kubernetes e come aggiornare le applicazioni senza tempi di inattività.
Quando vuoi testare un nuovo deployment in produzione con un sottoinsieme di utenti, usa un deployment canary. I deployment canary ti consentono di rilasciare una modifica in un piccolo sottoinsieme di utenti per ridurre il rischio associato alle nuove release.
Un deployment canary consiste in un deployment separato con la tua nuova versione e un servizio destinato sia al tuo deployment normale e stabile che al tuo deployment canary.
Output:
hello
e hello-canary
. Verifica con questo comando kubectl
:Nel servizio hello
, il selettore app:hello
abbinerà i pod in entrambi i deployment: sia nel deployment di produzione che nel deployment canary. Tuttavia, poiché il deployment canary ha un numero inferiore di pod, sarà visibile a un numero inferiore di utenti.
hello
fornita dalla richiesta:Fai clic su Controlla i miei progressi qui sotto per verificare lo stato di avanzamento del lab. Se hai creato correttamente il deployment canary, visualizzerai un punteggio di valutazione.
In questo lab, ogni richiesta inviata al servizio Nginx ha avuto la possibilità di essere gestita dal deployment canary. E se volessi assicurarti che un utente non venga gestito dal deployment canary? Un caso d'uso potrebbe essere che l'interfaccia utente di un'applicazione è cambiata e non vuoi confondere l'utente. In un caso come questo, vuoi che l'utente si "attenga" a un deployment o all'altro.
Puoi farlo creando un servizio con affinità sessione. In questo modo lo stesso utente sarà sempre gestito dalla stessa versione. Nell'esempio seguente il servizio è lo stesso di prima, ma è stato aggiunto un nuovo campo sessionAffinity
, impostato su ClientIP
. Tutti i client con lo stesso indirizzo IP riceveranno le loro richieste inviate alla stessa versione dell'applicazione hello
.
Poiché è difficile configurare un ambiente per eseguire questo test, sebbene non sia necessario in questo caso, potresti voler usare sessionAffinity
per i deployment canary in produzione.
Gli aggiornamenti in sequenza sono ideali perché consentono di eseguire lentamente il deployment di un'applicazione con sovraccarichi, impatto sulle prestazioni e tempi di inattività minimi. In alcuni casi è utile modificare i bilanciatori del carico in modo che puntino alla nuova versione solo dopo il completamento del deployment. In questo caso, i deployment blu/verde sono la strada da percorrere.
A questo scopo, Kubernetes crea due deployment separati: uno per la vecchia versione "blu" e uno per la nuova versione "verde". Utilizza il tuo deployment hello
esistente per la versione "blu". Si accederà ai deployment tramite un servizio che fungerà da router. Quando la nuova versione "verde" è in esecuzione, per passare a questa versione dovrai aggiornare il servizio.
Utilizza lo stesso servizio hello, ma aggiornalo in modo che abbia un selettore app:hello
, version: 1.0.0
. Il selettore corrisponderà al deployment "blu" esistente. Non corrisponderà invece al deployment "verde" perché utilizzerà una versione diversa.
resource service/hello is missing
" poiché riceverà automaticamente la patch.Per supportare uno stile di deployment blu/verde, creerai un nuovo deployment "verde" per la nuova versione. Il deployment verde aggiorna l'etichetta della versione e il percorso dell'immagine.
Se necessario, puoi eseguire il rollback alla versione precedente allo stesso modo.
Obiettivo raggiunto. Hai imparato cos'è un deployment blu/verde e come eseguire il deployment degli aggiornamenti delle applicazioni che devono cambiare versione contemporaneamente.
Hai avuto l'opportunità di utilizzare di più lo strumento a riga di comando kubectl
e molti stili di configurazione di deployment nei file YAML per avviare, aggiornare e scalare i tuoi deployment. Con queste conoscenze di base dovresti sentirti a tuo agio nell'applicare queste competenze alle tue prassi DevOps.
Guide e soluzioni DevOps nella documentazione di Google Cloud.
Nel sito web di Kubernetes, entra in contatto con la Community di Kubernetes!
… 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: 2 aprile 2024
Ultimo test del lab: 14 agosto 2023
Copyright 2025 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.
Questi contenuti non sono al momento disponibili
Ti invieremo una notifica via email quando sarà disponibile
Bene.
Ti contatteremo via email non appena sarà disponibile
One lab at a time
Confirm to end all existing labs and start this one