Linkerd Update: Gateway API, Client-Specific Policy, Federated Services, Multicluster... Alex Leong

Linkerd Update: Gateway API, Client-Specific Policy, Federated Services, Multicluster... Alex Leong

Speakers: Alex Leong, Project Maintainer, Software Engineer, Buoyant

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=aYGGnDDGX-Q

Overview

This article details the latest advancements and strategic direction of the Linkerd project, as presented by project maintainer Alex Leong at KubeCon EU. The talk, titled "Linkerd Update: Gateway API, Client-Specific Policy, Federated Services, Multicluster...", provided a comprehensive overview of the service mesh's rapid development over the past year, highlighting significant releases and a robust roadmap. Leong emphasized Linkerd's core philosophy: an ultra-light, ultra-fast, and security-first service mesh specifically engineered for Kubernetes.

The presentation underscored Linkerd's commitment to delivering a secure, reliable, and observable cloud-native platform with minimal operational overhead. Key themes included deeper integration with the Gateway API, enhanced multicluster capabilities with a focus on GitOps, sophisticated egress control, and advanced traffic management policies. This update is crucial for platform engineers, SREs, and developers seeking to leverage a battle-tested, CNCF-graduated project that continues to innovate at a rapid pace while prioritizing resource efficiency and ease of use.

Background

▶ Watch: Introduction to Linkerd: lightweight, security-first service mesh (0:00)

Linkerd has been a cornerstone in the cloud-native ecosystem for eight years, distinguishing itself as a CNCFF-graduated project with a strong emphasis on practical, production-ready solutions. Its design philosophy centers on making the complex simple, ensuring that a service mesh augments, rather than complicates, the operation of Kubernetes applications. This is achieved through principles such as "it should just work," requiring minimal configuration for easy tasks, and scaling complexity only when necessary. Crucially, Linkerd adheres to a "not greedy" approach, recognizing that in a sidecar proxy model, every byte of memory and every microsecond of latency matters.

A defining characteristic of Linkerd is its custom-built micro-proxy, written in Rust. Unlike other service meshes that often leverage Envoy, Linkerd's proxy was developed from the ground up to be security-first, ensuring memory safety and efficient resource utilization through modern Rust networking libraries like Tokyo, Hyper, H2, and Tower. This bespoke proxy is an implementation detail for users, designed to be invisible while providing mTLS by default and robust Layer 7 capabilities. The project's sustainability is further bolstered by its primary funder, Buoyant, now a profitable company, enabling a consistent and accelerated pace of development with weekly production-ready releases.

Key Findings

▶ Watch: Linkerd's design philosophy: simplicity, efficiency, security, ease of use (2:00)

The past year has been exceptionally busy for the Linkerd project, marked by three significant releases: Linkerd 2.16, Linkerd 2.17, and the upcoming Linkerd 2.18. Each release introduced substantial features aimed at enhancing security, observability, and operational efficiency within Kubernetes environments.

Linkerd 2.16 laid the groundwork for modern traffic management by transitioning away from proprietary service profiles towards the Gateway API. This release introduced support for per-route retries, timeouts, and metrics configured via HTTPRoute, gRPCRoute, and TCP/TLS routes. It also brought IPv6 support and a critical policy audit mode, allowing users to test authorization policies in a non-enforcing manner before switching to a default-deny posture, thereby mitigating the risk of application disruption.

Linkerd 2.17 significantly expanded the mesh's capabilities with the introduction of egress rate limiting and federated services. Egress rate limiting provides robust control over outbound traffic, protecting external services from excessive load. Federated services represent a major leap in multicluster management, enabling seamless load balancing across geographically distributed instances of the same service, enhancing resilience and availability.

The soon-to-be-released Linkerd 2.18 focuses on improving the GitOps compatibility of Linkerd's multicluster linking, streamlining declarative deployments. It further refines Gateway API integration, aligning with modern API versions, and introduces protocol declarations to optimize traffic handling by bypassing protocol detection for known protocols, addressing edge cases and performance bottlenecks. These releases collectively demonstrate Linkerd's commitment to evolving its feature set to meet the demands of complex, distributed cloud-native architectures.

Technical Deep Dive

▶ Watch: Understanding Linkerd's unique Rust-based "micro-proxy" (4:00)

Linkerd's recent developments showcase a strategic evolution towards deeper integration with Kubernetes standards, enhanced traffic control, and robust multicluster capabilities.

