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 paquet 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   # the authoritative default for every key below

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, gateway, 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. Schema + lint — catches typo'd keys and structural mistakes
helm lint ./scrydon -f your-values.yaml

# 2. Render and validate against your Kubernetes version
#    (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. Dry-run the install against the live cluster (server-side validation)
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. Log in to the registry (username = ACR token name from your account team)
helm registry login scrydonops.azurecr.io --username <acr-token-name>

# 2. Create the release namespace + an image-pull secret in it.
#    The chart defaults every service to scrydon-platform; split namespaces
#    are opt-in via namespaces.* (create the secret in each one you target).
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 — the entire minimal install.
global:
  imageRegistry: scrydonops.azurecr.io   # pull images from the ACR you logged into
  imagePullSecrets:
    - scrydon-registry
  storageClass: <your-storage-class>     # cloud default class name, or your on-prem provisioner

routing:
  host: app.example.com                  # the hostname your DNS points at

gateway:
  tls:
    enabled: true                        # browser reaches Scrydon over HTTPS — see Gateway below

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. Install
helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --namespace scrydon-platform \
  -f values.customer.yaml --wait --wait-for-jobs

Lancer l'assistant de configuration

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

Pré-injecter la licence

Évitez l'étape licence de l'assistant en donnant au chart le champ jwt de votre fichier de licence lors de la première installation. La valeur est lue 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: "eyJhbGciOiJNTC1EU0EtNjUi…"     # the file's `jwt` field

Lorsqu'elle est définie, l'étape Licence de l'assistant s'ouvre déjà vérifiée. Il n'y a pas de valeur de clé publique : auth.secrets.LICENSE_PUBLIC_KEY est ignorée en production, et la mise à jour supprime toute ligne de clé publique qu'elle avait stocké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

gateway — exposition et schéma TLS

La périphérie repose sur la Gateway API de Kubernetes (Gateway + HTTPRoute), et non sur Ingress. Ingress est gelée : elle reste GA, conserve ses garanties de stabilité et Kubernetes ne prévoit pas de la supprimer — mais elle ne reçoit plus aucun développement, et Kubernetes recommande la Gateway API à sa place. Le chart suit cette recommandation.

Le chart génère une Gateway nommée gateway-frontdoor dans l'espace de noms de la plateforme, et une HTTPRoute par application activée dans l'espace de noms de cette application, rattachée à l'unique Gateway par-delà les espaces de noms.

Trois contrôles qui étaient auparavant des annotations propres au contrôleur relèvent désormais du cœur de la Gateway API et sont générés sans condition ; ils existent donc sur toute implémentation conforme et non plus seulement sur Traefik :

• Le retrait des en-têtes Dapr / on-behalf-of. Chaque règle de route qui transmet porte un filtre RequestHeaderModifier qui supprime dapr-caller-app-id, dapr-api-token, x-scrydon-self-call, les en-têtes d'identité x-on-behalf-of-* et x-scrydon-storage-scope des requêtes externes. Il n'y a plus ni branche par classe ni mode pouvant silencieusement ne rien produire : ingress.stripDaprHeaders.* — et l'avertissement d'installation qui l'accompagnait — disparaît sans remplacement.
• La redirection HTTP → HTTPS. Un filtre RequestRedirect sur le listener HTTP, généré dès que gateway.tls.enabled est actif. ingress.middleware.forceHttps.* disparaît sans remplacement.
• La précédence des chemins. La spécification impose le préfixe correspondant le plus long d'abord, sur toutes les routes d'un listener : l'ordre de déclaration n'a donc plus d'importance et la règle racine / est simplement la moins prioritaire.

Les chemins internes des services ne sont pas publiés. Sur chaque nom d'hôte, /api/internal sous la racine de chaque application (/api/internal, /platform/api/internal, /agentic/api/internal, etc.) correspond à une règle sans backend : la passerelle répond 500 et ne transmet jamais la requête ; ces routes ne sont joignables qu'à l'intérieur du maillage de services. C'est aussi du cœur de Gateway API.

Les choix de certificats pour Let's Encrypt, les domaines exclusivement privés, l'ACME interne et les certificats d'entreprise statiques sont traités dans Certificats TLS.

Ports des listeners : 8000 / 8443, et non 80 / 443

gateway.listenerPorts.* est le port sur lequel votre contrôleur écoute, pas celui auquel vos utilisateurs se connectent. C'est la seule valeur propre à l'implémentation dans toute la périphérie.

Traefik associe un listener de Gateway à l'un de ses entryPoints par le port, et ces entryPoints écoutent sur :8000 (web) et :8443 (websecure) dans le conteneur tandis que son Service publie 80/443. Un listener déclaré sur le port 80 est rejeté d'emblée (vérifié sur Traefik v3.6.10, le 2026-09-12) :

Accepted=False  reason=PortUnavailable
"Cannot find entryPoint for Gateway: no matching entryPoint for port 80 and protocol HTTP"

