arrow_back

Gestione dei deployment utilizzando Kubernetes Engine

Accedi Partecipa
Metti alla prova le tue conoscenze e condividile con la nostra community.
done
Accedi a oltre 700 lab pratici, badge delle competenze e corsi

Gestione dei deployment utilizzando Kubernetes Engine

Lab 1 ora universal_currency_alt 5 crediti show_chart Intermedio
info Questo lab potrebbe incorporare strumenti di AI a supporto del tuo apprendimento.
Metti alla prova le tue conoscenze e condividile con la nostra community.
done
Accedi a oltre 700 lab pratici, badge delle competenze e corsi

GSP053

Laboratori autogestiti Google Cloud

Panoramica

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.

Obiettivi

In questo lab imparerai a:

  • Utilizzare lo strumento kubectl
  • Creare file yaml per i deployment
  • Avviare, aggiornare e scalare i deployment
  • Aggiornare i deployment e scoprire gli stili di deployment

Prerequisiti

Per massimizzare il tuo apprendimento, per questo lab si consiglia quanto segue.

  • Hai seguito questi lab di Google Cloud Skills Boost:
  • Hai competenze di amministrazione del sistema Linux.
  • Comprendi la teoria DevOps: concetti di deployment continuo.

Introduzione ai deployment

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:

  • Risorse esaurite: in ogni singolo ambiente, in particolare negli ambienti on-premise, potresti non disporre delle risorse di computing, networking e archiviazione necessarie per soddisfare le tue esigenze di produzione.
  • Copertura geografica limitata: i deployment in un unico ambiente richiedono che le persone geograficamente distanti l'una dall'altra accedano a un deployment. Il loro traffico potrebbe viaggiare in tutto il mondo verso una posizione centrale.
  • Disponibilità limitata: i pattern di traffico su scala web sfidano le applicazioni a mantenersi resilienti e a tolleranza di errore.
  • Vincoli al fornitore: la piattaforma e le astrazioni dell'infrastruttura a livello di fornitore possono impedirti la portabilità delle applicazioni.
  • Risorse non flessibili: le tue risorse potrebbero essere limitate a un particolare set di offerte di computing, archiviazione o networking.

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:

  • deployment multi-cloud
  • infrastruttura di dati on-premise
  • processi di integrazione continua/distribuzione continua (CI/CD)

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.

Configurazione e requisiti

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:

    • Il pulsante Apri console Google Cloud
    • Tempo rimanente
    • Credenziali temporanee da utilizzare per il lab
    • Altre informazioni per seguire questo lab, se necessario
  2. 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.

    Nota: se visualizzi la finestra di dialogo Scegli un account, fai clic su Usa un altro account.
  3. Se necessario, copia il Nome utente di seguito e incollalo nella finestra di dialogo di accesso.

    {{{user_0.username | "Username"}}}

    Puoi trovare il Nome utente anche nel riquadro Dettagli lab.

  4. Fai clic su Avanti.

  5. Copia la Password di seguito e incollala nella finestra di dialogo di benvenuto.

    {{{user_0.password | "Password"}}}

    Puoi trovare la Password anche nel riquadro Dettagli lab.

  6. Fai clic su Avanti.

    Importante: devi utilizzare le credenziali fornite dal lab. Non utilizzare le credenziali del tuo account Google Cloud. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.
  7. 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: per visualizzare un menu con un elenco di prodotti e servizi Google Cloud, fai clic sul menu di navigazione in alto a sinistra. Icona menu di navigazione

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

  1. (Facoltativo) Puoi visualizzare il nome dell'account attivo con questo comando:
