
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
Use Terraform to set up the necessary infrastructure
/ 50
Deploy demo application
/ 25
Generate Telemetry Data
/ 25
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.
Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, 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:
Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá un diálogo para que selecciones la forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:
Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).
El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.
Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.
De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.
También puedes encontrar el nombre de usuario en el panel Detalles del lab.
Haz clic en Siguiente.
Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.
También puedes encontrar la contraseña en el panel Detalles del lab.
Haz clic en Siguiente.
Haz clic para avanzar por las páginas siguientes:
Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.
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.
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:
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.
Haz clic en Autorizar.
Ahora, el resultado debería verse de la siguiente manera:
Resultado:
Resultado:
Resultado de ejemplo:
gcloud
, consulta la guía con la descripción general de gcloud CLI en Google Cloud.
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.
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):
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.
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.
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.
Dado que la autenticación se configuró anteriormente, ya puedes implementar la infraestructura.
Quita la versión del proveedor de Terraform del archivo de secuencia de comandos provider.tf
.
provider.tf
:google
como la que se muestra a continuación, quítala:Después de la modificación, el archivo de secuencia de comandos provider.tf
debería verse así:
Desde aquí, inicializa Terraform:
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
.
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:
terraform.tfvars
por los que prefieras.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.
Se muestran los cambios que se realizarán y se te pide que confirmes con yes
.
Mientras esperas que se complete tu compilación, configura el espacio de trabajo de Cloud Monitoring para usar más adelante en el lab.
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.
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.
Cuando se abra la página de Descripción general de Monitoring, tu proyecto de permisos de métricas estará listo.
En Cloud Shell, cuando veas el mensaje Apply complete!
, vuelve a la consola.
En Menú de navegación, dirígete a Kubernetes Engine > Clústeres para ver tu clúster.
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.
Ahora, implementa la aplicación de demostración con el comando de kubectl
de Kubernetes:
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":
Por cierto, el extremo se puede adquirir de manera programática con el siguiente comando:
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.
Una vez implementada la aplicación de demostración, deberías ver una lista de tus servicios expuestos.
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:
?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.
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.
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.
Haz clic en el botón de activación Volver a cargar automáticamente para ver los datos más recientes.
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.
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
:
Resultado:
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.
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.
En la consola, selecciona Menú de navegación > Supervisión > Explorador de métricas.
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:
Para ver los registros, selecciona Menú de navegación > Logging.
En la sección Campos de registro, configura los siguientes parámetros:
Kubernetes Container
tracing-demo-space
default
Se pueden diagnosticar varios errores posibles con el comando kubectl
.
Por ejemplo, se puede mostrar una implementación:
Resultado:
Puedes obtener más información con describe
:
Este comando mostrará una lista de pods implementados:
Resultado:
Una vez más, los detalles del pod se pueden ver con describe
:
Toma nota del nombre del Pod para usarlo en el próximo paso.
Una vez que sepas el nombre del Pod, usa ese nombre para ver los registros de forma local:
Resultado:
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
.
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.
Los siguientes son algunos materiales relevantes para realizar una mayor investigación:
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 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 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.
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 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 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:
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.
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:
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.
Este contenido no está disponible en este momento
Te enviaremos una notificación por correo electrónico cuando esté disponible
¡Genial!
Nos comunicaremos contigo por correo electrónico si está disponible
One lab at a time
Confirm to end all existing labs and start this one