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

gateway:
  tls:
    enabled: true                        # le navigateur accède à Scrydon via HTTPS — voir Gateway 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

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

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: <votre-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      # 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:
  marimoDocument:
    enabled: true                           # rendu privé de documents sans calcul
  marimoRuntime:
    startupDeadlineMs: 300000               # délai de préparation Connect/Run
  secrets:
    MARIMO_RUNTIME_HMAC_SECRET: ""           # vide → généré et 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:
    gateway:
      hostname: ws-agentic.example.com      # mode sous-domaine uniquement
  passkey:
    rpId: app.example.com                   # DOIT correspondre à routing.host sinon l'enregistrement passkey échoue
    origin: https://app.example.com

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.

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. Aucun workload ne revient à une exécution dans le processus ou dans un 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é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 nouveau processus enfant et un espace de travail, tout en réutilisant les mêmes runners Agent, implémentation et notebook. Ce niveau partage le noyau du pod 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.)

Les deux niveaux produit sont microvm et managed_process. Les anciens champs du protocole Runtime Plane (require_true_vm, fallback, mediated, hardened) ne sont plus des contrôles Helm ou d'organisation. Après sélection de microvm, l'adaptateur envoie une valeur interne fixe uniquement pour la compatibilité des mises à niveau.

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" # 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"
  isolation:
    microvm:
      renderRuntimeClass: false # AKS possède 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, 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.

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 la destination étroite de l'API Kubernetes observée par votre CNI, avec un masque /32. Sur AKS avec Calico, il s'agit de l'adresse prête de l'EndpointSlice kubernetes, et non du ClusterIP du Service, car la politique est évaluée après le DNAT du Service. Deux politiques sélectionnées par pod réutilisent cette destination : le RBAC limite api-platform à get/list sur les nœuds, tandis que le labeler PSS est limité à get/patch sur l'unique espace de noms de la release Helm.

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

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. 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 gatewayclass traefik          # ACCEPTED=True
kubectl get gateway -n scrydon-platform   # PROGRAMMED=True, avec une ADDRESS
kubectl get httproute -A                  # une par application activée, acceptée par la Gateway
kubectl get certificates -A               # Certificats cert-manager 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 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é.