gcloud auth list
  1. Fai clic su Autorizza.

  2. 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`
  1. (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.

Imposta la zona

Imposta la tua zona Google Cloud di lavoro eseguendo questo comando, sostituendo la zona locale con :

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

Recupera il codice campione per questo lab

  1. Recupera il codice campione per la creazione e l'esecuzione di container e deployment:
gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes
  1. Crea un cluster con 3 nodi (il completamento dell'operazione richiederà alcuni minuti):
gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Attività 1: scopri di più sull'oggetto deployment

Per iniziare, dai un'occhiata all'oggetto deployment.

  1. Il comando explain in kubectl può fornire informazioni sull'oggetto deployment:
kubectl explain deployment
  1. Possiamo anche visualizzare tutti i campi utilizzando l'opzione --recursive:
kubectl explain deployment --recursive
  1. Puoi utilizzare il comando explain durante il lab per comprendere la struttura di un oggetto deployment e capire a cosa servono i singoli campi:
kubectl explain deployment.metadata.name

Attività 2: crea un deployment

  1. Aggiorna il file di configurazione deployments/auth.yaml:
vi deployments/auth.yaml
  1. Avvia l'editor:
i
  1. Nella sezione relativa ai container del deployment, modifica image come segue:
... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...
  1. Salva il file auth.yaml: premi <Esc> quindi digita:
:wq
  1. Premi <Invio>. Ora crea un deployment semplice. Esamina il file di configurazione del deployment:
cat deployments/auth.yaml

Output:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

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.

  1. Crea il tuo oggetto deployment utilizzando kubectl create:
kubectl create -f deployments/auth.yaml
  1. Una volta creato il deployment, puoi verificare che sia stato creato correttamente.
kubectl get deployments
  1. Una volta creato il deployment, Kubernetes creerà un ReplicaSet per il deployment. È possibile verificare che sia stato creato un ReplicaSet per il deployment:
kubectl get replicasets

Dovresti vedere un ReplicaSet con un nome simile a auth-xxxxxxx

  1. Visualizza i pod che sono stati creati come parte del deployment. Kubernetes crea un pod singolo quando si crea un ReplicaSet:
kubectl get pods

Ora creerai un servizio per il deployment auth. Hai già visto i file manifest dei servizi, quindi non entreremo in dettaglio qui.

  1. Usa il comando kubectl create per creare il servizio auth:
kubectl create -f services/auth.yaml
  1. Ora esegui la stessa operazione per creare ed esporre il deployment hello:
kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml
  1. Eseguilo ancora una volta per creare ed esporre il deployment frontend:
kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml Nota: hai creato una risorsa ConfigMap per il frontend.
  1. Interagisci con il frontend recuperando il suo IP esterno e condividendolo tramite comando curl:
kubectl get services frontend Nota: potrebbero volerci alcuni secondi prima che il campo IP esterno venga compilato per il tuo servizio. È normale. Esegui il comando riportato sopra a intervalli regolari di alcuni secondi fino a quando il campo non viene compilato. curl -ks https://<EXTERNAL-IP>

In questo modo ottieni la risposta hello.

  1. Puoi anche utilizzare la funzionalità per la creazione di modelli di output kubectl per usare curl come one-liner:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Verifica l'attività completata

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.

Crea un cluster Kubernetes e i deployment (auth, hello e frontend)

Scala un deployment

Ora che hai creato un deployment, puoi scalarlo. Per farlo, aggiorna il campo spec.replicas.

  1. Puoi visualizzare una spiegazione di questo campo utilizzando nuovamente il comando kubectl explain:
kubectl explain deployment.spec.replicas
  1. Il campo replicas può essere aggiornato più facilmente utilizzando il comando kubectl scale:
kubectl scale deployment hello --replicas=5 Nota: l'avvio di tutti i nuovi pod può richiedere circa un minuto.

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.

  1. Verifica che siano presenti 5 pod hello in esecuzione:
kubectl get pods | grep hello- | wc -l
  1. Ora ridimensiona l'applicazione:
kubectl scale deployment hello --replicas=3
  1. Verifica nuovamente di avere il numero corretto di pod:
kubectl get pods | grep hello- | wc -l

Ora sai cosa sono i deployment Kubernetes e come gestire e scalare un gruppo di pod.

Attività 3: aggiornamento in sequenza

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.

Diagramma del deployment tra set di repliche

Attiva un aggiornamento in sequenza

  1. Per aggiornare il tuo deployment, esegui questo comando:
kubectl edit deployment hello
  1. Nella sezione relativa ai container del deployment, modifica image come segue:
... containers: image: kelseyhightower/hello:2.0.0 ...
  1. Salva ed esci.

Il deployment aggiornato verrà salvato nel tuo cluster e Kubernetes inizierà un aggiornamento in sequenza.

  1. Guarda il nuovo ReplicaSet creato da Kubernetes:
kubectl get replicaset
  1. Puoi anche vedere una nuova voce nella cronologia di implementazione:
kubectl rollout history deployment/hello

Metti in pausa l'aggiornamento in sequenza

Se rilevi problemi con un'implementazione in esecuzione, mettila in pausa per interrompere l'aggiornamento.

  1. Esegui questo comando per mettere in pausa l'implementazione:
kubectl rollout pause deployment/hello
  1. Verifica lo stato attuale dell'implementazione:
kubectl rollout status deployment/hello
  1. Puoi anche verificarlo direttamente nei pod:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Riprendi l'aggiornamento in sequenza

L'implementazione è in pausa, il che significa che alcuni pod sono nella nuova versione, mentre altri pod sono nella versione precedente.

  1. Continua l'implementazione utilizzando il comando resume:
kubectl rollout resume deployment/hello
  1. Al termine dell'implementazione, dovresti vedere quanto segue durante l'esecuzione del comando status:
kubectl rollout status deployment/hello

Output:

deployment "hello" successfully rolled out

Esegui il rollback di un aggiornamento

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.

  1. Utilizza il comando rollout per eseguire il rollback alla versione precedente:
kubectl rollout undo deployment/hello
  1. Verifica il rollback nella cronologia:
kubectl rollout history deployment/hello
  1. Infine, verifica che per tutti i pod sia stato eseguito il rollback alle versioni precedenti:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Bene. Hai imparato come eseguire un aggiornamento in sequenza per i deployment Kubernetes e come aggiornare le applicazioni senza tempi di inattività.

Attività 4: deployment canary

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.

Crea un deployment canary

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.

Diagramma di un deployment canary

  1. Innanzitutto, crea un deployment canary per la nuova versione:
cat deployments/hello-canary.yaml

Output:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...
  1. Ora crea il deployment canary:
kubectl create -f deployments/hello-canary.yaml
  1. Una volta creato il deployment canary, dovresti avere due deployment, hello e hello-canary. Verifica con questo comando kubectl:
kubectl get deployments

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.

Verifica il deployment canary

  1. Puoi verificare la versione di hello fornita dalla richiesta:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
  1. Esegui questo comando più volte. Alcune delle richieste vengono gestite da hello 1.0.0 e un piccolo sottoinsieme (1/4 = 25%) viene gestito dalla versione 2.0.0.

Verifica l'attività completata

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.

Deployment canary

Deployment canary in produzione - Affinità sessione

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.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

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.

Attività 5: deployment blu/verde

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.

Diagramma di un deployment blu/verde

Nota: uno dei principali svantaggi dei deployment blu/verde è che dovrai disporre almeno del doppio delle risorse nel tuo cluster per ospitare la tua applicazione. Assicurati di avere risorse sufficienti nel cluster prima di eseguire il deployment di entrambe le versioni dell'applicazione contemporaneamente.

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.

  • Innanzitutto, aggiorna il servizio:
kubectl apply -f services/hello-blue.yaml Nota: ignora l'avviso "resource service/hello is missing" poiché riceverà automaticamente la patch.

Aggiornamento mediante deployment blu/verde

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.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1
  1. Crea il deployment verde:
kubectl create -f deployments/hello-green.yaml
  1. Una volta creato e avviato correttamente il deployment verde, verifica che sia ancora in uso la versione corrente 1.0.0:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
  1. Ora aggiorna il servizio in modo che punti alla nuova versione:
kubectl apply -f services/hello-green.yaml
  1. Una volta aggiornato il servizio, il deployment "verde" verrà utilizzato immediatamente. Ora puoi verificare che la nuova versione sia sempre in uso:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Rollback blu/verde

Se necessario, puoi eseguire il rollback alla versione precedente allo stesso modo.

  1. Mentre il deployment "blu" è ancora in esecuzione, aggiorna semplicemente il servizio alla versione precedente:
kubectl apply -f services/hello-blue.yaml
  1. Una volta aggiornato il servizio, il rollback sarà stato eseguito correttamente. Verifica nuovamente che sia in uso la versione corretta:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Obiettivo raggiunto. Hai imparato cos'è un deployment blu/verde e come eseguire il deployment degli aggiornamenti delle applicazioni che devono cambiare versione contemporaneamente.

Complimenti!

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.

Prossimi passi/Scopri di più

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: 2 aprile 2024

Ultimo test del lab: 14 agosto 2023

Copyright 2024 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