Présentation du déploiement
Déployez, licenciez et mettez à niveau la plateforme Scrydon sur Kubernetes
Cette section couvre le déploiement, la licence et la mise à niveau de la plateforme Scrydon. Scrydon fonctionne sur Kubernetes et est livré soit sous forme de chart Helm (environnements connectés) soit sous forme de package Zarf autonome (environnements isolés).
Choisir votre emplacement
Chaque installation utilise le même chart Helm. Commencez par la page correspondant à votre environnement de déploiement — chacune renvoie à la référence Helm et ajoute uniquement les notes spécifiques à l'environnement.
| Où | Par où commencer |
|---|---|
| Votre propre centre de données / cluster autogéré | On-Premise |
| Azure (AKS, contrôle Helm complet) | Azure (AKS) |
| Azure (natif du portail, en un clic) | Azure Marketplace |
| Pas d'Internet sortant (classifié / isolé) | Air-Gapped |
AWS et GCP suivent la même installation Helm que On-Premise ; des guides spécifiques au cloud seront publiés ici au fur et à mesure de leur rédaction.
Présentation de l'architecture
Scrydon est livré sous la forme d'un chart Helm unique qui, par défaut, déploie tous les services dans un seul espace de noms Kubernetes (scrydon-platform). Le chart accepte également un bloc namespaces.* qui répartit les services dans plusieurs espaces de noms lorsqu'une isolation est requise.
| Groupe de services | Espace de noms par défaut | Composants | Objectif |
|---|---|---|---|
| Platform | scrydon-platform | api-platform, UI platform | Authentification, autorisation, plan de contrôle de la plateforme |
| Agentic | scrydon-platform (remplaçable via namespaces.agentic) | agentic, agentic-realtime | Moteur de workflows IA, coordination d'exécution en temps réel |
| Analytics | scrydon-platform (remplaçable via namespaces.analytics) | analytics, marimo-document | Interface d'analyse et rendu de notebooks sans calcul (optionnel) |
| Runtime Plane | scrydon-runtimes | runtime-plane | Contrôleur optionnel des workloads isolés |
| Workloads runtime | scrydon-runtime-workloads | Étapes Agent, sessions Marimo et jobs de notebooks éphémères | Calcul non fiable ; créé uniquement lors d'une intention d'exécution |
| Cortex | scrydon-platform (remplaçable via namespaces.cortex) | cortex | Interface chat / chemin rapide LLM |
| Ontology | scrydon-platform | api-ontology | Graphe de connaissances + manifests de packs |
| Tables | scrydon-platform | api-table | Tables gérées (OLAP basé sur StarRocks) |
| Infra (intégrée) | scrydon-platform (remplaçable via namespaces.infra) | PostgreSQL+pgvector, StarRocks, SeaweedFS, OPA | Plan de données interne optionnel — désactivez individuellement si vous apportez le vôtre |
Tous les services partagent une seule instance PostgreSQL (intégrée ou BYO). Chaque service nécessitant de la persistance dispose de sa propre base de données logique (auth, agentic, analytics, cortex, ontology). La communication service à service utilise Dapr avec mTLS — les politiques ACL du chart appliquent l'identité basée sur SPIFFE. La périphérie repose sur la Gateway API de Kubernetes (Gateway + HTTPRoute) ; la GatewayClass par défaut est traefik, et toute implémentation conforme fonctionne.
Pour une isolation par espace de noms, remplacez namespaces.<service> — le chart aligne automatiquement les politiques ACL Dapr et le RBAC du lecteur de secrets.
Ce dont vous avez besoin avant de commencer
- Cluster Kubernetes 1.28+
- PostgreSQL 16+ avec l'extension
pgvector(ou utilisez le Postgres intégré au cluster) - Les CRD de la Gateway API (
gateway.networking.k8s.io) et une GatewayClass — outraefik.enabled: true, qui fait installer par le chart une release Traefik fournissant les deux - Enregistrements DNS pour le nom d'hôte de la plateforme (nom d'hôte unique pour le routage par sous-chemin)
- Certificats TLS (cert-manager recommandé, avec sa prise en charge Gateway API activée)
- Un bundle de licence Scrydon (
{ jwt, publicKey }fichier JSON) — contactez sales@scrydon.com - Un fournisseur de messagerie (Resend, SendGrid ou SMTP) pour les e-mails transactionnels — vérification à l'inscription, invitations et réinitialisations de mot de passe
- Un fournisseur d'IA (OpenAI, Anthropic, Azure OpenAI, Bedrock, Mistral, ou Ollama/vLLM auto-hébergé) pour utiliser les fonctionnalités d'IA — connecté après l'installation sous Paramètres → Plateforme → Extensions
Consultez la page Prérequis pour tous les détails, y compris les exigences en ressources.
Plan de la section
Emplacement — choisissez où déployer :
Cycle de vie — opérez dans la durée :
Référence — les mécanismes sur lesquels chaque emplacement s'appuie :
- Helm — la référence complète du chart (connexion, espaces de noms, valeurs, assistant de configuration, vérification et tous les remplacements)
- Modes de routage — sous-chemin vs sous-domaine
- Déchargement TLS — derrière une App Gateway / ALB / GCP LB
- BYO Database — Postgres externe/géré à la place de celui intégré
Opérations — runbooks J+2 : voir Opérations.
Avant toute installation, complétez les Prérequis.