Kubernetes
O Ongrid roda no Kubernetes mas não é um alvo de deployment first-class. O caminho de instalação padrão é docker compose em um único host Linux, porque é o caminho mais rápido de git clone a um https://your-host/ funcionando. K8s é para operadores que já têm uma plataforma Kubernetes e querem encaixar o Ongrid nela.
Status do Helm chart
Ainda não há Helm chart oficial. O tarball de release distribui deploy/docker-compose.yml e os scripts de instalação que envolvem ele — sem deploy/charts/, sem kustomize/. Se você precisa fazer deploy no K8s hoje, traduza o compose file à mão. Um chart da comunidade está no roadmap; acompanhe no issue tracker do GitHub.
O que o compose file te dá, os equivalentes que você vai precisar:
| Serviço Compose | Equivalente K8s |
|---|---|
mysql | StatefulSet (1 replica) + Service headless + PVC |
ongrid | Deployment (1 replica) + Service ClusterIP para :8080 (/api) e :9100 (/metrics) |
nginx (porta da frente) | Deployment + LoadBalancer/Ingress para :443 e :80 |
frontier | Deployment + LoadBalancer/NodePort para a porta de tunnel :40012 |
prometheus | StatefulSet + PVC, ou seu kube-prom-stack existente |
loki | StatefulSet + PVC, ou seu loki-distributed existente |
tempo | StatefulSet + PVC |
grafana | Deployment + PVC, ou seu grafana existente |
searxng | Deployment + ClusterIP |
Use ConfigMap + Secret para o env ONGRID_*. Monte o mesmo cert TLS no pod do nginx que você monta na stack do compose.
O manager deve rodar no K8s?
Resposta honesta: funciona, mas você não ganha muito disso. O manager é um processo único com estado persistente (MySQL) e não é horizontalmente escalável — rodar dois pods atrás de um Service quebra o evaluator de alerta in-process, o roteador de sessão de chat, e os caches do tool registry do kernel do agent. Então você está rodando um Deployment de 1 replica com um PVC, que é fundamentalmente a mesma forma de uma VM com Docker, só que com mais YAML.
Onde o K8s te compra algo:
- Você já tem ingress / cert-manager / external-DNS conectados — reaproveite-os para a porta da frente do manager.
- Você já tem um MySQL gerenciado (RDS / CloudSQL / Vitess) — aponte
ONGRID_DB_DSNpara ele e descarte o StatefulSet. - Você já tem uma stack Prometheus / Loki / Tempo — aponte
ONGRID_PROM_URL,ONGRID_LOG_QUERY_URL,ONGRID_TRACE_QUERY_URLpara eles e descarte aqueles StatefulSets.
Depois das substituições, "manager no K8s" se reduz a dois Deployments (manager + nginx) mais um Service por upstream que você reaproveitou.
Edge no K8s — padrão daemonset
Se seu workload roda no K8s e você quer observabilidade por nó, rode o edge agent como um DaemonSet. Um pod de agent por nó, hostPath em /proc, /sys, o journal do nó, e o syslog do nó.
Esboço:
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 } }
# casos raros (skills de network introspection read-only)
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 } }Você vai precisar de uma imagem Docker de ongrid-edge — make docker-ongrid-edge produz uma (ongrid-edge:<version>). Faça push para seu registry privado.
O mesmo par access/secret é reaproveitado por cada nó. A página Edges do manager vai mostrar uma linha por nó, deduplicada por hostname.
Edge no K8s — padrão sidecar
Se você só quer observar um app — não o nó inteiro — rode o edge agent como um sidecar no pod desse app. Mesma imagem, mesmas env vars, sem hostPath. Você perde métricas de host (o collector gopsutil vai retornar a view do pod, não a do nó) mas ganha escopo mais estreito.
Este é o formato certo quando:
- Múltiplos times compartilham um cluster e cada time quer seu próprio manager / tenant Ongrid.
- Você não tem permissão para rodar DaemonSets privilegiados.
- Você só se importa com logs e traces de um workload.
O que NÃO funciona
ongridrodando em múltiplas replicas. O manager é stateful in-process: estado do evaluator de alerta, roteador de sessão de chat, caches do kernel do agent são todos single-instance. Um Deployment de 2-replicas vai produzir notificações duplicadas, fazer race no evaluator de alerta, e dividir sessões de chat entre instâncias. Rode uma replica.- O instalador curl-pipe dentro de um pod. Falha duro sem systemd. Use a imagem em vez disso.
- O upgrade staged-bundle do ADR-024. O hook é um shell script Linux conectado ao systemd. No K8s você faz upgrade mudando a tag da imagem e fazendo roll do DaemonSet — o caminho de swap in-place é bypassed.
- NodePort para porta 40012. Funciona, mas cada conexão de edge faz re-hash quando o nó atrás do NodePort muda. Prefira um LoadBalancer para o listener de tunnel, ou exponha o broker frontier num nó dedicado.
Roadmap
- Um Helm chart com defaults sensatos (manager de 1-replica, MySQL / Prom / Loki / Tempo opcionalmente bundled).
- Um operator CRD-driven que pega um recurso
ManagereEdgePool, gera o par access/secret automaticamente, e rolla upgrades. - Um plugin de edge k8s-native que lê logs de pod via API do kubelet em vez de journald, para que logs cluster-locais não exijam hostPath.
Nenhum desses está comprometido a uma release; veja as issues do GitHub se você quer ajudar a tocá-los.