Descripción general

En este lab, configurarás y probarás sondeos de funcionamiento y preparación de Kubernetes para contenedores.

Objetivos

En este lab, aprenderás a hacer lo siguiente:

• Configurar y probar un sondeo de funcionamiento
• Configurar y probar un sondeo de preparación

Configuración del lab

Accede a Qwiklabs

En cada lab, recibirá un proyecto de Google Cloud y un conjunto de recursos nuevos por tiempo limitado y sin costo adicional.

1. Accede a Qwiklabs desde una ventana de incógnito.

2. Ten en cuenta el tiempo de acceso del lab (por ejemplo, 1:15:00) y asegúrate de finalizarlo en el plazo asignado.
   No existe una función de pausa. Si lo necesita, puede reiniciar el lab, pero deberá hacerlo desde el comienzo.

3. Cuando esté listo, haga clic en Comenzar lab.

4. Anote las credenciales del lab (el nombre de usuario y la contraseña). Las usarás para acceder a la consola de Google Cloud.

5. Haga clic en Abrir Google Console.

6. Haga clic en Usar otra cuenta, copie las credenciales para este lab y péguelas en el mensaje emergente que aparece.
   Si usa otras credenciales, se generarán errores o incurrirá en cargos.

7. Acepta las condiciones y omite la página de recursos de recuperación.

Después de completar los pasos iniciales de acceso, aparecerá el panel del proyecto.

Activa Google Cloud Shell

Google Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud.

Google Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. En la consola de Cloud, en la barra de herramientas superior derecha, haz clic en el botón Abrir Cloud Shell.

   

2. Haz clic en Continuar.

El aprovisionamiento y la conexión al entorno demorarán unos minutos. Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. Por ejemplo:

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con el completado de línea de comando.

• Puedes solicitar el nombre de la cuenta activa con este comando:

gcloud auth list

Resultado:

Credentialed accounts: - @.com (active)

Resultado de ejemplo:

Credentialed accounts: - google1623327_student@qwiklabs.net

• Puedes solicitar el ID del proyecto con este comando:

gcloud config list project

Resultado:

[core] project =

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: La documentación completa de gcloud está disponible en la guía de descripción general de gcloud CLI .

Tarea 1: Conéctate al clúster de GKE del lab

En esta tarea, te conectarás al clúster de GKE del lab y clonarás su repositorio en el entorno de Cloud Shell correspondiente.

Conéctate al clúster de GKE del lab

1. En Cloud Shell, escribe el siguiente comando para establecer la variable de entorno para la zona y el nombre del clúster:

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

2. Configura el completado de línea de comando para la herramienta de línea de comandos de kubectl:

source <(kubectl completion bash)

3. Configura el acceso al clúster para kubectl:

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

4. En Cloud Shell, ingresa el siguiente comando para clonar el repositorio en el entorno de Cloud Shell del lab:

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

5. Crea un vínculo simbólico como un acceso directo al directorio de trabajo:

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

6. Cambia al directorio que contenga los archivos de muestra de este lab:

cd ~/ak8s/Probes/

Tarea 2: Configura los sondeos de funcionamiento

Configura un sondeo de funcionamiento

En esta tarea, implementarás un sondeo de funcionamiento para detectar aplicaciones que hayan pasado de un estado activo a uno con errores. A veces sucede que las aplicaciones no pueden entregar el tráfico temporalmente. Por ejemplo, una aplicación podría necesitar cargar grandes archivos de datos o de configuración durante el inicio.

En esos casos, no se recomienda forzar el cierre de la aplicación ni enviarle solicitudes. Kubernetes proporciona sondeos de preparación para detectar y mitigar estas situaciones. Si un Pod con contenedores informa que no está preparado, este no recibirá tráfico mediante los Services de Kubernetes.

Los sondeos de preparación se configuran de manera similar a los de funcionamiento. La única diferencia es que se usa el campo readinessProbe en vez del campo livenessProbe.

