linkerd · travisbeckham · Nov 3, 2025 · Oct 30, 2025 · Oct 30, 2025 · Oct 31, 2025
diff --git a/linkerd.io/config/_default/menu.yaml b/linkerd.io/config/_default/menu.yaml
@@ -39,6 +39,9 @@ docs:
   - name: Linkerd edge
     pageRef: /2-edge/
     weight: 99
+  - name: Linkerd 2.19
+    pageRef: /2.19/
+    weight: 19
   - name: Linkerd 2.18
     pageRef: /2.18/
     weight: 18

diff --git a/linkerd.io/config/_default/params.yaml b/linkerd.io/config/_default/params.yaml
@@ -14,4 +14,4 @@ social:
   twitter: Linkerd
 
 # Latest major version of Linkerd
-latestMajorVersion: "2.18"
+latestMajorVersion: "2.19"
diff --git a/linkerd.io/content/2-edge/features/gateway-api.md b/linkerd.io/content/2-edge/features/gateway-api.md
@@ -3,14 +3,16 @@ title: Gateway API support
 description: Linkerd uses Gateway API resource types to configure certain features.
 ---
 
-The Gateway API is a set of CRDs in the `gateway.networking.k8s.io` API group
-which describe types of traffic in a way that is independent of a specific mesh
-or ingress implementation. Recent versions of Linkerd fully support the
-[Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) as a core
-configuration mechanism, and many Linkerd features, including [authorization
-policies][auth-policy], [dynamic traffic routing][dyn-routing], and [request
-timeouts][timeouts], rely on resource types from the Gateway API for
-configuration.
+The [Gateway API](https://gateway-api.sigs.k8s.io/) is a set of CRDs in the
+`gateway.networking.k8s.io` API group which describe types of traffic in a way
+that is independent of a specific mesh or ingress implementation. Recent
+versions of Linkerd fully support the [Kubernetes Gateway
+API](https://gateway-api.sigs.k8s.io/) as a core configuration mechanism, and
+many Linkerd features, including [authorization policies][auth-policy], [dynamic
+traffic routing][dyn-routing], and [request timeouts][timeouts], require these
+resource types from the Gateway API in order to be used. (Note that Linkerd does
+not require these types in order to run, but these features will not be
+useable.)
 
 The two primary Gateway API types used to configure Linkerd are:
 
@@ -19,36 +21,23 @@ The two primary Gateway API types used to configure Linkerd are:
 
 Both of these types are used in a variety of ways when configuring Linkerd.
 
-## Managing the Gateway API
+## Checking the existing Gateway API version
 
-One complication with using the Gateway API in practice is that many different
-packages, not just Linkerd, may provide the Gateway API on your cluster, but
-only some Gateway API *versions* are compatible with Linkerd.
-
-Linkerd requires that the Gateway API be installed on your cluster before
-Linkerd can be installed. In practice, there are three basic approaches to
-managing the Gateway API with Linkerd. The Gateway API may already be installed
-on your cluster, you can install the Gateway API yourself, or you can have
-Linkerd install the Gateway API for you.
-
-### Option 1: The Gateway API is already installed {#gateway-api-compatibility}
-
-The Gateway API may already be installed on your cluster; either because it came
-pre-installed on the cluster or because another tool has installed it. You can
-check if the Gateway API is installed by running:
+The Gateway API may already be installed on your cluster. Check by running:
 
 ```bash
-> kubectl get crds/httproutes.gateway.networking.k8s.io -o "jsonpath={.metadata.annotations.gateway\.networking\.k8s\.io/bundle-version}"
+kubectl get crds/httproutes.gateway.networking.k8s.io -o "jsonpath={.metadata.annotations.gateway\.networking\.k8s\.io/bundle-version}"
 ```
 
 If this command returns Not Found error, the Gateway API is not installed.
 Otherwise it will return the Gateway API version number. Check that version
 against the compatibility table:
 
-| Linkerd versions | Gateway API version compatibilty | HTTPRoute version | gRPC version |
-| ---------------- | -------------------------------- | ----------------- | ------------ |
-| 2.15 - 2.17      | 0.7 - 1.1.1                      | v1beta1           | v1alpha2     |
-| 2.18             | 1.1.1 - 1.2.1                    | v1                | v1           |
+| Linkerd versions | Gateway API version compatibility | HTTPRoute version | gRPC version |
+| ---------------- | --------------------------------- | ----------------- | ------------ |
+| 2.15 - 2.17      | 0.7 - 1.1.1                       | v1beta1           | v1alpha2     |
+| 2.18             | 1.1.1 - 1.2.1                     | v1                | v1           |
+| 2.19             | 1.1.1 - 1.4.0                     | v1                | v1           |
 
 {{< note >}}
 
@@ -59,52 +48,23 @@ for more information.
 [the Gateway API 1.2.0 release notes]: https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.2.0
 {{< /note >}}
 
-If the Gateway API is installed at a compatible version, you can go ahead and
-install Linkerd as normal. Note that if you are using Helm to install, you must
-set `--set installGatewayAPI=false` or specify this in your `values.yml` when
-installing the `linkerd-crds` Helm chart. This prevents Linkerd from attempting
-to override your existing installation of the Gateway API
-
 {{< warning >}}
 Running Linkerd with an incompatible version of the Gateway API
 on the cluster can lead to hard-to-debug issues with your Linkerd installation.
 {{< /warning >}}
 
-### Option 2: Install the Gateway API yourself
+## Installing the Gateway API
 
-If the Gateway API is not already installed on your cluster, you may install
-it yourself by following the [Gateway API install
-guide](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api), which
-is often as simple as something like
+If the Gateway API is not already installed on your cluster, you may install it
+by following the [Gateway API install
+guide](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api), which is
+often as simple as:
 
 ```bash
-kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
+kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml
 ```
 
-You will need to ensure the version of the Gateway API that you install is
-compatible with Linkerd by checking the above table. In general, we recommend
-the latest `Standard` channel release of Gateway API.
-
-Once a compatible version of the Gateway API is installed, you can proceed with
-the Linkerd installation as above.
-
-### Option 3: Have Linkerd install the Gateway API
-
-If the Gateway API is not already installed on your cluster, you may have
-Linkerd install it bundled with Linkerd's CRDs by setting
-`--set installGatewayAPI=true` or specifying this in your `values.yml`. This
-applies to the `linkerd install --crds` command or when installing the
-`linkerd-crds` Helm chart.
-
-Note that if Linkerd installs the Gateway API like this, then the Gateway API
-will also be removed if Linkerd is uninstalled.
-
-| Linkerd versions | Gateway API version installed |
-| ---------------- | ----------------------------- |
-| 2.15 - 2.17      | 0.7                           |
-| 2.18             | 1.1.1                         |
-
-## Precursors to Gateway API-based configuration
+## Note: Precursors to Gateway API-based configuration
 
 Prior to the complete support of the Gateway API introduced in Linkerd 2.14,
 Linkerd provided two earlier variants of configuration:

diff --git a/linkerd.io/content/2-edge/getting-started/_index.md b/linkerd.io/content/2-edge/getting-started/_index.md
@@ -86,12 +86,17 @@ Make sure that your Linkerd version and Kubernetes version are compatible by
 checking Linkerd's [supported Kubernetes
 versions](../reference/k8s-versions/).
 
-## Step 2: Install the Gateway API
+## Step 2 (optional): Install the Gateway API
 
-Linkerd requires the Gateway API. If the Gateway API is already installed on
-your cluster, you are good to go. Otherwise, you will need to install it first.
-Follow [these instructions](../features/gateway-api/) for determining if the
-Gateway API is installed or how to install it.
+Several features in Linkerd are configured using CRDs from the [Gateway
+API](https://gateway-api.sigs.k8s.io/) project, including authorization policy
+and dynamic request routing. In many Kubernetes clusters, these CRDs are already
+available, but if they aren't, you won't be able to use those features unless
+you install these CRDs.
+
+If you want to use those features, follow our [Gateway API Linkerd
+doc](../features/gateway-api/) to ensure the Gateway API CRDs are
+installed. You can always do this step later.
 
 ## Step 3: Validate your Kubernetes cluster
 

diff --git a/linkerd.io/content/2-edge/reference/k8s-versions.md b/linkerd.io/content/2-edge/reference/k8s-versions.md
@@ -27,6 +27,7 @@ chart below as these situations arise.
 | `2.16`          | `1.22`                     | `1.29`                     |
 | `2.17`          | `1.22`                     | `1.31`                     |
 | `2.18`          | `1.22`                     | `1.32`                     |
+| `2.19`          | `1.22`                     | `1.34`                     |
 {{< /keyval >}}
 
 Note that Linkerd will almost never change the supported Kubernetes version in
@@ -36,11 +37,7 @@ later required Kubernetes 1.17 as shown in the table above.
 
 ## Edge Releases
 
-{{< keyval >}}
-| Linkerd Version | Minimum Kubernetes Version | Maximum Kubernetes Version |
-|-----------------|----------------------------|----------------------------|
-| `edge-22.10.1` - `edge-23.12.1` | `1.21`     | `1.29`                     |
-| `edge-23.12.2` - `edge-24.11.4` | `1.22`     | `1.29`                     |
-| `edge-24.11.5` - `edge-25.1.2`  | `1.22`     | `1.31`                     |
-| `edge-25.2.1` and newer         | `1.22`     | `1.32`                     |
-{{< /keyval >}}
+Unless otherwise noted in the release notes, edge releases support all versions
+of Kubernetes which are readily available on major cloud providers at the time
+of release. In other words, support is a function of "can the Linkerd
+maintainers easily get access to a specific Kubernetes version for testing".
diff --git a/linkerd.io/content/2-edge/tasks/gateway-api-ownership-migration.md b/linkerd.io/content/2-edge/tasks/gateway-api-ownership-migration.md
@@ -1,34 +1,46 @@
 ---
-title: Migrating Gateway API Ownership
-description: Instructions for migrating from a Linkerd-managed Gateway API to an externally managed Gateway API, ensuring no loss of dependent CRs during the transition.
+title: Migrating Gateway API Ownership in Linkerd 2.18
+description: Migrating from a Linkerd-managed Gateway API to an externally managed one as part of upgrading to Linkerd 2.18
 ---
 
-As outlined in [Gateway API support](../features/gateway-api/), Linkerd uses
-the Gateway API as a key configuration mechanism. Although Linkerd can install
-the Gateway API CRDs independently, the Gateway API is an official Kubernetes
-project maintained separately from Linkerd. For this reason, we recommend
-following the official [Gateway API installation
-guide](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api) and
-managing these CRDs externally rather than relying on Linkerd to handle them.
+Linkerd [uses the Gateway API as a key configuration
+mechanism](../features/gateway-api/). Prior to Linkerd 2.18, Linkerd would
+optionally install the Gateway API types on your cluster and manage them for
+you--it optionally "owned" the types. From Linkerd 2.19 onwards, Linkerd will
+longer own the Gateway API types on your behalf. Thus, Linkerd 2.18 itself is a
+_transition_ release, where you need to remove the ownership of any
+Linkerd-installed Gateway API resources.
 
-Not only is this approach recommended today, but starting with Linkerd 2.19,
-installing Gateway API CRDs will no longer be the default behavior (when
-installing with Helm).
+All Linkerd users upgrading to 2.18 who have Linkerd-managed Gateway API CRDs
+will need to transition this ownership away from Linkerd, by following the steps
+below.
 
 To migrate from a Linkerd-managed Gateway API to an externally managed one—while
 preserving any CRs dependent on these APIs—follow the steps below based on your
 installation method.
 
+## Determining whether Linkerd currently owns the Gateway API CRDs
+
+To determine whether Linkerd owns the Gateway API CRDs, run:
+
+```bash
+kubectl get crds/httproutes.gateway.networking.k8s.io -ojsonpath='{.metadata.annotations.linkerd\.io/created-by}'
+```
+
+If this command returns a NotFound error, the CRDs are not installed. If this
+command returns an _empty result_, the CRDs are not managed by Linkerd. If this
+command returns a string including "linkerd", the CRDs _are_ managed by Linkerd.
+
 ## If Linkerd was installed with the CLI
 
-Starting with version 2.18, the `linkerd upgrade --crds` command checks the
+Starting with Linkerd 2.18, the `linkerd upgrade --crds` command checks the
 cluster for existing Gateway API CRDs before proceeding and avoids overwriting
 them. To transition ownership of these CRDs to an external source, install the
-externally provided CRDs _before_ upgrading Linkerd:
+externally provided CRDs _before_ upgrading to Linkerd 2.18:
 
 ```bash
 kubectl apply -f \
-    https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.1/experimental-install.yaml
+    https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
 ```
 
 Next, run the usual upgrade command:
@@ -67,7 +79,7 @@ Linkerd’s CRDs with the externally managed ones:
 
 ```bash
 kubectl apply -f \
-    https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.1/experimental-install.yaml
+    https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
 ```
 
 For all subsequent configuration updates or chart upgrades, use `--set

diff --git a/linkerd.io/content/2.15/reference/k8s-versions.md b/linkerd.io/content/2.15/reference/k8s-versions.md
@@ -35,9 +35,7 @@ later required Kubernetes 1.17 as shown in the table above.
 
 ## Edge Releases
 
-{{< keyval >}}
-| Linkerd Version | Minimum Kubernetes Version | Maximum Kubernetes Version |
-|-----------------|----------------------------|----------------------------|
-| `edge-22.10.1` - `edge-23.12.1` | `1.21`     | `1.29`                     |
-| `edge-23.12.2` and newer        | `1.22`     | `1.29`                     |
-{{< /keyval >}}
+Unless otherwise noted in the release notes, edge releases support all versions
+of Kubernetes which are readily available on major cloud providers at the time
+of release. In other words, support is a function of "can the Linkerd
+maintainers easily get access to a specific Kubernetes version for testing".
diff --git a/linkerd.io/content/2.16/reference/k8s-versions.md b/linkerd.io/content/2.16/reference/k8s-versions.md
@@ -34,9 +34,7 @@ later required Kubernetes 1.17 as shown in the table above.
 
 ## Edge Releases
 
-{{< keyval >}}
-| Linkerd Version | Minimum Kubernetes Version | Maximum Kubernetes Version |
-|-----------------|----------------------------|----------------------------|
-| `edge-22.10.1` - `edge-23.12.1` | `1.21`     | `1.29`                     |
-| `edge-23.12.2` and newer        | `1.22`     | `1.29`                     |
-{{< /keyval >}}
+Unless otherwise noted in the release notes, edge releases support all versions
+of Kubernetes which are readily available on major cloud providers at the time
+of release. In other words, support is a function of "can the Linkerd
+maintainers easily get access to a specific Kubernetes version for testing".
diff --git a/linkerd.io/content/2.17/reference/k8s-versions.md b/linkerd.io/content/2.17/reference/k8s-versions.md
@@ -35,10 +35,7 @@ later required Kubernetes 1.17 as shown in the table above.
 
 ## Edge Releases
 
-{{< keyval >}}
-| Linkerd Version | Minimum Kubernetes Version | Maximum Kubernetes Version |
-|-----------------|----------------------------|----------------------------|
-| `edge-22.10.1` - `edge-23.12.1` | `1.21`     | `1.29`                     |
-| `edge-23.12.2` - `edge-24.11.4` | `1.22`     | `1.29`                     |
-| `edge-24.11.5` and newer        | `1.22`     | `1.31`                     |
-{{< /keyval >}}
+Unless otherwise noted in the release notes, edge releases support all versions
+of Kubernetes which are readily available on major cloud providers at the time
+of release. In other words, support is a function of "can the Linkerd
+maintainers easily get access to a specific Kubernetes version for testing".
diff --git a/linkerd.io/content/2.18/features/gateway-api.md b/linkerd.io/content/2.18/features/gateway-api.md
@@ -45,10 +45,10 @@ If this command returns Not Found error, the Gateway API is not installed.
 Otherwise it will return the Gateway API version number. Check that version
 against the compatibility table:
 
-| Linkerd versions | Gateway API version compatibilty | HTTPRoute version | gRPC version |
-| ---------------- | -------------------------------- | ----------------- | ------------ |
-| 2.15 - 2.17      | 0.7 - 1.1.1                      | v1beta1           | v1alpha2     |
-| 2.18             | 1.1.1 - 1.2.1                    | v1                | v1           |
+| Linkerd versions | Gateway API version compatibility | HTTPRoute version | gRPC version |
+| ---------------- | --------------------------------- | ----------------- | ------------ |
+| 2.15 - 2.17      | 0.7 - 1.1.1                       | v1beta1           | v1alpha2     |
+| 2.18             | 1.1.1 - 1.2.1                     | v1                | v1           |
 
 {{< note >}}
 

diff --git a/linkerd.io/content/2.18/reference/k8s-versions.md b/linkerd.io/content/2.18/reference/k8s-versions.md
@@ -36,11 +36,7 @@ later required Kubernetes 1.17 as shown in the table above.
 
 ## Edge Releases
 
-{{< keyval >}}
-| Linkerd Version | Minimum Kubernetes Version | Maximum Kubernetes Version |
-|-----------------|----------------------------|----------------------------|
-| `edge-22.10.1` - `edge-23.12.1` | `1.21`     | `1.29`                     |
-| `edge-23.12.2` - `edge-24.11.4` | `1.22`     | `1.29`                     |
-| `edge-24.11.5` - `edge-25.1.2`  | `1.22`     | `1.31`                     |
-| `edge-25.2.1` and newer         | `1.22`     | `1.32`                     |
-{{< /keyval >}}
+Unless otherwise noted in the release notes, edge releases support all versions
+of Kubernetes which are readily available on major cloud providers at the time
+of release. In other words, support is a function of "can the Linkerd
+maintainers easily get access to a specific Kubernetes version for testing".
diff --git a/linkerd.io/content/2.19/_index.md b/linkerd.io/content/2.19/_index.md
@@ -0,0 +1,11 @@
+---
+title: Docs
+cascade:
+  type: docs
+
+# Redirect
+type: _default
+layout: redirect
+params:
+  redirect: ./overview
+---
diff --git a/linkerd.io/content/2.19/checks/index.md b/linkerd.io/content/2.19/checks/index.md
@@ -0,0 +1,10 @@
+---
+title: Checks
+
+# Redirect
+type: _default
+layout: redirect
+params:
+  unlisted: true
+  redirect: /2/tasks/troubleshooting/
+---
diff --git a/linkerd.io/content/2.19/common-errors/_index.md b/linkerd.io/content/2.19/common-errors/_index.md
@@ -0,0 +1,21 @@
+---
+title: Common Errors
+weight: 10
+sitemap:
+  priority: 1.0
+---
+
+Linkerd is generally robust, but things can always go wrong! You'll find
+information here about the most common things that cause people trouble.
+
+## When in Doubt, Start With `linkerd check`
+
+Whenever you see anything that looks unusual about your mesh, **always** start
+with `linkerd check`. It will check a long series of things that have caused
+trouble for others and make sure that your configuration is sane, and it will
+point you to help for any problems it finds. It's hard to overstate how useful
+this command is.
+
+## Common Errors
+
+{{< docs/section-toc >}}