Panoramica

In questo lab configurerai e testerai i probe di attività e di idoneità Kubernetes per i container.

Obiettivi

In questo lab imparerai a:

• Configurare e testare un probe di attività
• Configurare e testare un probe di idoneità

Configurazione del lab

Accedi a Qwiklabs

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: connettiti al cluster GKE del lab

In questa attività, ti connetterai al cluster GKE del lab e clonerai il repository del lab in Cloud Shell.

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 per lo strumento a riga di comando kubectl:

source <(kubectl completion bash)

3. Configura l'accesso al tuo cluster per kubectl:

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

4. In Cloud Shell, inserisci questo comando per clonare il repository del lab 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/Probes/

Attività 2: configura probe di attività

Configura un probe di attività

In questa attività eseguirai il deployment di un probe di attività per rilevare le applicazioni che sono passate da uno stato in esecuzione a uno stato non funzionante. In alcuni casi, le applicazioni non sono temporaneamente in grado di gestire il traffico. Ad esempio, durante l'avvio di un'applicazione potrebbe essere necessario caricare file di dati o di configurazione di grandi dimensioni.

In questi casi, non vuoi terminare l'applicazione, ma non vuoi neanche che vengano inviate richieste. Kubernetes fornisce probe di idoneità per rilevare e mitigare queste situazioni. Un pod con container che segnalano di non essere pronti non riceve traffico tramite i Service Kubernetes.

La configurazione dei probe di idoneità è analoga a quella dei probe di attività. L'unica differenza è che utilizzi il campo readinessProbe anziché il campo livenessProbe.

Ti è stato fornito un file di definizione del pod exec-liveness.yaml, che definisce un container semplice denominato liveness, che esegue Busybox, e un probe di attività, che utilizza il comando cat sul file/tmp/healthy all'interno del container per testare l'attività ogni 5 secondi.

Lo script di avvio del container liveness crea /tmp/healthy all'avvio e lo elimina 30 secondi dopo per simulare un'interruzione che può essere rilevata dal probe di attività.

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

1. In Cloud Shell, esegui questo comando per creare il pod:

kubectl create -f exec-liveness.yaml

2. Entro 30 secondi, visualizza gli eventi del pod:

kubectl describe pod liveness-exec

L'output indica che al momento nessun probe di attività ha avuto esito negativo.

Output di esempio ridotto:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 11s ... Successfully assigned liveness-e ... Normal Su...ntVolume 10s ... MountVolume.SetUp succeeded for ... Normal Pulling 10s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 9s ... Successfully pulled image "k8s.g ... Normal Created 9s ... Created container Normal Started 9s ... Started container

L'output di esempio mostrato qui è stato ridotto per una migliore leggibilità, sullo schermo vedrai molti più dettagli.

3. Dopo 35 secondi, visualizza di nuovo gli eventi del pod:

kubectl describe pod liveness-exec

Nella parte inferiore dell'output sono presenti messaggi che indicano che i probe di attività non sono riusciti e che i container sono stati terminati e ricreati.

Output di esempio ridotto:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 2m ... Successfully assigned liveness-e ... Normal Su...ntVolume 2m ... MountVolume.SetUp succeeded for ... Normal Pulling 49s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 49s ... Successfully pulled image "k8s.g ... Normal Created 49s ... Created container Normal Started 49s ... Started container Normal Killing 49s ... Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated. Warning Unhealthy 5s ... Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

4. Attendi altri 60 secondi e verifica che il container sia stato riavviato:

kubectl get pod liveness-exec

L'output mostra che RESTARTS è stato incrementato in risposta all'errore rilevato dal probe di attività:

Esempio di output:

NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 2 4m

5. Elimina il pod dimostrativo del probe di attività:

kubectl delete pod liveness-exec

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Configura probe di attività

Attività 3: configura i probe di idoneità

Sebbene un pod possa avviarsi correttamente ed essere considerato integro da un probe di attività, è probabile che non sia pronto a ricevere traffico immediatamente. Questo è comune per i deployment che fungono da backend per un servizio come un servizio di bilanciamento del carico. Un probe di idoneità viene utilizzato per determinare quando un pod e i relativi container sono pronti per iniziare a ricevere traffico.

La configurazione dei probe di idoneità è analoga a quella dei probe di attività. L'unica differenza nella configurazione è che utilizzi il campo readinessProbe anziché il campo livenessProbe. I probe di idoneità controllano se un container specifico è considerato pronto e questa informazione viene utilizzata dai servizi per decidere quando un container può ricevere il traffico.

