Add dynamic request routing feature doc, and random cleanup (#1648)

* doc and site updates Signed-off-by: William Morgan <[email protected]> * doc and site updates Signed-off-by: William Morgan <[email protected]> * lint Signed-off-by: William Morgan <[email protected]> * lint Signed-off-by: William Morgan <[email protected]> --------- Signed-off-by: William Morgan <[email protected]> Co-authored-by: Flynn <[email protected]>
linkerd · Jul 19, 2023 · 245abff · 245abff
1 parent dd5bd46
commit 245abff
Show file tree

Hide file tree

Showing 15 changed files with 66 additions and 38 deletions.
diff --git a/linkerd.io/content/2.13/features/cni.md b/linkerd.io/content/2.13/features/cni.md
@@ -9,10 +9,10 @@ every meshed pod to its proxy. (See the
 without the application being aware.
 
 By default, this rewiring is done with an [Init
-Container](../../reference/architecture/#linkerd-init-container) that uses iptables
-to install routing rules for the pod, at pod startup time. However, this requires
-the `CAP_NET_ADMIN` capability; and in some clusters, this capability is not
-granted to pods.
+Container](../../reference/architecture/#linkerd-init-container) that uses
+iptables to install routing rules for the pod, at pod startup time. However,
+this requires the `CAP_NET_ADMIN` capability; and in some clusters, this
+capability is not granted to pods.
 
 To handle this, Linkerd can optionally run these iptables rules in a [CNI
 plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)

diff --git a/linkerd.io/content/2.13/features/http-grpc.md b/linkerd.io/content/2.13/features/http-grpc.md
@@ -4,18 +4,18 @@ description = "Linkerd will automatically enable advanced features (including me
 weight = 1
 +++
 
-Linkerd can proxy all TCP connections, and will automatically enable advanced
-features (including metrics, load balancing, retries, and more) for HTTP,
-HTTP/2, and gRPC connections. (See
-[TCP Proxying and Protocol Detection](../protocol-detection/) for details of how
-this detection happens).
+Linkerd can proxy all TCP connections. For HTTP connections (including HTTP/1.0,
+HTTP/1.1, HTTP/2, and gRPC connections), it will automatically enable advanced
+L7 features including [request-level metrics](../telemetry/), [latency-aware
+load balancing](../load-balancing/), [retries](../retries-and-timeouts/), and
+more.
 
-## Notes
+(See [TCP Proxying and Protocol Detection](../protocol-detection/) for details of
+how this detection happens automatically, and how it can sometimes fail.)
 
-* gRPC applications that use [grpc-go][grpc-go] must use version 1.3 or later due
-  to a [bug](https://github.com/grpc/grpc-go/issues/1120) in earlier versions.
-* gRPC applications that use [@grpc/grpc-js][grpc-js] must use version 1.1.0 or later
-  due to a [bug](https://github.com/grpc/grpc-node/issues/1475) in earlier versions.
-
-[grpc-go]: https://github.com/grpc/grpc-go
-[grpc-js]: https://github.com/grpc/grpc-node/tree/master/packages/grpc-js
+Note that while Linkerd does [zero-config mutual TLS](../automatic-mtls/), it
+cannot decrypt TLS connections initiated by the outside world. For example, if
+you have a TLS connection from outside the cluster, or if your application does
+HTTP/2 plus TLS, Linkerd will treat these connections as raw TCP streams. To
+take advantage of Linkerd's full array of L7 features, communication between
+meshed pods must be TLS'd by Linkerd, not by the application itself.
diff --git a/linkerd.io/content/2.13/features/nft.md b/linkerd.io/content/2.13/features/nft.md
@@ -1,14 +1,14 @@
 +++
-title = "Proxy Init Iptables Modes"
-description = "Linkerd's init container can run in two separate modes, nft or legacy."
+title = "Iptables-nft Support"
+description = "Linkerd's init container can use iptables-nft on systems that require it."
 +++
 
 To transparently route TCP traffic through the proxy, without any awareness
 from the application, Linkerd will configure a set of [firewall
 rules](../../reference/iptables/) in each injected pod. Configuration can be
 done either through an [init
 container](../../reference/architecture/#linkerd-init-container) or through a
-[CNI plugin](../cni/)
+[CNI plugin](../cni/).
 
 Linkerd's init container can be run in two separate modes: `legacy` or `nft`.
 The difference between the two modes is what variant of `iptables` they will use
@@ -26,7 +26,7 @@ two, is which binary they will call into:
    This is the default mode that `linkerd-init` runs in, and is supported by
    most operating systems and distributions.
 2. `nft` mode will call into `iptables-nft`, which uses the newer `nf_tables`
-   kernel API. The [`nftables`] utilities are used by newer operating systems to
+   kernel API. The `nftables` utilities are used by newer operating systems to
    configure firewalls by default.
 
 [`iptables-legacy`]: https://manpages.debian.org/bullseye/iptables/iptables-legacy.8.en.html

diff --git a/linkerd.io/content/2.13/features/request-routing.md b/linkerd.io/content/2.13/features/request-routing.md
@@ -0,0 +1,24 @@
++++
+title = "Dynamic Request Routing"
+description = "Linkerd can route individual HTTP requests based on their properties."
++++
+
+Linkerd's dynamic request routing allows you to control routing of HTTP and gRPC
+traffic based on properties of the request, including verb, method, query
+parameters, and headers. For example, you can route all requests that match
+a specific URL pattern to a given backend; or you can route traffic with a
+particular header to a different service.
+
+This is an example of _client-side policy_, i.e. ways to dynamically configure
+Linkerd's behavior when it is sending requests from a meshed pod.
+
+Dynamic request routing is built on Kubernetes's Gateway API types, especially
+[HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/).
+
+This feature extends Linkerd's traffic routing capabilities beyond those of
+[traffic splits](../traffic-split/), which only provide percentage-based
+splits.
+
+## Learning more
+
+- [Guide to configuring routing policy](../../tasks/configuring-dynamic-request-routing/)
diff --git a/linkerd.io/content/2.13/features/server-policy.md b/linkerd.io/content/2.13/features/server-policy.md
@@ -130,5 +130,5 @@ result in an abrupt termination of those connections.
 
 ## Learning more
 
-- [Policy reference](../../reference/authorization-policy/)
+- [Authorization policy reference](../../reference/authorization-policy/)
 - [Guide to configuring per-route policy](../../tasks/configuring-per-route-policy/)
diff --git a/linkerd.io/content/2.13/features/traffic-split.md b/linkerd.io/content/2.13/features/traffic-split.md
@@ -13,8 +13,14 @@ for example, by slowly easing traffic off of an older version of a service and
 onto a newer version.
 
 {{< note >}}
-If working with headless services, traffic splits cannot be retrieved. Linkerd
-reads service discovery information based off the target IP address, and if that
+This feature will eventually be supplanted by the newer [dynamic request
+routing](../request-routing/) capabilities, which does not require the SMI
+extension.
+{{< /note >}}
+
+{{< note >}}
+TrafficSplits cannot be used with headless services. Linkerd reads
+service discovery information based off the target IP address, and if that
 happens to be a pod IP address then it cannot tell which service the pod belongs
 to.
 {{< /note >}}

diff --git a/linkerd.io/content/2.13/tasks/configuring-dynamic-request-routing.md b/linkerd.io/content/2.13/tasks/configuring-dynamic-request-routing.md
@@ -24,7 +24,7 @@ request routing, by deploying in the cluster two backend and one frontend
 podinfo pods. Traffic will flow to just one backend, and then we'll switch
 traffic to the other one just by adding a header to the frontend requests.
 
-## Set Up
+## Setup
 
 First we create the `test` namespace, annotated by linkerd so all pods that get
 created there get injected with the linkerd proxy:

diff --git a/linkerd.io/content/2.13/tasks/configuring-per-route-policy.md b/linkerd.io/content/2.13/tasks/configuring-per-route-policy.md
@@ -1,12 +1,12 @@
 +++
-title = "Configuring Per-Route Policy"
+title = "Configuring Fine-grained Authorization Policy"
 description = "Fine-grained authorization policies can be configured for individual HTTP routes."
 aliases = []
 +++
 
 <!-- markdownlint-disable-file MD014 -->
 
-In addition to [enforcing authorization policies at the service
+In addition to [enforcing authorization at the service
 level](../restricting-access/), finer-grained authorization policies can also be
 configured for individual HTTP routes. In this example, we'll use the Books demo
 app to demonstrate how to control which clients can access particular routes on
@@ -16,7 +16,7 @@ This is an advanced example that demonstrates more complex policy configuration.
 For a basic introduction to Linkerd authorization policy, start with the
 [Restricting Access to Services](../restricting-access/) example. For more
 comprehensive documentation of the policy resources, see the
-[Policy reference docs](../../reference/authorization-policy/).
+[Authorization policy reference](../../reference/authorization-policy/).
 
 ## Prerequisites
 

diff --git a/linkerd.io/content/_index.md b/linkerd.io/content/_index.md
@@ -98,7 +98,7 @@ foundation_member_banner:
 cta_buoyant:
   image: "/uploads/buoyant-logo-blue.png"
   textcreated: "Linkerd was created by"
-  caption: "Learn more about Buoyant"
+  caption: "Learn more about Buoyant's Linkerd offerings"
   url: "https://buoyant.io/"
 
 ---
diff --git a/linkerd.io/content/blog/2023/0130-mtls-and-linkerd.md b/linkerd.io/content/blog/2023/0130-mtls-and-linkerd.md
@@ -1,5 +1,5 @@
 ---
-title: "mTLS and Linkerd"
+title: "Workshop recap: A deep dive into Kubernetes mTLS with Linkerd"
 author: 'flynn'
 date: 2023-01-30T00:00:00+00:00
 slug: mtls-and-linkerd
@@ -20,8 +20,6 @@ _This blog post is based on a workshop I recently delivered at Buoyant’s
 interesting, check out the [full
 recording](https://buoyant.io/service-mesh-academy/kubernetes-mtls-with-linkerd)!_
 
-## mTLS and Linkerd
-
 You don’t have to spend much time in the cloud-native world before
 [mTLS](https://buoyant.io/mtls-guide) comes up. It shows up over and over
 again, especially once you start talking about

diff --git a/linkerd.io/content/blog/2023/0221-linkerd-and-ingress.md b/linkerd.io/content/blog/2023/0221-linkerd-and-ingress.md
@@ -2,7 +2,7 @@
 author: 'flynn'
 date: 2023-02-21T00:00:00Z
 title: |-
-  Linkerd and Ingress Controllers: Bringing the Outside World In
+  Workshop recap: Linkerd and Ingress Controllers: Bringing the Outside World In
 url:
   /2023/02/21/linkerd-and-ingress/
 thumbnail: '/uploads/2023/02/door-battaglia-9drS5E_Rguc-square.jpg'

diff --git a/linkerd.io/content/blog/2023/0515-real-world-gitops.md b/linkerd.io/content/blog/2023/0515-real-world-gitops.md
@@ -2,7 +2,7 @@
 author: 'flynn'
 date: 2023-05-15T00:00:00Z
 title: |-
-  Real-World GitOps with Flux, Flagger, and Linkerd
+  Workshop recap: Real-World GitOps with Flux, Flagger, and Linkerd
 url:
   /2023/05/15/real-world-gitops/
 thumbnail: '/uploads/2023/05/gitops-square.png'

diff --git a/linkerd.io/content/blog/2023/0613-dynamic-request-routing-circuit-breaking.md b/linkerd.io/content/blog/2023/0613-dynamic-request-routing-circuit-breaking.md
@@ -2,7 +2,7 @@
 author: 'flynn'
 date: 2023-06-13T00:00:00Z
 title: |-
-  Dynamic Request Routing and Circuit Breaking
+  Workshop recap: Dynamic Request Routing and Circuit Breaking
 url:
   /2023/06/13/dynamic-request-routing-circuit-breaking/
 thumbnail: '/uploads/2023/06/dnevozhai-routing-7nrsVjvALnA-unsplash-square.jpg'

diff --git a/linkerd.io/content/blog/2023/0621-edge-roundup.md b/linkerd.io/content/blog/2023/0621-edge-roundup.md
@@ -2,7 +2,7 @@
 author: 'matei'
 date: 2023-06-21T00:00:00Z
 title: |-
-  Linkerd Edge Roundup: 21 June 2023
+  Linkerd Edge Release Roundup: 21 June 2023
 url:
   /2023/06/20/linkerd-edge-roundup/
 thumbnail: '/uploads/2023/06/roundup-clocks-square.png'
@@ -12,7 +12,7 @@ featured: false
 ---
 
 {{< fig
-  alt="21 June Linkerd Edge Roundup"
+  alt="21 June Linkerd Edge Release Roundup"
   src="/uploads/2023/06/roundup-clocks-rect.png" >}}
 
 Linkerd’s edge releases are a big part of our development process that we’re

diff --git a/linkerd.io/content/blog/2023/0713-linkerd-in-production.md b/linkerd.io/content/blog/2023/0713-linkerd-in-production.md
@@ -2,7 +2,7 @@
 author: 'flynn'
 date: 2023-07-13T00:00:00Z
 title: |-
-  Linkerd 2.13 in Production
+  Workshop recap: Running Linkerd in Production
 url:
   /2023/07/13/linkerd-in-production/
 thumbnail: '/uploads/2023/07/jan-huber-0xNbk7D_s6U-square.jpg'