blumeops/docs/reference/kubernetes/tailscale-operator.md
Erich Blume 54db8643a1 Update docs to reflect public service routing via Fly.io
- security-model: Replace "no public access" with Fly.io proxy description
- routing: Add *.eblu.me as third DNS domain for public services
- architecture: Add Fly.io to network layer and service routing table
- CLAUDE.md: Add public routing domain to routing table
- gandi: Add public CNAME records section
- tailscale-operator: Document ProxyGroup, VIP routing, per-Ingress tags
- flyio-proxy: Clarify why Alloy uses direct Tailscale endpoints (ACL)
- Remove hardcoded Tailscale IP (100.98.163.89) from docs, use DNS names

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-08 21:53:07 -08:00

1.4 KiB

title tags
Tailscale Operator
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.