Cómo funciona · el bucle del incidente
Son las 3am y algo se rompe. Esto es lo que pasa después.
El mismo incidente que la portada resuelve en 87 segundos, paso a paso: qué lo detecta, qué lee el modelo, qué puede tocar y qué queda escrito por la mañana.
01 · Detecta · L1
Nadie te llama. Ya se dio cuenta.
Veinticuatro reglas deterministas miran el estado del clúster: crash loops, OOM, imágenes que no bajan, certificados por expirar, nodos que se van. Sin configurar nada y sin gastar un crédito de IA. Y no te dejan el hallazgo a secas: cada uno llega con su recomendación, así que puedes resolverlo tú aunque ese incidente no esté en el catálogo que Autopilot gestiona solo.
Las seis capas que recorre un incidente
Detector
reglas sobre eventos
100% deterministaRouter
clasifica y prioriza
IAInvestigator
correlaciona logs, métricas y deploys
IAPlanner
genera el plan
IAExecutor
ejecuta con guardarraíl determinista
IA + deterministaPostmortem
línea de tiempo y evidencias
IACada capítulo de abajo es una de ellas. Solo la primera es 100% determinista; la última que toca producción trabaja detrás de un guardarraíl que también lo es.
L1 Insights Engine (L1): 24 reglas de cero configuración detectan el incidente antes de que intervenga un modelo. Ver las 24 reglas →
- Las reglas corren sobre el estado actual, no sobre el historial, así que funcionan desde el primer minuto y no dependen de cuánta retención tenga tu plan.
- Detectar no cuesta créditos. Solo se gasta cuando hay que investigar, y esa decisión la toma la siguiente capa.
- Cada regla es una Skill: lleva su umbral de confianza y dice qué acciones del catálogo son válidas para ese incidente.
02 · Diagnostica · L2 a L4
El modelo propone. Nunca ejecuta.
Cuando ese dato se vuelve una pregunta, Kobi razona y propone la respuesta, pero no la ejecuta: tú autorizas, y todo queda auditado.
Backend
ejecuta las tools
resultados
LLM
proveedor de IA
propuesta
Card
aprobación humana
solo tras aprobar
Tu clúster
RBAC del agente
Las herramientas corren en el backend. El modelo solo ve resultados.
- BYOK (tu propia clave o endpoint: Azure OpenAI, vLLM, Ollama) aplica en OSS y EE Self-Hosted: el tráfico de IA va de tu instalación a tu proveedor, sin pasar por KubeBolt. En el SaaS la IA es gestionada.
- Tú autorizas cada acción y se ejecuta con el RBAC del agente; KubeBolt no suplanta tus credenciales ni tu RBAC de Kubernetes. Quién tiene solo lectura o edición lo define el admin de tu organización, y cada acción queda auditada: quién la autorizó, cuándo y qué recursos afectó.
- Un log manipulado no puede ejecutar nada. Los logs son texto que un tercero pudo escribir; por eso el modelo propone en vez de ejecutar.
La regla dice qué se rompió; saber por qué pide contexto: eventos, logs, métricas y cambios recientes. Es lo único que cruza el canal.
El agente abre la conexión. El clúster no expone ningún puerto.
- Los valores de Secret se redactan antes de salir de la capa de API. No es una política de prompt: es una validación en el servidor.
- Metadatos de red, no contenido. De cada flujo viaja origen, destino, veredicto, código y latencia, nunca el cuerpo de la petición.
- Los logs no se envían a granel. Se leen solo cuando pides un diagnóstico que los necesita.
- En self-hosted no llega nada a KubeBolt: sin telemetría de producto ni ping de uso.
03 · Remedia · L5
Kobi actúa solo. Tú apruebas lo destructivo.
Sin nadie a quien preguntar, el dato dispara a Kobi: detecta, investiga, remedia y documenta. El modelo propone; un guardarraíl determinista comprueba que la acción esté en el catálogo antes de tocar producción.
- hoy
Lo destructivo siempre lo aprueba una persona
El rollback siempre requiere aprobación, en cualquier nivel de autonomía.
- hoy
Si la verificación no pasa, Autopilot revierte
El cambio vuelve al estado previo, automáticamente.
- hoy
Cada acción queda registrada
Con su resultado y quién la aprobó.
Tres niveles de autonomía: solo sugerir (por defecto), aprobar y ejecutar, autónomo. Y apagado, si quieres. Con gate de confianza y namespaces bloqueados por clúster.
Si un paso no está en la lista, el plan se rechaza y escala a una persona.
- El plan se valida contra código, no contra un prompt. Una acción nueva exige un release, no una instrucción distinta.
- Ventana desatendida (días, horas, zona horaria) y techo de autonomía a nivel de plataforma: fuera de la ventana, el incidente se registra, no se actúa.
04 · Verifica y revierte
Si el arreglo no aguanta, lo deshace y te llama.
Aplicar no es resolver. Autopilot guarda los valores previos antes de tocar nada, comprueba el resultado y, si no pasa, restaura y escala a una persona. Funciona hoy, no está en el roadmap.
Guarda el estado previo
Los valores que va a cambiar quedan capturados antes de aplicar nada, así el revert restaura exactamente lo que había.
Comprueba el resultado
Espera a que los pods vuelvan a Ready y a que dejen de reiniciarse. No basta con que la acción se aplique sin error.
Revierte si no pasa
En modo autónomo, si la verificación falla o el ejecutor cae, el cambio se deshace solo. Un rollback que necesite aprobación no se auto-ejecuta: te espera.
Escala a una persona
El incidente queda como "necesita a alguien", con lo que se intentó y por qué no funcionó. Ese es el final honesto cuando el catálogo no alcanza.
Y si la confianza del diagnóstico no llega al umbral de su regla, Autopilot no llega ni a aplicar: deja el plan como sugerencia.
05 · Postmortem · L6
Por la mañana ya está escrito.
El último paso no arregla nada: lo cuenta. Línea de tiempo, qué se probó, qué lo resolvió y con qué evidencias, listo para pegar en el canal o en el ticket.
La línea de tiempo
De la primera señal al último pod Ready, con las horas reales y lo que pasó entre medias.
El registro de acciones
Qué se ejecutó, con qué resultado y quién lo aprobó. En modo autónomo la aprobación queda a nombre de Autopilot, no de una persona cualquiera.
Las cinco preguntas
Un borrador de análisis con acciones propuestas. Lo escribe el modelo; lo firmas tú.
06 · Qué instalas y qué no
Un agente, un canal saliente, y nada más.
Esto es lo que pones dentro de tu clúster para que pueda hacerlo, y lo que sigue siendo tuyo.
El modelo de acceso
Los dashboards tradicionales tocan tu API server. KubeBolt invierte la dirección: el agente sale, no entra, y sobre eso se apoya todo lo demás.
Modelo tradicional
Lens · Kite · K9s · kubectl directo
Cliente
kubeconfig
inbound
API Server
(público)
- El API server debe ser accesible desde el cliente
- Credenciales en cada máquina de usuario
- Clústeres privados requieren VPN o jump host
- Auditoría vive en el clúster, no centralizada
Modelo KubeBolt
Agent outbound · el clúster permanece privado
Control Plane
KubeBolt
saliente
gRPC
CLÚSTER PRIVADO
Agent
ServiceAccount
- El API server permanece privado, nunca se expone
- Credenciales solo en el agente (ServiceAccount de Kubernetes)
- Funciona en GKE/EKS privados y VPCs aisladas
- Auditoría centralizada en el control plane de KubeBolt
De dónde salen las métricas
El agente se adapta a lo que ya tienes: toma las métricas del kubelet o consulta tu Prometheus, sin que rehagas tu observabilidad.
CLÚSTER PRIVADO
Modo DaemonSet
kubelet + Hubble
Modo Prom-read
lee tu Prometheus
Integraciones
OpenCost · Trivy · Kyverno · Falco · ArgoCD
un solo canal
VictoriaMetrics
serie temporal
Los dos modos conviven, cada uno en su pod y con su propio buffer.
- Modo DaemonSet, sin dependencias previas: un pod por nodo toma métricas del kubelet y, si tienes Cilium, eventos de flujo de Hubble.
- Modo Prom-read, sin tocar tu configuración: para AMP, Azure Monitor o GMP que no pueden hacer remote_write hacia afuera, KubeBolt consulta tu Prometheus y reenvía las series.
- Las integraciones se detectan solas: OpenCost, Trivy, Kyverno, Falco y ArgoCD no hay que declararlos. Si están en el clúster, se usan.
Cuánto se guarda
El dato descansa en VictoriaMetrics. Cuánto puedes mirar hacia atrás depende de tu plan, o de tu disco si lo operas tú.
La retención mide cuánto hacia atrás puedes consultar. Los detectores del Insights Engine corren sobre el estado actual, así que no dependen de ella.
En self-hosted mandas tú.
La retención es un valor de tu chart de Helm. No imponemos topes sobre datos que viven en tu disco.
Lo que ocupa, en concreto.
Alrededor de 1 GB por cada 100 pods a 30 días. Un clúster de 60 pods entra por debajo de 1 GB. Manda la cardinalidad, no los días.
El estado del clúster no se persiste.
Pods, deployments y demás objetos viven en memoria y se reconstruyen desde los informers al reconectar.
07 · Además, el panel
Todo lo que harías con kubectl. Desde el navegador.
Sobre ese mismo canal operas el clúster entero, no solo lo miras: terminal, logs, filesystem, port-forward y edición de recursos, desde el navegador.
01
Terminal interactiva en cualquier pod
Sesiones exec con stdin/stdout/stderr completos. Multi-pod, multi-clúster, desde el navegador. Sin kubeconfig en el cliente, sin VPN, sin acceso al API server.
kubectl exec via agent02
Filesystem inspection en runtime
Navega el sistema de archivos de pods en ejecución: directorios, archivos generados por la app, configuración cargada al startup, certificados, volúmenes montados con datos reales.
Más útil que inspeccionar la imagen estática: ves qué está pasando ahora, no qué venía empaquetado.
runtime fs · no imagen03
Lectura de logs multi-pod
Lectura on-demand a nivel de workload, con agregación cross-pod en deployments con réplicas. Se leen cuando los necesitas, sin esperar a tu observability stack y sin stream continuo.
logs on-demand04
Port-forward sin exposición
Acceso a UIs internas (Grafana, ArgoCD, herramientas privadas) sin LoadBalancers ni Ingress públicos. El túnel va por el agente, los servicios permanecen privados.
tunneling via agent05
CRUD completo de recursos
Create, update, delete, scale, restart, rollout vía UI o API, con validación inline y CRDs nativos. El borrado de Namespaces, Nodes, PV, PVC y recursos de RBAC está vetado por diseño.
kubectl surface06
Multi-clúster por defecto
Un agente por clúster, todos visibles desde el mismo control plane. Sin juggling de kubeconfigs, sin context-switching mental. El clúster es solo otro filtro en la UI.
fleet-native08 · Si usas GitOps Roadmap · en diseño
Si usas GitOps, el arreglo va al repo.
Un arreglo en el clúster se va con el próximo deploy. Autopilot ya verifica cada arreglo y lo revierte si empeora; lo que viene es que quede escrito en tu repo, donde vive la verdad.
Causa raíz
Kobi, en Copilot o en Autopilot, identifica el fallo
Origen
se resuelve el repo desde la CR de ArgoCD
Pull Request
diff mínimo sobre la fuente
Merge
tu equipo revisa, tus checks mandan
KubeBolt no toca el clúster: escribe donde vive la verdad.
- Nunca se abre un PR a ciegas: antes se confirma que ese archivo produce exactamente ese workload. Si no, queda como recomendación y se explica por qué.
- Tu proceso manda: se respeta la protección de rama. Auto-merge significa mergear cuando tus checks pasen, nunca omitirlos.
09 · Lo que realmente es KubeBolt
La mayoría de las herramientas miran. KubeBolt opera.
«KubeBolt no es un dashboard con AI añadido. Es una plataforma de AI operations para Kubernetes.
Tu clúster se auto-diagnostica con runbooks deterministas y agentes de IA construidos sobre Claude Agent SDK, y resuelve el incidente solo cuando puede. Sin exponer tu API server: el agente abre la conexión saliente y el clúster sigue siendo privado.
La UI es excelente, pero el producto son dos piezas: el Core (API), donde vive el motor de correlación, y el agente que le lleva los hechos sin exponer nada.»
Leafar Maina · Founder, CLM Cloud Solutions
Recibe las novedades de cada release → Cómo tratamos tus datos: confianza y privacidad →