GSP484

Descripción general

Cuando se admite un sistema de producción que entrega solicitudes HTTP o proporciona una API, es importante medir la latencia de tus extremos para detectar cuándo el rendimiento de un sistema no funciona según las especificaciones. En los sistemas monolíticos, esta única medida de latencia puede ser útil para detectar y diagnosticar un comportamiento que se va deteriorando. No obstante, con las arquitecturas de microservicio modernas, esto resulta mucho más difícil porque una sola solicitud puede dar lugar a numerosas solicitudes adicionales a otros sistemas antes de que la solicitud pueda controlarse por completo.

El deterioro del rendimiento en un sistema subyacente puede afectar a todos los demás sistemas que dependen de él. Si bien la latencia se puede medir en cada extremo del servicio, puede resultar difícil correlacionar un comportamiento lento en el extremo público con un determinado subservicio que tiene un mal comportamiento.

Comienza a usar el seguimiento distribuido. El seguimiento distribuido utiliza metadatos que se pasan junto con las solicitudes para correlacionarlas en los diferentes niveles de servicio. Por medio de la recopilación de datos de telemetría de todos los servicios en una arquitectura de microservicio y la propagación de un ID de seguimiento desde una solicitud inicial hasta todas las solicitudes secundarias, los desarrolladores pueden identificar de forma mucho más fácil qué servicio está causando las demoras que afectan al resto del sistema.

Google Cloud proporciona el operations suite, un paquete de productos para controlar el registro, la supervisión y el seguimiento distribuido. El contenido de este lab se implementará en Kubernetes Engine y se demostrará una arquitectura de varios niveles que implementa el seguimiento distribuido. También aprovechará Terraform para compilar la infraestructura necesaria.

Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor la autorización binaria de GKE. Para ver esta demostración, ejecuta los comandos gsutil cp -r gs://spls/gke-binary-auth/* . y cd gke-binary-auth-demo en Cloud Shell. Te invitamos a hacer cualquier aporte que creas conveniente.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar su lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab que tiene estos elementos:

   • El botón Abrir la consola de Google
   • Tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haga clic en Abrir la consola de Google. El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ve el diálogo Elegir una cuenta, haga clic en Usar otra cuenta.

3. Si es necesario, copie el nombre de usuario del panel Detalles del lab y péguelo en el cuadro de diálogo Acceder. Haga clic en Siguiente.

4. Copie la contraseña del panel Detalles del lab y péguela en el cuadro de diálogo de bienvenida. Haga clic en Siguiente.

   Importante: Debe usar las credenciales del panel de la izquierda. No use sus credenciales de Google Cloud Skills Boost. Nota: Usar su propia Cuenta de Google podría generar cargos adicionales.

5. Haga clic para avanzar por las páginas siguientes:

   • Acepte los términos y condiciones.
   • No agregue opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No se registre para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Cloud en esta pestaña.

Nota: Para ver el menú con una lista de los productos y servicios de Google Cloud, haga clic en el Menú de navegación que se encuentra en la parte superior izquierda de la pantalla.

Activa Cloud Shell

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. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. El resultado contiene una línea que declara el PROJECT_ID para esta sesión:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

Clona la demostración

1. Ejecuta el siguiente comando para clonar los recursos que se necesitarán en este lab:

git clone https://github.com/GoogleCloudPlatform/gke-tracing-demo

2. Dirígete al directorio de esta demostración:

cd gke-tracing-demo

Configura tu región y zona

Algunos recursos de Compute Engine se encuentran en regiones y zonas. Una región es una ubicación geográfica específica donde puedes ejecutar tus recursos. Cada región tiene una o más zonas.

Para obtener más información sobre las regiones y zonas y ver una lista de todas ellas, consulta esta documentación.

Ejecuta el siguiente comando para configurar una región y zona para tu lab (puedes usar la región/zona más adecuada para tu caso):

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

Arquitectura