In questa attività ti è stato fornito un file di definizione del pod, denominato readiness-deployment.yaml, che crea un singolo pod che fungerà da server web di prova insieme a un bilanciatore del carico.

Per ogni container è definito un probe di idoneità che utilizza il comando cat sul file /tmp/healthz all'interno del container per testare l'idoneità ogni 5 secondi.

Ogni container ha anche un probe di attività che utilizza il comando cat sullo stesso file all'interno del container per testare l'idoneità ogni 5 secondi, ma prevede inoltre un ritardo di avvio di 45 secondi per simulare un'applicazione con un processo di avvio complesso, che richiede tempo per stabilizzarsi dopo l'avvio del container.

Dopo che il servizio ha iniziato a gestire il traffico, questo pattern garantisce che lo inoltrerà solo ai container pronti a gestirlo.

apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe

1. In Cloud Shell, esegui questo comando per creare il pod:

kubectl create -f readiness-deployment.yaml

2. In Cloud Shell, controlla lo stato del servizio di bilanciamento del carico readiness-demo-svc:

kubectl get service readiness-demo-svc

3. Inserisci l'indirizzo IP in una finestra del browser e noterai che riceverai un messaggio di errore che indica che il sito non può essere raggiunto.

4. Controlla gli eventi del pod:

kubectl describe pod readiness-demo-pod

L'output rivelerà che il probe di idoneità ha avuto esito negativo:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

A differenza del probe di attività, un probe di idoneità non integro non attiva il riavvio del pod.

5. Utilizza il comando seguente per generare il file che il probe di idoneità sta controllando:

kubectl exec readiness-demo-pod -- touch /tmp/healthz

La sezione Conditions della descrizione del pod ora dovrebbe mostrare True come valore per Ready.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Output:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

6. Ora aggiorna la scheda del browser che contiene il tuo IP esterno readiness-demo-svc. Dovresti vedere il messaggio "Welcome to nginx!" visualizzato correttamente.

L'impostazione di probe di idoneità significativi per i container delle applicazioni garantisce che i pod ricevano traffico solo quando sono pronti a farlo. Un esempio di probe di idoneità significativo è verificare se la cache su cui fa affidamento l'applicazione viene caricata all'avvio.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Configura probe di idoneità

Monitora il comportamento dei probe di attività e di idoneità

Ora puoi verificare come lo stato pronto dei pod nel deployment corrisponde agli endpoint che sono attivamente abilitati per il tuo servizio. Quando i pod non superano i test dei probe di idoneità e di attività, vengono contrassegnati come non pronti, i relativi endpoint vengono rimossi dal servizio e il probe di attività inizia il processo di riavvio per recuperare il pod in errore.

I pod riavviati non vengono contrassegnati immediatamente come pronti e devono attendere il superamento del test di idoneità prima che il servizio aggiunga di nuovo l'endpoint al pool.

1. Controlla di nuovo lo stato dei pod:

kubectl get pods

Ora vedrai che i singoli pod sono mostrati come pronti. A seconda delle tempistiche, uno o più pod potrebbero riavviarsi, ma perché questo avvenga dovrebbero trascorrere 2-3 minuti. I pod elencati come pronti devono avere un endpoint corrispondente associato al servizio.

2. Per verificare se puoi connetterti all'applicazione, innanzitutto esegui una query sull'indirizzo IP esterno indicato nei dettagli del servizio bilanciatore del carico e salvalo in una variabile di ambiente:

export EXTERNAL_IP=$(kubectl get services readiness-demo-svc -o json | jq -r '.status.loadBalancer.ingress[0].ip')

3. Verifica se l'applicazione risponde:

curl $EXTERNAL_IP

4. Nei prossimi minuti, ripeti i comandi seguenti ogni 10 secondi circa per controllare lo stato del deployment e inviare una richiesta al bilanciatore del carico:

curl $EXTERNAL_IP kubectl get pods

Dovresti continuare a vedere risposte senza errori o timeout anche se i singoli container vengono riavviati regolarmente a causa degli errori rilevati dai probe di attività. Se tutti e tre i container si riavviano più o meno contemporaneamente, potresti comunque visualizzare un timeout, ma questo dovrebbe avvenire di rado.

La combinazione dei probe di attività e di idoneità fornisce un metodo per garantire che i sistemi in errore vengano riavviati in modo sicuro mentre il servizio inoltra il traffico solo ai container di cui è noto che siano in grado di rispondere.

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.