arrow_back

Usando Cloud Trace en Kubernetes Engine

Unirse Acceder

Usando Cloud Trace en Kubernetes Engine

1 hora 5 créditos

GSP484

Labs de autoaprendizaje de Google Cloud

Descripción general

Cuando se brinda asistencia a un sistema de producción que proporciona servicios de solicitudes HTTP o proporciona una API, es importante medir la latencia de sus 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 el comportamiento en deterioro. 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 rendimiento en deterioro 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 el comportamiento lento en el extremo público con un subservicio particular con un mal comportamiento.

Ingrese el seguimiento distribuido. El seguimiento distribuido utiliza metadatos que pasan junto con solicitudes para correlacionarlas en los niveles de servicio. Mediante 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 más fácil qué servicio está causando las demoras que afectan al resto del sistema.

Google Cloud proporciona el conjunto de productos de Operations para controlar el registro, la supervisión y el seguimiento distribuido. En este lab, implementará en Kubernetes Engine y verá 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 brindarle una mejor comprensión de la autorización binaria de GKE. Puede ver esta demostración ejecutando el comando gsutil cp -r gs://spls/gke-binary-auth/* . y cd gke-binary-auth-demo en cloud shell. Invitamos a todos a contribuir con nuestros recursos.

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á a la solicitud de 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.

architecture.png

Configuración

Antes de hacer clic en el botón Comenzar lab

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

Este lab práctico de Qwiklabs le permitirá llevar a cabo las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, le proporciona credenciales temporales nuevas que utilizará para acceder a Google Cloud durante todo el lab.

Qué necesita

Para completar este lab, necesitará lo siguiente:

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

Nota: Si ya tiene un proyecto o una cuenta personal de Google Cloud, no los use para este lab.

Nota: Si usa un dispositivo con Chrome OS, ejecute este lab en una ventana de incógnito.

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. Ícono del menú de navegación

Active Google Cloud Shell

Google Cloud Shell es una máquina virtual que cuenta con herramientas de desarrollo. 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 sus recursos de GCP.

  1. En GCP Console, en la barra de herramientas superior derecha, haga clic en el botón Abrir Cloud Shell.

    Ícono de Cloud Shell

  2. Haga clic en Continue (Continuar):

    cloudshell_continue

Toma unos minutos aprovisionar y conectarse con el entorno. Cuando está conectado, ya está autenticado y el proyecto está configurado en su PROJECT_ID . Por ejemplo:

Terminal de Cloud Shell

gcloud es la herramienta de línea de comandos para Google Cloud Platform. Viene preinstalada en Cloud Shell y es compatible con la función “tab-completion”.

Puede mostrar el nombre de la cuenta activa con este comando:

gcloud auth list

Resultado:

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

Puede mostrar el ID del proyecto con este comando:

gcloud config list project
	

Resultado:

[core]
project = <project_ID>
	

Resultado de ejemplo:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

Clone la demostración

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

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

Vaya al directorio de esta demostración:

cd gke-tracing-demo

Configure su 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 puede ejecutar sus recursos. Cada región tiene una o más zonas.

Ejecute el siguiente comando a fin de configurar una región y zona para su lab (puede usar la región/zona más adecuada para su caso):

gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

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 API de Google Cloud para proporcionar y actualizar los recursos con el fin de 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 compilar proyectos de Google Cloud y también 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á los comandos de Kubernetes para implementar una aplicación de demostración en el clúster. De manera predeterminada, los clústeres de Kubernetes Engine en Google Cloud se inician con un colector preconfigurado basado en Fluentd que reenvía los eventos de registro del clúster hacia 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.

Cómo ejecutar 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 características 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 y versión de la nube 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 dará como resultado mensajes al usuario en el entorno de ejecución.

Inicialización

Dado que la autenticación se configuró anteriormente, ahora está listo para implementar la infraestructura.

Ejecute el siguiente comando desde el directorio raíz del proyecto:

cd terraform

Actualice el archivo provider.tf

Elimine la version del proveedor para el Terraform desde el archivo script provider.tf.

Edite el archivo script provider.tf

nano provider.tf

Si el archivo contiene una cadena de version estática para el proveedor google como se indica a continuación, elimínelo

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

Luego guarde el archivo con CTRL+X > Y > Enter

Después de modificar su archivo script provider.tf este se vera así:

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

Desde aquí, inicialice Terraform:

Ingrese el siguiente comando:

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 sabe. 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 un archivo terraform.tfvars. Ejecute el siguiente comando:

../scripts/generate-tfvars.sh

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

Si los valores mostrados no se corresponden con el lugar en el que desea ejecutar la aplicación de demostración, cambie los valores en terraform.tfvars a los que prefiera.

Implementación

Una vez que inicialice Terraform, puede 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 le informará si detecta algún error. Si bien no es necesario, se recomienda ejecutarlo siempre antes de cambiar la infraestructura con Terraform.

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

terraform apply

Se muestran los cambios que se realizarán y se le pide que confirme con yes.

Mientras espera que se complete su compilación, configure el espacio de trabajo de Cloud Monitoring para usar más adelante en el lab.

Pruebe la tarea completada

Haga clic en Revisar mi progreso para verificar la tarea que realizó. Si ha implementado exitosamente infraestructura usando Terraform, verá un puntaje de evaluación.

Use Terraform para configurar la infraestructura necesaria

Cree un lugar de trabajo de Monitoring

Ahora configure un lugar de trabajo de Monitoring que esté vinculado con su proyecto de Google Cloud. Siga estos pasos para crear una cuenta nueva que incluya una prueba gratuita de Monitoring.

  1. En Cloud Console, haga clic en Menú de navegación > Monitoring.

  2. Cuando se abre la página Descripción general, su proyecto de alcance de métricas está listo.

