GSP736

Descripción general

Cloud Logging y su herramienta complementaria, Cloud Monitoring, son productos con funciones completas y profundamente integrados a Google Kubernetes Engine (GKE). En este lab, aprenderás cómo funciona Cloud Logging con aplicaciones y clústeres de GKE, además de algunas prácticas recomendadas para recopilar registros a través de casos de uso comunes.

Objetivos

En este lab, aprenderás a realizar las siguientes tareas:

• Usar Cloud Monitoring para detectar problemas
• Usar Cloud Logging para solucionar problemas de una aplicación activa en GKE

La aplicación de demostración que se usa en el lab

Para usar un ejemplo concreto, solucionarás problemas de una app de demostración de microservicios de muestra implementada en un clúster de GKE. En esta app de demostración, hay muchos microservicios y dependencias entre ellos. Generarás tráfico con un creador de cargas y, luego, usarás Logging, Monitoring y GKE para encontrar el error (alerta o métricas), identificar la causa raíz con Logging y, por último, corregir o confirmar que el problema se haya solucionado con Logging y Monitoring.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

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:

• Acceso a un navegador de Internet estándar. Se recomienda el navegador Chrome.

Nota: Usa una ventana del navegador privada o de incógnito (opción recomendada) para ejecutar el lab. Así evitarás conflictos 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: Usa solo la cuenta de estudiante para este lab. Si usas otra cuenta de Google Cloud, es posible que se apliquen cargos a esa cuenta.

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

1. 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 derecha, se encuentra el panel Configuración del lab y acceso, que tiene los siguientes elementos:

   • El botón Abrir la consola de Google Cloud
   • Las credenciales temporales (nombre de usuario y contraseña) que debes usar para este lab
   • Otra información para completar el lab (si es necesaria)

   Ten en cuenta que el cronómetro del lab se encuentra cerca de la parte superior de la página y muestra el tiempo restante.

2. 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 los 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.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usa otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Configuración del lab y acceso.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Configuración del lab y acceso.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia cuenta de Google Cloud para este lab podría generar cargos adicionales.

7. Haz clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación ni autenticación de dos factores, ya que esta cuenta es temporal.
   • No te registres para obtener pruebas gratuitas.

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

Nota: Para acceder a los productos y servicios de Google Cloud, haz clic en el menú de navegación o escribe el nombre del servicio o producto en el campo Buscar.

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.

2. Haz clic para avanzar por las siguientes ventanas:

   • Continúa en la ventana de información de Cloud Shell.
   • Autoriza a Cloud Shell para que use tus credenciales para realizar llamadas a la API 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 {{{project_0.project_id | "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.

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

gcloud auth list

4. Haz clic en Autorizar.

Resultado:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} 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_0.project_id | "PROJECT_ID"}}} Nota: Para obtener toda la documentación de gcloud, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.

Tarea 1: Configura la infraestructura

Conéctate a un clúster de Google Kubernetes Engine y verifica que se haya creado correctamente.

1. Usa el siguiente comando para ver el estado del clúster:

gcloud container clusters list

El estado del clúster será PROVISIONING.

2. Espera un momento y vuelve a ejecutar el comando anterior hasta que el estado cambie a RUNNING. Este proceso puede tardar varios minutos.

3. Verifica si se creó el clúster llamado central.

También puedes supervisar el progreso en la consola de Cloud dirigiéndote al menú de navegación > Kubernetes Engine > Clústeres.

4. Cuando el clúster tenga el estado RUNNING, ejecuta el siguiente comando para obtener sus credenciales:

gcloud container clusters get-credentials central --zone {{{project_0.startup_script.zone | ZONE}}}

Resultado:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

5. Ejecuta el siguiente comando para verificar que se hayan creado los nodos:

kubectl get nodes

El resultado debería ser similar al siguiente:

Resultado:

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

Tarea 2: Implementa una aplicación

