Kubernetes

Ongrid запускается на Kubernetes, но это не first-class deployment target. Дефолтный путь установки — docker compose на одной Linux-машине, потому что это самый быстрый путь от git clone до рабочего https://your-host/. K8s — для операторов, у которых уже есть Kubernetes-платформа и которые хотят встроить Ongrid в неё.

Статус Helm-chart

Официального Helm-chart пока нет. Release-tarball отгружает deploy/docker-compose.yml и install-скрипты, которые его оборачивают — нет deploy/charts/, нет kustomize/. Если вам нужно развернуть на K8s сегодня, вы переводите compose-файл вручную. Community-chart на roadmap; отслеживайте на GitHub issue tracker.

Что compose-файл даёт вам, эквиваленты, которые вам понадобятся:

Compose service	K8s эквивалент
mysql	StatefulSet (1 реплика) + headless Service + PVC
ongrid	Deployment (1 реплика) + ClusterIP Service для :8080 (/api) и :9100 (/metrics)
nginx (front door)	Deployment + LoadBalancer/Ingress для :443 и :80
frontier	Deployment + LoadBalancer/NodePort для tunnel-порта :40012
prometheus	StatefulSet + PVC, или ваш существующий kube-prom-stack
loki	StatefulSet + PVC, или ваш существующий loki-distributed
tempo	StatefulSet + PVC
grafana	Deployment + PVC, или ваш существующий grafana
searxng	Deployment + ClusterIP

Используйте ConfigMap + Secret для env ONGRID_*. Смонтируйте тот же TLS-сертификат в nginx-pod, который вы монтируете в compose-стек.

Должен ли manager запускаться на K8s?

Честный ответ: работает, но вы мало что от этого получаете. Manager — единый процесс с persistent-состоянием (MySQL) и горизонтально не масштабируется — запуск двух pod'ов за Service ломает in-process alert evaluator, chat session router и кэши tool registry agent kernel. Так что вы запускаете 1-replica Deployment с PVC, что фундаментально та же форма, что VM с Docker, только с большим количеством YAML.

Где K8s что-то покупает:

• У вас уже подключены ingress / cert-manager / external-DNS — переиспользуйте их для front door manager'а.
• У вас уже есть managed MySQL (RDS / CloudSQL / Vitess) — направьте ONGRID_DB_DSN на него и сбросьте StatefulSet.
• У вас уже есть Prometheus / Loki / Tempo стек — направьте ONGRID_PROM_URL, ONGRID_LOG_QUERY_URL, ONGRID_TRACE_QUERY_URL на них и сбросьте эти StatefulSet'ы.

После подстановок «manager на K8s» сводится к двум Deployment'ам (manager + nginx) плюс Service на каждый upstream, который вы переиспользовали.

Edge на K8s — паттерн daemonset

Если ваша нагрузка работает на K8s, и вы хотите per-node observability, запустите edge-агент как DaemonSet. Один agent-pod на ноду, hostPath в /proc, /sys, journal ноды и syslog ноды.

Эскиз:

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

Вам понадобится Docker-образ ongrid-edge — make docker-ongrid-edge производит один (ongrid-edge:<version>). Push'ните его в ваш приватный registry.

Та же пара access/secret переиспользуется каждой нодой. Страница Edges manager'а покажет одну строку на ноду, дедуплицированную по hostname.

Edge на K8s — паттерн sidecar

Если вы хотите наблюдать только одно приложение — не всю ноду — запустите edge-агент как sidecar в pod'е этого приложения. Тот же образ, те же env-переменные, без hostPath. Вы теряете host-метрики (gopsutil collector вернёт вид pod'а, не ноды), но получаете более узкую область.

Это правильная форма, когда:

• Несколько команд делят кластер, и каждая команда хочет свой собственный Ongrid manager / tenant.
• У вас нет permission запускать privileged DaemonSet'ы.
• Вы заботитесь только о логах и трейсах одной нагрузки.

Что НЕ работает

• ongrid, запущенный по нескольким репликам. Manager stateful in-process: состояние alert evaluator, chat session router, кэши agent kernel — все single-instance. 2-replica Deployment произведёт дубликатные уведомления, race alert evaluator и разделит chat-сессии между instance'ами. Запускайте одну реплику.
• Curl-pipe installer внутри pod'а. Hard-fails без systemd. Используйте образ вместо этого.
• ADR-024 staged-bundle апгрейд. Hook — это Linux shell-script, подключённый к systemd. На K8s вы апгрейдите, меняя image-tag и roll'я DaemonSet — in-place swap path обходится.
• NodePort для порта 40012. Работает, но каждое edge-соединение re-hash'ится, когда нода за NodePort меняется. Предпочитайте LoadBalancer для tunnel-listener, или выставьте frontier-брокер на dedicated ноде.

Roadmap

• Helm-chart с разумными дефолтами (1-replica manager, опциональные bundled MySQL / Prom / Loki / Tempo).
• CRD-driven operator, который принимает ресурсы Manager и EdgePool, генерирует пару access/secret автоматически, и roll'ит апгрейды.
• K8s-native edge-плагин, который читает pod-логи через kubelet API вместо journald, так что cluster-local логи не требуют hostPath.

Ничто из этого не зафиксировано на релиз; см. GitHub issues, если хотите помочь продвинуть их.