MonitoringWindow.png

Implemente la aplicación de demostración

Vuelva a Cloud Shell, después de ver el mensaje Apply complete! y regrese a la consola. En el menú de navegación, vaya a Kubernetes Engine > Clústeres para ver su clúster.

Haga clic en el menú de navegación, luego desplácese hacia abajo hasta la sección de análisis y haga clic en Pub/Sub para ver el tema y la suscripción.

Ahora, implemente la aplicación de demostración mediante 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 puede ver el balanceador de cargas que se creó para la aplicación en la sección Ingress y servicios de la consola.

La aplicación puede tardar unos minutos en implementarse. Si su consola de cargas de trabajo le muestra un estado parecido a este "Does not have minimum availability":

minimum-availability.png

Actualice la página hasta que vea un "OK" en la barra de estado.

workload-running.png

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

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

Pruebe la tarea completada

Haga clic en Revisar mi progreso para verificar la tarea que realizó. Si ha implementado exitosamente la aplicación de demostración, verá un puntaje de evaluación.

Implemente la aplicación de demostración

Validación

Cómo generar datos de telemetría

Una vez implementada la aplicación de demostración, debería ver una lista de sus servicios expuestos. Aún en la ventana de Kubernetes, haga clic en Ingress y servicios para ver los servicios expuestos.

services-ui.png

Haga 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 su navegador. Tenga en cuenta que su dirección IP probablemente será diferente a la del ejemplo anterior. La página que se muestra es simple:

hello-world-browser.png

Agregue la string ?string=CustomMessage a la URL y verifique que se muestre el siguiente mensaje:

custom-message-browser.png

Como puede 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. Reemplace ‟CustomMessage” con sus propios mensajes para generar algunos datos de análisis.

Pruebe la tarea completada

Haga clic en Revisar mi progreso para verificar la tarea que realizó. Si ha generado exitosamente datos Telemetry, verá un puntaje de evaluación.

Genere datos Telemetry

Cómo examinar los seguimientos

En la consola, seleccione Menú de Navegación > Trace > Lista de seguimiento. Debería ver un gráfico que muestra los eventos de seguimiento trazados en un cronograma con la latencia como la métrica vertical.

Haga clic en el botón de alternar Volver a cargar automáticamente para ver los datos más actualizados.

trace-ui.png

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

span-ui-full.png

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, está claro 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 su aplicación, puede identificar fácilmente dónde están los cuellos de botella.

Cómo extraer mensajes de Pub/Sub

Como se describe en la sección de 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.

Cómo supervisar y registrar

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

En la consola, seleccione Menú de navegación > Monitoring > Explorador de métricas.

En el campo Seleccionar una métrica, seleccione VM Instance > Instance > CPU Usage y luego haga clic en Aplicar.

Debería ver un gráfico de esa métrica trazada para ver diferentes pods que se ejecutan en el cluster.

metric-select.jpg

Para ver los registros, seleccione Menú de navegación > logging.

En la sección Campos de registro, configure lo siguiente:

  • RESOURCE TYPE: Kubernetes Container
  • CLUSTER NAME: tracing-demo-space
  • NAMESPACE NAME: default

logs-fields-results.jpg

Cómo solucionar problemas en su propio entorno

Se pueden diagnosticar varios errores posibles mediante el comando de 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

Puede encontrar 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

Anote el nombre del pod, para que lo use en el siguiente paso.

Una vez que se conoce el nombre del pod, los registros se pueden ver 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úrese de que la cuenta detallada en gcloud config list tenga los permisos necesarios para crear recursos. Si los tiene, vuelva a generar las credenciales predeterminadas de la aplicación mediante gcloud auth application-default login.

Desmontaje

Qwiklabs se encargará de cerrar todos los recursos utilizados en este lab, pero esto es lo que debe hacer para limpiar su propio entorno a fin de reducir los costos y ser un buen ciudadano de la nube:

terraform destroy

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

Dado que Terraform realiza un seguimiento de los recursos que creó, podrá desmontar el clúster, el tema y la suscripción de Pub/Sub.

Felicitaciones

CloudOpsGKE_125x135.png

Finalice su Quest

Este lab de autoaprendizaje forma parte de la Quest Paquete de operaciones de Google Cloud en GKE de Qwiklabs. Una Quest es una serie de labs relacionados que forman una ruta de aprendizaje. Si completa esta Quest, obtendrá la insignia que se muestra arriba como reconocimiento de su logro. Puede hacer públicas sus insignias y agregar vínculos a ellas en su currículum en línea o en sus cuentas de redes sociales. Inscríbase en esta Quest y obtenga un crédito inmediato de finalización si realizó este lab. Consulte otras Quests de Qwiklabs disponibles.

Realice su próximo lab

Continúe su Quest con Cloud Logging on Kubernetes Engine, o consulte estas sugerencias:

Próximos pasos/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 marco de trabajo popular Spring. Spring Sleuth admite una abstracción de los colectores 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 conjunto de herramientas en Google Cloud que proporciona registro, supervisión, seguimiento y funciones relacionadas. Este documento y la demostración tratan especialmente sobre 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 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 mediante el uso de 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.

Finalice su lab

Cuando haya completado su lab, haga clic en End Lab. Qwiklabs quitará los recursos que usó y limpiará la cuenta por usted.

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

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

Última actualización del manual: 21 de marzo de 2022
Prueba más reciente del lab: 21 de marzo de 2022

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