Kubernetes
Exigences Kubernetes et Helm pour les déploiements Scrydon
Avant de déployer Scrydon, assurez-vous que votre cluster respecte les exigences Kubernetes ci-dessous.
-
Version : Kubernetes 1.28 ou ultérieur. Le chart l'applique ;
helm installrefuse les clusters antérieurs à 1.28. -
Helm : Helm 3.14 ou ultérieur.
-
Un compte de service limité à un namespace avec les permissions de créer des Deployments, Services, Gateways, HTTPRoutes, Secrets et ConfigMaps.
-
Les CRD de la Gateway API et une GatewayClass. La périphérie du chart repose sur
Gateway+HTTPRoute(gateway.networking.k8s.io), et non surIngress— et contrairement à Ingress, ni les CRD ni une implémentation ne sont présents dans un cluster standard. Installez-en une vous-même et définissezgateway.classNamesur sa GatewayClass, ou définisseztraefik.enabled: trueet le chart installe une release Traefik qui fournit les CRD et publie la GatewayClasstraefik. La redirection HTTPS, le retrait des en-têtes d'identité Dapr et la précédence des chemins relèvent du cœur de la Gateway API et fonctionnent sur toute implémentation conforme ; le seul contrôle propre à Traefik estgateway.publicAuthRateLimit. Voir Autres implémentations Gateway API.Kubernetes Ingress est gelée, et non dépréciée : elle est GA, conserve ses garanties de stabilité et n'est pas destinée à être supprimée, mais elle ne reçoit plus aucun développement et Kubernetes recommande la Gateway API à sa place. Notez qu'
ingress-nginxa été retiré — archivé le 2026-03-24, sans plus aucune version, correction de bug ou correctif de sécurité — et n'est donc pas une voie d'entrée prise en charge vers un cluster Scrydon.Quelle que soit l'implémentation, vérifiez
gateway.listenerPorts.*: c'est le port sur lequel votre contrôleur écoute, pas le port public. Traefik écoute sur:8000/:8443en interne (valeur par défaut du chart) alors que son Service publie 80/443 ; une implémentation managée qui écoute sur le port public attend au contraire 80/443. -
Au moins deux nœuds pour la pile complète par défaut. Le plan de contrôle, les bases de données et les applications qui démarrent ensemble sur un seul petit nœud peuvent provoquer des OOM kill pendant le pic de démarrage. Voir Ressources.
Le plan d'exécution (calcul isolé)
Le plan d'exécution exécute le code client — étapes Agent et noyaux de notebook — dans des pods isolés. Il est désactivé par défaut (runtimePlane.enabled: false), car l'activer sans risque exige des capacités de cluster et des décisions de politique que le chart ne peut pas prendre à votre place.
Ce que cela implique par fonctionnalité :
| Fonctionnalité | Avec le plan d'exécution désactivé |
|---|---|
| Étapes Agent dans les workflows | S'exécutent en processus, avec audit, à condition que personne n'ait explicitement exigé l'isolation et que l'hôte n'ait pas de /dev/kvm. Une organisation qui active Exiger une exécution isolée, ou un déploiement qui l'épingle, échoue en mode fermé. |
| Calcul des notebooks Marimo | Indisponible. Les notebooks s'ouvrent et s'éditent toujours, mais Connecter échoue avec Le calcul n'a pas pu démarrer. Il n'existe volontairement aucun repli sur l'hôte Analytics. |
Le calcul des notebooks n'a pas de repli en processus. Si vos utilisateurs ont besoin des notebooks, le plan d'exécution est une exigence stricte, et non un durcissement facultatif : prévoyez le pool de nœuds ci-dessous avant de promettre la fonctionnalité.
Ce qu'exige son activation
- Dapr activé pour la plateforme et le plan d'exécution. Il constitue le chemin de contrôle authentifié.
- Un CNI qui applique Kubernetes NetworkPolicy, avec
networkPolicies.enabled: true. - Des namespaces séparés pour le contrôleur et les charges non fiables, ainsi qu'une exception d'admission examinée pour le sidecar d'enforcement de sortie root aux capacités limitées (
NET_ADMINetNET_BIND_SERVICEuniquement), tandis que l'application non fiable reste non-root avec toutes les capacités supprimées. - Des images runner et enforcer accessibles par le cluster, épinglées par digest. Le plan refuse les références vides, sans tag ou
latest. Les charts publiés embarquent ces digests ; siruntimePlane.marimoRuntimeImage/enforcerImage/runnerImagesont vides dans votre chart, définissez-les explicitement avant l'activation. - Un RuntimeClass Kata planifiable, adossé à KVM ou à la virtualisation imbriquée, pour le niveau microVM. La seule présence d'un objet RuntimeClass ne prouve pas la capacité : vérifiez qu'un nœud Ready éligible peut exécuter la charge et consultez le rapport de capacités au démarrage du plan. Sur AKS, cela impose un pool de nœuds Pod Sandboxing distinct —
--workload-runtime KataVmIsolationavec--os-sku AzureLinux(le seul SKU pris en charge) et une taille de VM Gen2 compatible avec la virtualisation imbriquée. Cela ne peut pas être activé sur un pool existant. ConservezruntimePlane.isolation.microvm.renderRuntimeClass: false, car AKS enregistre son propre RuntimeClasskata-vm-isolationet en rendre un second provoque un conflit. Le Runtime Plane découvre cette classe et un nœud Ready, non cordonné et compatible au démarrage. - De la capacité pour les charges elles-mêmes. Chaque runtime de notebook interactif réserve ~5,6 Gio et chaque job de notebook ~4,25 Gio ; voir Ressources.
Définissez executionFabric.managedProcess.enabled: false lorsque le déploiement doit être physiquement microVM-only. Si le backend géré est déployé, il n'est utilisé qu'après indisponibilité de la microVM et désactivation de Exiger l'exécution isolée par un administrateur d'organisation. Il n'existe pas de niveau produit « conteneur durci ».