arrow_back

Cómo administrar implementaciones con Kubernetes Engine

Unirse Acceder
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Cómo administrar implementaciones con Kubernetes Engine

Lab 1 hora universal_currency_alt 5 créditos show_chart Intermedio
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP053

Labs de autoaprendizaje de Google Cloud

Descripción general

Normalmente, las prácticas de DevOps usarán varias implementaciones para administrar situaciones de implementación de aplicaciones como “Implementación continua”, “Implementaciones azul-verde”, “Implementaciones de versiones canary” y mucho más. En este lab puedes practicar el escalamiento y la administración de contenedores para alcanzar estas situaciones comunes en las cuales se utilizan varias implementaciones heterogéneas.

Objetivos

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

  • Obtener una experiencia práctica con la herramienta de kubectl
  • Crear archivos de implementación yaml
  • Iniciar, actualizar y escalar implementaciones
  • Actualizar implementaciones y aprender sobre los estilos de implementación

Requisitos previos

Para maximizar tu aprendizaje, sigue estas recomendaciones para este lab:

  • Has realizado estos labs de Google Cloud Skills Boost:
  • Tienes las habilidades de administración de sistemas de Linux.
  • Comprendes la teoría de DevOps: los conceptos de implementación continua.

Introducción a las implementaciones

Las implementaciones heterogéneas normalmente implican conectar dos o más entornos o regiones de infraestructura distintos para abordar una necesidad operativa o técnica específica. Las implementaciones heterogéneas se llaman "híbridas", "de múltiples nubes", o "pública-privada", según los datos específicos de la implementación.

A los fines de este lab, las implementaciones heterogéneas incluyen aquellas que abarcan regiones dentro de un único entorno de nube, múltiples entornos de nube pública (múltiples nubes) o una combinación de entornos de nube locales y públicas (híbridas o pública-privada).

Pueden surgir varios desafíos comerciales y técnicos en las implementaciones que se limitan a un único entorno o región:

  • Recursos agotados: En cualquier entorno único, particularmente en los entornos locales, es posible que no tengas los recursos de procesamiento, las herramientas de redes y el almacenamiento para satisfacer tus necesidades de producción.
  • Alcance geográfico limitado: Las implementaciones en un entorno único requieren personas que estén geográficamente distantes entre sí para acceder a una implementación. Tu tráfico puede viajar por todo el mundo a una ubicación central.
  • Disponibilidad limitada: Los patrones del tráfico a escala de la Web desafían a las aplicaciones a permanecer tolerantes a errores y resilientes.
  • Dependencia de un solo proveedor: Las abstracciones de infraestructura y plataforma a nivel del proveedor pueden evitar la portabilidad de aplicaciones.
  • Recursos inflexibles: Tus recursos pueden estar limitados a un conjunto particular de soluciones de procesamiento, almacenamiento o herramientas de redes.

Las implementaciones heterogéneas pueden ayudar a abordar estos desafíos, pero su arquitectura debe usar procesos y procedimientos programáticos y determinísticos. Los procedimientos de implementación por única vez o ad-hoc pueden hacer que las implementaciones o procesos sean intolerantes a errores y frágiles. Los procesos ad-hoc pueden perder datos o disminuir el tráfico. Los buenos procesos de implementación deben ser repetibles y utilizar enfoques comprobados para administrar el aprovisionamiento, la configuración y el mantenimiento.

Tres situaciones comunes para la implementación heterogénea son las implementaciones de múltiples nubes, el fronting de datos locales y los procesos de integración continua/entrega continua (CI/CD).

Los siguientes ejercicios repasan algunos casos de uso comunes para implementaciones heterogéneas, junto con enfoques de buen diseño que utilizan Kubernetes y otros recursos de infraestructura para lograrlos.

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

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 Ícono de 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.

  1. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):
