ADR-028: Kafka en un pod del clúster para desarrollo y ensayos, Confluent Cloud desde el 15/11/2026, con un interruptor

Aceptado el 14/11/2026 por Andrés. Lo implementó el carril `borde-eks`. Complementa ADR-024 (decisión 8, Kafka en Confluent Cloud) y no lo reemplaza: Confluent sigue siendo el Kafka del demo; este ADR fija cuándo entra y qué hay si falla.

Contexto

ADR-024 deja Kafka en Confluent Cloud Basic, con una cuenta de servicio y una llave por carga y permisos de mínimo privilegio desde el contrato AsyncAPI. Con las 151 particiones del contrato, Confluent cobra 0,70 dólares por hora (6 eCKU, elastic Confluent unit for Kafka, la unidad de capacidad con la que cobra Confluent; docs/plataforma/05-infraestructura-aws.md), desde que existen los tópicos, aunque nadie los use.

El clúster de EKS (Elastic Kubernetes Service, el Kubernetes administrado de AWS) se enciende por horas antes del demo del 17/11/2026, para desarrollar y ensayar: ver que los pods arrancan, que el borde recibe una llamada autenticada, que una orden recorre la saga. Esos ensayos no necesitan Confluent. La cuenta de Confluent depende de Andrés, y su costo, del crédito de 400 dólares para cuentas nuevas que cita 04-stack.md, que la página de precios hoy no muestra: hay que comprobarlo al crear la cuenta.

En kind ya existe un Kafka de un nodo (chart kafka, modo KRaft: Kafka Raft, el que coordina el clúster sin ZooKeeper), con los tópicos creados desde el contrato y factor de replicación 1. Las cargas ya eligen la conexión por configuración (global.kafkaSecurity): sin SASL (Simple Authentication and Security Layer, la autenticación de Kafka con usuario y clave) contra ese Kafka, SASL_SSL (la misma autenticación sobre TLS) contra Confluent. Ningún código cambia entre los dos.

Opciones

Opción	A favor	En contra
A. Confluent siempre, desde hoy	Un solo modo; cada ensayo prueba lo mismo que el demo	Cada ensayo espera la cuenta de Confluent y paga 0,70 dólares por hora más; sin plan si el crédito no aplica
B. Kafka en un pod ahora; Confluent desde el 15/11/2026 hasta el demo; el pod como respaldo; un interruptor que va y vuelve	Los ensayos de hoy no esperan a Confluent; el mismo chart que kind; si Confluent falla o el crédito no aplica, el demo sigue con el pod	Dos modos que mantener; lo propio de Confluent (SASL_SSL, ACL por carga, es decir, listas de control de acceso a cada tópico, llaves en Secrets Manager) se prueba desde el 15/11
C. Kafka en un pod también para el demo	El demo más barato	Contradice ADR-024 y `04-stack.md` (servicio administrado); sin réplicas ni permisos por carga, la seguridad de Kafka que describe el entregable no se mostraría
D. Amazon MSK (Managed Streaming for Apache Kafka, el Kafka administrado de AWS)	Servicio administrado de AWS	Ya descartado en ADR-024: el clúster mínimo cuesta más por hora y pide su propia red

Decisión

Opción B.

Fecha	Kafka
Desde el 14/11/2026	En un pod del clúster (`KAFKA_MODE=pod`): desarrollo y ensayos
Del domingo 15/11/2026 al demo del martes 17/11/2026	Confluent Cloud (`KAFKA_MODE=confluent`), si el crédito de 400 dólares de cuenta nueva funciona
Si Confluent falla o el crédito no aplica	Vuelve al pod (`KAFKA_MODE=pod`) como respaldo, también para el demo; se dice en la presentación y en el entregable

Un solo interruptor, KAFKA_MODE, en platform/k8s/scripts/k8s.sh (y por él en make k8s-eks-deploy):

	`KAFKA_MODE=pod` (por defecto)	`KAFKA_MODE=confluent`
Kafka	Release `kafka` en `data`: un nodo KRaft, disco `gp3` (el tipo de disco EBS de uso general) cifrado de 10 GiB que se borra al desinstalar	Confluent Cloud Basic de la raíz `kafka` de OpenTofu
Conexión de las cargas	`kafka.data.svc.cluster.local:9092`, sin SASL (`global.kafkaSecurity: plaintext`); con sidecar, el tramo va cifrado por el mTLS (TLS mutuo: cada lado presenta su certificado) de Istio	SASL_SSL con la llave de la carga
Secreto `<carga>-kafka`	No se monta	Se monta, como hoy
Tópicos	Desde el contrato (`scripts/topics-plan.js --replicas=1`), al instalar la release	Desde el contrato, por la raíz `kafka` (factor 3)
Raíz `kafka` de OpenTofu	No hace falta	Aplicada antes del despliegue
Costo de Kafka por hora	Unos 0,001 dólares (el disco); corre en los nodos que ya existen	0,70 dólares (6 eCKU), contra el crédito si aplica

Ida y vuelta con un despliegue limpio: el mismo make k8s-eks-deploy, con el otro valor de KAFKA_MODE. El cambio de modo cambia la configuración y los volúmenes de cada carga, así que cada una se reinicia con la conexión nueva. Al pasar a confluent, el despliegue desinstala la release kafka al final (con su disco); al volver a pod, la instala de nuevo, vacía, y crea los tópicos. Los eventos que hubiera en el Kafka que se deja no se migran: el demo los rehace desde la semilla y la carga inicial de los adaptadores.

El cambio es solo de configuración: ni código ni contratos. make verify renderiza EKS en los dos modos y scripts/check-catalog.mjs comprueba lo que cambia: en pod, la release kafka está y ninguna carga monta <carga>-kafka; en confluent, no está y cada carga con kafka = true en el catálogo lo monta.

Qué se sacrifica

En modo pod, Kafka es un solo nodo: sin réplicas ni tolerancia a fallos. Si el pod o su nodo caen, los productores esperan y los consumidores se detienen hasta que vuelve. El escenario de caída de un broker no se puede ensayar así.
En modo pod no hay permisos por servicio: cualquier carga que llegue al puerto puede leer y escribir cualquier tópico. Los permisos de mínimo privilegio de ADR-024 (ACL desde el contrato) solo existen en Confluent.
Lo propio de Confluent (SASL_SSL en Java y en Node, las llaves en Secrets Manager con Pod Identity, las ACL, la cuota de particiones) solo se prueba desde el 15/11/2026: queda poco margen antes del demo para corregir un defecto ahí. Para eso existe el respaldo.
Si el demo corre con el respaldo, lo que el entregable dice de Kafka en la nube (réplicas, ACL por carga) se presenta como diseño y no como demostrado.
Las cifras de latencia y de frescura que dependen de Kafka se anotan con el modo en que se midieron.
Cambiar de modo pierde los eventos del Kafka que se deja (no hay replicación entre los dos).
Dos modos que mantener en los valores y en make verify.

Verificación

make verify (k8s-verify): helm lint, template, kubeconform, catálogo y Trivy de EKS con KAFKA_MODE=pod y con KAFKA_MODE=confluent. En kind, el mismo chart kafka corre en cada make k8s-kind-e2e. En EKS, por verificar en el primer encendido con KAFKA_MODE=pod: el disco gp3 del broker en Bound, los tópicos creados y las cargas conectadas con su sidecar; y el 15/11/2026, la ida a confluent y la vuelta a pod con un despliegue cada una.