El lab comienza con la implementación de un clúster de Kubernetes Engine. En este clúster, se implementará una aplicación web simple encabezada por un balanceador de cargas. La aplicación web publicará los mensajes que proporciona el usuario en un tema de Cloud Pub/Sub. La aplicación está instrumentada de tal manera que las solicitudes HTTP que recibe darán lugar a la creación de un seguimiento cuyo contexto se propagará en la solicitud a la API de publicación de Cloud Pub/Sub. Los datos de telemetría correlacionados de estas solicitudes estarán disponibles en la consola de Cloud Trace.

Introducción a Terraform

De acuerdo con los principios de la infraestructura como código y de la infraestructura inmutable, Terraform admite escrituras de descripciones declarativas del estado deseado de la infraestructura. Cuando se aplica el descriptor, Terraform usa las APIs de Google Cloud para aprovisionar y actualizar los recursos para que coincidan. Terraform compara el estado deseado con el estado actual para poder realizar cambios incrementales sin tener que borrar todo y volver a empezar. Por ejemplo, Terraform puede crear proyectos de Google Cloud, instancias de procesamiento, etc., incluso configurar un clúster de Kubernetes Engine y, luego, implementar aplicaciones en él. Cuando los requisitos cambian, el descriptor se puede actualizar, y Terraform ajustará la infraestructura de nube según corresponda.

En este ejemplo, se iniciará un clúster de Kubernetes Engine con Terraform. Luego, utilizarás los comandos de Kubernetes para implementar una aplicación de demostración en el clúster. De forma predeterminada, los clústeres de Kubernetes Engine en Google Cloud se lanzan con un colector preconfigurado basado en Fluentd que reenvía los eventos de registro del clúster a Cloud Monitoring. La interacción con la aplicación de demostración producirá eventos de seguimiento que se verán en la IU de Cloud Trace.

Ejecuta Terraform

Hay tres archivos de Terraform que se proporcionan con esta demostración, ubicados en el subdirectorio /terraform del proyecto. El primer archivo, main.tf, es el punto de partida de Terraform. Describe las funciones que se utilizarán, los recursos que se manipularán y los resultados que se obtendrán. El segundo archivo es provider.tf, que indica qué proveedor de servicios en la nube y qué versión serán los destinatarios de los comandos de Terraform, en este caso, Google Cloud. El último archivo es variables.tf, que contiene una lista de variables que se usan como entradas en Terraform. Cualquier variable a la que se haga referencia en main.tf que no tenga valores predeterminados configurados en variables.tf tendrá como resultado mensajes al usuario en el entorno de ejecución.

Tarea 1: Inicialización

Dado que la autenticación se configuró anteriormente, ya puedes implementar la infraestructura.

• Ejecuta el siguiente comando desde el directorio raíz del proyecto:

cd terraform

Actualiza el archivo provider.tf

Quita la versión del proveedor de Terraform del archivo de secuencia de comandos provider.tf.

1. Edita el archivo de secuencia de comandos provider.tf:

nano provider.tf

2. Si el archivo contiene una cadena de versión estática para el proveedor google como la que se muestra a continuación, quítala:

.... provider "google" { project = var.project version = "~> 2.10.0" }

3. Guarda el archivo con CTRL + X > Y > Intro.

Después de la modificación, el archivo de secuencia de comandos provider.tf debería verse así:

... provider "google" { project = var.project }

Desde aquí, inicializa Terraform:

4. Ingresa lo siguiente:

terraform init

Esto descargará las dependencias que Terraform requiere: el proyecto de Google Cloud y la zona de Google Cloud en la que se debe implementar la aplicación de demostración. Terraform solicitará estos valores si todavía no los conoce. De forma predeterminada, buscará un archivo llamado terraform.tfvars o archivos con un sufijo .auto.tfvars en el directorio actual para obtener esos valores.

Esta demostración proporciona una secuencia de comandos conveniente para solicitar la zona y el proyecto, y mantenerlos en el archivo terraform.tfvars.