gcloud auth list
  1. Haz clic en Autorizar.

  2. 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`
  1. 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.

Configura la zona

Configura tu zona de trabajo de Google Cloud con la ejecución del siguiente comando, sustituyendo la zona local de la siguiente manera:

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

Obtén un código de muestra para este lab

  1. Obtén el código de muestra para crear y ejecutar implementaciones y contenedores:
gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes
  1. Crea un clúster con 3 nodos (te llevará unos pocos minutos completarlo):
gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Tarea 1. Obtén más información sobre el objeto Deployment

Para comenzar, consulta el objeto Deployment.

  1. El comando explain en kubectl nos puede dar información sobre el objeto Deployment:
kubectl explain deployment
  1. También puedes ver todos los campos que usan la opción --recursive:
kubectl explain deployment --recursive
  1. Puedes utilizar el comando explain a medida que avanzas en el lab para que puedas comprender la estructura de un objeto Deployment y entender qué hace cada campo:
kubectl explain deployment.metadata.name

Tarea 2. Crea un objeto Deployment

  1. Actualiza el archivo de configuración deployments/auth.yaml:
vi deployments/auth.yaml
  1. Inicia el editor:
i
  1. Cambia image en la sección de contenedores del objeto Deployment por la siguiente información:
... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...
  1. Guarda el archivo auth.yaml: presiona <Esc> y luego escribe:
:wq
  1. Presiona <Intro>. Ahora, crea una implementación simple. Examina el archivo de configuración de la implementación:
cat deployments/auth.yaml

Resultado:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Observa cómo la implementación está creando una réplica y está utilizando la versión 1.0.0 del contenedor de auth.

Cuando ejecutes el comando kubectl create para crear el Deployment auth, creará un Pod que se ajuste a los datos en el manifiesto de implementación. Esto significa que puedes escalar la cantidad de Pods con solo modificar el número que se especifica en el campo réplicas.

  1. Crea tu objeto Deployment con kubectl create:
kubectl create -f deployments/auth.yaml
  1. Luego de crear el Deployment, verifica que se haya hecho correctamente:
kubectl get deployments
  1. Una vez creado el Deployment, Kubernetes creará un ReplicaSet para el Deployment. Puedes verificar que se creó un ReplicaSet para el Deployment:
kubectl get replicasets

Deberías ver un ReplicaSet con un nombre como auth-xxxxxxx

  1. Observa los Pods que se crearon como parte del Deployment. Kubernetes crea el único Pod cuando se produce el ReplicaSet:
kubectl get pods

Es momento de crear un servicio para la implementación auth. Ya has visto los archivos de manifiesto de servicio, así que no entraremos en detalles aquí.

  1. Usa el comando kubectl create para crear el servicio auth:
kubectl create -f services/auth.yaml
  1. Ahora, realiza los mismos pasos para crear y exponer el Deployment hello:
kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml
  1. Realízalos una vez más para crear y exponer el Deployment frontend:
kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml Nota: Creaste un ConfigMap para frontend.
  1. Usa la IP externa de frontend y aplica el comando curl para interactuar con él:
kubectl get services frontend Nota: Es posible que los datos del campo IP externa demoren algunos segundos en propagarse para tu servicio. Esto es normal. Ejecuta el comando mencionado con anterioridad cada unos pocos segundos hasta que se complete el campo. curl -ks https://<EXTERNAL-IP>

Recibirás la respuesta hello.

  1. También puedes usar la función de plantillas de salida de kubectl para usar curl como una sola línea:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Prueba la tarea completada

Haz clic en Revisar mi progreso a continuación para revisar tu progreso en el lab. Si creaste correctamente un clúster de Kubernetes y los Deployment Auth, Hello y Frontend, verás una puntuación de evaluación.

Crear Deployments (Auth, Hello y Frontend) y un clúster de Kubernetes

Escala un Deployment

Ahora que has creado un Deployment, puedes escalarlo. Para realizar esta acción, actualiza el campo spec.replicas.

  1. Podrás ver una explicación de este campo usando el comandokubectl explain nuevamente:
kubectl explain deployment.spec.replicas
  1. El campo replicas se puede actualizar más fácilmente usando el comando kubectl scale:
kubectl scale deployment hello --replicas=5 Nota: El inicio de todos los Pods nuevos puede tardar un minuto aproximadamente.

Luego de que se actualice el Deployment, Kubernetes actualizará automáticamente el objeto ReplicaSet asociado y, luego, iniciará nuevos Pods para que el número total de estos sea igual a 5.

  1. Verifica que ahora haya 5 Pods hello en ejecución:
kubectl get pods | grep hello- | wc -l
  1. Ahora, reduce la escala de la aplicación:
kubectl scale deployment hello --replicas=3
  1. Nuevamente, verifica que tengas el número correcto de Pods:
kubectl get pods | grep hello- | wc -l

Aprendiste sobre los objetos Deployment de Kubernetes y sobre cómo administrar y escalar un grupo de Pods.

Tarea 3: Actualización progresiva

Los objetos Deployment admiten la actualización de imágenes a una nueva versión a través de un mecanismo de actualización progresiva. Cuando se actualiza un Deployment con una versión nueva, crea un nuevo objeto ReplicaSet y aumenta lentamente la cantidad de réplicas en el ReplicaSet nuevo a medida que disminuye las réplicas en el ReplicaSet anterior.

Diagrama de Deployment entre conjuntos de réplicas

Activa una actualización progresiva

  1. Para actualizar tu Deployment, ejecuta el siguiente comando:
kubectl edit deployment hello
  1. Cambia image en la sección de contenedores del Deployment por la siguiente información:
... containers: image: kelseyhightower/hello:2.0.0 ...
  1. Guarda y cierra.

Luego de guardar y salir del editor, la implementación actualizada se guardará en tu clúster y Kubernetes comenzará una actualización progresiva.

  1. Mira el nuevo ReplicaSet que crea Kubernetes:
kubectl get replicaset
  1. También puedes ver una nueva entrada en el historial de actualizaciones progresivas:
kubectl rollout history deployment/hello

Pausa una actualización progresiva

Si detectas problemas con una actualización progresiva en ejecución, páusala para detenerla.

  1. Inténtalo ahora:
kubectl rollout pause deployment/hello
  1. Verifica el estado actual de la actualización progresiva:
kubectl rollout status deployment/hello
  1. También puedes verificarlo directamente en los Pods:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Reanuda una actualización progresiva

La actualización progresiva está en pausa, lo que significa que algunos Pods están en la nueva versión y otros, en la anterior.

  1. Continúa con la actualización progresiva con el comando resume:
kubectl rollout resume deployment/hello
  1. Luego de completar la actualización progresiva, deberías ver la siguiente información cuando ejecutes el comando status:
kubectl rollout status deployment/hello

Resultado:

deployment "hello" successfully rolled out

Revierte una actualización

Supongamos que se detectó un error en tu nueva versión. Dado que se supone que la nueva versión tiene problemas, cualquier usuario conectado a los nuevos Pods experimentará esos problemas.

Es preferible revertirla a la versión anterior para poder investigar y, luego, lanzar una versión que se haya corregido.

  1. Usa el comando rollout para revertirla a la versión anterior:
kubectl rollout undo deployment/hello
  1. Verifica la reversión en el historial:
kubectl rollout history deployment/hello
  1. Finalmente, verifica que todos los Pods se hayan revertido a sus versiones anteriores:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Perfecto. Aprendiste sobre actualizaciones progresivas para objetos Deployment de Kubernetes y sobre cómo actualizar aplicaciones sin tiempo de inactividad.

Tarea 4. Implementaciones de versiones canary

Cuando desees probar una nueva implementación en producción con un subconjunto de sus usuarios, usa una implementación de versiones canary. Las implementaciones de versiones canary te permiten actualizar un cambio en un pequeño subconjunto de tus usuarios para mitigar el riesgo asociado con los nuevos lanzamientos.

Crea una implementación de versiones canary

Una implementación de versiones canary consiste en una implementación separada con su nueva versión y un servicio que apunta tanto a su implementación normal y estable como a su implementación de versiones canary.

Diagrama de implementación de versiones canary

  1. Primero, crea una nueva implementación de versiones canary para la nueva versión:
cat deployments/hello-canary.yaml

Resultado:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...
  1. Ahora, crea la implementación de versiones canary:
kubectl create -f deployments/hello-canary.yaml
  1. Después de crear la implementación de versiones canary, deberías tener dos implementaciones: hello y hello-canary. Verifícalo con este comando kubectl:
kubectl get deployments

En el servicio hello, el selector utiliza el app:hello, que hará coincidir los Pods en ambas implementaciones, la de producción y la de versiones canary. Sin embargo, debido a que la implementación de versiones canary tiene una cantidad menor de Pods, será visible para menos usuarios.

Verifica la implementación de versiones canary

  1. Puedes verificar la versión hello que se entrega según la solicitud:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
  1. Ejecuta esto varias veces y deberías ver que hello 1.0.0 entrega algunas de las solicitudes y 2.0.0 entrega un pequeño subconjunto (1/4 = 25%).

Prueba la tarea completada

Haz clic en Revisar mi progreso a continuación para revisar tu progreso en el lab. Si creaste correctamente una implementación de versiones canary, verás una puntuación de evaluación.

Implementación de versiones canary

Implementaciones de versiones canary en producción: afinidad de sesión

En este lab, cada solicitud que se envió al servicio Nginx tuvo la oportunidad de que la entregara la implementación de versiones canary. Pero ¿qué pasaría si quisieras asegurarte de que la implementación de versiones canary no entregará solicitudes a un usuario? Un caso de uso podría ser que la IU de una aplicación haya cambiado y no desees confundir al usuario. En un caso como este, es conveniente que el usuario se "mantenga" con una implementación o con otra.

Para hacer esto, crea un servicio con afinidad de sesión. De esta manera, siempre se entregarán solicitudes al mismo usuario desde la misma versión. En el ejemplo a continuación, el servicio es el mismo de antes, pero se agregó un nuevo campo sessionAffinity y se configuró como ClientIP. Las solicitudes de los clientes que tengan la misma dirección IP se enviarán a la misma versión de la aplicación hello.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

Debido a que es difícil configurar un entorno para probar esto, no es necesario hacerlo aquí, pero, tal vez, prefieras utilizar sessionAffinity para implementaciones de versiones canary en producción.

Tarea 5. Implementaciones azul-verde

Las actualizaciones progresivas son ideales porque te permiten implementar una aplicación lentamente con una sobrecarga mínima, un impacto mínimo en el rendimiento y un tiempo de inactividad mínimo. Hay casos en los que es beneficioso modificar los balanceadores de cargas para que apunten a esa nueva versión solo después de que se haya implementado por completo. En este caso, las implementaciones azul-verde son el camino a seguir.

Para lograr esto, Kubernetes crea dos implementaciones separadas: una para la versión “azul” anterior y otra para la nueva versión “verde”. Utiliza tu implementación hello existente para la versión “azul”. Se accederá a las implementaciones a través de un servicio que actuará como el router. Una vez que la nueva versión “verde” esté en funcionamiento, actualizarás el servicio para comenzar a usar esa versión.

Diagrama de implementación azul-verde

Nota: Una desventaja importante de las implementaciones azul-verde es que necesitarás que tu clúster tenga al menos el doble de recursos necesarios para alojar tu aplicación. Asegúrate de tener recursos suficientes en tu clúster antes de implementar ambas versiones de la aplicación a la vez.

El servicio

Utiliza el servicio hello existente, pero actualízalo para que tenga un selector app:hello, versión: 1.0.0. El selector coincidirá con la implementación “azul” existente. Sin embargo, no coincidirá con la implementación “verde” porque usará una versión diferente.

  • Primero, actualiza el servicio:
kubectl apply -f services/hello-blue.yaml Nota: Ignora la advertencia que dice resource service/hello is missing ya que se repara automáticamente.

Cómo actualizar con la implementación azul-verde

Si quieres admitir un estilo de implementación azul-verde, debes crear una nueva implementación “verde” para la nueva versión. La implementación verde actualiza la etiqueta de la versión y la ruta de la imagen.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1
  1. Crea la implementación verde:
kubectl create -f deployments/hello-green.yaml
  1. Una vez que tengas una implementación verde y que se haya iniciado correctamente, verifica que todavía se esté usando la versión actual de 1.0.0:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
  1. Ahora, actualiza el servicio para que apunte a la nueva versión:
kubectl apply -f services/hello-green.yaml
  1. Con la actualización del servicio, la implementación “verde” se utilizará de inmediato. Ahora, puedes verificar que se esté utilizando siempre la nueva versión:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Reversión azul-verde

Si es necesario, puedes revertir a la versión anterior de la misma manera.

  1. Mientras la implementación “azul” se esté ejecutando, actualiza el servicio a la versión anterior:
kubectl apply -f services/hello-blue.yaml
  1. Cuando hayas actualizado el servicio, la reversión habrá sido exitosa. Una vez más, verifica que ahora se esté usando la versión correcta:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

¡Lo lograste! Aprendiste acerca de las implementaciones azul-verde y cómo implementar actualizaciones en las aplicaciones que necesitan cambiar las versiones de una sola vez.

Felicitaciones

De esta manera, finaliza este lab práctico sobre la administración de implementaciones con Kubernetes. En este lab, tuviste la oportunidad de trabajar más con la herramienta de línea de comandos kubectl y muchos estilos de implementaciones configurados en archivos YAML para iniciar, actualizar y escalar tus implementaciones. Con esta base de práctica, deberías sentirte a gusto cuando aplicas estas habilidades a tu propia práctica de DevOps.

Próximos pasos y más información

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: 26 de enero de 2024

Prueba más reciente del lab: 14 de agosto de 2023

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