Helm

Voici la référence de configuration du chart Helm Scrydon. Ce document présente une installation condensée, puis les groupes de valeurs importants pour l'exploitation — ce que fait chaque clé, pourquoi la modifier et comment procéder. Si vous souhaitez simplement démarrer un cluster le plus rapidement possible, commencez par la page Localisation (On-Premise, Azure (AKS), Air-Gapped) et revenez ici pour les options.

Pour un cluster air-gapped (sans internet sortant), consultez le Déploiement Air-Gapped — le même chart est livré dans un bundle Zarf.

Fonctionnement de la configuration

Trois couches, de la priorité la plus basse à la plus haute :

1. Valeurs par défaut du chart — le chart fournit des valeurs de production sensées pour tout. La liste de référence est le values.yaml du chart lui-même (voir Inspecter le chart localement).
2. Votre values.customer.yaml — le fichier que vous passez avec -f. Ne surchargez que ce dont vous avez besoin ; tout le reste hérite de la valeur par défaut.
3. Flags --set — priorité maximale, utile pour injecter des secrets au moment de l'installation depuis un gestionnaire de secrets.

helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> -n scrydon-platform \
  -f values.customer.yaml \
  --set apiTable.secrets.STARROCKS_PASSWORD="$(vault kv get -field=password kv/scrydon/starrocks)"

Les secrets vivent dans votre fichier de valeurs. values.customer.yaml et helm get values <release> reproduisent toutes les valeurs fournies par l'utilisateur. Ne placez pas ce fichier dans un dépôt de code source, ou gérez-le via Sealed Secrets / SOPS / External Secrets Operator, et restreignez le RBAC du cluster sur le Secret de la release.

Inspecter le chart localement

Le chart est un artefact OCI dans scrydonops.azurecr.io — il n'existe pas de miroir Git public. Téléchargez-le pour lire chaque template et le values.yaml par défaut complet :

helm pull oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --untar
less scrydon/values.yaml   # la valeur par défaut de référence pour chaque clé ci-dessous

Valider votre configuration

Le chart embarque un schéma de valeurs (values.schema.json). Il rejette les clés inconnues ou mal orthographiées au niveau racine et dans les groupes stricts à haut risque tels que routing, ingress, license, les namespaces, Pod Security et NetworkPolicy. Certains blocs applicatifs — notamment les clés imbriquées de runtimePlane dans les charts actuels — restent permissifs : la validation du schéma est nécessaire, mais pas suffisante. Une faute comme routing.mdoe échoue immédiatement :

Error: values don't meet the specifications of the schema(s) in the following chart(s):
scrydon:
- routing: Additional property mdoe is not allowed

Avant une installation ou une mise à niveau, exécutez un contrôle préalable avec vos valeurs et votre version de Kubernetes :

# 1. Schéma + lint — détecte les clés mal orthographiées et les erreurs de structure
helm lint ./scrydon -f your-values.yaml

# 2. Rendre et valider contre votre version de Kubernetes
#    (kubeconform : https://github.com/yannh/kubeconform)
helm template scrydon ./scrydon -f your-values.yaml \
  | kubeconform --strict --ignore-missing-schemas \
      --kubernetes-version "$(kubectl version -o json | jq -r '.serverVersion.gitVersion' | tr -d v)"

# 3. Simulation d'installation contre le cluster réel (validation côté serveur)
helm install scrydon ./scrydon -f your-values.yaml --dry-run=server

Le chart exige Kubernetes 1.28 ou ultérieur (kubeVersion: ">=1.28.0-0") — helm install refuse les clusters plus anciens avec une erreur claire plutôt que d'échouer en cours de déploiement.

Installation rapide

Le minimum pour obtenir un cluster opérationnel. Chaque étape est développée avec des notes spécifiques à l'environnement sur les pages Localisation.

# 1. Se connecter au registre (nom d'utilisateur = nom du token ACR fourni par votre équipe)
helm registry login scrydonops.azurecr.io --username <acr-token-name>