5. Ejecuta lo siguiente:

../scripts/generate-tfvars.sh Nota: Recibirás un mensaje de error si el archivo ya existe.

La secuencia de comandos usa valores previamente configurados del comando de gcloud. Si no se configuraron, el mensaje de error indicará cómo deben configurarse. Los valores existentes se pueden ver con el siguiente comando:

gcloud config list

6. Si los valores mostrados no se corresponden con el lugar en el que deseas ejecutar la aplicación de demostración, cambia los valores en terraform.tfvars por los que prefieras.

Tarea 2: Implementación

1. Una vez que inicialices Terraform, puedes ver el trabajo que Terraform realizará con el siguiente comando:

terraform plan

Este comando se puede usar para verificar visualmente que la configuración es correcta, y Terraform te informará si detecta algún error. Si bien no es necesario, se recomienda ejecutarlo siempre antes de cambiar la infraestructura con Terraform.

2. Después de la verificación, indícale a Terraform que configure la infraestructura necesaria:

terraform apply

Se muestran los cambios que se realizarán y se te pide que confirmes con yes.

Nota: Si recibes advertencias de baja relacionadas con la variable de zona, ignóralas y avanza en el lab.

Mientras esperas que se complete tu compilación, configura el espacio de trabajo de Cloud Monitoring para usar más adelante en el lab.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente la infraestructura necesaria con Terraform, verás una puntuación de evaluación.

Usar Terraform para configurar la infraestructura necesaria

Crea un permiso de métricas de Monitoring

Configura un permiso de métricas de Monitoring que esté vinculado a tu proyecto de Google Cloud. Sigue estos pasos para crear una cuenta nueva que incluya una prueba gratuita de Monitoring.

• En la consola de Cloud, haz clic en Menú de navegación () > Monitoring.

Cuando se abra la página de Descripción general de Monitoring, tu proyecto de permisos de métricas estará listo.

Tarea 3: Implementa la aplicación de demostración

1. En Cloud Shell, cuando veas el mensaje Apply complete!, vuelve a la consola.

2. En Menú de navegación, dirígete a Kubernetes Engine > Clústeres para ver tu clúster.

3. Haz clic en Menú de navegación, luego desplázate hacia abajo hasta la sección Estadísticas y haz clic en Pub/Sub para ver el tema y la suscripción.

4. Ahora, implementa la aplicación de demostración con el comando de kubectl de Kubernetes:

kubectl apply -f tracing-demo-deployment.yaml

Una vez que la aplicación se implementó, se puede ver en Kubernetes Engine > Cargas de trabajo. También puedes ver el balanceador de cargas que se creó para la aplicación en la sección Ingress y servicios de la consola.

Es posible que la aplicación demore unos minutos en implementarse. Si la consola de tus cargas de trabajo se parece a la siguiente y tiene el estado "No tiene disponibilidad mínima":

5. Actualiza la página hasta que veas "OK" o "Sin errores" en la barra de estado.

Por cierto, el extremo se puede adquirir de manera programática con el siguiente comando:

echo http://$(kubectl get svc tracing-demo -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente la aplicación de demostración, verás una puntuación de evaluación.

Implementar la aplicación de demostración

Tarea 4: Validación

Genera datos de telemetría

Una vez implementada la aplicación de demostración, deberías ver una lista de tus servicios expuestos.

1. En la ventana de Kubernetes, haz clic en Ingress y servicios para ver los servicios expuestos.

2. Haz clic en el extremo que se encuentra al lado del balanceador de cargas tracing-demo para abrir la página web de la aplicación de demostración en una pestaña nueva de tu navegador.

Ten en cuenta que tu dirección IP probablemente será diferente a la del ejemplo anterior. La página que se muestra es simple:

3. Agrega la cadena ?string=CustomMessage a la URL y observa que se muestra el mensaje:

Como puedes ver, si no se proporciona un parámetro string, utiliza el valor predeterminado Hello World. La aplicación se utiliza para generar datos de telemetría de seguimiento.

