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

46 lines
1.5 KiB
Markdown

---
title: Tailscale Operator
date-modified: 2026-02-08
tags:
- 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|Caddy]] (`*.ops.eblu.me`) instead.
## Related
- [[tailscale]] - Network configuration
- [[routing]] - Service routing options
- [[apps]] - Application registry