menu
arrow_back

Prueba de carga distribuida con Kubernetes

Prueba de carga distribuida con Kubernetes

Horas 5 Créditos

GSP182

Labs de autoaprendizaje de Google Cloud

Descripción general

En este lab, aprenderá a utilizar Kubernetes Engine para implementar un marco de trabajo de prueba de carga distribuida. El marco de trabajo usa varios contenedores con el objetivo de crear tráfico de prueba de carga para una API simple basada en REST. A pesar de que esta solución pone a prueba una aplicación web simple, se puede usar el mismo patrón si se quieren crear situaciones de prueba de carga más complejas, como aplicaciones de Internet de las cosas (IoT) o de videojuegos. Esta solución analiza la arquitectura general de un marco de trabajo de prueba de carga basado en contenedores.

Sistema a prueba

Para este lab, el sistema que se somete a prueba es una pequeña aplicación web implementada en Google App Engine. La aplicación expone extremos de estilo REST básicos para capturar solicitudes POST de HTTP entrantes (los datos entrantes no se conservan).

Ejemplos de cargas de trabajo

La aplicación que implementará se basa en el componente de servicio de backend que se encuentra en muchas implementaciones de Internet de las cosas (IoT). Los dispositivos primero se registran en el servicio y luego comienzan a enviar métricas o lecturas de sensores, a la vez que se vuelven a registrar regularmente en el servicio.

La interacción del componente de servicio de backend común se ve de la siguiente manera:542dlt85f86jjd1f.png

Para modelar esta interacción, usará Locust, una herramienta de prueba de carga distribuida basada en Python que es capaz de distribuir solicitudes a través de varias rutas de destino. Por ejemplo, puede distribuir solicitudes a las rutas de destino /login y /metrics.

La carga de trabajo se basa en la interacción descrita anteriormente y se modela como un conjunto de tareas en Locust. Para aproximarse a los clientes del mundo real, cada tarea de Locust está ponderada. Por ejemplo, el registro se realiza una vez por cada mil solicitudes totales de clientes.

Procesamiento basado en contenedores

  • La imagen del contenedor de Locust es una imagen de Docker que contiene el software de Locust.

  • Un clúster de contenedor consta de al menos una instancia principal de clúster y varias máquinas trabajadoras, llamadas nodos. Estas máquinas de instancia principal y de nodo ejecutan el sistema de organización de clústeres de Kubernetes. Para obtener más información sobre los clústeres, consulte la Documentación de Kubernetes Engine.

  • Un pod es un contenedor o varios implementados juntos en un host y la unidad de procesamiento más pequeña que se puede definir, implementar y administrar. Algunos pods contienen un solo contenedor. Por ejemplo, en este lab, cada uno de los contenedores de Locust se ejecuta en su propio pod.

  • Un controlador de implementación proporciona actualizaciones declarativas de los pods y ReplicaSets. En este lab, hay dos implementaciones: una para locust-master y otra para locust-worker.

  • Servicios

    Un pod en particular puede desaparecer por varias razones, entre las que se incluye la falla en un nodo o la interrupción intencional del nodo para realizar actualizaciones o mantenimiento. Esto significa que la dirección IP de un pod no proporciona una interfaz confiable para ese pod. Un enfoque más confiable usaría una representación abstracta de esa interfaz que nunca cambia, incluso si el pod subyacente desaparece y se reemplaza por un pod nuevo con una dirección IP diferente. Un servicio de Kubernetes Engine proporciona este tipo de interfaz abstracta por medio de la definición de un conjunto lógico de pods y una política para acceder a ellos.

    En este lab, hay varios servicios que representan pods o conjuntos de pods. Por ejemplo, hay un servicio para el pod del servidor DNS, otro servicio para el pod principal de Locust y un servicio que representa los 10 pods trabajadores de Locust.

    En el siguiente diagrama, se muestran los contenidos del nodo principal y de los nodos trabajadores.

4er1cd4e32459737.png

Actividades

  • Cree un sistema a prueba, es decir, una pequeña aplicación web implementada en Google App Engine.
  • Use Kubernetes Engine para implementar un marco de trabajo de prueba de carga distribuida.
  • Cree un tráfico de prueba de carga para una API simple basada en REST.

Requisitos previos

  • Se recomienda estar familiarizado con App Engine y los servicios de GCP de Kubernetes Engine.
  • Se recomienda estar familiarizado con editores de texto estándares de Linux, como Vim, Emacs o Nano.

Join Qwiklabs to read the rest of this lab...and more!

  • Get temporary access to the Google Cloud Console.
  • Over 200 labs from beginner to advanced levels.
  • Bite-sized so you can learn at your own pace.
Join to Start This Lab