Erich Blume
2bea048dbf
## Summary - Mirrors `tailscale/tailscale` on forge (`mirrors/tailscale`) - Replaces vendored `operator.yaml` (495 KB / 5,386 lines) with ArgoCD apps sourcing the upstream static manifest, pinned via `targetRevision: v1.94.2` - Adds `tailscale-operator-base` app for indri and `tailscale-operator-base-ringtail` for ringtail - Local kustomization retains only ProxyClass and DNSConfig custom resources - Updates `[[tailscale-operator]]` doc to reflect new sourcing ## Deployment and Testing - [ ] Register `mirrors/tailscale` repo in ArgoCD (it needs to know about the new repo) - [ ] Sync `apps` app to pick up the new `tailscale-operator-base` app definitions - [ ] Sync `tailscale-operator-base` — verify CRDs, RBAC, operator Deployment come up - [ ] Sync `tailscale-operator` — verify ProxyClass, DNSConfig still apply cleanly - [ ] Verify existing Tailscale Ingresses still work (ProxyGroup pods healthy) - [ ] Repeat for ringtail cluster - [ ] After merge: apps already point at tags, no revision reset needed Reviewed-on: #295
46 lines
1.5 KiB
Markdown
46 lines
1.5 KiB
Markdown
---
|
|
title: Tailscale Operator
|
|
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` |
|
|
| **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|Caddy]] (`*.ops.eblu.me`) instead.
|
|
|
|
## Related
|
|
|
|
- [[tailscale]] - Network configuration
|
|
- [[routing]] - Service routing options
|
|
- [[apps]] - Application registry
|