A continuación, implementarás una aplicación de microservicios llamada Hipster Shop en tu clúster para crear una carga de trabajo que puedas supervisar.

1. Ejecuta el siguiente comando para clonar el repo:

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. Cambia al directorio microservices-demo usando el siguiente comando:

cd microservices-demo

3. Ejecuta el siguiente comando para instalar la app con kubectl:

kubectl apply -f release/kubernetes-manifests.yaml

4. Ejecuta el siguiente comando para confirmar que todo se está ejecutando correctamente:

kubectl get pods

El resultado debería ser similar al siguiente:

Resultado:

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. Antes de continuar al siguiente paso, vuelve a ejecutar el comando hasta que todos los Pods tengan el estado Running.

Haz clic en Revisar mi progreso para verificar el objetivo. Implementar una aplicación

6. Ejecuta el siguiente comando para obtener la IP externa de la aplicación. El comando solo devolverá la dirección IP una vez que se haya implementado el Service, por lo que tal vez necesites repetir el comando hasta que haya una dirección IP externa asignada:

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. Ejecuta el siguiente comando para ver la dirección IP asignada. Si no hay ninguna, repite el paso 6:

echo $EXTERNAL_IP

8. Por último, ejecuta el siguiente comando para confirmar que la app está funcionando correctamente:

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

La confirmación debería ser similar al siguiente resultado.

Resultado:

200

Después de que se haya implementado la aplicación, visita la consola de Cloud y consulta el estado.

En la página Kubernetes Engine > Cargas de trabajo verás que todos los Pods funcionan correctamente.

9. En el panel izquierdo, selecciona Puertas de enlace, Ingress y Services. Luego, haz clic en la pestaña Objetos Service para verificar que todos los servicios estén en buen estado. Quédate en esta pantalla y configura la supervisión para la aplicación.

Tarea 3: Abre la aplicación

• Desplázate a frontend-external y haz clic en las IPs de los endpoints del Service.

Debería abrirse la aplicación y mostrarse una página como la siguiente:

Tarea 4: Crea una métrica basada en registros

En esta tarea, configurarás Cloud Logging para crear una métrica basada en registros, que es una métrica personalizada de Cloud Monitoring creada a partir de entradas de registros. Las métricas basadas en registros son útiles para contabilizar la cantidad de entradas de registro y hacer un seguimiento de la distribución de un valor en tus registros.

En este caso, usarás la métrica basada en registros para contar la cantidad de errores en tu Service de frontend. Puedes usar la métrica en los paneles y en las alertas.

1. En la barra de título de la consola de Google Cloud, escribe logging en el campo Buscar y, luego, haz clic en Explorador de registros en los resultados de la búsqueda.

2. Habilita Mostrar consulta y, en el cuadro Compilador de consultas, agrega lo siguiente:

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. Haz clic en Ejecutar consulta.

La consulta que estás usando te permite encontrar todos los errores del Pod de frontend. De cualquier manera, no deberías ver ningún resultado por el momento, ya que aún no hay errores.

4. Para crear la métrica basada en registros, haz clic en el menú desplegable Acciones y selecciona Crear métrica.

5. Asigna el nombre Error_Rate_SLI a la métrica y haz clic en Crear métrica para guardar la métrica basada en registros:

Ahora la métrica aparece en la lista de métricas definidas por el usuario en la página Métricas basadas en registros.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear una métrica basada en registros

Tarea 5: Crea una política de alertas

Las alertas permiten el reconocimiento oportuno de los problemas en tus aplicaciones de la nube para que puedas resolverlos con rapidez.

En esta tarea, usarás Cloud Monitoring para supervisar la disponibilidad de tu Service de frontend creando una política de alertas en función de la métrica basada en registros de errores de frontend que creaste con anterioridad. Cuando se reúnen las condiciones de la política de alertas, Cloud Monitoring crea y muestra un incidente en la consola de Cloud.

1. En el menú de navegación, abre Monitoring y haz clic en Alertas.