Une implémentation managée qui écoute sur le port public — Application Gateway for Containers, un ALB cloud — attend au contraire 80 / 443 ici :

gateway:
  className: <your-gatewayclass>
  listenerPorts:
    http: 80
    https: 443

Autres implémentations Gateway API

Définissez gateway.className sur votre GatewayClass et le routage fonctionne sans changement : le chart n'émet que des ressources Gateway et HTTPRoute du cœur de la spécification, sans aucune annotation de contrôleur sur les routes. Deux points à vérifier avant de changer :

Tout ce que le chart n'exprime pas — limites de taille de corps de requête, délais de lecture, comportement d'inactivité WebSocket sur la route routing.paths.agenticRealtime — se configure sur votre implémentation elle-même et non via ce chart ; gateway.annotations est le seul point d'accroche d'annotations et il s'applique à la Gateway, pas aux routes. Dimensionnez la limite de taille de corps au moins à hauteur du plafond d'upload de 100 Mo de la plateforme.

Une remarque portable : les implémentations dont la sonde de santé du backend vise / par défaut reçoivent une chaîne de redirections des applications SSR. Pointez la sonde vers le /api/healthz de chaque application, avec le mécanisme de health check fourni par votre implémentation.

routing — sous-chemin vs sous-domaine

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

routing.annotations a disparu. Cette clé n'existait que parce qu'une installation en sous-chemin comportait exactement un Ingress et aucun autre moyen de l'annoter ; les deux modes de routage génèrent désormais une seule Gateway, et gateway.annotations est cet endroit — voir Autres implémentations Gateway API.