# 2. Créer le namespace de la release + un secret d'extraction d'image dans ce namespace.
#    Le chart cible par défaut scrydon-platform pour chaque service ; la séparation en
#    namespaces est optionnelle via namespaces.* (créer le secret dans chaque namespace ciblé).
kubectl create namespace scrydon-platform 2>/dev/null || true
kubectl create secret docker-registry scrydon-registry --namespace scrydon-platform \
  --docker-server=scrydonops.azurecr.io \
  --docker-username=<acr-token-name> --docker-password=<acr-token-password>

# 3. values.customer.yaml — l'installation minimale complète.
global:
  imageRegistry: scrydonops.azurecr.io   # récupérer les images depuis l'ACR connecté
  imagePullSecrets:
    - scrydon-registry
  storageClass: <your-storage-class>     # nom de classe cloud par défaut, ou votre provisionneur on-prem

routing:
  host: app.example.com                  # le nom d'hôte vers lequel pointe votre DNS

ingress:
  tls:
    enabled: true                        # le navigateur accède à Scrydon via HTTPS — voir Ingress ci-dessous

infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD          # openssl rand -hex 16
auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET         # openssl rand -hex 32
apiTable:
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW # openssl rand -hex 24

# 4. Installer
helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --namespace scrydon-platform \
  -f values.customer.yaml --wait

Lancer l'assistant de configuration

Ouvrez https://app.example.com/platform/setup (ou /setup si vous avez monté platform à la racine). Cinq étapes :

Pré-injecter la licence

Évitez l'étape licence de l'assistant en injectant le bundle lors de la première installation. Les valeurs sont lues une seule fois pour initialiser la base de données ; ensuite la licence vit dans platform_config et est gérée depuis l'interface :

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET
    LICENSE: |                              # le champ `jwt` du bundle (une ligne)
      eyJhbGciOiJSUzI1NiIs...
    LICENSE_PUBLIC_KEY: |                    # le champ `publicKey` du bundle (PEM)
      -----BEGIN PUBLIC KEY-----
      MIIBIjANBgkqhkiG9w0BAQEFA...
      -----END PUBLIC KEY-----

Lorsque les deux valeurs sont définies, l'étape Licence de l'assistant s'ouvre déjà vérifiée.

Référence de configuration

Chaque groupe ci-dessous correspond à une clé de premier niveau dans le values.yaml du chart, dans l'ordre du fichier. Les valeurs par défaut indiquées sont celles du chart ; ne surchargez que ce dont vous avez besoin.

global — registre, images, stockage

Paramètres à l'échelle du cluster, hérités par chaque service.

global:
  imageRegistry: scrydonops.azurecr.io
  imagePullSecrets:
    - name: scrydon-registry
  storageClass: managed-csi

namespaces — placement des charges de travail

Chaque service cible par défaut scrydon-platform. Surchargez par service pour un isolement multi-namespace ; le chart aligne automatiquement les politiques ACL Dapr et le RBAC de lecture des secrets.

namespaces:
  infra: scrydon-infra
  platform: scrydon-platform
  agentic: scrydon-agentic
  analytics: scrydon-platform
  cortex: scrydon-platform

ingress — exposition et schéma TLS

routing — sous-chemin vs sous-domaine

Choisit comment les applications sont exposées. Discussion complète : Modes de routage.

routing:
  mode: subpath
  host: app.example.com
  paths:
    cortex: /scrydon/cortex      # personnaliser les préfixes si nécessaire
    platform: /scrydon/platform

dapr — maillage de services et identité

Les appels de service à service utilisent Dapr avec mTLS ; les politiques ACL du chart sont basées sur le domaine de confiance SPIFFE.

Apporter votre propre Dapr requiert la version testée 1.18.1, le domaine de confiance scrydon sur dapr-sentry (ou faire correspondre via dapr.trustDomain) et un injecteur de sidecar opérationnel. Voir Installations Dapr existantes.

Base de données — Postgres intégré ou BYO

