What We Learned From the Gateway API: Designing Linkerd’s New Policy CRD

The presentation discusses the adoption of the Gateway API for service mesh management and administration, highlighting the importance of distinguishing between traffic frontends and backends and leveraging existing API frameworks.

• The Gateway API is a well-designed API with extensibility points that make it intuitive to work with
• Adopting the Gateway API now makes sense for the project despite its newness and potential for API churn
• The Gateway API's policy attachment framework is useful for both gateways and meshes
• Distinguishing between traffic frontends and backends is crucial for effective service mesh management
• Leveraging existing API frameworks, such as the Gateway API, is preferable to reinventing the wheel

The speaker emphasizes the importance of distinguishing between traffic targets and backends, as failing to do so can lead to confusion and muddiness in service mesh management. The Gateway API's explicit recognition of this difference is a key reason why it is a useful framework for service mesh management and administration.

Since the introduction of the new Gateway APIs, created by the SIG Network community, Linkerd maintainers have been working on leveraging a new pattern known as policy attachment in Linkerd’s authorization mechanism. In this talk, Matei, a Linkerd maintainer, will briefly cover the collection of Gateway APIs, what policy attachment represents, and how it works in practice, and uncover how Linkerd’s authorization policies have been revised with the policy attachment pattern in mind. Policy attachment, as outlined by the SIG Network community, allows platform-level policies, such as timeouts, retries, and custom health checks, to attach to any arbitrary Kubernetes type. This enables users to create custom policies that extend, and plug into the API instead of being a concrete part of it.