2. Una vez que se haya creado el espacio de trabajo, haz clic en Crear política en la parte superior.

Nota: Si es necesario, haz clic en Probar para usar el flujo actualizado de creación de alertas.

3. Haz clic en Selecciona una métrica. Anula la selección de la casilla de verificación Activo.

4. En el campo Filtrar por nombre de recurso o métrica, escribe Error_Rate.

5. Haz clic en Contenedor de Kubernetes > Métricas basadas en registros. Selecciona logging/user/Error_Rate_SLI y haz clic en Aplicar.

En la pantalla deberías ver lo siguiente:

6. Configura Función de ventana progresiva en Tasa.

7. Haz clic en Siguiente.

8. Establece 0.5 como Valor del umbral.

Como es de esperar, no se produce ningún error y tu aplicación cumple su objetivo de nivel de servicio (SLO) de disponibilidad.

9. Haz clic en Siguiente otra vez.

10. Inhabilita Usar el canal de notificaciones.

11. Proporciona un nombre de alerta, como Error Rate SLI, y haz clic en Siguiente.

12. Revisa la alerta y haz clic en Crear política.

Nota: En este lab no crearás un canal de notificaciones, pero deberías hacerlo para tus aplicaciones activas en producción, ya que te permite enviar notificaciones por correo electrónico, apps para dispositivos móviles, SMS, Pub/Sub y webhooks.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear una política de alertas

Activa un error de aplicación

En esta sección, usarás un generador de cargas para crear algo de tráfico para tu aplicación web. Como hay un error que se ingresó de forma intencional en esta versión de la aplicación, cierto volumen de tráfico activará errores. Trabajarás paso a paso para identificar y corregir el error.

1. En el menú de navegación, selecciona Kubernetes Engine, luego, Puertas de enlace, Ingress y Services y, por último, haz clic en la pestaña Objetos Service.

2. Busca el Service loadgenerator-external y, luego, haz clic en el vínculo de endpoints.