infra.db contrôle le Postgres intégré (pgvector). Pour une instance externe/managée, la recette complète — notes par fournisseur, clés infra.db.external.*, pré-création des bases — est sur BYO Database.

# Intégré (défaut) — définir juste un mot de passe fort :
infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD
# Postgres managé BYO :
infra:
  db:
    enabled: false
    external:
      existingSecrets:
        auth: scrydon-auth-db
        agentic: scrydon-agentic-db
      lakekeeperUrl: "postgres://scrydon:REDACTED@pg.example.com:5432/lakekeeper"
      sslMode: require

StarRocks — Tables managées (OLAP)

Pod unique allin1-ubuntu. Alimente l'interface Tables et le fallback d'inférence de schéma agentique. Associé à apiTable.

L'image intégrée livre root sans mot de passe. Définissez apiTable.secrets.STARROCKS_PASSWORD dans les valeurs, puis appliquez-le dans StarRocks après l'installation — voir Identifiants StarRocks. Pour une production multi-AZ, passez à l'starrocks-kubernetes-operator (séparation FE/BE) et pointez apiTable.starrocks.host vers son Service FE.

SeaweedFS — stockage objet

Stockage compatible S3 en pod unique pour les téléversements.

Services applicatifs

Les applications produit — auth (api-platform), platform, cortex, analytics, apiOntology, apiTable, agentic (app + realtime). Chaque bloc partage une forme commune :

Clés notables spécifiques aux applications :

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET   # signature de session — openssl rand -hex 32
  auditLog:
    enabled: true                           # transfert SIEM + crons de rétention (ADR 2026-04-16)
    chain:
      enabled: false                        # chaîne de hachage infalsifiable — optionnel, coût de signature

analytics:
  marimoSidecar:
    enabled: true                           # éditeur de notebooks ; désactiver pour réduire ~2Gi
  secrets:
    MARIMO_EDIT_TOKEN: ""                   # vide → généré automatiquement à l'installation, réutilisé entre les mises à niveau

apiTable:
  starrocks:
    host: ""                                # vide → Service FE intégré ; indiquer pour StarRocks externe
    user: root
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW

agentic:
  realtime:
    ingress:
      annotations:                          # cookie sticky pour la route WebSocket
        traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
  passkey:
    rpId: app.example.com                   # DOIT correspondre à routing.host sinon l'enregistrement passkey échoue
    origin: https://app.example.com

auth.secrets.SERVICE_ADMIN_TOKEN est déprécié — la production utilise Dapr mTLS (SPIFFE). Ne le définir que pour le développement local sans sidecars. Quand les clés avec underscore sont interdites (paramètres protégés Azure Marketplace), utiliser auth.authSecret à la place de auth.secrets.AUTH_SECRET.

runtimePlane — exécution Agent isolée

Le plan d'exécution est opt-in jusqu'à qualification de Kata/KVM et des contrôles réseau. Une fois activé, chaque session Agent standard s'exécute dans un pod Kata neuf à usage unique, avec une boucle modèle/outils/CLI bornée et un /workdir partagé ; elle ne revient jamais à une exécution dans le processus. La politique par défaut est requireTrueVm: true avec fallback: hard_refuse. Un opérateur peut choisir le niveau hardened, explicitement plus faible, uniquement dans un profil de déploiement examiné séparément. Dapr est le chemin de contrôle authentifié : si dapr.enabled global ou runtimePlane.dapr.enabled vaut false, aucun contrôleur n'est généré et l'Agent refuse avec une erreur typée.

Le chart réplique vos global.imagePullSecrets du namespace de la release vers les deux namespaces runtime au moment de l'installation/mise à niveau, donc les registres privés fonctionnent sans étape supplémentaire. (Les pipelines helm template puis apply n'ont pas de cluster à lire — pré-créez les secrets de pull dans les deux namespaces runtime dans ce mode de travail.)

Deux choix de sécurité fonctionnent aujourd'hui :

