Tailscale Operator 1.102 Automates In-Cluster Peer Relays and Cross-Cluster Routing

Tailscale has officially released version 1.102 of its Kubernetes Operator, introducing native Custom Resource support for in-cluster Peer Relays, upgraded IPv6 egress via ProxyGroup, and mitigations for certificate churn during dynamic provisioning. The centerpiece of this release is the new PeerRelay Custom Resource Definition (CRD), which enables platform engineers to automatically deploy and maintain dedicated UDP relay endpoints directly inside Kubernetes clusters instead of managing out-of-band client setups. Additionally, the release brings automated 4via6 IPv6 mapping support to the operator's routing layer, allowing workloads to seamlessly communicate across environments with overlapping IPv4 subnet spaces. For platform teams and network engineers, this release addresses two severe friction points in modern cloud-native networking: throughput degradation across restricted VPC boundaries and configuration sprawl. When direct NAT traversal fails between isolated VPCs or multi-cloud clusters, traffic historically fell back to shared DERP relay infrastructure, which can introduce throughput bottlenecks and variable latency. By making Peer Relays declarative and natively manageable through the operator, teams can automate the deployment of dedicated, high-performance relays that provide near-direct WireGuard throughput without requiring complex firewall modifications or external bastion maintenance. This update reflects a broader, industry-wide evolution in network automation: the transition from static, out-of-band overlay scripting toward declarative, intent-based network infrastructure embedded directly inside container orchestrators. As organizations adopt distributed microservices across disparate clouds and edge locations, traditional network plumbing like static site-to-site VPNs and complex transit gateways becomes increasingly unsustainable to manage at scale. Embedding overlay routing, encryption, and relay infrastructure directly into Kubernetes CRDs enables platform engineers to treat complex network topologies as code, integrating network provisioning directly into standard CI/CD and GitOps deployment cycles. In practice, teams managing multi-cluster topologies should evaluate deploying PeerRelay custom resources within their transit or centralized connectivity clusters to avoid shared relay throttling. Practitioners operating in environments with overlapping CIDR blocks can now leverage the enhanced 4via6 support to interconnect isolated clusters without undergoing disruptive IP renumbering projects. However, platform engineers must ensure appropriate Tailscale Access Control Lists (ACLs) and RBAC policies are defined, as opening UDP relay ports and automating egress across clusters requires continuous validation of service identities and network access boundaries.