Como alternativa, puedes abrir una nueva ventana o pestaña del navegador, y copiar y pegar la IP en el campo de URL (por ejemplo: http://\[loadgenerator-external-ip\]).

Ya deberías estar en la página de generador de carga Locust:

Locust es un generador de cargas de código abierto que te permite cargar una app web de prueba. Puedes simular una cantidad determinada de usuarios que alcanza los endpoints de tu aplicación de manera simultánea a una tasa determinada.

3. Simula 300 usuarios que utilizan la app con una tasa de generación de 30. Locust agregará 30 usuarios por segundo hasta que alcance los 300 usuarios.

4. En el campo Host, usarás frontend-external. Copia la URL de la página Puertas de enlace, Ingress y Services (asegúrate de excluir el puerto). Por ejemplo:

5. Haz clic en el botón Start swarming. Deberías tener cerca de 300 usuarios que visitan las URLs predefinidas en pocos segundos.

6. Haz clic en la pestaña Failures para ver los errores que comienzan a aparecer. Notarás que hay muchos errores 500.

Mientras tanto, si haces clic en algún producto de la página principal, notarás que carga muy lento o, si haces clic en un producto, recibes errores como el siguiente:

Confirma la alerta y los errores de la aplicación

1. En la consola, desde el menú de navegación, haz clic en Monitoring y, luego, en Alertas. Deberías ver un incidente de logging/user/Error_Rate_SLI. Si no lo ves en ese momento, espera unos minutos y actualiza la página. La alerta puede tardar hasta 5 minutos en activarse.

2. Haz clic en el vínculo del incidente:

Esta acción te llevará a la página de detalles.

3. En el panel de la izquierda, haz clic en Explorador de registros.

4. También puedes hacer clic en la etiqueta Error en el campo Registros para consultar solo los errores.

Como alternativa, puedes hacer clic en el campo de vista previa de consultas para ver el Compilador de consultas; luego, haz clic en Gravedad en el menú desplegable y agrega Error a la búsqueda. Haz clic en el botón Agregar y, luego, haz clic en Ejecutar consulta. El menú desplegable permite agregar varios valores de gravedad.

El resultado agregará severity=ERROR a tu consulta. Una vez que hayas hecho esto, deberías tener todos los errores del Pod recommendationservice.

5. Revisa los detalles de los errores expandiendo cada evento de error. Por ejemplo:

6. Expande textPayload.

7. Haz clic en el mensaje de error y elige Agregar campo a línea de resumen para que los mensajes de error aparezcan como un campo de resumen:

Desde ahí puedes confirmar que el Service RecommendationService tiene muchos errores. Según los mensajes de error, parece que RecommendationService no se pudo conectar a algún servicio downstream para conseguir productos o recomendaciones. De cualquier manera, aún no está claro cuál es la causa raíz de los errores.

Si vuelves a consultar el diagrama de arquitectura, RecommendationService provee una lista de recomendaciones a los Services de frontend. Sin embargo, tanto el Service de frontend como el de RecommendationService invocan ProductCatalogService para la lista de productos.

En el próximo paso, examinarás las métricas de la fuente más probable de los problemas, ProductCatalogService, en busca de anomalías. Sin embargo, puedes desglosar los registros para obtener información.

Soluciona problemas con el panel y los registros de Kubernetes

1. Uno de los primeros lugares en donde puedes ver las métricas es en la sección Kubernetes Engine de la consola de Monitoring (menú de navegación > Monitoring > Paneles > GKE).

2. Consulta la sección Cargas de trabajo.

3. Navega a Kubernetes Engine > Cargas de trabajo > productcatalogservice. Puedes ver que el Pod del Service falla y se reinicia de forma constante.

A continuación, observa si hay algo interesante en los registros.

Hay 2 maneras de llegar con facilidad a tus registros de contenedores:

4. Haz clic en la pestaña Registros para obtener una vista rápida de los registros más recientes. Luego, haz clic en el botón de vínculo externo en la esquina superior derecha del panel de registros para volver al Explorador de registros.

5. En la pestaña Resumen, haz clic en el vínculo Registros de contenedores de la página de detalles de la implementación.

Estás en la página Explorador de registros otra vez, ahora con una consulta predefinida filtrada específicamente para los registros del contenedor que consultaste en GKE.

Desde el Visor de registros, tanto los mensajes de registro como el histograma muestran que el contenedor analiza de forma repetida el catálogo de productos en un corto período. Parece ser muy ineficiente.

En la parte inferior de los resultados de las consultas, podría haber un error de tiempo de ejecución como el siguiente:

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

Esta podría ser la causa de que el Pod falle.

Para entender mejor la razón, busca el mensaje de registro en el código.

6. En la terminal de Cloud Shell, ejecuta el siguiente comando:

grep -nri 'successfully parsed product catalog json' src

Tu resultado debería verse como el siguiente, que tiene el nombre del archivo fuente con un número de línea:

Resultado:

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

7. Para ver el archivo fuente, haz clic en el botón Abrir editor del menú de Cloud Shell y, luego, en Abrir en una ventana nueva. Si ves el error "No se puede cargar el editor de código debido a que las cookies de terceros están inhabilitadas", haz clic en el ojo en la parte superior de la página de Chrome.

8. Haz clic en el archivo microservices-demo/src/productcatalogservice/server.go, desplázate hasta la línea 237 y encontrarás los registros del método readCatalogFile con este mensaje:

Con un poco más de esfuerzo, puedes ver que, si la variable booleana reloadCatalog es verdadera, el Service vuelve a cargar y analizar el catálogo de productos cada vez que se invoca, lo que parece innecesario.

Si buscas en el código la variable reloadCatalog, puedes ver que está controlada por la variable de entorno ENABLE_RELOAD y escribe un mensaje de registro para su estado.

Revisa de nuevo los registros, agrega este mensaje a tu consulta y determina si hay alguna entrada existente.

9. Vuelve a la pestaña donde tienes abierto el Explorador de registros y agrega la siguiente línea a la consulta:

jsonPayload.message:"catalog reloading"

Esta será la consulta completa en tu compilador de consultas:

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

10. Haz clic en Ejecutar consulta una vez más y verás el mensaje "Enable catalog reloading" en el registro del contenedor, lo que confirma que está habilitada la función para volver a cargar el catálogo.

En este punto, puedes tener la certeza de que el error en el frontend es causado por la sobrecarga de volver a cargar el catálogo en cada solicitud. Cuando aumentaste la carga, la sobrecarga hizo que el Service fallara y que se generara el error.

Tarea 6: Corrige el problema y verifica el resultado

Sobre la base del código y en lo que ves en los registros, puedes corregir el problema inhabilitando la recarga del catálogo.

En esta tarea, quitarás la variable de entorno ENABLE_RELOAD del Service de catálogo de productos. Una vez que realices los cambios en la variable, podrás volver a implementar la aplicación y verificar que los cambios hayan solucionado el problema en cuestión.

1. Haz clic en el botón Abrir terminal para volver a la terminal de Cloud Shell si se cerró.

2. Ejecuta el siguiente comando:

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

El resultado muestra el número de línea de la variable de entorno en el archivo de manifiesto.

Resultado:

373: - name: ENABLE_RELOAD 374- value: "1"

3. Ejecuta el siguiente comando para borrar esas dos líneas que inhabilitarán la recarga:

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. Luego, ejecuta el siguiente comando para volver a aplicar el archivo de manifiesto:

kubectl apply -f release/kubernetes-manifests.yaml

Notarás que solo productcatalogservice está configurado. Los demás Services no cambiaron.

5. Regresa a la página Detalles de la implementación (menú de navegación > Kubernetes Engine > Cargas de trabajo > productcatalogservice) y espera hasta que el Pod se ejecute correctamente. Espera de 2 a 3 minutos o hasta que puedas confirmar que dejó de fallar.

6. Si vuelves a hacer clic en el vínculo Registros de contenedores, verás que desaparecieron los mensajes repetidos successfully parsing the catalog json:

7. Si te diriges de nuevo a la URL de la app web y haces clic en los productos de la página principal, notarás que es mucho más responsiva y no deberías encontrar ningún error de HTTP.

8. Vuelve al generador de cargas y haz clic en el botón Reset Stats en la parte superior derecha. El porcentaje de fallas se restableció, y no deberías ver que se incremente más.

Todo lo anterior indica que se corrigió el problema. Si aún ves el error 500, espera unos minutos más y haz clic en un producto otra vez.

¡Felicitaciones!

Usaste Cloud Logging y Cloud Monitoring para encontrar un error en una versión mal configurada de manera intencional de la app de demostración de microservicios. Este es un proceso de solución de problemas similar al que usarías para reducir problemas de tus apps de GKE en un entorno de producción.

Primero, implementaste la app en GKE y configuraste una métrica y una alerta para errores de frontend. Luego, generaste una carga y notaste que se activó la alerta. En la alerta, redujiste el problema a Services particulares a través de Cloud Logging. Luego, usaste Cloud Monitoring y la IU de GKE para consultar las métricas de los Services de GKE. Para solucionar el problema, implementaste una configuración actualizada en GKE y confirmaste que la corrección solucionó los errores en los registros.

Próximos pasos y más información

• Este lab se basa en esta entrada de blog sobre cómo usar Logging para tus apps que se ejecutan en GKE.
• La publicación de seguimiento sobre cómo los equipos de DevOps pueden usar Cloud Monitoring y Logging para detectar problemas con rapidez también puede ser de tu interés.

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 13 de julio de 2026

Prueba más reciente del lab: 13 de julio de 2026

Copyright 2026 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.