• MicroVM Kata : microvm.enabled: true, requireTrueVm: true, fallback: hard_refuse. Un noyau invité dédié est utilisé, sinon l'exécution est refusée.
• Repli durci : requireTrueVm: false, fallback: hardened. Le noyau hôte est partagé, avec application sans root, capacités abandonnées, seccomp et le même enforcer. Ce niveau est explicitement plus faible.

Le niveau mediated correspond à gVisor runsc, mais il n'est pas utilisable de bout en bout avec le mur réseau natif actuel : gVisor n'expose pas les API netfilter/netlink nécessaires à nftables/nfqueue. Le protocole interne du runtime-plane reste lisible pendant les mises à niveau progressives, mais les entrées Helm, d'environnement et de politique d'organisation refusent mediated ou échouent de manière fermée. Utilisez hard_refuse ou le repli explicitement plus faible hardened jusqu'à la livraison d'un mécanisme de sortie natif gVisor.

networkPolicies:
  enabled: true

runtimePlane:
  enabled: true
  namespace: scrydon-runtimes
  workloadNamespace: scrydon-runtime-workloads
  persistence:
    size: 1Gi
  runnerImage: registry.example.com/scrydon/bundle-runner@sha256:<digest>
  enforcerImage: registry.example.com/scrydon/egress-enforcer@sha256:<digest>
  blockedCidrs:
    - "10.0.0.0/8" # remplacer/étendre avec les CIDR réels des pods et services
    - "172.16.0.0/12"
    - "192.168.0.0/16"
  upstreamDns: "10.0.0.10:53"
  execution:
    isolateUntrusted: true
    requireTrueVm: true
    fallback: hard_refuse
  isolation:
    microvm:
      enabled: true
      renderRuntimeClass: false # AKS possède kata-vm-isolation

Le Deployment du contrôleur et l'identité exec consomment global.imagePullSecrets. Les pods Agent à usage unique utilisent le ServiceAccount sa-runtime-exec, qui appartient au chart et définit automountServiceAccountToken: false : le code non fiable ne reçoit aucun jeton d'API Kubernetes, tandis que kubelet peut toujours utiliser l'identifiant de registre configuré. Ne modifiez pas le ServiceAccount default du namespace. Si le registre exige un secret d'extraction, créez le Secret portant le même nom dans runtimePlane.namespace, runtimePlane.workloadNamespace et chaque namespace applicatif activé avant l'installation, ou fournissez un accès au registre équivalent au niveau des nœuds.

Après le déploiement, vérifiez le rapport de capacités au démarrage et prouvez le niveau choisi sur un pod réel à usage unique. Un contrôleur Ready ne prouve pas à lui seul Kata, l'extraction des images, les rappels, le DNS, la suppression ou l'enforcement de sortie.

opa — point de décision d'autorisation

Chaque décision d'autorisation sur les espaces de travail, workflows et ontologies est évaluée par OPA.

license — posture de validation

auth.secrets.LICENSE_PUBLIC_KEY doit être défini chaque fois que license.enabled: true pour qu'api-platform puisse vérifier les signatures JWT. Scrydon doit s'exécuter sur un cluster dédié, car la capacité inclut tous les nœuds workers planifiables. Voir Licences et Rapport de capacité de licence.

Lorsque networkPolicies.enabled=true, définissez networkPolicies.kubernetesApiEgress.enabled=true et son cidr sur l'adresse IP du Service de l'API Kubernetes avec un masque /32. Cela autorise uniquement la connexion à l'API de capacité des nœuds ; le RBAC limite toujours l'identité à get/list sur les nœuds.

packSources — distribution de packs gérée par le chart

Ordonnancement des pods

Les nodeSelector, tolerations et affinity à l'échelle du chart s'appliquent à chaque Deployment, StatefulSet et Job de migration — les pods peuvent ainsi atterrir sur des nœuds dédiés ou marqués avec des teints. Les surcharges par composant ne sont pas exposées.

tolerations:
  - { key: workload, operator: Equal, value: scrydon, effect: NoSchedule }
