Cyphernetes: Revoluciona tu Kubernetes
Cyphernetes es un lenguaje de query inspirado en Cypher (de Neo4j) que permite consultarle a Kubernetes de forma gráfica e intuitiva. Creado por Avital Tamir y distribuido bajo Apache 2.0, permite expresar operaciones complejas sobre recursos del cluster usando sintaxis de grafos, reemplazando bash pipelines tediosos por queries legibles que entienden relaciones entre deployments, servicios, pods y custom resources automáticamente.
En 30 segundos
- Cyphernetes es un lenguaje de query para Kubernetes inspirado en Cypher, creado por Avital Tamir y open-source bajo Apache 2.0.
- Usa sintaxis de grafos con parenthesis para nodos y arrows (->) para relaciones:
(d:Deployment) -> (s:Service). - Se instala como plugin kubectl (kubectl-cypher) vía krew, con acceso también por web UI, CLI e integración programática.
- Reemplaza bash pipelines complejos con queries legibles que entienden relaciones entre resource kinds sin configuración extra.
- Soporta Custom Resource Definitions (CRDs), queries multi-cluster y automation de workflows vía DynamicOperator.
Qué es Cyphernetes: lenguaje query para Kubernetes
Cyphernetes es un lenguaje de query declarativo para Kubernetes basado en grafos. Creado por Avital Tamir, un ingeniero de software en groundcover.com, permite expresar operaciones complejas sobre tu cluster sin necesidad de escribir bash pipelines, kubectl one-liners o scripting en Go (ojo con esto, porque cualquiera que haya intentado automatizar algo en Kubernetes sabe que terminás con un script de 200 líneas que nadie entiende).
La idea central es simple: Kubernetes es esencialmente un grafo de objetos relacionados. Un Deployment apunta a un Service. Un Service selecciona Pods. Los Pods montan Volumes. Cyphernetes entiende estas relaciones y te deja consultarlas con una sintaxis clara y expresiva.
Cómo funciona: relaciones entre recursos con arrows
Ponele que necesitás deletar todos los pods que NO están en estado Running. Con kubectl normal habrías escrito algo como:
kubectl get pods --all-namespaces --field-selector=status.phase!=Running -o json | jq '.items[] | .metadata.name' | xargs kubectl delete pod
Difícil de leer, frágil, y si se rompe algo a mitad del pipeline te quedás con una deuda técnica de troubleshooting que nadie quiere arreglar. Con Cyphernetes sería algo así:
MATCH (p:Pod {status: "NotRunning"}) DELETE (p)
La sintaxis usa paréntesis para nodos, flechas para relaciones y una DSL inspirada en Cypher. Los nodos se definen con tipo (`:Pod`, `:Deployment`, `:Service`) y propiedades opcionales en llaves. Las relaciones se expresan con `->` o `<-` indicando dirección. MATCH busca, RETURN devuelve, CREATE genera, DELETE elimina, UPDATE modifica. Sobre eso hablamos en ejecutar agentes sin APIs externas.
Lo que es genial: Cyphernetes entiende automáticamente las relaciones entre resource kinds de Kubernetes. No tenés que decirle “los Deployments apuntan a Pods vía selector labels” — el motor de query lo sabe. Eso significa queries más cortas y menos propenso a errores.
Instalación y modos de uso
Cyphernetes está organizado como un monorepo con múltiples componentes: el core en Go, un CLI, un cliente web en TypeScript, y un Kubernetes operator. La forma más simple de instalarlo es como plugin de kubectl vía krew:
kubectl krew install cypher
Luego accedés vía:
- CLI plugin:
kubectl cypher MATCH (...) RETURN (...) - Web UI: interfaz interactiva para queries, con autocomplete y visualización de resultados
- Interactive shell: REPL donde escribís queries de forma iterativa
- Go API: importás como librería para integrar en tus propios scripts
- Kubernetes operator: para automatizar workflows complejos dentro del cluster
Si no usás krew, podés clonar el repo de GitHub y compilar manualmente. El proyecto está en https://github.com/AvitalTamir/cyphernetes y la documentación del lenguaje en https://cyphernet.es/docs/language.
Ejemplos prácticos: queries reales que simplifican kubectl
Acá se ponen interesantes las cosas. Veamos ejemplos que resuelven problemas reales que tenés en producción.
Buscar y deletar pods no-running
MATCH (p:Pod {status: "NotRunning"}) DELETE (p)
Eso. Una línea. Sin piping, sin jq, sin confundir el selector de labels (que en Kubernetes no es trivial).
Tracer relaciones entre Deployments y Services
MATCH (d:Deployment) -> (s:Service) RETURN d.metadata.name, s.metadata.name
Eso te muestra qué Services están sirviendo a qué Deployments. Probá hacer eso con kubectl sin enloquecer. Cubrimos ese tema en detalle en seguridad y privacidad en desarrollo.
Crear un Service desde un Deployment existente
MATCH (d:Deployment {name: 'nginx'}) CREATE (d) -> (s:Service {name: 'nginx-svc', port: 80})
Esto es más complejo porque CREATE en Cyphernetes no es un “crear de la nada” sino un “expresar una relación que quiero que exista” y el operator se encarga de hacerlo realidad en el cluster. Pero la idea es que automatizás tareas complejas sin escribir YAML o scripting manual.
Características avanzadas: CRDs, multi-cluster y automation
Lo que distingue a Cyphernetes de las alternativas es el soporte automático para Custom Resource Definitions (CRDs). Si tu cluster tiene CRDs custom, Cyphernetes los descubre e indexa automáticamente. No tenés que decirle “che, existe este tipo de recurso”. Eso significa que podés escribir queries sobre ArgoCD ApplicationSets, Prometheus Rules, Kyverno ClusterPolicies o cualquier cosa custom que tengas instalada, todo con la misma sintaxis.
El DynamicOperator es un componente que vive dentro del cluster y ejecuta workflows declarativos. Subís un manifest que describe qué queries correr y en qué orden, qué hacer con los resultados, y el operator lo automatiza. Es como Argo Workflows pero con sintaxis Cyphernetes.
Multi-cluster: Cyphernetes puede quedarle hablando a múltiples clusters sin necesidad de configuración extra, siempre que tengas kubeconfig con contextos. Una query única puede traer datos de todos los clusters (ahora, si querés correlacionar datos entre clusters de verdad, eso ya es más complejo).
Cyphernetes vs alternativas: KubeQL, kubectl-sql, Kube-Query y otros
Existen otros intentos de query languages para Kubernetes, pero ninguno con el alcance de Cyphernetes. Veamos cómo se compara:
| Herramienta | Enfoque | Sintaxis | CRD support | Estado |
|---|---|---|---|---|
| Cyphernetes | Graph-based, Cypher-inspired, automation | Cypher (grafos) | Automático, out-of-box | Activo, Apache 2.0 |
| KubeQL | Educational, SQL-like toy project | SQL | No | Abandonado (learning tool) |
| kubectl-sql | SQL puro sobre kubectl output | SQL estándar | Limitado | Esporádico |
| Kube-Query | Monitoring y alerting en real-time | osquery (SQL-like) | No | Mantenido, enfoque observabilidad |
| Kugl | SQLite backend para Kubernetes | SQL | Experimental | Experimental |
KubeQL es basicamente un playground para aprender cómo escribir parsers SQL, no algo que uses en producción. kubectl-sql funciona pero es frágil (si cambia el output de kubectl, se rompe). Kube-Query es bueno si lo que querés es monitoring y alerting, pero no para automation. Cyphernetes es el único que fue pensado desde cero como un lenguaje de expresión de grafos para Kubernetes. Para más detalles técnicos, mirá orquestar herramientas de inteligencia artificial.
Casos de uso real: cuándo es útil Cyphernetes
DevOps y platform engineers debugging clusters complejos. Cuando tenés 200 namespaces y necesitás saber qué Ingress apunta a qué Deployment y por qué uno está caído, Cyphernetes es tu aliado. Una query y tenés la visibilidad.
Automatización de workflows complejos sin necesidad de scripting Go o Helm hooks custom. Necesitás “cuando un Deployment escala a más de 5 replicas, disparar un job de presupuesto”. Cyphernetes + DynamicOperator lo hace declarativo (que no es poco).
SREs y architects monitoreando dependencias entre aplicaciones en ambientes grandes. “Dame todos los Pods en namespace X que estén esperando un Secret que no existe”. Queries multi-namespace, multi-cluster.
Troubleshooting de red intra-cluster. Pods que no pueden conectarse a Services, NetworkPolicies que bloquean tráfico involuntariamente. Cyphernetes te deja trazar esas relaciones rápidamente.
Errores comunes
Pensar en Cyphernetes como “SQL para Kubernetes”
No es. Es Cypher, que es un lenguaje de grafos. Las sintaxis parecidas (MATCH, RETURN) pueden confundir, pero la semántica es diferente. En SQL pensás en tablas y joins. En Cypher pensás en nodos y relaciones. Si intentás escribir queries SQL, van a fallar.
Asumir que DELETE es inmediato en el cluster
Cyphernetes construye un plan de ejecución y te lo muestra antes de aplicarlo (cuando usás el web client o el REPL). Pero en modo no-interactivo, DELETE va directo. Probá siempre en un namespace de test primero, y usá el flag --dry-run que muchos modos soportan (verificá en docs porque depende de tu versión).
No entender el DynamicOperator vs queries manuales
El DynamicOperator es para automation permanente dentro del cluster. Si solo querés queries puntuales, usás kubectl cypher desde tu máquina. Mezclar los dos conceptos es un error clásico que termina en CronJobs confusos y workflows que nadie mantiene. En alternativas a plataformas tradicionales profundizamos sobre esto.
Preguntas Frecuentes
¿Qué es exactamente Cyphernetes y para qué sirve?
Cyphernetes es un lenguaje de query declarativo para Kubernetes inspirado en Cypher (de Neo4j) que permite consultarle al cluster expresando operaciones complejas en forma de grafos. Sirve para automatizar debugging, queries multi-namespace, y workflows sin escribir bash pipelines o scripting Go tedioso.
¿Cómo instalo Cyphernetes?
El camino más simple es kubectl krew install cypher. Si no usás krew, cloná el repo en https://github.com/AvitalTamir/cyphernetes y compilá con Go. Luego accedés vía CLI, web UI, REPL o como librería Go según necesites.
¿Cyphernetes soporta Custom Resource Definitions (CRDs)?
Sí, y es uno de sus puntos fuertes. Descubre CRDs automáticamente y los indexa sin configuración. Podés escribir queries sobre ArgoCD, Prometheus, Kyverno o cualquier CRD custom que tengas en el cluster.
¿Cuál es la diferencia entre Cyphernetes y kubectl-sql o KubeQL?
KubeQL es un toy project educativo. kubectl-sql es frágil porque depende del output de kubectl. Cyphernetes es el único que fue pensado como un lenguaje de grafos de verdad, con soporte automático para CRDs, multi-cluster, y automation vía DynamicOperator. Es una categoría diferente.
¿Dónde encuentro documentación y ejemplos?
Documentación oficial en https://cyphernet.es/docs/language. Código en https://github.com/AvitalTamir/cyphernetes. Hay tutoriales comunitarios en Dev.to y Medium. Para consultar sobre Kubernetes en general, donweb.com tiene artículos sobre DevOps y hosting que complementan bien este tipo de infraestructura.
Conclusión
Cyphernetes es un proyecto maduro que resuelve un problema real: hacer Kubernetes queryable sin escribir bash pipelines o scripting frágil. Para DevOps engineers, SREs y platform engineers que trabajan con clusters grandes o complejos, vale la pena probarlo.
La adopción aún es niche (no es kubectl estándar), pero la comunidad crece y hay casos de uso serios en producción. Si trabajás con Kubernetes en plataformas grandes, clusters multi-namespace o necesitás automatizar workflows complejos, Cyphernetes merece estar en tu radar. Al menos para troubleshooting y queries puntuales, la curva de aprendizaje es corta y los beneficios son inmediatos.
