Update roadmap (#7413)

Signed-off-by: Charles Pretzer <charles@buoyant.io>
This commit is contained in:
cpretzer 2021-12-13 13:11:32 -08:00 committed by GitHub
parent bfed1b18f8
commit b4abb3f56c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 18 deletions

View File

@ -4,18 +4,10 @@ This document is intended to describe high-level plans for the Linkerd
project and is neither comprehensive nor prescriptive. For a more granular
view of planned work, please refer to the project's upcoming [milestones].
## Server-side policy
## Separate helm chart for Linkerd CRDs
Linkerd's `ServiceProfile` abstraction is primarily focused on client-side
policy/configuration and is inappropriate to address authorization-oriented
policies. We plan on identifying/introducing primitives to support
server-oriented policy/configuration to support authorization as well as
other types of server-centric policy, including the types of configuration
that have been provided by `ServiceProfile`s, including timeouts, routes,
etc.
These policies will supplant existing workload-level annotations where
possible.
Following best practices, Custom Resource Definitions are being migrated to
their own helm chart
## Client-side policy, v2
@ -26,13 +18,9 @@ that support the existing resources as well as:
- Circuit-breakers
- Non-cluster-local traffic targets
- TLS requirements
## Retries for gRPC services
Linkerd does not currently support for retries for requests with payloads,
but this limits the utility of this feature for gRPC services (that
necessarily include request payloads). We plan to support retries for unary
(non-streaming) gRPC requests.
- Route-Specific Authorization
- Outbound Route Configuration
- Header-based Routing
## Mesh expansion
@ -45,5 +33,14 @@ The OpenMetrics working group is developing a new standard for metric
exposition. We plan to support this format and follow best practices
identified by this project.
## Linkerd Gateway
The foundation for this feature exists in the multi-cluster gateway which
provides connectivity between clusters using the multi-cluster extension. As the
need for tighter ingress integration develops, the gateway functionality will
develop into a multi-purpose entry point for traffic entering the cluster,
reducing the dependency on features and development cycles for current ingress
providers.
<!-- references -->
[milestones]: https://github.com/linkerd/linkerd2/milestones