Ressources de sandbox
- Runner géré : un composant exploité par CoreWeave qui s’exécute dans l’un de vos clusters CKS. Le runner place, supervise et supprime les bacs à sable de ce cluster. Chaque cluster héberge au plus un runner géré, que CoreWeave maintient à jour sur le canal
RELEASE_CHANNEL_STABLEouRELEASE_CHANNEL_RAPIDde votre choix. - Politique : ce que les bacs à sable d’un cluster peuvent demander, et ce qu’ils obtiennent par défaut. Une politique n’est pas une ressource autonome et ne dispose d’aucun point de terminaison propre : il s’agit d’un champ du runner, si bien que chaque cluster est régi par une seule et unique politique. Pour en rédiger une, consultez Configurer une politique de sandbox.
- Sandbox : une charge de travail isolée qui s’exécute sur votre cluster. Une sandbox se décrit intégralement elle-même : elle déclare l’image, les ressources de calcul, l’accès réseau et la durée de vie dont elle a besoin. Les bacs à sable sont créés à la demande via le client Python.
api.cwsandbox.com, qui authentifie chaque appel client, choisit un runner éligible pour héberger la sandbox et relaie le trafic entre le client et le runner propriétaire de chaque sandbox. Une fois la sandbox en cours d’exécution, ses opérations sur les données peuvent également transiter par une connexion mTLS directe qui contourne la passerelle. Voir Connexions directes aux sandbox.
Contraintes clés
- Un cluster héberge au plus un runner géré, et chaque runner est associé à exactement une politique. Une politique régit donc un cluster. Pour exécuter des bacs à sable selon une posture différente, déployez un runner sur un autre cluster et attribuez-lui sa propre politique.
- Une politique est requise. Une politique vide est valide et déclare une posture entièrement permissive : la posture d’un cluster est ainsi toujours déclarée explicitement, et jamais héritée par accident.
- Une politique peut définir une durée de vie par défaut pour les bacs à sable ; la plateforme applique la durée maximale de 30 jours.
- La modification d’une politique s’applique aux bacs à sable créés après celle-ci. Les bacs à sable en cours d’exécution conservent la politique résolue lors de leur lancement.
- Il n’existe aucune portée par utilisateur ou par équipe au sein d’un cluster. Une politique s’applique à chaque bac à sable placé sur ce cluster, quel que soit son créateur.
Relations entre les ressources
L’exécuteur fait le lien entre les deux. Il porte la politique qui régit son cluster et place chaque sandbox sur ce cluster. Une sandbox déclare ses besoins, et la politique détermine si cette requête est autorisée. L’exécuteur fusionne la spécification du bac à sable avec les valeurs par défaut de la politique, la spécification étant prioritaire, puis vérifie que le résultat respecte les contraintes. Toute violation est rejetée au lieu d’être restreinte en silence, et le message d’erreur précise ce qui a été refusé. Voir Aperçu des politiques.Portée multi-cluster
Chaque cluster dispose de son propre exécuteur et de sa propre politique. Les utilisateurs n’ont pas besoin de connaître cette topologie : ils demandent au SDK une sandbox avec la configuration requise, et la passerelle achemine la requête vers un cluster dont la politique l’accepte. Pour le placement CKS, la passerelle sélectionne les ressources de calcul parmi les clusters de votre organisation. En l’absence de restriction par identifiant d’exécuteur, elle choisit un cluster qui dispose de capacité disponible et dont la politique de l’exécuteur autorise la requête de sandbox. Comme la posture est définie au niveau de chaque cluster, une équipe qui a besoin à la fois d’un environnement permissif et d’un environnement restreint utilise deux clusters, et non deux configurations sur un même cluster.Lancement des bacs à sable
Les ressources transitent par deux surfaces de service. C’est dans le plan de contrôle, accessible à l’adresseapi.coreweave.com, que vous définissez les exécuteurs ainsi que la politique associée à chacun d’eux. C’est dans le plan de données, accessible à l’adresse api.cwsandbox.com, que les bacs à sable sont lancés et exploités. Cette séparation compte lorsque vous analysez les défaillances et le contrôle d’accès : une panne du plan de contrôle bloque les modifications des exécuteurs et des politiques, sans affecter les bacs à sable déjà en cours d’exécution, tandis qu’une panne du plan de données perturbe le trafic en cours des bacs à sable, sans toucher à la configuration stockée dans le plan de contrôle.
Plan de contrôle : configuration initiale
Un administrateur utilise la CoreWeave Intelligent CLI ou l’API REST pour déployer un exécuteur sur un cluster CKS et définir la politique qui lui est associée. Le plan de contrôle déploie ensuite l’exécuteur dans le cluster, et l’exécuteur remonte son état via son signal de pulsation (heartbeat). Cette étape s’effectue une fois par cluster, puis de nouveau à chaque modification de la politique. Pour les flux de travail correspondants, voir Configurer une politique de sandbox et Déployer et gérer un runner.Plan de données : lancement d’une sandbox
Lorsqu’un client démarre une sandbox, la passerelle sélectionne un exécuteur éligible et lui envoie une requête de placement. L’exécuteur résout la spécification du bac à sable selon sa politique, puis crée la sandbox à partir du résultat obtenu. L’exécuteur accepte le placement dès qu’il a créé la sandbox, sans attendre son démarrage : le client reçoit donc l’ID de la sandbox alors que celle-ci est encore en cours de démarrage. Une réponse de démarrage réussie signifie que l’exécuteur a accepté la sandbox, et non que la sandbox est déjà en mesure d’exécuter des commandes. Avant d’utiliser la sandbox, attendez qu’elle atteigne l’étatRUNNING ou interrogez son statut jusqu’à ce que ce soit le cas. Si le démarrage échoue, la sandbox passe à l’état FAILED. Elle peut aussi atteindre COMPLETED avant RUNNING si sa commande principale se termine rapidement avec le statut 0. Gérez ces deux états terminaux. La méthode wait() du SDK Python interroge le statut à votre place, et les opérations telles que exec() attendent l’état RUNNING avant de s’exécuter. Voir Cycle de vie d’une sandbox.
C’est le cas de rejet que les utilisateurs remarquent. Comme l’erreur indique la contrainte non respectée, un utilisateur qui demande quelque chose que le cluster n’autorise pas sait ce qu’il doit modifier ou ce qu’il doit demander à un administrateur, sans avoir à connaître la posture à l’avance.
Plan de données : exécution des opérations sur la sandbox
Une fois la sandbox placée, les appels client ultérieurs (exec, opérations sur les fichiers, arrêt) transitent par la passerelle jusqu’à l’exécuteur qui détient la sandbox, puis de là jusqu’à la sandbox elle-même.
Les opérations d’exécution, de journalisation et sur les fichiers peuvent également contourner complètement la passerelle. Le SDK Python privilégie une connexion mTLS directe entre le client et le sandbox, et se rabat sur le chemin via la passerelle illustré ci-dessus lorsque l’accès direct n’est pas disponible. Les appels liés au cycle de vie et à la gestion passent toujours par la passerelle. Voir Connexions directes aux sandbox.
Ressources du plan de contrôle
Le plan de contrôle expose les runners en tant que ressource d’administration. Une politique n’a pas de point de terminaison propre : on y accède par l’intermédiaire du runner auquel elle est associée.
L’aperçu de l’API du plan de contrôle présente l’authentification, les masques de champs, les heartbeats ainsi que la structure des requêtes et des réponses de ces points de terminaison.
Voir aussi
- Utiliser votre propre infrastructure de calcul : activer un runner et lancer une sandbox.
- Aperçu des politiques : comment une sandbox est résolue par rapport à une politique.
- Configurer une politique de sandbox : chaque groupe de contraintes, avec des exemples détaillés.
- Déployer et gérer un runner : le cycle de vie des runners gérés.
- Aperçu de l’API du plan de contrôle : l’authentification, les masques de champs et la structure des requêtes et des réponses de chaque point de terminaison.
- Protobuf : l’hôte qui fournit chaque service, et comment générer un client à partir du module Protobuf publié.