A ti se te proporcionó un archivo de definición de Pods llamado exec-liveness.yaml que define un contenedor sencillo llamado liveness. Este contenedor ejecuta Busybox y un sondeo de funcionamiento que usa el comando cat en el archivo /tmp/healthy dentro del contenedor para hacer una prueba de funcionamiento cada 5 segundos.

La secuencia de comandos de inicio para el contenedor liveness crea el archivo /tmp/healthy en el inicio y, 30 segundos más tarde, lo borra para simular una interrupción que puede detectar el sondeo de funcionamiento.

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. En Cloud Shell, ejecuta el siguiente comando para crear el Pod:

kubectl create -f exec-liveness.yaml

2. Después de 30 segundos, visualiza los eventos del Pod:

kubectl describe pod liveness-exec

El resultado indica que todavía no hubo errores en los sondeos de funcionamiento.

Resultado de muestra abreviado:

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

El resultado de muestra que se presenta aquí se resumió para una mayor legibilidad; verás muchos más detalles en la pantalla.

3. Después de 35 segundos, visualiza los eventos del Pod nuevamente:

kubectl describe pod liveness-exec

En la parte inferior del resultado, hay mensajes que indican que se produjeron errores en los sondeos de funcionamiento y que los contenedores se eliminaron y se volvieron a crear.

Resultado de muestra abreviado:

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. Espera otros 60 segundos y verifica que el contenedor se haya reiniciado:

kubectl get pod liveness-exec

En el resultado, el valor de RESTARTS indica que los reinicios aumentaron en respuesta al error detectado por el sondeo de funcionamiento:

Resultado de muestra:

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

5. Borra el Pod de demostración del sondeo de funcionamiento:

kubectl delete pod liveness-exec

Haz clic en Revisar mi progreso para verificar el objetivo. Configurar sondeos de funcionamiento

Tarea 3: Configura los sondeos de preparación

Si bien un Pod podría iniciarse con éxito y considerarse en buen estado a través de un sondeo de funcionamiento, es probable que no esté listo para recibir tráfico de inmediato. Esto es común en los Deployments que funcionan como backend para un Service como un balanceador de cargas. Un sondeo de preparación se usa para determinar cuándo un Pod y sus contenedores están listos para comenzar a recibir tráfico.

Los sondeos de preparación se configuran de manera similar a los de funcionamiento. La única diferencia es que debe utilizar el campo readinessProbe en vez de livenessProbe. Los sondeos de preparación controlan si un contenedor específico se considera listo, y los servicios utilizan esta información para decidir cuándo se puede enviar tráfico a un contenedor.

En esta tarea, se te proporcionó un archivo de definición de Pod llamado readiness-deployment.yaml que crea un solo Pod que funcionará como un servidor web de prueba junto con el balanceador de cargas.

Cada contenedor tiene un sondeo de preparación definido que utiliza el comando cat en el archivo /tmp/healthz dentro de dicho contenedor para hacer una prueba de preparación cada 5 segundos.

Cada contenedor también tiene un sondeo de funcionamiento definido que utiliza el comando cat en el mismo archivo dentro del contenedor para hacer una prueba de preparación cada 5 segundos, pero también tiene una demora en el inicio de 45 segundos para simular el comportamiento de aquellas aplicaciones que podrían tener un proceso de inicio complejo que tarde en estabilizarse tras el inicio del contenedor.

Una vez que el servicio haya comenzado a controlar el tráfico, este patrón garantiza que lo reenvíe solo a los contenedores que estén listos para recibirlo.

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. En Cloud Shell, ejecuta el siguiente comando para crear el Pod:

kubectl create -f readiness-deployment.yaml

2. En Cloud Shell, consulta el estado del servicio del balanceador de cargas readiness-demo-svc:

kubectl get service readiness-demo-svc

3. Ingresa la dirección IP en una ventana del navegador. Verás que aparecerá un mensaje de error que indica que no se puede acceder al sitio.

