Kubernetes

Ongrid tourne sur Kubernetes mais ce n'est pas une cible de déploiement de première classe. Le chemin d'install par défaut est docker compose sur un seul host Linux, parce que c'est le chemin le plus rapide de git clone à un https://your-host/ fonctionnel. K8s est pour les opérateurs qui ont déjà une plateforme Kubernetes et veulent intégrer Ongrid dedans.

Statut de la Helm chart

Il n'y a pas encore de Helm chart officielle. Le tarball de release livre deploy/docker-compose.yml et les scripts d'install qui l'enveloppent — pas de deploy/charts/, pas de kustomize/. Si vous devez déployer sur K8s aujourd'hui, vous traduisez le fichier compose à la main. Une chart communautaire est sur la roadmap ; suivez-la sur le tracker d'issues GitHub.

Ce que le fichier compose vous donne, les équivalents dont vous aurez besoin :

Service compose	Équivalent K8s
mysql	StatefulSet (1 replica) + Service headless + PVC
ongrid	Deployment (1 replica) + Service ClusterIP pour :8080 (/api) et :9100 (/metrics)
nginx (porte d'entrée)	Deployment + LoadBalancer/Ingress pour :443 et :80
frontier	Deployment + LoadBalancer/NodePort pour le port du tunnel :40012
prometheus	StatefulSet + PVC, ou votre kube-prom-stack existant
loki	StatefulSet + PVC, ou votre loki-distributed existant
tempo	StatefulSet + PVC
grafana	Deployment + PVC, ou votre grafana existant
searxng	Deployment + ClusterIP

Utilisez ConfigMap + Secret pour les env ONGRID_*. Montez le même cert TLS dans le pod nginx que vous montez dans la stack compose.

Le manager devrait-il tourner sur K8s ?

Réponse honnête : ça marche, mais vous n'en tirez pas grand-chose. Le manager est un processus unique avec état persistant (MySQL) et n'est pas scalable horizontalement — exécuter deux pods derrière un Service casse l'evaluator d'alerte in-process, le router de session de chat, et les caches du registre d'outils du kernel d'agent. Donc vous exécutez un Deployment 1-replica avec un PVC, ce qui est fondamentalement la même forme qu'une VM avec Docker, juste avec plus de YAML.

Là où K8s vous apporte quelque chose :

• Vous avez déjà ingress / cert-manager / external-DNS câblés — réutilisez-les pour la porte d'entrée du manager.
• Vous avez déjà un MySQL managé (RDS / CloudSQL / Vitess) — pointez ONGRID_DB_DSN dessus et droppez le StatefulSet.
• Vous avez déjà une stack Prometheus / Loki / Tempo — pointez ONGRID_PROM_URL, ONGRID_LOG_QUERY_URL, ONGRID_TRACE_QUERY_URL dessus et droppez ces StatefulSets.

Après les substitutions, « manager sur K8s » se réduit à deux Deployments (manager + nginx) plus un Service par upstream que vous avez réutilisé.

Edge sur K8s — pattern daemonset

Si votre workload tourne sur K8s et que vous voulez de l'observabilité par nœud, exécutez l'agent edge comme DaemonSet. Un pod agent par nœud, hostPath vers /proc, /sys, le journal du nœud, et le syslog du nœud.

Esquisse :

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

Vous aurez besoin d'une image Docker de ongrid-edge — make docker-ongrid-edge en produit une (ongrid-edge:<version>). Poussez-la vers votre registry privé.

La même paire access/secret est réutilisée par chaque nœud. La page Edges du manager affichera une ligne par nœud, dédoublonnée par hostname.

Edge sur K8s — pattern sidecar

Si vous voulez seulement observer une seule app — pas tout le nœud — exécutez l'agent edge comme sidecar dans le pod de cette app. Même image, mêmes variables d'env, pas de hostPath. Vous perdez les métriques host (le collecteur gopsutil renverra la vue du pod, pas du nœud) mais gagnez un scope plus étroit.

C'est la bonne forme quand :

• Plusieurs équipes partagent un cluster et chaque équipe veut son propre manager / tenant Ongrid.
• Vous n'avez pas la permission d'exécuter des DaemonSets privilégiés.
• Vous ne vous souciez que des logs et traces d'un workload.

Ce qui NE marche PAS

• ongrid tournant à travers plusieurs replicas. Le manager est stateful in-process : l'état de l'evaluator d'alerte, le router de session de chat, les caches du kernel d'agent sont tous mono-instance. Un Deployment 2-replicas produira des notifications dupliquées, fera courir l'evaluator d'alerte, et splittera les sessions de chat à travers les instances. Exécutez une réplique.
• L'installer curl-pipe à l'intérieur d'un pod. Il fail dur sans systemd. Utilisez l'image à la place.
• L'upgrade staged-bundle ADR-024. Le hook est un script shell Linux câblé dans systemd. Sur K8s vous upgradez en changeant le tag d'image et en rollant le DaemonSet — le chemin de swap en place est bypassé.
• NodePort pour le port 40012. Marche, mais chaque connexion edge re-hash quand le nœud derrière le NodePort change. Préférez un LoadBalancer pour le listener du tunnel, ou exposez le broker frontier sur un nœud dédié.

Roadmap

• Une Helm chart avec des défauts sensés (manager 1-replica, MySQL / Prom / Loki / Tempo embarqués optionnels).
• Un operator CRD-driven qui prend une ressource Manager et EdgePool, génère automatiquement la paire access/secret, et rolle les upgrades.
• Un plugin edge k8s-natif qui lit les logs de pod via l'API kubelet au lieu de journald, pour que les logs cluster-locaux ne nécessitent pas hostPath.

Aucun de ceux-ci n'est engagé à une release ; voir les issues GitHub si vous voulez aider à les piloter.