Skip to main content
La fonctionnalité de trafic sortant de cluster de Tailscale permet à une sandbox exécutée sur votre propre cluster CoreWeave Kubernetes Service (CKS) de se connecter à un appareil de votre tailnet, par exemple une API interne, une base de données de votre réseau d’entreprise ou un serveur de modèles sur un poste de travail. L’opérateur Kubernetes de Tailscale publie l’appareil du tailnet sous la forme d’un Service Kubernetes. Une règle de trafic sortant de la sandbox autorise ensuite celle-ci à accéder au proxy situé derrière ce Service. Cette page s’adresse aux administrateurs qui exécutent un exécuteur de sandbox managé sur un cluster CKS. L’exemple utilise le trafic sortant autonome, avec l’opérateur installé dans le namespace tailscale. Deux comportements de la plateforme conditionnent la configuration :
  • Exposer un Service interne au cluster via l’opérateur Tailscale permet aux appareils du tailnet de s’y connecter. En revanche, les connexions sortantes d’un Pod vers un appareil du tailnet nécessitent la fonctionnalité de trafic sortant de cluster de Tailscale.
  • Les règles de trafic sortant des Sandbox ne peuvent qu’autoriser du trafic, sur une référence qui refuse tout par défaut, et EgressRule(any=True) exclut les adresses internes au cluster. Une destination interne au cluster, comme un proxy Tailscale, n’est donc accessible que par une règle selector ou tenant.

Prérequis

  • Un cluster CKS doté d’un exécuteur de sandbox managé dont le installStatus est READY. Voir Utiliser votre propre infrastructure de calcul.
  • L’opérateur Kubernetes Tailscale installé sur ce cluster, avec le fichier de politique de votre tailnet configuré pour CKS. Voir Déployer l’opérateur Kubernetes Tailscale.
  • Le nom MagicDNS de l’appareil du tailnet que vous souhaitez joindre, par exemple db-host.[TAILNET-NAME].ts.net, ainsi que le port sur lequel votre service écoute.
  • Une politique de l’exécuteur qui autorise cette règle de trafic sortant par sélecteur. Un droit any ne couvre jamais les sélecteurs. Une politique dont le champ allowed_egress n’est pas vide doit donc comporter un droit selector de forme correspondante : il doit également définir namespace_labels, ses libellés doivent former un sous-ensemble de ceux que déclare la sandbox, et son filtre de port doit couvrir le port TCP 8080. Voir SelectorBlock.
  • Le SDK Python cwsandbox configuré avec des identifiants d’authentification pour le placement CKS, ainsi qu’une image de sandbox dans laquelle curl et getent sont installés.
  • Un accès kubectl permettant de créer ou de mettre à jour des Services dans le namespace default et de lister les Pods dans le namespace de l’opérateur.
  • Une politique de tailnet qui autorise le proxy de trafic sortant à se connecter à l’appareil cible et au port de l’application.

Créer un Service de trafic sortant Tailscale

Créez un Service ExternalName annoté avec le nom MagicDNS de l’appareil du tailnet. L’opérateur crée un Pod proxy et un Service headless dans son propre namespace, puis fait pointer le Service ExternalName vers ce Service headless. Les exemples utilisent le namespace tailscale, comme dans le guide d’installation indiqué en lien ; si vous avez installé l’opérateur dans un autre namespace, adaptez les commandes et les namespace_labels ci-dessous. Remplacez [TAILNET-FQDN] par le nom MagicDNS de l’appareil. Cet exemple crée le Service dans default et utilise son nom DNS entièrement qualifié pour que les Sandbox puissent s’y connecter depuis d’autres namespace. Il suppose un service HTTP exposé sur le port 8080 avec un point de terminaison /health ; adaptez le port et le chemin à votre service.
tailnet-egress.yaml
Les Sandbox se connectent à internal-api.default.svc.cluster.local:8080. Le nom court internal-api:8080 ne fonctionne que depuis le namespace du Service. Si votre cluster utilise un suffixe DNS autre que cluster.local, remplacez ce suffixe dans les exemples. Vérifiez que l’opérateur a bien créé le Pod du proxy :
Attendez que le proxy soit prêt. Exemple de sortie (le nom du Pod généré peut varier) :

Autoriser le trafic sortant de la sandbox vers le proxy

Sélectionnez le Pod du proxy par étiquette dans une EgressRule. La règle exige les deux ensembles de libellés :
  • pod_labels identifie le proxy par le Service qu’il expose, au moyen des libellés tailscale.com/parent-resource et tailscale.com/parent-resource-ns de l’opérateur. Incluez le libellé de namespace pour éviter que la règle ne corresponde aussi au proxy d’un Service homonyme situé dans un autre namespace.
  • namespace_labels sélectionne le namespace tailscale. Sans ce paramètre, la règle s’applique uniquement au namespace de la sandbox et ne peut pas atteindre un proxy situé dans un autre namespace.
Définissez ports sur le port d’écoute du service. Remplacez [RUNNER-ID] par l’ID de l’exécuteur du cluster sur lequel vous avez créé le Service. Sans runner_ids, le placement CKS peut utiliser n’importe quel exécuteur éligible de votre organisation, y compris un exécuteur situé sur un cluster dépourvu du proxy.
Ces sélecteurs et ces ports s’appliquent au trafic sortant autonome. Un ProxyGroup de trafic sortant utilise des Pods de proxy partagés et remappe les ports ; cette règle ne constitue donc pas une configuration complète pour ce mode. Voir le guide de Tailscale sur le trafic sortant à haute disponibilité. Le DNS du cluster reste accessible, sauf si la politique de l’exécuteur refuse le trafic sortant DNS au moyen de la contrainte dns_egress. La sandbox peut donc résoudre le nom du Service sans règle supplémentaire.

Vérifier la connexion

L’exemple affiche les en-têtes et le corps de la réponse HTTP, ainsi que les éventuelles erreurs curl. Pour un point de terminaison d’état de santé qui renvoie le statut 200, vous devriez obtenir une ligne de statut telle que HTTP/1.1 200 OK, suivie de la réponse d’état de santé du service. Une erreur HTTP telle que 401 ou 404 indique qu’un serveur HTTP a bien répondu ; vérifiez alors l’authentification de l’application ou le chemin demandé. Un délai d’expiration ou une erreur de connexion peut survenir entre la sandbox et le proxy, entre le proxy et l’appareil du tailnet, ou au niveau de l’application. Pour vérifier séparément la résolution DNS et l’échange HTTP, exécutez cet exemple de diagnostic avec l’identifiant de votre exécuteur :
Une résolution DNS réussie affiche au moins une adresse. Dans la sortie de curl, vérifiez la présence d’une connexion à l’adresse du proxy et d’un code de statut de réponse HTTP. La réussite de la résolution DNS ne suffit pas à confirmer que le proxy peut atteindre la cible.

Dépannage

Dernière modification le 4 novembre 2026