Skip to content

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 ComposeEquivalente K8s
mysqlStatefulSet (1 replica) + Service headless + PVC
ongridDeployment (1 replica) + Service ClusterIP para :8080 (/api) e :9100 (/metrics)
nginx (porta da frente)Deployment + LoadBalancer/Ingress para :443 e :80
frontierDeployment + LoadBalancer/NodePort para a porta de tunnel :40012
prometheusStatefulSet + PVC, ou seu kube-prom-stack existente
lokiStatefulSet + PVC, ou seu loki-distributed existente
tempoStatefulSet + PVC
grafanaDeployment + PVC, ou seu grafana existente
searxngDeployment + 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_DSN para ele e descarte o StatefulSet.
  • Você já tem uma stack Prometheus / Loki / Tempo — aponte ONGRID_PROM_URL, ONGRID_LOG_QUERY_URL, ONGRID_TRACE_QUERY_URL para 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:

yaml
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-edgemake 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

  • ongrid rodando 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 Manager e EdgePool, 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.