diff --git a/linkerd.io/content/2.13/features/cni.md b/linkerd.io/content/2.13/features/cni.md index a70dd80fad..999e5443fb 100644 --- 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 index 74ddd707ce..bb32e81916 100644 --- 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 index 502b7053fd..beb0a29504 100644 --- a/linkerd.io/content/2.13/features/nft.md +++ b/linkerd.io/content/2.13/features/nft.md @@ -1,6 +1,6 @@ +++ -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 @@ -8,7 +8,7 @@ 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 new file mode 100644 index 0000000000..6daef28b0f --- /dev/null +++ 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 index 2bad7ae96b..eb688edc33 100644 --- 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 index c6b9582eb9..725bbce8e3 100644 --- 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 index 319f5aa749..ec7d32ed47 100644 --- 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 index 881126f092..e724da6418 100644 --- 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 = [] +++ -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 index 4b95e4f8dc..98274a25b4 100644 --- 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 index 868a958183..bb564bf82c 100644 --- 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 index af39839be3..1e43cb8aae 100644 --- 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 index 6b1773f55b..44f9ea799a 100644 --- 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 index f3e3c7bf38..ae27d66901 100644 --- 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 index f93394864a..c5a3a564fc 100644 --- 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 index 3fa03c9980..fa56c8785e 100644 --- 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'