---
title: "Extensiones xk6: extender k6 sin bifurcar todo tu flujo de trabajo"
description: "Extensiones xk6: módulos Go custom, builds reproducibles, riesgo de upgrade—docs oficiales Grafana y cuándo basta k6 core."
publishDate: "2026-08-17"
draft: false
keyword: "extensiones xk6"
intent: "MOFU"
cta: "Usa Performate para convertir este playbook en escenarios k6 ejecutables, umbrales y reportes compartibles sin perder días en código de integración."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "xk6", "extensiones"]
translationOf: xk6-extensions-workflow
---

Necesitas métricas de consumo Kafka o APIs que no están en k6 core—alguien compila **xk6** local, commitea un binario que nadie más reproduce y CI rompe en el próximo upgrade. Las extensiones deben ampliar el flujo, no bifurcarlo en cultura perf de «funciona en mi laptop».

[xk6](https://grafana.com/docs/k6/latest/extensions/) arma binarios k6 con módulos Go. Úsalo cuando JavaScript core no alcance el protocolo; evítalo cuando HTTP + tags + `setup()` + Trends custom basten ([explorador de extensiones](https://grafana.com/docs/k6/latest/extensions/explorer/)). Esta guía cubre cuándo basta k6 core, flujo de build reproducible, tabla de decisión por necesidad y cómo exports de Performate siguen encajando con runners custom.

## Cuándo basta k6 core

Default a k6 core hasta tener una **brecha escrita** que HTTP no cierre:

- **Carga REST/GraphQL** con tags, umbrales y checks—camino por defecto ([Postman → k6](/es/blog/postman-a-k6-paso-a-paso)).
- **Long polls tipo SSE** vía HTTP con timeouts largos—limitaciones documentadas ([guía SSE](/es/blog/pruebas-carga-sse-long-polling-k6)); validación de parser puede necesitar compañeros.
- **Métricas custom** vía `Trend`/`Rate`/`Counter` en JS—lag desde body API, KPIs de negocio.
- **HMAC webhook** vía k6/crypto—carga de verificación de firma sin xk6.

Elige xk6 cuando necesites **Kafka**, **SQL**, **gRPC** (donde tu stack no lo cubra) o clientes especializados nativos—con **pipeline de build fijado** en git como Dockerfile o imagen CI—no binarios misteriosos.

### Costo del drift xk6

Cada extensión es un **segundo tren de release**: bump minor k6, lag del módulo extensión, rebuild imagen CI, sync equipo escritorio. Presupuesta ese costo en la tabla de decisión—no solo «Kafka necesita xk6-kafka».

## Flujo: build xk6 reproducible

Trata el binario custom como artefacto con pins semver—misma disciplina que contenedores de producción.

**Ejemplo de build (ilustrativo).** Fija versión k6 en Dockerfile o CI—nunca `latest`.

```bash
# Ejemplo — fija versiones en PERF.md e imagen CI
xk6 build v0.52.0 --with github.com/grafana/xk6-kafka@v0.9.0
```

Documenta en `PERF.md`: versión k6, lista de módulos, owner de rebuild, fecha de última verificación.

**El script k6 sigue siendo JS estándar**—la extensión expone nuevos imports:

```javascript
// Requiere binario xk6-kafka — ilustrativo
import { Writer } from 'k6/x/kafka';

export const options = {
  scenarios: {
    produce: {
      executor: 'constant-vus',
      vus: 5,
      duration: '2m',
      tags: { protocol: 'kafka' },
    },
  },
};

export default function () {
  // lógica productor vía API de extensión — ver docs xk6-kafka
}
```

**Qué demuestra este ejemplo:**

- Estructura de escenario familiar—executors y umbrales sin cambios.
- Capacidad del binario es artefacto separado—escenarios viven en git; imagen construye en CI.
- Tag `protocol:kafka` separa métricas de suites HTTP en el mismo tren de release.

**Patrones que funcionan**

- **Imagen docker CI** con xk6 fijado—`docker run` local coincide con pipeline.
- **Prototipar en k6 core primero**—demuestra que wrapper HTTP es insuficiente antes de módulo Go.
- **Plan B** si extensión retrasa release k6—bloquear upgrade o fijar k6 temporalmente.
- **Export Performate** para porciones HTTP; script runner xk6 documentado solo para porciones Kafka.

**Antipatrones a evitar**

- Commitear binario compilado a git—drift OS/arch garantizado.
- Cada ingeniero construye set `--with` distinto—«funciona en CI» se vuelve lotería.
- xk6 por conveniencia cuando existe gateway curl-vía-HTTP—impuesto operacional sin ganancia.
- Saltarse [smoke CI](/es/blog/pipeline-ci-smoke-carga-stress) porque «binario custom es difícil».

**Pro tip (comando de ejemplo):** verificar versión binario en CI antes de corrida.

```bash
./k6 version && ./k6 run kafka-produce.js --tag protocol=kafka
```

**Qué demuestra este comando:** CI loguea metadata de build k6 primero—postmortems conocen set exacto de extensiones cuando métricas Kafka se ven mal tras upgrade.

## Marco de decisión: necesidad vs camino

| Necesidad | Camino | Mantenimiento |
|:---|:---|:---|
| Carga API HTTP | k6 core | Bajo |
| Carga produce/consume Kafka | xk6-kafka + imagen fijada | Medio |
| Automatización browser | módulo browser k6 o xk6-browser | Medio–alto |
| Experimento puntual | xk6 local, no commitear binario | Ninguno |
| Dependencia Kafka de equipo | Extensión en docker CI + PERF.md | Continuo |
| gRPC | xk6 o gateway grpc-vía-HTTP | Evaluar gateway primero |

**Elige gateway HTTP** cuando el equipo de plataforma ya expone Kafka interno vía REST para ops—carga ese gateway con k6 core primero.

## Observabilidad y checklist xk6

- [ ] Archivo de pin de versión en repo (`PERF.md` o `versions.txt`).
- [ ] CI usa misma imagen que local—sin drift entre laptop y pipeline.
- [ ] Plan B si extensión retrasa release k6—owner nombrado.
- [ ] Ruta de export Performate documentada (HTTP core vs comando runner custom).
- [ ] Revisión trimestral vs paridad features k6 core—extensiones se encogen con el tiempo.
- [ ] Escenarios taggeados por protocolo—HTTP vs kafka en revisiones de release combinadas.

## Cómo Performate encaja en flujos xk6

Abajo hay un **ejemplo de flujo concreto** para equipo considerando extensión Kafka—adapta a tu análisis de brecha.

**Ejemplo: core primero, spike xk6, imagen CI fijada**

1. **Prototipa** carga Kafka vía gateway HTTP en k6 core—mide brecha con honestidad. *Problema resuelto:* evita impuesto xk6 si gateway basta para prueba SLO.
2. **Si brecha real**, spike xk6-kafka en branch—no mergear binario. *Problema resuelto:* exploración acotada en tiempo con criterios go/no-go.
3. **Añade** Dockerfile para build xk6 fijado—CI y escritorio tiran misma imagen. *Problema resuelto:* corridas reproducibles en el equipo.
4. **Mantén** escenarios HTTP en export Performate—escenarios Kafka en mismo repo, script runner documentado. *Problema resuelto:* PM/QA siguen usando escritorio para 80% rutas HTTP.
5. **Documenta** comando de corrida para equipo escritorio—`docker run ... k6 run kafka.js`. *Problema resuelto:* doc onboarding evita hilos de soporte «binario equivocado».
6. **Revisa trimestralmente** vs paridad features core—elimina extensión cuando ruta HTTP exista. *Problema resuelto:* conteo de extensiones no crece para siempre.

Ese flujo mapea directamente al `cta` de este post: ampliar capacidad sin bifurcar todo el bucle Postman → k6 → reporte.

## Cierre

xk6 es **disciplina de artefacto de build**, no un npm casual. Fija versiones, no commitees binarios misteriosos, default a k6 core hasta que HTTP falle de verdad y documenta el runner custom junto a exports Performate.

Antes de añadir xk6-kafka, escribe un párrafo explicando por qué HTTP no puede cargar la ruta—si el párrafo es débil, quédate en k6 core otro trimestre.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [Extensiones k6](https://grafana.com/docs/k6/latest/extensions/)