routing:
  mode: subpath
  host: app.example.com
  paths:
    cortex: /scrydon/cortex      # customize prefixes if needed
    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.9, le domaine de confiance scrydon (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.

# Bundled (default) — just set a strong password:
infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD
# BYO managed Postgres:
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.

Pour une production multi-AZ, passez à l'starrocks-kubernetes-operator (séparation FE/BE), définissez apiTable.starrocks.replicationNum selon son nombre de BE et pointez apiTable.starrocks.host vers son Service FE.

SeaweedFS — stockage objet

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

Une seule réplique sur un volume ReadWriteOnce : un déploiement (une mise à niveau du chart qui change son image ou ses identifiants) arrête l'ancien pod avant de démarrer le nouveau. Les écritures de tables pendant cette fenêtre reçoivent 503 object_store_unavailable et sont réessayées. Le pod n'est déclaré prêt qu'une fois que son master liste un nœud de stockage, ce qui limite la fenêtre à quelques secondes. Utilisez un S3 managé si le stockage doit rester disponible pendant les mises à niveau.

Stockage par défaut du déploiement

L'emplacement où chaque organisation sans stockage S3 ou Azure propre conserve ses fichiers, sous orgs/<organizationId>/ dans un même bucket. Seul auth (api-platform) résout le stockage, il est donc le seul à recevoir les variables d'environnement STORAGE_DEFAULT_S3_*. Sans stockage par défaut, ces organisations ne peuvent rien téléverser tant qu'un administrateur n'a pas configuré le stockage, et l'étape stockage de l'assistant de configuration devient obligatoire.

Services applicatifs

Les applications produit — auth (api-platform), platform, cortex, horizon, analytics, apiOntology, apiTable, agentic (app + realtime). Chaque bloc partage une forme commune (horizon est l'exception sans état : pas de base de données, pas de sidecar Dapr, toujours dans le namespace de la plateforme, et horizon.copEnabled ne conditionne que ses surfaces de situation tactique) :

Clés notables spécifiques aux applications :

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET   # session signing — openssl rand -hex 32
  auditLog:
    enabled: true                           # SIEM forwarding + retention crons (ADR 2026-04-16)
    chain:
      enabled: false                        # chaîne de hachage infalsifiable — optionnel, coût de signature
  maxInFlight: 64                           # appels ouverts par pod, partagés par le routeur, l'API et MCP (429 au-delà)
  bodyRead:                                 # un corps de requête doit continuer d'arriver (400 body_read_too_slow)
    graceMs: 10000                          # avant que le débit minimal ne s'applique
    minBytesPerSecond: 65536                # abaissez les deux pour des clients sur des liens lents

analytics:
  marimoDocument:
    enabled: true                           # private, compute-free document renderer
  marimoRuntime:
    startupDeadlineMs: 300000               # Connect/Run preparation deadline
  appRevalidation:
    enabled: false                          # ré-épingler les apps publiées après une mise à niveau du runtime (staging d'abord)
  secrets:
    MARIMO_RUNTIME_HMAC_SECRET: ""           # blank → generated and reused across upgrades

apiOntology:
  secrets:
    APP_PUBLICATION_SIGNING_SECRET: ""       # vide → généré et réutilisé entre les mises à niveau

apiTable:
  starrocks:
    host: ""                                # blank → bundled FE Service; set for external StarRocks
    user: root
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW

agentic:
  realtime:
    gateway:
      hostname: ws-agentic.example.com      # subdomain mode only
  passkey:
    rpId: example.com                       # subdomain mode: required, the domain every app host shares
    origin: https://app.example.com         # subdomain mode: required. Subpath mode derives both from routing.host

apiOntology.secrets.APP_PUBLICATION_SIGNING_SECRET — signe les sceaux de validation des publications d'app (Analytics signe, api-ontology vérifie). Au moins 32 octets. À définir uniquement ici ; le chart écrit la même valeur dans les deux Secrets. Vide, il réutilise la valeur existante ou en génère une ; avec global.requireExplicitSecrets=true, il est obligatoire. La clé se définit uniquement sous apiOntology ; la définir sous analytics.secrets fait échouer le rendu.

Les annotations de cookie sticky du temps réel ont disparu. Elles ne s'appliquaient qu'en mode sous-domaine, et l'affinité de session pour les backends Gateway API ne fait pas partie du canal standard — agentic-realtime n'a donc aucune affinité si vous l'exécutez avec plus d'un réplica en mode sous-domaine. Il est livré avec replicas: 1, ce que supposent également les paramètres PodDisruptionBudget ci-dessous.

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.

executionFabric et runtimePlane

Le plan d'exécution est opt-in jusqu'à qualification de Kata/KVM et des contrôles réseau. Il possède les pods Agent éphémères, les sessions Marimo de longue durée protégées par génération et les jobs de notebooks neufs à usage unique. L'ouverture d'un notebook utilise toujours le moteur de rendu sans calcul ; Connect, Run hors connexion et les jobs refusent si le plan est indisponible. Le calcul Marimo ne revient jamais à un processus de service produit. Les backends déployés et leur disponibilité authentifiée par profil déterminent les niveaux disponibles. Le résolveur essaie toujours microvm d'abord, puis managed_process uniquement si l'organisation l'autorise. L'hôte d'acteur générique du processus géré est généré par défaut (niveau normal) ; l'activation d'un Runtime Plane qualifié ajoute le niveau isolé sans autre liste ni préférence. Un administrateur d'organisation active Exiger l'exécution isolée dans Paramètres → Plateforme → Compute pour imposer la microVM comme plancher strict : les exécutions de cette organisation refusent alors au lieu d'utiliser le niveau processus géré. Une exécution liée ne descend jamais de niveau après son démarrage.

Le chart refuse de générer si aucun backend d'exécution n'est déployé. Cette combinaison s'installait silencieusement et toute exécution échouait ensuite à l'exécution avec « No permitted … execution tier is currently ready » ; elle échoue désormais dès helm install en nommant le chemin de valeurs à corriger. Une posture de production stricte qui veut uniquement la microVM définit explicitement managedProcess.enabled: false — voir values.production.example.yaml.

Le niveau géré utilise un unique Deployment et une unique image d'hôte d'acteur Dapr. Dapr gère le placement et le routage horizontal ; chaque invocation reçoit un nouvel arbre de processus enfants et un nouvel espace de travail, tout en réutilisant les mêmes runners Agent, implémentation et notebook que le backend microVM. Ce niveau partage le noyau du pod de l'hôte d'acteur et reste explicitement plus faible qu'une microVM.

Les Agents standard utilisent toujours AgentCapabilityContract avec le protocole fixe agent-capability-contract. Aucun mode de broker d'outils d'intégration n'est à activer pendant une installation ou une mise à niveau, et aucune valeur opérateur ne sélectionne une autre architecture Agent. Le chart épingle le protocole nommé dans Runtime Plane ; une image runner incompatible est refusée avant la création d'un workload Agent.

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.)

Tailles des runtimes Marimo

Chaque organisation choisit une taille pour les éditeurs de notebooks (par défaut small) et pour les applications publiées (par défaut xsmall) dans Paramètres → Calcul. Sur Kubernetes, une taille ne fixe que les ressources du conteneur marimo ; les sidecars et le stockage éphémère restent fixes :

Abaisser maxSizeTier prend effet au redémarrage du Runtime Plane avec la nouvelle valeur, et ce redémarrage arrête chaque runtime en cours au-dessus du nouveau plafond : chacun se termine avec le code d'échec size_tier_above_ceiling et ses ressources sont supprimées. Les runtimes au niveau du plafond ou en dessous continuent de tourner. Le premier démarrage de cette version reconstruit aussi une fois la table du registre des runtimes du plane, en conservant ses lignes, afin qu'elle puisse enregistrer ce code. Une taille qu'aucun nœud ne peut planifier n'est pas refusée d'emblée : le pod reste en attente jusqu'à provisionTimeoutSeconds, puis la tentative échoue par dépassement du délai de démarrage. Gardez maxSizeTier à une taille que votre pool de nœuds Kata peut placer.

N'abaissez maxSizeTier qu'une fois qu'API Platform et Analytics exécutent tous deux cette version. Le redémarrage qui arrête un runtime au-dessus du plafond enregistre cet arrêt comme événement d'audit via API Platform, et une version antérieure d'API Platform rejette le nouveau motif size_tier_above_ceiling. Le plane ne démarre pas tant que cet événement n'est pas enregistré : il échoue au démarrage et redémarre en boucle jusqu'à la mise à niveau d'API Platform. Une version antérieure d'Analytics ne sait pas non plus lire un runtime terminé avec ce code.

Lors d'une mise à niveau, déployez le Runtime Plane avant Analytics. Analytics n'envoie une taille qu'à un plane qui annonce sa prise en charge. Si Analytics est mis à niveau en premier, les runtimes démarrés entre-temps tournent en medium, et après la mise à niveau du plane, la demande suivante de chacun d'eux, désormais à la taille de l'organisation, peut échouer une fois avec un conflit d'intention. La mise à niveau d'Analytics change aussi une fois la clé de demande de chaque runtime, car la politique de taille en fait partie.

Les deux choix de déploiement sont microvm et managed_process. Les anciens champs du protocole Runtime Plane (require_true_vm, fallback, mediated et hardened) ne sont pas des contrôles de niveau Helm ou d'organisation. Les adaptateurs sensibles au niveau émettent une valeur de protocole fixe réservée à la microVM après que le résolveur partagé a sélectionné microvm, uniquement pour la compatibilité des mises à niveau progressives avec le plan Rust.

networkPolicies:
  enabled: true

executionFabric:
  managedProcess:
    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>
  marimoRuntimeImage: registry.example.com/scrydon/marimo-runtime@sha256:<digest>
  blockedCidrs:
    - "10.0.0.0/8" # replace/extend with the actual pod + service CIDRs
    - "172.16.0.0/12"
    - "192.168.0.0/16"
  # upstreamDns est omis volontairement : chaque pod utilise le DNS du cluster de
  # son propre /etc/resolv.conf. Ne le définir que pour épingler un autre résolveur.
  isolation:
    microvm:
      renderRuntimeClass: false # AKS owns kata-vm-isolation

Le Deployment du contrôleur et les deux identités de workload consomment global.imagePullSecrets. Les pods Agent/job de notebook à usage unique utilisent sa-runtime-exec ; les pods Marimo interactifs utilisent sa-runtime-workload. Les deux définissent 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 séparément le niveau choisi pour les profils Agent exec, Marimo interactif et job de notebook. Prouvez également que l'ouverture d'un notebook ne crée aucun runtime, que Connect n'exécute aucune cellule et que Run hors connexion exécute une seule fois la cellule sélectionnée. Un contrôleur Ready ne prouve pas à lui seul Kata, l'extraction des images, les callbacks, le DNS, l'installation des dépendances, le nettoyage ou l'enforcement de sortie.

Valkey managé partagé — événements, cache de modèles et limites Agentic

Le chart fournit un backbone d'événements durable (synchronisation validée de l'éditeur de workflows, flux d'événements d'organisation), un cache de découverte de modèles et des limites durables pour les webhooks et formulaires Agentic. Ces fonctions partagent une seule instance Valkey persistante ; le limiteur ne déploie pas une seconde base de données.

