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ègleselectoroutenant.
Prérequis
- Un cluster CKS doté d’un exécuteur de sandbox managé dont le
installStatusestREADY. 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
anyne couvre jamais les sélecteurs. Une politique dont le champallowed_egressn’est pas vide doit donc comporter un droitselectorde forme correspondante : il doit également définirnamespace_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. VoirSelectorBlock. - Le SDK Python
cwsandboxconfiguré avec des identifiants d’authentification pour le placement CKS, ainsi qu’une image de sandbox dans laquellecurletgetentsont installés. - Un accès
kubectlpermettant de créer ou de mettre à jour des Services dans le namespacedefaultet 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 ServiceExternalName 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
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 :
Autoriser le trafic sortant de la sandbox vers le proxy
Sélectionnez le Pod du proxy par étiquette dans uneEgressRule. La règle exige les deux ensembles de libellés :
pod_labelsidentifie le proxy par le Service qu’il expose, au moyen des libelléstailscale.com/parent-resourceettailscale.com/parent-resource-nsde 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_labelssélectionne le namespacetailscale. 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.
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.
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 queHTTP/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 :
Dépannage
Pages connexes
- Déployer l’Opérateur Kubernetes Tailscale : déployer et configurer l’opérateur sur CKS.
- Règles réseau : la référence complète de
EgressRuleetSelectorBlock. - Référence des stratégies : les droits définis par la politique, dont une règle de trafic sortant déclarée ne doit pas sortir.
- Points de terminaison publics : attribuer une adresse publique à un service exécuté dans une sandbox.