Limitations for the Tailscale Kubernetes Operator
Last validated:
The Tailscale Kubernetes Operator has the following known limitations.
General
- The operator is not officially supported on platforms that restrict privileged pods, such as GKE Autopilot. Features are limited on these platforms.
Egress
The following limitations apply to egress proxies that connect cluster workloads to tailnet devices:
- Egress does not support IP ranges in the
tailscale.com/tailnet-ipannotation. You can specify only a single IPv4 or IPv6 address as a route. - The egress proxy cannot reach 4via6 IP addresses.
- Refer to IPv6 support for IPv6-specific egress limitations.
Layer 7 ingress
The following limitations apply to ingress backed by a Kubernetes Ingress resource:
- The only supported ingress path type is
Prefix. The operator routes requests for paths with other path types according to prefix rules. Ingressresources only support TLS, and are only exposed over HTTPS using a MagicDNS name and publicly trusted certificates from Let's Encrypt. You must enable HTTPS and MagicDNS on your tailnet.- The operator provisions certificates on the first connection, so that connection can be slow or time out while provisioning runs.
Layer 3 ingress
The following limitations apply to L3 ingress backed by a Kubernetes Service resource:
- You cannot add the
tailscale.com/proxy-groupannotation to an existing standalone L3 ingressService. Create a newServicewith the annotation set to the name of the desiredProxyGroupinstead. - Hostname changes using the
tailscale.com/hostnameannotation are not reliably applied to an already-exposedServicewithout recreating it.
Tags
The following limitation applies to tags on operator-managed devices:
- The operator applies tags only during initial device provisioning. If you modify the
tailscale.com/tagsannotation on an already-exposedService, the device tags do not update until you recreate theService.