A cornerstone of the recent updates is the comprehensive integration with the Gateway API. Linkerd has upgraded its support from older versions (e.g., v0.7) to the v1 versions of HTTPRoute and gRPCRoute, ensuring compatibility with Gateway API versions ranging from v1 to v1.21. This broad compatibility extends to both standard and experimental channels, allowing users to leverage advanced types like TCPRoute and TLSRoute for non-HTTP/gRPC traffic. A significant philosophical shift is underway: Linkerd is moving away from bundling Gateway API CRDs by default. Instead, these CRDs will be treated as an external prerequisite, assuming they are already installed by an ingress controller or another project. This change, rolling out fully by Linkerd 2.19, aims to prevent conflicts and streamline deployments in diverse Kubernetes environments.

For outbound traffic management, Linkerd 2.17 introduced the Egress Network custom resource definition (CRD). This resource allows operators to define and gain observability into traffic leaving the mesh. An Egress Network can have routes attached to it, enabling the collection of detailed metrics, including TLS hostnames, for external communication. This provides an invaluable audit trail and granular control, allowing for a default-deny egress policy with specific, allowed exceptions defined via TLSRoute or HTTPRoute. This capability significantly enhances the security posture by limiting the blast radius of compromised workloads.

To protect services from excessive load, Linkerd 2.17 also delivered the HTTP Local Rate Limit Policy. This new resource type allows the specification of either global rate limits or per-client rate limits for HTTP traffic. By configuring maximum requests per second, Linkerd's proxy can intercept and reject requests exceeding the defined threshold before they reach the application, acting as a crucial first line of defense against Denial of Service (DoS) attacks or misbehaving clients.

Federated Services, another major feature from Linkerd 2.17, addresses the challenges of operating services across multiple Kubernetes clusters. When a service with the same name and namespace is deployed across several clusters, Linkerd can merge these instances into a single federated service. This abstract service then intelligently load balances requests across all available endpoints in all participating clusters. This provides a truly cluster-agnostic access model, where applications consume a service without needing to know its physical location. The dynamic nature of federated services ensures continued availability and resilience, automatically adapting to clusters joining or leaving the federation, making it ideal for disaster recovery and global deployments.

Addressing persistent edge cases in traffic handling, Linkerd 2.18 introduces protocol declarations. Historically, Linkerd relied on protocol detection, analyzing initial bytes to identify traffic as HTTP, gRPC, or TCP. While effective 97% of the time, this process could lead to 10-second timeouts and connection delays in scenarios with resource constraints or non-standard protocols. Protocol declarations leverage the appProtocol field in Kubernetes Service resources. By explicitly declaring a port as HTTP or Opaque (for TCP), Linkerd bypasses detection entirely, immediately applying the correct Layer 7 or Layer 4 policies and metrics. This not only eliminates detection timeouts but also ensures consistent behavior for applications that might otherwise trigger these edge cases.

Finally, GitOps-compatible multicluster linking in Linkerd 2.18 significantly refactors how clusters are connected. Previously, linking required imperative linkerd multicluster link commands, which were cumbersome for GitOps workflows and upgrades. The new approach embeds link definitions directly into the Linkerd multicluster Helm chart values. This declarative model means that all multicluster links are managed as part of the Helm release, simplifying upgrades and ensuring that the multicluster configuration is version-controlled and automatically applied, aligning seamlessly with modern GitOps practices. While this makes linking more declarative, future work aims to further enhance flexibility, particularly regarding naming conventions and service merging rules for federated services.

Beyond these immediate releases, Linkerd's roadmap includes expanding Windows support for the full service mesh, exploring ingress use cases to consolidate proxy functionalities, enabling egress TLS origination for Layer 7 visibility into external encrypted traffic, and improving mesh expansion for non-Kubernetes workloads, including support for private networks. The project also plans to investigate using Spiffy for identity within the cluster, unifying identity management across mesh-expanded and in-cluster workloads.

Demo / Proof of Concept

▶ Watch: Linkerd 2.16: Integrating per-route behavior with Gateway API (5:30)

While this specific KubeCon EU update talk did not feature a live demonstration or proof-of-concept, the speaker, Alex Leong, referenced a dedicated deep-dive talk he gave on federated services at "Linkerd Day" earlier in the week. This separate session likely included detailed explanations and possibly demonstrations of the federated services feature, illustrating its configuration and operational benefits in a multicluster environment. For the other features discussed, the presentation focused on their technical implementation and architectural impact rather than a live demonstration.