4. Verifica los eventos del Pod:

kubectl describe pod readiness-demo-pod

El resultado mostrará que el sondeo de preparación falló:

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 diferencia del sondeo de funcionamiento, un sondeo de preparación en mal estado no activa el reinicio del Pod.

5. Usa el siguiente comando para generar el archivo que busca el sondeo de preparación:

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

En la sección Conditions de la descripción del Pod, ahora debería aparecer True como el valor de Ready.

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

Resultado:

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

6. Ahora actualiza la pestaña del navegador que tenía la IP externa de readiness-demo-svc. Deberías ver correctamente el mensaje "Welcome to nginx!".

Configurar sondeos de preparación significativos para los contenedores de tu aplicación garantiza que los Pods solo reciban tráfico cuando estén listos para hacerlo. Un ejemplo de un sondeo de preparación considerable es verificar si la caché en la que se basa tu aplicación se carga durante el inicio.

Haz clic en Revisar mi progreso para verificar el objetivo. Configurar sondeos de preparación

Supervisa el comportamiento de los sondeos de funcionamiento y preparación

Ahora puedes verificar que los Pods de la implementación que se muestran como listos corresponden a los extremos que están activamente habilitados para tu servicio. Cuando los Pods no pasan las pruebas de sondeo de preparación y funcionamiento, sucede lo siguiente: se marcan como no listos, se quitan sus extremos del servicio, y el sondeo de funcionamiento comienza el proceso de reinicio para recuperar los Pods que no pasaron la prueba.

Los Pods reiniciados no se marcarán como listos de inmediato, sino que se debe esperar a que se ejecute la prueba de preparación antes de que el servicio vuelva a agregar el extremo a su grupo.

1. Ahora vuelve a verificar el estado de los Pods:

kubectl get pods

Ahora verás que los Pods individuales se muestran como listos. Según los tiempos, es posible que se reinicien uno o más de ellos, pero el proceso debería demorar 2 o 3 minutos. Los Pods que se marquen como listos deben tener el extremo correspondiente asociado con el servicio.

2. Para verificar que puedas conectarte a la aplicación, primero consulta la dirección IP externa en los detalles del servicio del balanceador de cargas y guárdala en una variable de entorno:

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

3. Verifica si la aplicación responde:

curl $EXTERNAL_IP

4. En el transcurso de los próximos minutos, repite los siguientes comandos cada unos 10 segundos para verificar el estado de la implementación y enviar una solicitud al balanceador de cargas:

curl $EXTERNAL_IP kubectl get pods

Deberías seguir viendo respuestas sin fallas o tiempos de espera, aun cuando los contenedores individuales se reinicien con regularidad debido a las fallas detectadas en los sondeos de funcionamiento. Si los tres contenedores se reinician más o menos al mismo tiempo, es posible que sigas viendo un tiempo de espera, pero es muy raro que eso suceda.

La combinación de los sondeos de funcionamiento y preparación permite garantizar que los sistemas con errores se reinicien de forma segura mientras el servicio solo reenvía el tráfico a los contenedores con una capacidad de respuesta comprobada.

Finalice su lab

Cuando haya completado el lab, haga clic en Finalizar lab. Google Cloud Skills Boost quitará los recursos que usó y limpiará la cuenta.

Tendrá la oportunidad de calificar su experiencia en el lab. Seleccione la cantidad de estrellas que corresponda, ingrese un comentario y haga clic en Enviar.

La cantidad de estrellas indica lo siguiente:

• 1 estrella = Muy insatisfecho
• 2 estrellas = Insatisfecho
• 3 estrellas = Neutral
• 4 estrellas = Satisfecho
• 5 estrellas = Muy satisfecho

Puede cerrar el cuadro de diálogo si no desea proporcionar comentarios.

Para enviar comentarios, sugerencias o correcciones, use la pestaña Asistencia.

Copyright 2020 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.