- 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>
1.4 KiB
1.4 KiB
| title | tags | ||
|---|---|---|---|
| Tailscale Operator |
|
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:
- Operator configures the shared ProxyGroup pods to serve the new Ingress
- Service gets a VIP (Virtual IP) address on the tailnet
- Service becomes accessible at
<hostname>.tail8d86e.ts.net - 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.