Kubernetes
Ongrid corre en Kubernetes pero no es un target de despliegue first-class. La ruta de install default es docker compose en un único host Linux, porque ese es el path más rápido de git clone a un https://your-host/ funcional. K8s es para operadores que ya tienen una plataforma Kubernetes y quieren encajar Ongrid en ella.
Estado del Helm chart
No hay Helm chart oficial aún. El tarball de release distribuye deploy/docker-compose.yml y los scripts de install que lo envuelven — sin deploy/charts/, sin kustomize/. Si necesitas desplegar en K8s hoy, traduces el archivo compose a mano. Un chart comunitario está en la roadmap; trackéalo en el tracker de issues de GitHub.
Lo que el archivo compose te da, los equivalentes que necesitarás:
| Servicio compose | Equivalente K8s |
|---|---|
mysql | StatefulSet (1 réplica) + Service headless + PVC |
ongrid | Deployment (1 réplica) + Service ClusterIP para :8080 (/api) y :9100 (/metrics) |
nginx (front door) | Deployment + LoadBalancer/Ingress para :443 y :80 |
frontier | Deployment + LoadBalancer/NodePort para el puerto del túnel :40012 |
prometheus | StatefulSet + PVC, o tu kube-prom-stack existente |
loki | StatefulSet + PVC, o tu loki-distributed existente |
tempo | StatefulSet + PVC |
grafana | Deployment + PVC, o tu grafana existente |
searxng | Deployment + ClusterIP |
Usa ConfigMap + Secret para los env ONGRID_*. Monta el mismo cert TLS al pod de nginx que montas en el stack compose.
¿Debería el manager correr en K8s?
Respuesta honesta: funciona, pero no sacas mucho de eso. El manager es un único proceso con estado persistente (MySQL) y no es horizontalmente escalable — correr dos pods detrás de un Service rompe el alert evaluator in-process, el router de sesión de chat y los caches del registry de tools del kernel del agente. Así que estás corriendo un Deployment de 1 réplica con un PVC, que es fundamentalmente la misma forma que una VM con Docker, solo con más YAML.
Donde K8s te compra algo:
- Ya tienes ingress / cert-manager / external-DNS cableado — reúsalos para el front door del manager.
- Ya tienes un MySQL managed (RDS / CloudSQL / Vitess) — apunta
ONGRID_DB_DSNa él y drop el StatefulSet. - Ya tienes un stack Prometheus / Loki / Tempo — apunta
ONGRID_PROM_URL,ONGRID_LOG_QUERY_URL,ONGRID_TRACE_QUERY_URLa ellos y drop esos StatefulSets.
Después de las sustituciones, "manager en K8s" se reduce a dos Deployments (manager + nginx) más un Service por cada upstream que reusaste.
Edge en K8s — patrón daemonset
Si tu workload corre en K8s y quieres observabilidad por-node, corre el agente edge como un DaemonSet. Un pod de agente por node, hostPath a /proc, /sys, el journal del node y el syslog del node.
Sketch:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ongrid-edge
namespace: ongrid
spec:
selector: { matchLabels: { app: ongrid-edge } }
template:
metadata: { labels: { app: ongrid-edge } }
spec:
hostPID: true
hostNetwork: false # tunnel is outbound; no need for hostNetwork
containers:
- name: edge
image: your-registry/ongrid-edge:vX.Y.Z
env:
- name: ONGRID_EDGE_CLOUD_ADDR
value: ongrid.example.com:40012
- name: ONGRID_EDGE_ACCESS_KEY
valueFrom: { secretKeyRef: { name: ongrid-edge, key: access_key } }
- name: ONGRID_EDGE_SECRET_KEY
valueFrom: { secretKeyRef: { name: ongrid-edge, key: secret_key } }
# rare cases (read-only network introspection skills)
securityContext:
capabilities: { add: ["NET_ADMIN"] }
volumeMounts:
- { name: proc, mountPath: /host/proc, readOnly: true }
- { name: sys, mountPath: /host/sys, readOnly: true }
- { name: jrnl, mountPath: /var/log/journal, readOnly: true }
volumes:
- { name: proc, hostPath: { path: /proc } }
- { name: sys, hostPath: { path: /sys } }
- { name: jrnl, hostPath: { path: /var/log/journal } }Necesitarás una imagen Docker de ongrid-edge — make docker-ongrid-edge produce una (ongrid-edge:<version>). Pusheala a tu registry privado.
El mismo par access/secret se reutiliza por cada node. La página Edges del manager mostrará una fila por node, deduplicada por hostname.
Edge en K8s — patrón sidecar
Si solo quieres observar una app — no el node entero — corre el agente edge como sidecar en el pod de esa app. Misma imagen, mismas env vars, sin hostPath. Pierdes host metrics (el collector gopsutil devolverá la vista del pod, no del node) pero ganas alcance más estrecho.
Esta es la forma correcta cuando:
- Múltiples equipos comparten un cluster y cada equipo quiere su propio manager / tenant de Ongrid.
- No tienes permiso para correr DaemonSets privilegiados.
- Solo te importan los logs y trazas de un workload.
Qué NO funciona
ongridcorriendo a través de múltiples réplicas. El manager es stateful in-process: estado del alert evaluator, router de sesión de chat, caches del kernel del agente son todos single-instance. Un Deployment de 2 réplicas producirá notificaciones duplicadas, hará race del alert evaluator y partirá sesiones de chat a través de instancias. Corre una réplica.- El installer curl-pipe dentro de un pod. Falla duro sin systemd. Usa la imagen en su lugar.
- El upgrade de bundle staged de ADR-024. El hook es un script shell Linux cableado a systemd. En K8s upgradeas cambiando el image tag y rolando el DaemonSet — el path de swap in-place se bypassa.
- NodePort para el puerto 40012. Funciona, pero cada conexión de edge re-hashea cuando el node detrás del NodePort cambia. Prefiere un LoadBalancer para el listener del túnel, o expón el broker frontier en un node dedicado.
Roadmap
- Un Helm chart con defaults sensatos (manager de 1 réplica, MySQL / Prom / Loki / Tempo bundled opcional).
- Un operador CRD-driven que tome un recurso
ManageryEdgePool, genere el par access/secret automáticamente y rollee upgrades. - Un plugin edge k8s-native que lea pod logs vía la API del kubelet en vez de journald, para que los logs cluster-local no requieran hostPath.
Ninguno de estos está comprometido a un release; ver los issues de GitHub si quieres ayudar a impulsarlos.