eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions
blumeops/docs/reference/kubernetes/tailscale-operator.md
Erich Blume 56224867fa Externalize Tailscale operator to forge mirror 
Replace vendored operator.yaml (495 KB) with ArgoCD apps sourcing the
upstream static manifest from mirrors/tailscale on forge, pinned to
v1.94.2 via targetRevision. Adds apps for both indri and ringtail
clusters. Local kustomization retains only ProxyClass and DNSConfig.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-15 17:33:32 -07:00

1.5 KiB
Raw Blame History

title modified tags
Tailscale Operator 2026-02-08
kubernetes
tailscale

Tailscale Kubernetes Operator

The Tailscale operator enables Kubernetes services to be exposed directly on the Tailscale network via Ingress resources.

Quick Reference

Property Value
Namespace tailscale
Upstream mirrors/tailscale on forge (static manifest)
ArgoCD Apps tailscale-operator-base (upstream), tailscale-operator (config)

How It Works

Ingresses use a shared ProxyGroup (ingress) rather than per-service Tailscale nodes. When you create an Ingress with ingressClassName: tailscale:

  1. Operator configures the shared ProxyGroup pods to serve the new Ingress
  2. Service gets a VIP (Virtual IP) address on the tailnet
  3. Service becomes accessible at <hostname>.tail8d86e.ts.net
  4. TLS is handled automatically via Tailscale

Tailnet clients must have --accept-routes enabled to route to VIP addresses.

Services can be individually tagged (e.g., tag:flyio-target) via Ingress annotations to control which ACL grants apply. See expose-service-publicly for the tagging workflow.

Limitations

Services exposed via Tailscale Ingress are not accessible from:

  • Other Kubernetes pods (they're not Tailscale clients)
  • Docker containers on indri

For pod-to-service communication, use routing (*.ops.eblu.me) instead.

Related