nodeSelector:
  workload: scrydon
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - { key: node-role.kubernetes.io/scrydon, operator: Exists }

Réduction pour les installations à ressources limitées

Les valeurs par défaut présupposent un cluster de forme production (≥ 8 vCPU / ≥ 32 Gio sur les nœuds). Sur des clusters d'évaluation (4 vCPU / 16 Gio), désactivez les composants optionnels les plus lourds :

infra:
  starrocks:
    enabled: false     # ~2–8 Gio RAM, 20 Gio PVC — seules les Tables managées + l'inférence de schéma agentique sont affectées
apiTable:
  enabled: false
analytics:
  enabled: false       # supprime l'interface analytique + le sidecar marimo (~2 Gio)

Recettes de configuration courantes

Personnaliser les chemins de routage

Montez les applications sous des préfixes différents (ex. tout sous /scrydon/...) via routing.paths.* — voir le tableau routing ci-dessus et Modes de routage.

Installations Dapr existantes

Si le cluster exécute déjà Dapr, mettez dapr.installControlPlane: false pour que le chart ne tente pas de le gérer, et pointez dapr.controlPlaneNamespace vers l'emplacement de Dapr :

dapr:
  installControlPlane: false
  controlPlaneNamespace: dapr-system

Votre Dapr doit satisfaire trois prérequis, faute de quoi la connexion fonctionne mais la création de compte / les appels inter-services échouent avec PermissionDenied :

kubectl -n <dapr-ns> get deploy dapr-sentry \
  -o jsonpath='{.spec.template.spec.containers[0].image}'   # attendre sentry:1.18.1

Ingress avancé : derrière un équilibreur de charge qui termine le TLS

Les configurations App Gateway / ALB / GCP LB / F5 nécessitent un ajustement du contrôleur Traefik (trustedIPs, externalTrafficPolicy: Local, la règle de schéma public ingress.tls.enabled, ingress privé, dépannage 502). Guide complet : TLS Offloading.

Identifiants StarRocks

Le StarRocks intégré est livré avec root sans mot de passe. Après helm install, appliquez le mot de passe défini dans apiTable.secrets.STARROCKS_PASSWORD :

NEW_PW="<your-starrocks-password>"   # même valeur que apiTable.secrets.STARROCKS_PASSWORD
# StarRocks est dans le namespace de la release par défaut (namespaces.infra → scrydon-platform).
kubectl -n scrydon-platform exec -it deploy/starrocks-fe -- \
  mysql -h127.0.0.1 -P9030 -uroot -e "SET PASSWORD FOR 'root' = PASSWORD('${NEW_PW}');"
kubectl -n scrydon-platform rollout restart deployment/svc-api-table

api-table entre en CrashLoop entre l'installation et cette étape — c'est attendu ; il se stabilise après le redémarrage. Pour apporter votre propre StarRocks :

infra:
  starrocks:
    enabled: false
apiTable:
  starrocks:
    host: starrocks-fe.starrocks.svc.cluster.local
    user: scrydon
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PASSWORD

Vérifier le déploiement

kubectl get pods -n scrydon-platform   # tous Running, 2/2 avec le sidecar Dapr
kubectl get ingress -n scrydon-platform   # chaque Ingress a une ADDRESS
kubectl get certificates -A             # Certificats cert-manager READY=True

Les données de licence (niveau, droits, jours avant expiration) apparaissent sous Paramètres de la plateforme → Licence après /setup. Connectez-vous sur https://app.example.com/ et passez d'une application à l'autre via le sélecteur de produit sans vous reconnecter.

Dépannage

Opérations de jour 2

• Renouveler la licence — collez le bundle renouvelé sous Paramètres → Licence → Mettre à jour la licence ; pas de redémarrage. Licences.
• Sauvegarde & restauration — CronJob Postgres intégré (infra.db.backup) ou votre fournisseur managé. Sauvegarde & Restauration.
• Mises à jour — Mises à jour.
• Observabilité — Observabilité.