networkPolicies.providerEgress — HTTPS sortant vers les sources de données

Les sources de données et les points de terminaison de connexion appellent l'adresse du fournisseur configurée par un administrateur de l'organisation : les outils de point de terminaison de connexion depuis api-platform, et toutes les sources de données — par interrogation, à la demande, en flux — depuis api-ingestion. Avec networkPolicies.enabled, cette règle permet à ces deux services — et à aucun autre — de joindre des adresses HTTPS publiques. Elle n'autorise jamais les adresses privées (RFC 1918), de NAT de niveau opérateur, link-local ou loopback, ni l'adresse de plateforme Azure 168.63.129.16, ni aucune autre plage à usage spécial ; en IPv6, elle n'admet que l'unicast global (2000::/3). L'hôte qu'une connexion peut joindre reste décidé, pour chaque connexion, par la liste d'autorisation de sortie de l'organisation.

networkPolicies.telemetry — votre collecteur OpenTelemetry

Si vous exploitez un collecteur OpenTelemetry, dapr.tracing.otel.endpointAddress et observability.otlpHttpEndpoint y dirigent Scrydon. Un collecteur situé dans un namespace que le chart ne gère pas n'est joignable que par cette route, car aucune des politiques default-deny n'admet ce namespace. Sans la route, une charge de travail isolée par une NetworkPolicy ne peut pas exporter sa télémétrie. Avec networkPolicies.enabled: false, il s'agit de marimo-document, dont la politique propre est toujours générée. Avec networkPolicies.enabled: true, il s'agit de toutes les charges de travail Dapr. Il en va de même pour la collecte des métriques de daprd sur dapr.metricsPort par votre scraper.