4. Reemplaza ‟CustomMessage” por tus propios mensajes para generar algunos datos de análisis.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si generaste los datos de telemetría correctamente, verás una puntuación de evaluación.

Generar datos de telemetría

Examina los seguimientos

1. En la consola, selecciona Menú de navegación > Trace > Explorador de seguimiento. Deberías ver un gráfico que muestra los eventos de seguimiento trazados en un cronograma con la latencia como métrica vertical.

2. Haz clic en el botón de activación Volver a cargar automáticamente para ver los datos más recientes.

Nota: Selecciona los puntos para expandir la vista.

3. Haz clic en uno de los puntos en el gráfico. Verás un gráfico con dos barras, en el que la barra superior es más larga que la inferior.

La barra superior se conoce como el intervalo raíz y representa la duración de la solicitud HTTP, desde el momento en que llega el primer byte hasta el momento en que se envía el último byte de la respuesta. La barra inferior representa la duración de la solicitud que se realiza cuando se envía el mensaje al tema de Pub/Sub.

Dado que el control de la solicitud HTTP está bloqueado por la llamada a la API de Pub/Sub, resulta evidente que la gran mayoría del tiempo dedicado a la solicitud HTTP está ocupado por la interacción de Pub/Sub. Esto demuestra que, cuando se instrumenta cada nivel de tu aplicación, puedes identificar fácilmente dónde están los cuellos de botella.

Extrae mensajes de Pub/Sub

Como se describe en la sección Arquitectura en este documento, los mensajes de la aplicación de demostración se publican en un tema de Pub/Sub.

Estos mensajes se pueden consumir desde el tema con la CLI de gcloud:

gcloud pubsub subscriptions pull --auto-ack --limit 10 tracing-demo-cli

Resultado:

DATA: Hello World MESSAGE_ID: 4117341758575424 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT: DATA: CustomMessage MESSAGE_ID: 4117243358956897 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT:

Extraer los mensajes del tema no tiene ningún impacto en el seguimiento. En esta sección, simplemente se proporciona un consumidor de los mensajes para fines de verificación.

Supervisión y registro

La supervisión y el registro de Cloud no son el tema de esta demostración, pero vale la pena señalar que la aplicación que implementaste publicará los registros en Cloud Logging y las métricas en Cloud Monitoring.

1. En la consola, selecciona Menú de navegación > Supervisión > Explorador de métricas.

2. En el campo Selecciona una métrica, selecciona Instancia de VM > Instancia > Uso de CPU y, luego, haz clic en Aplicar.

Deberías ver un gráfico de esta métrica trazado para diferentes pods que se ejecutan en el clúster:

3. Para ver los registros, selecciona Menú de navegación > Logging.

4. En la sección Campos de registro, configura los siguientes parámetros:

• TIPO DE RECURSO: Kubernetes Container
• NOMBRE DEL CLÚSTER: tracing-demo-space
• NOMBRE DEL ESPACIO DE NOMBRES: default

Tarea 5: Soluciona problemas en tu propio entorno

Se pueden diagnosticar varios errores posibles con el comando kubectl. Por ejemplo, se puede mostrar una implementación:

kubectl get deployment tracing-demo

Resultado:

NAME READY UP-TO-DATE AVAILABLE AGE tracing-demo 1/1 1 1 21m

Puedes obtener más información con describe:

kubectl describe deployment tracing-demo

Este comando mostrará una lista de pods implementados:

kubectl get pod

Resultado:

NAME READY STATUS RESTARTS AGE tracing-demo-59cc7988fc-h5w27 1/1 Running 0 23m

Una vez más, los detalles del pod se pueden ver con describe:

kubectl describe pod tracing-demo

1. Toma nota del nombre del Pod para usarlo en el próximo paso.

2. Una vez que sepas el nombre del Pod, usa ese nombre para ver los registros de forma local:

kubectl logs <LOG_NAME>