Defensive Implications

▶ Watch: Linkerd 2.16: New policy audit mode for authorization policies (6:00)

Linkerd's latest features significantly bolster the defensive capabilities of cloud-native platforms, providing robust tools for securing, observing, and controlling traffic. The project's foundational commitment to security-first design means mTLS is enabled by default upon installation, ensuring all in-mesh communication is encrypted and authenticated without any configuration overhead.

The policy audit mode introduced in Linkerd 2.16 is a critical defensive tool. It allows platform engineers to define and validate authorization policies in a "warn-only" mode. Instead of immediately denying unauthorized traffic, Linkerd logs policy violations while still permitting the traffic. This enables operators to thoroughly test their security policies, identify legitimate traffic flows that might otherwise be blocked, and refine their rules with confidence. Only once the policies are proven correct can the system be switched to a default-deny posture, dramatically reducing the risk of accidental application outages while achieving a stronger security baseline.

Egress network policies provide granular control over outbound traffic. By defining an Egress Network CRD, organizations can implement a zero-trust security model for external communication. This allows for a default policy to deny all egress traffic, with explicit exceptions for known and approved external services. The ability to audit TLS hostnames in egress metrics further enhances visibility, allowing security teams to detect unauthorized communication attempts and maintain a clear understanding of what external resources their applications are interacting with. This is vital for preventing data exfiltration and controlling access to third-party services.

The HTTP Local Rate Limit Policy acts as a crucial protective layer against various forms of abuse, including Denial of Service (DoS) attacks, brute-force attacks, or simply misbehaving clients that generate excessive load. By enforcing rate limits at the mesh edge (the proxy), Linkerd can shed excess traffic before it consumes application resources, ensuring the stability and availability of services even under duress. This offloads the burden of rate limiting from application developers, providing a consistent and robust defense mechanism across the mesh.

Federated services, while primarily a multicluster feature, also contribute to resilience, a key aspect of defensive posture. By load balancing across multiple clusters, a federated service can automatically route traffic away from compromised or failing clusters, maintaining service availability and continuity. This inherent redundancy and failover capability significantly enhances the overall reliability and fault tolerance of distributed applications.

Finally, protocol declarations improve the predictability and reliability of traffic handling. By eliminating potential protocol detection timeouts, Linkerd ensures that traffic is correctly identified and routed, preventing scenarios where misidentified traffic might bypass intended Layer 7 policies. This contributes to a more consistent and secure application of traffic rules, reducing the attack surface introduced by unexpected protocol fallback behaviors.

Key Takeaways

• Gateway API as the Standard: Linkerd is fully embracing the Kubernetes Gateway API (v1 HTTPRoute, gRPCRoute, TCPRoute, TLSRoute) for advanced traffic management, moving away from proprietary service profiles and treating Gateway API CRDs as an external prerequisite.
• Enhanced Security Posture: New features like policy audit mode enable safe implementation of default-deny authorization policies, while Egress Network CRDs provide granular control and observability over outbound traffic, including TLS hostname auditing.
• Robust Traffic Protection: The HTTP Local Rate Limit Policy allows services to defend against excessive load and DoS attacks by enforcing global or per-client rate limits directly within the mesh proxies.
• Seamless Multicluster Resilience: Federated services provide cluster-agnostic load balancing across service instances spanning multiple Kubernetes clusters, significantly enhancing application availability and resilience.
• Optimized Traffic Handling: Protocol declarations, using the appProtocol field, eliminate protocol detection timeouts and improve performance and predictability for specific protocols like HTTP and opaque TCP.
• GitOps-Friendly Multicluster: Linkerd 2.18 streamlines multicluster linking by embedding link configurations directly into Helm chart values, making the setup fully declarative and compatible with modern GitOps workflows.

About the Speaker(s)

Alex Leong is a dedicated Project Maintainer for Linkerd and a Software Engineer at Buoyant, the company primarily funding Linkerd's development. His work focuses on the continuous evolution and enhancement of the Linkerd service mesh. Leong is actively involved in the Linkerd community, contributing to its rapid pace of execution and presenting on its advancements, including deep dives into specific features like federated services, at major conferences such as KubeCon EU. He plays a key role in translating user feedback into practical improvements and shaping the project's roadmap.