Código abierto · Solo lectura · Apache 2.0
VenomOps explica en lenguaje claro por qué falla Kubernetes o EKS, convierte el hallazgo en el cambio mínimo de Terraform y, si quieres una segunda opinión con IA, revisa tus planes con un comité de agentes antes del apply. No modifica nada por su cuenta: la decisión siempre es de una persona.
sudo dnf install venom
$ venom doctor -n venom-demo SEVERIDAD ID RECURSO PROBLEMA HIGH VD-K8S-001 crashloop CrashLoopBackOff HIGH VD-K8S-002 oom OOMKilled HIGH VD-K8S-003 badimage ImagePullBackOff HIGH VD-K8S-005 probe-liveness Liveness probe falla HIGH VD-K8S-009 irsa-mal ARN de rol mal formado MEDIUM VD-K8S-007 pdb-greedy PDB imposible de cumplir LOW VD-K8S-007 pdb-orphan PDB sin Pods que cubrir ── [HIGH] VD-K8S-001 · CrashLoopBackOff en el container app Causa probable: La aplicación terminó con un error (código 1). Evidencia: • exit-code: Last state: Terminated, exitCode=1 • log-tail: fatal: missing required env DB_HOST Cómo arreglarlo (riesgo low): corregir la causa…
Qué hace
Cada comando hace una cosa y se puede encadenar con los demás: lo que uno produce, el siguiente lo entiende. Todo lo que ves en esta página es salida real.
Explica por qué algo está roto en tu clúster y cómo arreglarlo. Solo lee: no puede modificar nada.
── [HIGH] VD-K8S-002 · OOMKilled Evidencia: • exitCode=137, restartCount=4 • limits.memory=32Mi Cómo arreglarlo: Subir limits.memory de 32Mi a 64Mi
Convierte un hallazgo en un Pull Request con el cambio mínimo en Terraform. Nunca lo mezcla: lo revisa una persona.
--- a/main.tf +++ b/main.tf limits = { - memory = "32Mi" + memory = "64Mi" } Branch: fix/vd-k8s-002-oom Risk: low
Un comité de agentes revisa tu plan de Terraform, debate y deja por escrito los desacuerdos y los riesgos aceptados. Es la única función que necesita IA.
Hallazgos finales: 10 (7 high, 3 medium) Desacuerdos registrados: 8 Riesgos aceptados: 2 reliability: «falta redundancia en IGW» security: desacuerda cost: desacuerda → Resuelto: un IGW por región es la arquitectura correcta
Sobre la IA
Diagnosticar, corregir y actualizar son funciones deterministas: dan el mismo resultado cada vez y no envían nada fuera de tu red. La IA es un extra opcional en tres sitios, y solo se usa si la pides.
Funcionan sin salida a internet (salvo update), sin credenciales de AWS y sin enviar datos a ningún modelo.
Usan Amazon Bedrock en tu cuenta, sin modelo por defecto y con los secretos enmascarados antes de enviar nada.
Cómo funciona
La información fluye en una sola dirección y cada paso termina en una persona. Lo que lee el clúster nunca escribe; lo que propone un cambio nunca lo aplica.
Cómo identificar problemas
No es una lista de alertas: cada hallazgo se explica solo. Sabes qué es, dónde está, por qué lo creemos y qué hacer, sin tener que encadenar get, describe, logs y events.
critical a info. Cada regla tiene un ID estable (VD-K8S-005) que puedes buscar, filtrar o ignorar.① [HIGH] VD-K8S-005 · La probe de liveness falla ② Recurso: Pod venom-demo/probe-liveness ③ Causa probable: El endpoint de la probe devuelve 404: la ruta configurada no existe. El kubelet reinicia el contenedor cada vez que falla. ④ Evidencia: • restartCount=3 • liveness probe failed (x4): statuscode: 404 • probe-config: httpGet /no-existe:8080, periodSeconds=3, failureThreshold=1 ⑤ Cómo arreglarlo (riesgo low): 1. Corregir el path de la probe para que coincida con el endpoint de salud real. 2. Verificar si la ruta cambió entre versiones.
Qué detecta
Cada una tiene su página con el síntoma, la evidencia, cómo confirmarlo tú a mano con comandos de solo lectura y cómo arreglarlo.
El contenedor arranca, falla y se reinicia en bucle.
El kernel mató el contenedor por superar su memoria. Se puede corregir con un PR.
No se descarga la imagen. Distingue tag inexistente, credenciales, límite de descargas o red.
El scheduler no encuentra dónde colocar el Pod: recursos, taints, selectores o un PVC.
Liveness, readiness o startup. Distingue puerto, ruta, timeout, 5xx y comando fallido.
Kubelet detenido, red de Pods o runtime caídos, o presión de memoria, disco y PIDs. Con -A.
Un PodDisruptionBudget que hará colgar el próximo mantenimiento. Distingue cuatro causas.
NodePool no listo o en su límite, NodeClaim atascado. Con -A; muestra el motivo tal cual lo reporta Karpenter.
Pods sin el rol de IAM de su ServiceAccount; pueden estar usando las credenciales del nodo sin saberlo.
Casos de uso
Situaciones reales, con los comandos y qué esperar.
Sabes que algo falla pero no por dónde empezar. Una pantalla con la causa, la prueba y los pasos.
Ver el caso → MantenimientoDescubre qué PDB y qué nodos van a impedir la actualización, antes de dejar medio clúster cordonado.
Ver el caso → AutomatizaciónUn límite de memoria se convierte en un Pull Request revisable, con el plan de Terraform adjunto.
Ver el caso → Antes del applySeguridad, costes, fiabilidad y operación a la vez, con los desacuerdos por escrito.
Ver el caso → CI / cronSalida JSON validada y un script que falla si aparece algo grave. Con un rol de solo lectura.
Ver el caso → AuditoríaQué ServiceAccounts están bien cableados y cuáles usan en silencio las credenciales del nodo.
Ver el caso →Diseñado para ser seguro
Una herramienta que trabaja cerca de producción no puede confiar en que un prompt se porte bien. Estas garantías se hacen cumplir con código y tests.
El lector del clúster solo expone get y list. Un test falla si algo emite otro verbo.
Solo puede ejecutar terraform init, validate y plan. Cualquier otra orden lanza una excepción.
Abre Pull Requests, nunca los mezcla ni empuja a main. Cada PR lleva su lista de revisión.
Sin --explain, --agent o venom review no hay ninguna llamada de IA. Y no hay modelo por defecto.
Claves de AWS, tokens, contraseñas e IDs de cuenta se ocultan antes de enviar nada a un modelo o escribirlo en un PR.
El repositorio y los paquetes llevan firma GPG, y se rechazan los manipulados. Está probado, no solo declarado.
Instalación
Los paquetes incluyen todo lo necesario. Elige tu sistema:
RHEL 9, Rocky, AlmaLinux y Amazon Linux 2023, en x86_64 y aarch64. Todo: venom y kubectl-venom_doctor.
sudo tee /etc/yum.repos.d/venom.repo <<'REPO'
[venom]
name=VenomOps
baseurl=https://cloudvipers.github.io/VenomOps/rpm/$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://cloudvipers.github.io/VenomOps/venom-repo.asc
REPO
sudo dnf install venomLa primera vez, dnf muestra la huella de la clave: debe ser A7BE 1F5E 03EC 7AA9 C797 A9DE 3237 E8D7 9E6E 29C5.
Debian 12+ y Ubuntu 22.04+, en amd64 y arm64.
sudo curl -fsSL https://cloudvipers.github.io/VenomOps/venom-repo.gpg -o /usr/share/keyrings/venom.gpg
echo 'deb [signed-by=/usr/share/keyrings/venom.gpg] https://cloudvipers.github.io/VenomOps/deb stable main' | sudo tee /etc/apt/sources.list.d/venom.list
sudo apt update && sudo apt install venomSolo el diagnóstico de clústeres, como plugin de kubectl. Linux, macOS y Windows.
kubectl krew install --manifest-url=https://raw.githubusercontent.com/CloudVipers/VenomOps/main/packages/venom-doctor/venom-doctor.yaml
kubectl venom-doctor -AEstá propuesto al índice oficial de krew; cuando lo acepten bastará kubectl krew install venom-doctor.
Cada versión trae el binario para Linux, macOS y Windows, con su checksums.txt.
VERSION=0.1.5
curl -fsSLO https://github.com/CloudVipers/VenomOps/releases/download/venom-doctor-v${VERSION}/venom-doctor_v${VERSION}_linux_amd64.tar.gz
curl -fsSLO https://github.com/CloudVipers/VenomOps/releases/download/venom-doctor-v${VERSION}/checksums.txt
sha256sum -c checksums.txt --ignore-missing
tar -xzf venom-doctor_v${VERSION}_linux_amd64.tar.gz && sudo install kubectl-venom_doctor /usr/local/bin/