Tu aplicación funciona perfecto en desarrollo. Los tests pasan. El deploy a staging sale limpio. Todo se ve bien. Hasta que un martes a las 11 AM entran 5.000 usuarios simultáneos y tu servicio de checkout empieza a devolver 502s, la base de datos se satura y el equipo entra en modo bombero.
La pregunta incómoda: ¿probaste tu aplicación bajo carga real antes de mandarla a producción? La mayoría de los equipos no lo hace — no por falta de voluntad, sino porque el load testing siempre quedó en el backlog como algo que “vamos a hacer la semana que viene”.
El ecosistema de herramientas maduró mucho, y varias están diseñadas específicamente para correr dentro de Kubernetes — lo cual te da ventajas enormes en términos de escala, acceso a servicios internos y realismo del test.
Probablemente la herramienta de load testing más popular de los últimos años. La propuesta de valor de k6 es clara: developer experience ante todo. Escribir un test de carga se siente como escribir un test unitario — definís escenarios con stages que simulan rampas de usuarios, carga sostenida y bajada gradual, todo en un archivo JavaScript que vive en tu repositorio.
k6 está escrito en Go, lo que significa que un solo pod puede generar miles de requests por segundo sin consumir grandes cantidades de memoria o CPU. La integración con Prometheus y Grafana es nativa — las métricas del test aparecen en los mismos dashboards donde monitoreás tu aplicación, permitiéndote correlacionar carga con latencia, CPU, memoria y error rates en una sola vista.
- Querés adoptar load testing sin curva de aprendizaje pronunciada
- Ya usás el stack Grafana para observabilidad
- Tu equipo trabaja en JavaScript o TypeScript
- Necesitás generar carga distribuida masiva desde un solo pod (existe k6-operator pero agrega complejidad)
- Tu equipo es mayoritariamente Python — la experiencia no va a ser tan natural
Si tu equipo vive en Python, Locust se siente como casa. Los tests son clases de Python donde definís el comportamiento de cada usuario simulado: qué endpoints llama, en qué orden, con qué datos, cuánto espera entre requests. Esta flexibilidad permite modelar comportamientos de usuario muy realistas y complejos.
Locust tiene una interfaz web integrada donde podés ver en tiempo real cuántos usuarios están activos, la tasa de requests, los tiempos de respuesta y los errores. Podés arrancar un test y subir la carga gradualmente desde la UI sin tocar la terminal. Para demos y sesiones de equipo, esto es invaluable. La arquitectura master/workers se mapea perfectamente a Kubernetes.
- Tu equipo trabaja en Python y querés máxima flexibilidad
- Necesitás modelar flujos de usuario complejos con lógica custom
- La UI en tiempo real es importante para el equipo
- Tu objetivo es puro volumen de requests por segundo — las coroutines de Python son menos eficientes que Go para eso
- Recursos son muy limitados — necesitás más pods de worker que k6 para el mismo volumen
Gatling lleva más de una década en el mercado y es especialmente popular en equipos enterprise y ecosistemas JVM. Si hay algo que lo define es la calidad de sus reportes: al terminar un test genera un HTML detallado con distribución de tiempos de respuesta, percentiles (p50, p95, p99), requests por segundo y errores por tipo — segmentado por escenario y endpoint.
El DSL de Gatling permite modelar flujos de usuario complejos con pasos encadenados, extracción de datos de respuestas anteriores (correlation), manejo de sesiones y lógica condicional. Para testear flujos como login → buscar producto → agregar al carrito → checkout, Gatling brilla. Usa Akka y Netty para I/O asincrónico, lo que lo hace muy eficiente para concurrencia.
- Necesitás reportes de calidad profesional sin esfuerzo adicional
- Tus flujos de usuario son complejos y encadenados con correlation
- Tu equipo ya trabaja en el ecosistema JVM
- Necesitás presentar resultados en auditorías o compliance
- Tu equipo no viene del mundo JVM — el DSL de Scala tiene curva pronunciada
- Recursos son escasos — la JVM tiene cold start lento y mayor consumo de memoria base
Vegeta es una herramienta de línea de comandos pura con una filosofía radicalmente diferente: una cosa, bien hecha. Mientras k6 o Locust modelan “usuarios virtuales”, Vegeta trabaja con “requests por segundo”. Le decís “mandá 500 req/s a este endpoint durante 60 segundos” y eso es exactamente lo que hace.
Un solo comando genera carga, otro analiza los resultados. Podés integrarlo en un pipeline de CI/CD como un gate automático: si la latencia p99 supera X milisegundos, el deploy falla. Para tests rápidos y exploratorios — “¿cuántos req/s aguanta este endpoint antes de romperse?” — no hay nada más rápido de levantar.
- Querés una respuesta en minutos, no en horas
- Necesitás un gate de performance en CI/CD
- Preferís herramientas Unix-style que se componen con pipes y scripts
- Necesitás simular un flujo de usuario realista con múltiples pasos — Vegeta no modela sesiones ni encadena requests
- Necesitás manejo automático de cookies o tokens entre requests
Artillery se posiciona como el punto medio entre la simplicidad de Vegeta y la flexibilidad de Locust o k6. Los tests se definen en YAML con la posibilidad de extender con JavaScript cuando necesitás lógica custom. Para el 80% de los casos, el YAML es suficiente.
Artillery puede testear HTTP, WebSockets, Socket.io, gRPC y GraphQL out of the box. Si tu aplicación usa WebSockets para comunicación en tiempo real o gRPC para servicios internos, Artillery te permite testear esos flujos sin plugins ni configuración adicional — una ventaja significativa sobre el resto de las herramientas.
- Querés empezar rápido con YAML sin escribir código
- Necesitás testear WebSockets, gRPC o GraphQL
- Tu equipo trabaja en Node.js y quiere extender con JS cuando sea necesario
- Necesitás generar cientos de miles de req/s desde pocos pods — Node.js es menos eficiente que Go para esto
- El volumen masivo es prioridad por sobre la facilidad de configuración
| Herramienta | Lenguaje | Protocolos | Curva | Mejor para |
|---|---|---|---|---|
| k6 | JavaScript | HTTP, gRPC, WS | Baja | Equipos dev-first, stack Grafana |
| Locust | Python | HTTP (extensible) | Baja–Media | Escenarios complejos, UI en vivo |
| Gatling | Scala/Java | HTTP, WS, JMS | Media–Alta | Reportes profesionales, flujos JVM |
| Vegeta | CLI (Go) | HTTP | Muy baja | Tests rápidos, CI/CD gates |
| Artillery | YAML + JS | HTTP, WS, gRPC, GraphQL | Baja | Multiprotocolo, inicio sin código |
La decisión más importante no es cuál herramienta usar — es decidir hacer load testing en primer lugar. Un test de 30 minutos antes de un lanzamiento puede ahorrarte horas de downtime, miles de dólares en facturación perdida y la confianza de tus usuarios.
No tiene que ser perfecto ni exhaustivo. Un test básico que responda “¿cuántos usuarios concurrentes aguanta mi servicio antes de degradarse?” ya es infinitamente mejor que no tener nada.
El test de carga genera tráfico desde la misma red donde vive tu aplicación, lo cual te da resultados más realistas que cualquier test externo. Tenés acceso a servicios internos, el mismo DNS, los mismos timeouts de red — el ambiente es idéntico a producción.
Correr workloads en Kubernetes debería ser simple
Ya sea un test de carga, un CronJob o un worker — desplegar workloads en Kubernetes no debería requerir ser experto en manifiestos YAML. En SleakOps, la infraestructura de red, observabilidad y autoescalado ya están resueltos para que te enfoques en lo que importa.
Conocé SleakOps →