Resultado:

10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "HEAD / HTTP/1.0" 200 - "-" "-" Publishing string: Hello World 10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "GET / HTTP/1.1" 200 669 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

La secuencia de comandos de instalación falla con Permission denied cuando se ejecuta Terraform. Las credenciales que utiliza Terraform no proporcionan los permisos necesarios para crear recursos en los proyectos seleccionados. Asegúrate de que la cuenta detallada en gcloud config list tenga los permisos necesarios para crear recursos. Si los tiene, vuelve a generar las credenciales predeterminadas de la aplicación con gcloud auth application-default login.

Tarea 6: Eliminación

• Qwiklabs se encargará de cerrar todos los recursos utilizados en este lab, pero esto es lo que debes hacer para limpiar tu propio entorno y así reducir los costos y ser un buen ciudadano de la nube:

terraform destroy

Al igual que con apply, Terraform solicitará un yes para confirmar tu intención.

Dado que Terraform realiza un seguimiento de los recursos que creaste, puedes eliminar el clúster, el tema de Pub/Sub y la suscripción de Pub/Sub.

Nota: Si aparecen advertencias de baja relacionadas con la variable de zona, ignóralas.

¡Felicitaciones!

Próximos pasos y más información

Los siguientes son algunos materiales relevantes para realizar una mayor investigación:

Kubernetes

Kubernetes es una plataforma de organización de contenedores popular en las arquitecturas de microservicio. Google Cloud proporciona una versión administrada de Kubernetes llamada Kubernetes Engine.

OpenCensus

OpenCensus proporciona bibliotecas estandarizadas para capturar y publicar datos de telemetría de seguimiento. Se proporcionan bibliotecas para varios lenguajes populares y se admiten numerosas plataformas de seguimiento, como Cloud Monitoring y Zipkin. La demostración que se describe en este documento utiliza OpenCensus para publicar datos de telemetría en Cloud Monitoring.

Spring Sleuth

Spring Sleuth brinda instrumentación de aplicaciones Java que usan el framework popularSpring. Spring Sleuth admite una abstracción de los recopiladores de telemetría de seguimiento distribuidos para que los desarrolladores puedan cambiar sin problemas entre Zipkin, Cloud Monitoring y otros motores de seguimiento.

Cloud Monitoring

Operations es un paquete de productos en Google Cloud que ofrece funciones de registro, supervisión, seguimiento y otras relacionadas. Este documento y la demostración se enfocan especialmente en la función que Cloud Trace proporciona.

Terraform

Terraform es una herramienta declarativa de infraestructura como código que habilita que los archivos de configuración se puedan usar en la automatización de la implementación y de la evolución de la infraestructura en la nube.

Zipkin

Zipkin es una herramienta de seguimiento distribuido que ayudó a popularizar la práctica.

Las aplicaciones que ya están instrumentadas para Zipkin pueden adaptar sus datos de telemetría de Zipkin a los eventos de Cloud Monitoring con un recopilador de Zipkin. Se puede implementar en Kubernetes Engine:

kubectl run stackdriver-zipkin --image=gcr.io/stackdriver-trace-docker/zipkin-collector --expose --port=9411

Esto implementará el recopilador en el conocido puerto 9411 de Zipkin y las aplicaciones que lo buscan en su puerto local lo encontrarán idéntico desde un servidor Zipkin, pero los datos de telemetría aparecerán en Cloud Trace.

Finaliza el lab

Cuando completes el lab, haz clic en Finalizar lab. Tu cuenta y los recursos que usaste se quitaron de la plataforma del lab.

Tendrás la oportunidad de calificar tu experiencia en el lab. Selecciona la cantidad de estrellas que corresponda, ingresa un comentario y haz 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

Puedes cerrar el cuadro de diálogo si no deseas proporcionar comentarios.

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

Actualización más reciente del manual: 28 de septiembre de 2023

Prueba más reciente del lab: 28 de septiembre de 2023

Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.