networkPolicies:
  telemetry:
    collectors:
      - namespace: observability
        podSelector:
          app.kubernetes.io/component: otel-collector
        ports: [4317, 4318]   # OTLP gRPC (daprd), OTLP HTTP (applications)
    metricsScrapers:
      - namespace: observability
        podSelector:
          app.kubernetes.io/component: otel-collector

La route n'ouvre que les directions que vous configurez. Elle ne sélectionne que des pods qu'une autre politique du chart isole déjà : l'activer ne peut donc pas restreindre une charge de travail qui ne l'était pas. Le profil NATO UNCLASSIFIED laisse les deux listes vides.

global.egress.privateNetworks — réseaux privés

Un endpoint de connexion (une source poll, à la demande ou en flux dont l'URL vient de sa connexion) n'atteint que des adresses publiques sur le port 443, et la base de données d'une source de requête n'est joignable par aucun réseau. Deux autres sortes d'adresses qu'un administrateur d'organisation configure sont appelées depuis les serveurs de Scrydon : l'URL d'un récepteur de logs, et les endpoints du fournisseur OAuth d'une extension (ses URL de connexion, de jeton et d'informations utilisateur, que les paramètres de fournisseur de l'organisation peuvent placer sur son propre hôte). Les deux n'atteignent que des adresses https:// publiques. Toutes en restent là tant que vous, l'opérateur, n'ouvrez pas un réseau privé. Un réseau privé désigne des plages d'adresses, leurs ports, ce qui peut les utiliser et quelles organisations le peuvent :

Seul l'opérateur ouvre un réseau : aucun paramètre d'organisation n'en élargit un. Pour un endpoint de connexion ou une source de requête, l'organisation décide aussi pour elle-même : sa liste d'autorisation de sortie doit désigner l'hôte (une adresse IP exactement), et un réseau situé dans une plage privée exige aussi son interrupteur Réseaux privés (Paramètres → Gouvernance → Egress). Un récepteur de logs ou un paramètre de fournisseur OAuth n'exige qu'un réseau ouvert à son organisation. Le loopback, le link-local, les métadonnées et les autres adresses réservées ne peuvent jamais être ouverts, et chaque adresse vers laquelle un nom se résout est vérifiée à nouveau à chaque connexion d'une source, à chaque livraison et à chaque appel au fournisseur. Sans réseau, les récepteurs de logs et les endpoints de fournisseurs restent limités au public.

Avec networkPolicies.enabled, le chart produit une NetworkPolicy par workload et par famille d'adresses : les plages de chaque réseau sur ses propres ports, pour api-platform et api-ingestion quand il sert http, et pour api-table quand il sert query. La règle HTTPS large (providerEgress) et le palier d'exécution managée excluent à la fois les plages privées et runtimePlane.blockedCidrs : restreindre le plancher n'ouvre jamais d'espace privé hors d'un réseau.

queryJdbc.remoteCidrs et queryJdbc.remotePorts ont été supprimés : le rendu échoue tant que l'un des deux est défini. Déplacez chaque plage de bases de données vers un réseau avec uses: [query], ses ports et ses trustedCaRefs. La passerelle de requêtes exige au moins un tel réseau, et chaque entrée de trustedCaRefs doit être distribuée par un profil de driver de requête.

Exemple : Azure Private Link sur AKS

Un cluster AKS avec Azure CNI overlay : VNet 10.224.0.0/12, nœuds 10.224.0.0/16, pods 10.244.0.0/16, services 10.0.0.0/16 (lisez les vôtres avec az aks show -g <rg> -n <cluster> --query networkProfile). Les private endpoints de Contoso sont dans le sous-réseau snet-pe, 10.225.8.0/24, dans le même VNet ou un VNet appairé — pas une plage de pods, de services ou de nœuds. Le fournisseur d'identité auquel toutes les organisations se connectent se trouve dans 10.225.9.0/28.

runtimePlane:
  # The floor: the cluster's own ranges. 168.63.129.16 is always refused already.
  blockedCidrs: [10.224.0.0/16, 10.244.0.0/16, 10.0.0.0/16]
global:
  egress:
    trustAnchors:
      existingSecret: scrydon-egress-trust   # key: contoso-internal
    privateNetworks:
      - name: contoso-pg
        cidrs: [10.225.8.0/28]
        ports: [5432]
        uses: [query]
        organizations: [<identifiant de l'organisation Contoso>]
        trustedCaRefs: [azure-db]
      - name: contoso-api
        cidrs: [10.225.8.16/28]
        ports: [443, 8443]
        uses: [http]
        organizations: [<contoso organization id>]
        caRef: contoso-internal
      - name: corporate-idp
        cidrs: [10.225.9.0/28]
        ports: [443]
        uses: [http]
        allOrganizations: true

• Base de données (Azure Database for PostgreSQL, private endpoint). L'administrateur de l'organisation saisit le nom public du serveur, contoso-pg.postgres.database.azure.com. Dans le cluster, CoreDNS transmet à Azure DNS, et la zone privatelink.postgres.database.azure.com liée au VNet répond 10.225.8.4 ; le driver vérifie le certificat par rapport au nom saisi. Ne saisissez jamais le nom privatelink. : le certificat du serveur ne le porte pas.
• API HTTP (Private Link Service). Contoso publie son API derrière un Private Link Service ; son private endpoint reçoit 10.225.8.20. Ajoutez un enregistrement A pour api.contoso.internal dans une zone DNS privée liée au VNet, et placez l'autorité de certification qui signe le certificat de l'API dans le Secret des ancres de confiance, sous la clé contoso-internal.
• Récepteur de logs. Le collecteur SIEM de Contoso a un private endpoint dans la même plage, 10.225.8.21, avec un certificat émis par l'autorité interne de Contoso. L'administrateur de Contoso enregistre https://siem.contoso.internal:8443/ingest comme récepteur de logs (une zone DNS privée liée au VNet répond 10.225.8.21). Un récepteur de logs n'exige ni entrée dans la liste d'autorisation ni interrupteur.
• Fournisseur d'identité. Toute organisation peut régler le domaine du fournisseur d'identité de son extension sur l'hôte de l'IdP, que corporate-idp ouvre à toutes les organisations.
• L'organisation. Activez Réseaux privés et ajoutez contoso-pg.postgres.database.azure.com et api.contoso.internal à la liste d'autorisation.

AWS PrivateLink (endpoints d'interface dans vos sous-réseaux) et Google Private Service Connect (une adresse du sous-réseau consommateur ; retirez le point final du nom DNS) fonctionnent de la même manière : le sous-réseau de l'endpoint est le réseau, et les plages propres au cluster restent dans le plancher. Les installations sur site et isolées listent le propre sous-réseau de la base de données, de l'API, du collecteur ou de l'IdP.

ingestBuffer — tampon durable des sources en flux et en push

Les sources de données en flux (stream) et en push acceptent leurs entrées dans un tampon dédié avant de les valider dans leur table, et le bail d'un flux y est aussi conservé : aucune des deux ne s'exécute sans lui. Les sources planifiées (poll) n'en ont pas besoin : le bail qui garde chacune sur un seul réplica est conservé dans la base de données de la plateforme. ingestBuffer.enabled (défaut false) l'active. Par défaut, le chart l'exécute comme un Valkey unique dans le cluster, qui écrit chaque entrée acceptée sur disque avant de répondre (ingestBuffer.existingSecret et ingestBuffer.tls.existingSecret sont alors obligatoires). Pour utiliser à la place un service Redis ou Valkey managé, pointez ingestBuffer.external vers celui-ci :

Le service doit être non clusterisé et utiliser maxmemory-policy noeviction, et le mode replicated exige au moins un réplica. Configurations prises en charge : Azure Managed Redis avec la stratégie Non-clustered et la haute disponibilité ; Amazon ElastiCache avec le mode cluster désactivé et Multi-AZ ; Google Memorystore for Redis (niveau Standard) ou Memorystore for Valkey avec le mode cluster désactivé ; ou votre propre Valkey ou Redis 6.2+ avec réplicas. Azure Cache for Redis (Basic, Standard, Premium), ElastiCache Serverless, Amazon MemoryDB et tout service en mode cluster ne sont pas pris en charge. Les services qui utilisent le tampon refusent de démarrer, avec un message indiquant le paramètre à modifier, lorsque le service ne remplit pas ces exigences.

apiIngestion — le service d'ingestion

Toute source de données qui récupère ou reçoit des données s'exécute dans son propre service, api-ingestion : la récupération à la demande et le téléversement de fichier d'une personne, ainsi que les sources planifiées (poll), en flux et en push. Il est déployé sur chaque installation (tant que dapr, auth et platform gardent leurs valeurs par défaut), et exécute les sources planifiées sur chaque installation. Les sources en flux et en push exigent en plus le tampon d'ingestion : avec ingestBuffer.enabled désactivé, api-ingestion exécute les sources planifiées, les récupérations à la demande et les téléversements, et l'URL de push n'est pas publiée. Il ne possède aucune base de données et ne stocke aucun identifiant : la plateforme lui délivre l'identifiant de la connexion d'une source à chaque exécution, tentative de connexion ou livraison, et il ne le conserve que pour cette tentative.

L'URL à laquelle un fournisseur livre est https://<routing.host>/api/platform/data-sources/push/<binding id> en mode subpath et https://<auth.gateway.hostname>/api/platform/data-sources/push/<binding id> en mode subdomain. gateway.publicAuthRateLimit ne s'y applique jamais ; chaque source a sa propre limite de livraison.

Ce que chaque plateforme requiert — aucune de ces combinaisons n'a encore été validée par Scrydon. Du côté du chart, le HTTPS sortant relève de networkPolicies.providerEgress :

Actions sortantes — dispatcher, clés de mandat et sortie sur liaison

Toute action sortante est désactivée jusqu'à ce que vous l'activiez. Ces valeurs règlent le côté déploiement ; un administrateur d'organisation active toujours chaque action, et un approbateur admet chaque demande qui exige une approbation. Voir Actions sortantes pour le guide.

Le chart ne rend jamais de clé : nommez des Secrets que vous créez dans l'espace de noms de la plateforme.

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

La licence elle-même se saisit dans l'assistant de configuration et est stockée dans la base de la plateforme ; auth.secrets.LICENSE ne fait que la pré-renseigner. 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 le point de terminaison de l'API Kubernetes tel que votre CNI le voit. cidr n'a pas de valeur par défaut — l'adresse diffère d'un cluster à l'autre — et le chart refuse le rendu tant qu'elle est vide et que cette sortie est activée. Utilisez l'adresse prête de l'EndpointSlice kubernetes plutôt que le ClusterIP du Service, car la politique est évaluée après le DNAT du Service. Trois politiques sélectionnées par pod réutilisent cette destination : le RBAC limite api-platform à get/list sur les nœuds, le labeler PSS à get/patch sur l'unique espace de noms de la release Helm et, en isolation stricte, le contrôleur Runtime Plane à ses propres pods.

kubectl get endpointslice -n default -l kubernetes.io/service-name=kubernetes \
  -o jsonpath='{range .items[*].endpoints[?(@.conditions.ready==true)].addresses[*]}{.}{"\n"}{end}'

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

responseCompression — pages compressées

Les applications platform, agentic, analytics, cortex et horizon compressent elles-mêmes leurs pages, les données de leurs fonctions serveur et leur JSON : brotli pour un navigateur qui l'accepte, gzip sinon. Cela fonctionne derrière n'importe quelle périphérie : vous n'avez pas besoin d'activer la compression sur votre passerelle ou votre équilibreur de charge pour ces applications. Les flux d'événements et les réponses de moins de 1 Ko sont laissés tels quels.

Les réponses de connexion et de session (routing.paths.apiAuth, et le proxy /api/auth de l'application platform) ne sont jamais compressées, car elles contiennent des jetons de session et un secret compressé peut être récupéré (BREACH). Le proxy de platform les marque Cache-Control: no-transform. Si votre propre périphérie compresse, excluez-en routing.paths.apiAuth et respectez no-transform.

Sécurité des pods et budgets de perturbation

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 le cluster minimum (8 vCPU / 40 Go sur au moins deux nœuds). Sur un cluster d'évaluation plus petit, désactivez les composants optionnels les plus lourds. Les trois ci-dessous font passer la mémoire que l'ordonnanceur doit réserver d'environ 24 Gio à environ 14 Gio, ce qui tient dans environ 24 Go de mémoire de nœud :

infra:
  starrocks:
    enabled: false     # 5–8Gi RAM, 20Gi PVC — only Managed Tables + agentic schema-inference affected
apiTable:
  enabled: false
analytics:
  enabled: false       # drops the analytics UI (2 replicas × 1.5Gi) and the marimo-document renderer

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.

Rendu sans cluster actif (GitOps / hors ligne)

À utiliser chaque fois que le chart est rendu sans connexion au cluster cible — tout ce qui exécute helm template en coulisse :

• ArgoCD (son moteur de rendu par défaut)
• l'inflateur helmCharts: de Kustomize
• helm template … | kubectl apply -f -, le flux hors ligne habituel à travers l'isolement
• helm install --dry-run, helm diff

Le HelmRelease de Flux exécute un vrai helm upgrade --install et n'en a pas besoin. Pas plus qu'un helm install/helm upgrade direct, ni zarf package deploy.

Pourquoi c'est important. Chaque secret géré par le chart se résout ainsi : Secret actif du cluster → valeur fournie → valeur aléatoire générée. Sans connexion à l'API, le lookup de Helm ne renvoie rien : la troisième branche s'exécute et produit une valeur différente à chaque rendu. L'appliquer fait tourner 38 secrets à chaque synchronisation, et certaines rotations sont irréversibles :

Que faire. Définissez global.requireExplicitSecrets: true. Chaque branche de génération devient un échec de rendu qui nomme le chemin exact de la valeur : une entrée manquante est bruyante au lieu d'être destructrice. Partez de values.gitops.example.yaml, qui liste le jeu complet requis et les commandes kubectl pour lire les valeurs actuelles d'une installation existante avant de l'adopter :

helm template scrydon ./helm/scrydon \
  -f helm/scrydon/values.yaml \
  -f helm/scrydon/values.gitops.example.yaml \
  -n scrydon-platform

Générez chaque valeur une fois, stockez-la dans votre gestionnaire de secrets et injectez-la au rendu (valuesFrom d'ArgoCD, un overlay déchiffré par sops, --set-file). Gardez les valeurs stables : en changer une ici la change dans le cluster. L'exemple livre chaque secret sous la forme REPLACE-ME-WITH-A-REAL-VALUE-FROM-YOUR-SECRET-STORE, et le rendu échoue, en nommant le chemin de valeur, tant qu'une valeur est encore ce marqueur.

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

Définissez les deux. installControlPlane: false seul laisse le chart supposer que Dapr tourne dans le namespace de la release, et l'installation attend un pod marimo-document dont le sidecar n'arrive pas à joindre dapr-sentry. L'installateur (setup.sh) détecte un plan de contrôle existant et passe les deux options pour vous. Le paquet air-gapped (Zarf) installe toujours son propre Dapr : à côté d'un Dapr existant, son preflight échoue et vous oriente vers --backend mirror, qui le réutilise.

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}'   # expect sentry:1.18.9

Périphérie avancée : 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 gateway.tls.enabled, périphérie privée, dépannage 502). Guide complet : TLS Offloading.

Identifiants StarRocks

Le StarRocks intégré est livré avec root sans mot de passe. Si vous définissez une valeur non vide pour apiTable.secrets.STARROCKS_PASSWORD, le chart l'applique pour vous — un sidecar password-reconciler dans le pod starrocks-fe réconcilie le mot de passe root à chaque démarrage, puis le revérifie une fois par minute : il applique le mot de passe sur un root sans mot de passe, ne fait rien s'il correspond déjà, fait tourner root automatiquement lorsque vous changez la valeur (une annotation de checksum redémarre le pod ; le sidecar change la clé à partir du mot de passe précédent qu'il a enregistré sur le PVC StarRocks), et journalise de manière visible — sans rien écraser — si root a été modifié hors bande. Aucune étape manuelle n'est nécessaire ; laissez la valeur vide pour un root sans mot de passe.

Deux comportements à connaître :

• Le premier démarrage avec mot de passe peut redémarrer starrocks-fe une fois. La vérification de démarrage propre à l'image entre en concurrence avec la toute première application du mot de passe et arrête le conteneur si elle perd ; le mot de passe est déjà persisté à ce moment-là, le démarrage suivant est donc propre. Un redémarrage sur une nouvelle installation est bénin — un CrashLoop ou des redémarrages répétés ne le sont pas.
• L'ordre de rotation est géré pour vous. Changer la valeur et exécuter helm upgrade redémarre starrocks-fe (le sidecar fait tourner root) et api-table (le checksum de son secret a changé) — aucun SET PASSWORD manuel.

NEW_PW="<your-starrocks-password>"   # same value as apiTable.secrets.STARROCKS_PASSWORD
# StarRocks runs in the release namespace by default (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/api-table

Si le mot de passe n'atteint jamais StarRocks (chart plus ancien dont le Job hook a échoué, ou étape manuelle omise), api-table reste en 1/2 Running — conteneur Ready plus un sidecar, mais l'application échoue à sa sonde de disponibilité (/api/table/health/ready → 503, "starrocks": false). Il n'entre pas en CrashLoop, le pod semble donc sain au premier coup d'œil. Comme un pod non Ready est retiré des endpoints de son service api-table-dapr, tout service qui appelle api-table via Dapr (api-ontology, par exemple) reçoit ERR_DIRECT_INVOKE: failed to resolve address for api-table-dapr…. Voir Dépannage. (replication_num est automatiquement ramené au nombre de BE actifs, de sorte qu'un StarRocks en pod unique ne fait plus échouer à lui seul le provisionnement des tables.)

Le mot de passe root est stocké dans les métadonnées FE sur le PVC StarRocks : il survit donc aux redémarrages du pod, et le sidecar de réconciliation le revérifie en continu.

Pour apporter votre propre StarRocks à la place :

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      # all Running, 2/2 with the Dapr sidecar
kubectl get gatewayclass traefik          # ACCEPTED=True
kubectl get gateway -n scrydon-platform   # PROGRAMMED=True, and an ADDRESS
kubectl get httproute -A                  # one per enabled app, Accepted by the Gateway
kubectl get certificates -A               # cert-manager Certificates READY=True

Le cas à examiner de près est une Gateway Programmed dont les listeners ne sont pas Accepted — kubectl describe gateway gateway-frontdoor -n scrydon-platform affiche un bloc de conditions par listener.

Les données de licence (niveau, droits, jours avant expiration) apparaissent sous Settings → Organization → License après /setup. Connectez-vous sur https://app.example.com/platform 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 fichier de licence renouvelé sous Settings → Organization → License → Update license ; 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é.