Kubernetes

Ongrid läuft auf Kubernetes, aber es ist kein erstklassiges Deployment-Ziel. Der Standard-Install-Pfad ist docker compose auf einem einzelnen Linux-Host, weil das der schnellste Pfad von git clone zu einem funktionierenden https://your-host/ ist. K8s ist für Operatoren, die bereits eine Kubernetes-Plattform haben und Ongrid darin einpassen wollen.

Helm-Chart-Status

Es gibt noch keinen offiziellen Helm-Chart. Das Release-Tarball liefert deploy/docker-compose.yml und die Install-Skripte aus, die es wickeln — kein deploy/charts/, kein kustomize/. Wenn Sie heute auf K8s deployen müssen, übersetzen Sie die Compose-Datei von Hand. Ein Community-Chart steht auf der Roadmap; tracken Sie es auf dem GitHub-Issue-Tracker.

Was die Compose-Datei Ihnen gibt, die Äquivalente, die Sie brauchen werden:

Compose-Service	K8s-Äquivalent
mysql	StatefulSet (1 Replica) + Headless-Service + PVC
ongrid	Deployment (1 Replica) + ClusterIP-Service für :8080 (/api) und :9100 (/metrics)
nginx (Frontdoor)	Deployment + LoadBalancer/Ingress für :443 und :80
frontier	Deployment + LoadBalancer/NodePort für den Tunnel-Port :40012
prometheus	StatefulSet + PVC, oder Ihr bestehender kube-prom-stack
loki	StatefulSet + PVC, oder Ihr bestehender loki-distributed
tempo	StatefulSet + PVC
grafana	Deployment + PVC, oder Ihr bestehender grafana
searxng	Deployment + ClusterIP

Verwenden Sie ConfigMap + Secret für die ONGRID_* env. Mounten Sie dasselbe TLS-Zertifikat in den nginx-Pod, das Sie in den Compose-Stack mounten.

Sollte der Manager auf K8s laufen?

Ehrliche Antwort: es funktioniert, aber Sie bekommen nicht viel daraus. Der Manager ist ein einzelner Prozess mit persistentem Zustand (MySQL) und ist nicht horizontal skalierbar — zwei Pods hinter einem Service laufen zu lassen bricht den In-Process-Alarm-Evaluator, den Chat-Session-Router und die Agent-Kernel-Tool-Registry-Caches. Sie laufen also ein 1-Replica-Deployment mit einem PVC, was fundamental dieselbe Form wie eine VM mit Docker ist, nur mit mehr YAML.

Wo K8s Ihnen etwas bringt:

• Sie haben bereits Ingress / Cert-Manager / External-DNS verdrahtet — wiederverwenden Sie sie für die Manager-Frontdoor.
• Sie haben bereits eine Managed-MySQL (RDS / CloudSQL / Vitess) — richten Sie ONGRID_DB_DSN darauf aus und droppen Sie das StatefulSet.
• Sie haben bereits einen Prometheus- / Loki- / Tempo-Stack — richten Sie ONGRID_PROM_URL, ONGRID_LOG_QUERY_URL, ONGRID_TRACE_QUERY_URL darauf aus und droppen Sie diese StatefulSets.

Nach den Substitutionen reduziert sich „Manager auf K8s" auf zwei Deployments (Manager + nginx) plus einen Service pro wiederverwendetem Upstream.

Edge auf K8s — DaemonSet-Muster

Wenn Ihre Workload auf K8s läuft und Sie Per-Node-Observability wollen, laufen Sie den Edge-Agenten als DaemonSet. Ein Agent-Pod pro Knoten, hostPath in /proc, /sys, das Journal des Knotens und syslog des Knotens.

Skizze:

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 } }

Sie brauchen ein Docker-Image von ongrid-edge — make docker-ongrid-edge produziert eins (ongrid-edge:<version>). Pushen Sie es in Ihre private Registry.

Dasselbe Access/Secret-Paar wird von jedem Knoten wiederverwendet. Die Edges-Seite des Managers zeigt eine Zeile pro Knoten, dedupliziert nach Hostnamen.

Edge auf K8s — Sidecar-Muster

Wenn Sie nur eine App beobachten wollen — nicht den ganzen Knoten — laufen Sie den Edge-Agenten als Sidecar im Pod dieser App. Gleiches Image, gleiche env-Variablen, kein hostPath. Sie verlieren Host-Metriken (der gopsutil-Collector wird die Sicht des Pods zurückgeben, nicht die des Knotens), gewinnen aber engeren Scope.

Das ist die richtige Form, wenn:

• Mehrere Teams einen Cluster teilen und jedes Team seinen eigenen Ongrid-Manager / Tenant will.
• Sie keine Berechtigung haben, privilegierte DaemonSets zu laufen.
• Sie nur die Logs und Traces einer Workload interessieren.

Was NICHT funktioniert

• ongrid läuft über mehrere Replicas. Der Manager ist In-Process zustandsbehaftet: Alarm-Evaluator-State, Chat-Session-Router, Agent-Kernel-Caches sind alle Single-Instance. Ein 2-Replica-Deployment wird doppelte Benachrichtigungen produzieren, den Alarm-Evaluator rennen lassen und Chat-Sessions über Instanzen aufteilen. Laufen Sie eine Replica.
• Der curl-pipe-Installer innerhalb eines Pods. Er scheitert hart ohne systemd. Verwenden Sie stattdessen das Image.
• Das ADR-024 Staged-Bundle-Upgrade. Der Hook ist ein Linux-Shell-Skript, in systemd verdrahtet. Auf K8s upgraden Sie, indem Sie den Image-Tag ändern und das DaemonSet rollen — der In-Place-Swap-Pfad wird umgangen.
• NodePort für Port 40012. Funktioniert, aber jede Edge-Verbindung re-hasht, wenn der Knoten hinter dem NodePort wechselt. Bevorzugen Sie einen LoadBalancer für den Tunnel-Listener, oder exponieren Sie den Frontier-Broker auf einem dedizierten Knoten.

Roadmap

• Ein Helm-Chart mit vernünftigen Defaults (1-Replica-Manager, optional gebündelte MySQL / Prom / Loki / Tempo).
• Ein CRD-getriebener Operator, der eine Manager- und EdgePool-Ressource nimmt, das Access/Secret-Paar automatisch generiert und Upgrades rollt.
• Ein k8s-natives Edge-Plugin, das Pod-Logs via die Kubelet-API liest statt journald, sodass Cluster-lokale Logs kein hostPath erfordern.

Keines davon ist auf ein Release committet; siehe die GitHub-Issues, wenn Sie helfen wollen, sie voranzutreiben.