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 1c32e351f7 Backfill date-modified frontmatter on all docs 
Dagger's --src=. excludes .git, so Quartz can't use git history for
page dates inside containers. Populate date-modified: YYYY-MM-DD in
frontmatter for all 80 doc articles so the frontmatter priority level
(highest in quartz.config.ts) works with or without git.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-11 16:11:05 -08:00

1.5 KiB
Raw Blame History

title date-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
Helm Chart tailscale/tailscale-operator
ArgoCD App tailscale-operator

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