fix(docs): correct spelling and duplicated words across docs

linkerd.io/content/2-edge/features/automatic-mtls.md

@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?

linkerd.io/content/2-edge/features/dashboard.md

@@ -104,7 +104,7 @@ to use your browser instead:
 
 ![Tap](/images/docs/getting-started/tap.png 'Tap')
 
-## Futher reading
+## Further reading
 
 See [Exporting metrics](../tasks/exporting-metrics/) for alternative ways to
 consume Linkerd's metrics.

linkerd.io/content/2-edge/features/topology-aware-routing.md

@@ -13,7 +13,7 @@ multiple zones. Users can now implement routing constraints and prefer endpoints
 in a specific zone in order to limit cross-zone networking costs or improve
 performance through lowered cross-zone latency and bandwidth constraints.
 
-The goal of topology aware routing is to to provide a simpler way for users to
+The goal of topology aware routing is to provide a simpler way for users to
 prefer endpoints by basing decisions solely off the node's
 `topology.kubernetes.io/zone` label. If a client is in `zone-a`, then it should
 prefer endpoints marked for use by clients in `zone-a`. When the feature is

linkerd.io/content/2-edge/reference/architecture.md

@@ -93,7 +93,7 @@ You can read more about these micro-proxies here:
 - [Why Linkerd doesn't use Envoy](/2020/12/03/why-linkerd-doesnt-use-envoy/)
 - [Under the hood of Linkerd's state-of-the-art Rust proxy, Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/)
 
-### Meshed Conncections
+### Meshed Connections
 
 When one pod establishes a TCP connection to another pod and both of those pods
 are injected with the Linkerd proxy, we say that the connection is _meshed_. The

linkerd.io/content/2-edge/reference/authorization-policy.md

@@ -47,7 +47,7 @@ The general pattern for authorization is:
 - A `Server` describes a set of pods, and a single port on those pods.
 - Optionally, an `HTTPRoute` references that `Server` and describes a subset of
   HTTP traffic to it.
-- A `MeshTLSAuthentication` or `NetworkAuthentication` decribes who is allowed
+- A `MeshTLSAuthentication` or `NetworkAuthentication` describes who is allowed
   access.
 - An `AuthorizationPolicy` references the `HTTPRoute` or `Server` (the thing to
   be authorized) and the `MeshTLSAuthentication` or `NetworkAuthentication` (the
@@ -169,7 +169,7 @@ lifecycle.
 
 A given HTTP request can only match one HTTPRoute. If multiple HTTPRoutes are
 present that match a request, one will be picked according to the
-[Gateway API rules of precendence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+[Gateway API rules of precedence](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
 
 {{< /note >}}
 
@@ -333,7 +333,7 @@ spec:
     - "webapp.booksapp.serviceaccount.identity.linkerd.cluster.local"
 ```
 
-A `MeshTLSAuthentication` which authenticate thes `books` and `webapp` mesh
+A `MeshTLSAuthentication` which authenticates the `books` and `webapp` mesh
 identities. This is an alternative way to specify the same thing as the above
 example.
 

linkerd.io/content/2-edge/reference/circuit-breaking.md

@@ -85,7 +85,7 @@ accrual, see [Rate Limit Aware Load Balancing](../tasks/rate-limit-aware-load-ba
 
 ## Probation and Backoffs
 
-Once a failure accrual policy makes an endpoint unavailble, the circuit breaker
+Once a failure accrual policy makes an endpoint unavailable, the circuit breaker
 will attempt to determine whether the endpoint is still in a failing state, and
 transition it back to available if it has recovered. This process is called
 _probation_. When an endpoint enters probation, it is temporarily made available
@@ -106,7 +106,7 @@ application traffic must succeed for the endpoint to become available again.
 {{< /note >}}
 
 When an endpoint's failure accrual policy trips the circuit breaker, it will
-remain unavailble for at least a _minimum penalty_ duration. After this duration
+remain unavailable for at least a _minimum penalty_ duration. After this duration
 has elapsed, the endpoint will enter probation. When a probe request fails, the
 endpoint will not be placed in probation again until a backoff duration has
 elapsed. Every time a probe request fails, [the backoff increases
@@ -160,7 +160,7 @@ configure parameters for the consecutive-failures failure accrual policy:
   unavailable. Must be an integer. If this annotation is not present, the
   default value is 7.
 - `balancer.linkerd.io/failure-accrual-consecutive-min-penalty`: Sets the
-  minumum penalty duration for which an endpoint will be marked as unavailable
+  minimum penalty duration for which an endpoint will be marked as unavailable
   after `max-failures` consecutive failures occur. After this period of time
   elapses, the endpoint will be [probed](#probation-and-backoffs). This duration
   must be non-zero, and may not be greater than the max-penalty duration. If

linkerd.io/content/2-edge/reference/proxy-metrics.md

@@ -20,7 +20,7 @@ port (default: `:4191`) in the [Prometheus format][prom-format].
   - `tls_kx_groups`: The set of key exchange algorithms the proxy will use,
     sorted by preference order.
   - `tls_rand`: The secure randomness provider
-  - `tls_key_provider`: The crytpographic key provider
+  - `tls_key_provider`: The cryptographic key provider
   - `tls_fips`: A boolean denoting if the proxy's connections are
     FIPS-compliant.
 - `tokio_rt_*`: A set of counters and gauges with stats on the proxy's
@@ -350,7 +350,7 @@ Kubernetes resources to which traffic is routed by the proxy:
   route resource through which the proxy discovered the route binding. This will
   either reference an [HTTPRoute] resource or a default (synthesized) route.
 - `backend_group`, `backend_kind`, `backend_name`, and `backend_namespace`
-  reference the backend resource to which which the proxy routed the request.
+  reference the backend resource to which the proxy routed the request.
   This will always be a Service.
 
 In addition, the `outbound_http_balancer_endpoints` gauge metric adds the

linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md

@@ -388,7 +388,7 @@ Almost done! We only need one more thing: the _trust bundle_ will lets Linkerd
 know which trust anchors to accept. We'll use trust-manager for this, but
 there's a catch: when rotating the trust anchor, both the control plane and the
 data plane (the proxies) need to be restarted. Since that can't happen
-instaneously, we need to have both the old trust anchor and the new trust anchor
+instantaneously, we need to have both the old trust anchor and the new trust anchor
 in the trust bundle until all the restarts have completed.
 
 trust-manager can do this, but it needs a specific source for _each_ certificate

linkerd.io/content/2-edge/tasks/circuit-breakers.md

@@ -7,7 +7,7 @@ Circuit breaking is a powerful feature where Linkerd will temporarily stop
 routing requests to an endpoint if that endpoint is deemed to be unhealthy,
 instead routing that request to other replicas in the Service.
 
-In this tutoral, we'll see how to enable circuit breaking on a Service to
+In this tutorial, we'll see how to enable circuit breaking on a Service to
 improve client success rate when a backend replica is unhealthy.
 
 See the [reference documentation](../reference/circuit-breaking/) for more
@@ -217,7 +217,7 @@ failure accrual:
 
 This tells us that Linkerd will use `ConsecutiveFailures` failure accrual when
 talking to the `bb` Service. It also tells us that the `max_failures` is 7,
-meaning that it will trip the circuit breaker once it observes 7 consective
+meaning that it will trip the circuit breaker once it observes 7 consecutive
 failures. We'll talk more about each of the parameters here at the end of this
 article.
 

linkerd.io/content/2-edge/tasks/configuring-dynamic-request-routing.md

@@ -156,7 +156,7 @@ In the example above, we used the `x-request-id` header, which is a common
 header that is forwarded by podinfo. However, the same technique will work with
 arbitrary headers, as long as the application forwards them.
 
-Note also that dyanmic request routing is client-side behavior, so while the
+Note also that dynamic request routing is client-side behavior, so while the
 traffic source (in this case, the frontend pod) needs to be meshed, strictly
 speaking, the destination does not need to be meshed.
 

linkerd.io/content/2-edge/tasks/federated-services.md

@@ -8,7 +8,7 @@ which act as a union of multiple services in different clusters with the same
 name and namespace. By sending traffic to the federated service, that traffic
 will be load balanced among all endpoints of that service in all linked
 clusters. This allows the client to be cluster agnostic, balance traffic across
-multiple clusters, and be resiliant to the failure of any individual cluster.
+multiple clusters, and be resilient to the failure of any individual cluster.
 
 Federated services send traffic directly to the pods of the member services
 rather than through a gateway. Therefore, federated services have the same
@@ -362,7 +362,7 @@ is distributing requests across all three clusters:
 
 ## Next Steps
 
-We now have a federated service that balances traffic accross services in three
+We now have a federated service that balances traffic across services in three
 clusters. Additional clusters can be added simply by:
 
 - Updating the linkerd-multicluster config in `west` to add the required

linkerd.io/content/2-edge/tasks/generate-certificates.md

@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 

linkerd.io/content/2-edge/tasks/grafana.md

@@ -81,7 +81,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 

linkerd.io/content/2-edge/tasks/install-helm.md

@@ -43,7 +43,7 @@ then `linkerd-control-plane`.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}

linkerd.io/content/2-edge/tasks/install.md

@@ -66,7 +66,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}

linkerd.io/content/2-edge/tasks/rotating_webhooks_certificates.md

@@ -64,7 +64,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 

linkerd.io/content/2-edge/tasks/setting-up-service-profiles.md

@@ -19,7 +19,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 per-route metric, retries, and timeouts.
 
 The `destination service` for a request is computed by selecting the value of

linkerd.io/content/2-edge/tasks/traffic-shifting.md

@@ -14,8 +14,8 @@ Traffic splitting is accomplished with [HTTPRoute] and [GRPCRoute] types.
 
 Earlier versions of Linkerd provided a
 [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/main/apis/traffic-split/v1alpha2/traffic-split.md/)
-resource as part of the the [Linkerd SMI extension](linkerd-smi/) for traffic
-splitting. This approach is still supported but will not recieve further feature
+resource as part of the [Linkerd SMI extension](linkerd-smi/) for traffic
+splitting. This approach is still supported but will not receive further feature
 development.
 
 {{< /note >}}

linkerd.io/content/2-edge/tasks/troubleshooting.md

@@ -703,7 +703,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).
@@ -1161,7 +1161,7 @@ triggered if an extension value is used for the label key more than once across
 the cluster.
 
 To resolve this warning, ensure that the `linkerd.io/extension` namespace label
-does not have any dupliate values, indicating that an extension has been
+does not have any duplicate values, indicating that an extension has been
 installed more than once in different namespaces.
 
 ### Extensions checks

linkerd.io/content/2-edge/tasks/uninstall.md

@@ -31,7 +31,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 

linkerd.io/content/2-edge/tasks/using-ingress.md

@@ -333,8 +333,8 @@ spec:
 
 ## GCE
 
-The GCE ingress should be meshed with with
-[ingress mode enabled](#ingress-mode), , i.e. with the
+The GCE ingress should be meshed with
+[ingress mode enabled](#ingress-mode), i.e. with the
 `linkerd.io/inject: ingress` annotation rather than the default `enabled`.
 
 This example shows how to use a

linkerd.io/content/2.10/features/automatic-mtls.md

@@ -18,7 +18,7 @@ See [Caveats and future work](#caveats-and-future-work) below for some details.
 ## What is mTLS?
 
 A full definition of mTLS is outside the scope of this doc. For an overview of
-what mTLS is and how it works in Kuberentes clusters, we suggest reading through
+what mTLS is and how it works in Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?

linkerd.io/content/2.10/tasks/generate-certificates.md

@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 

linkerd.io/content/2.10/tasks/rotating_webhooks_certificates.md

@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 

linkerd.io/content/2.10/tasks/setting-up-service-profiles.md

@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 

linkerd.io/content/2.10/tasks/troubleshooting.md

@@ -724,7 +724,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).

linkerd.io/content/2.10/tasks/uninstall.md

@@ -34,7 +34,7 @@ linkerd multicluster uninstall | kubectl delete -f -
 
 {{< note >}}
 
-Uninstallating the control plane requires cluster-wide permissions.
+Uninstalling the control plane requires cluster-wide permissions.
 
 {{< /note >}}
 

linkerd.io/content/2.11/features/automatic-mtls.md

@@ -47,7 +47,7 @@ only happens in one direction--the client authenticates the server but the
 server doesn’t authenticate the client. mTLS makes the authenticity symmetric.
 
 mTLS is a large topic. For a broad overview of what mTLS is and how it works in
-Kuberentes clusters, we suggest reading through
+Kubernetes clusters, we suggest reading through
 [A Kubernetes engineer's guide to mTLS](https://buoyant.io/mtls-guide/).
 
 ## Which traffic can Linkerd automatically mTLS?

linkerd.io/content/2.11/tasks/generate-certificates.md

@@ -21,7 +21,7 @@ You can generate these certificates using a tool like openssl or
 [step](https://smallstep.com/cli/). All certificates must use the ECDSA P-256
 algorithm which is the default for `step`. To generate ECDSA P-256 certificates
 with openssl, you can use the `openssl ecparam -name prime256v1` command. In
-this tutorial, we'll walk you through how to to use the `step` CLI to do this.
+this tutorial, we'll walk you through how to use the `step` CLI to do this.
 
 {{< production-note >}}
 

linkerd.io/content/2.11/tasks/grafana.md

@@ -65,7 +65,7 @@ Linkerd Deployments Grafana dashboard providing the same (and more) metrics
 
 ### In-cluster Grafana instances
 
-In the case of in-cluster Grafana instances (such as as the one from the Grafana
+In the case of in-cluster Grafana instances (such as the one from the Grafana
 Helm chart or the Grafana Operator mentioned above), make sure a reverse proxy
 is set up, as shown in the sample `grafana/values.yaml` file:
 

linkerd.io/content/2.11/tasks/install-helm.md

@@ -48,7 +48,7 @@ the `2.12.0` stable release as well when it comes out.
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}

linkerd.io/content/2.11/tasks/install.md

@@ -46,7 +46,7 @@ check out the additional instructions on
 
 If installing Linkerd in a cluster that uses Cilium in kube-proxy replacement
 mode, additional steps may be needed to ensure service discovery works as
-intended. Instrunctions are on the
+intended. Instructions are on the
 [Cilium cluster configuration](../reference/cluster-configuration/#cilium) page.
 
 {{< /note >}}

linkerd.io/content/2.11/tasks/rotating_webhooks_certificates.md

@@ -68,7 +68,7 @@ For Helm users, use the `helm upgrade` command to recreate the deleted secrets.
 
 If you render the helm charts externally and apply them with `kubectl apply`
 (e.g. in a CI/CD pipeline), you do not need to delete the secrets manually, as
-they wil be overwritten by a new cert and key generated by the helm chart.
+they will be overwritten by a new cert and key generated by the helm chart.
 
 {{< /note >}}
 

linkerd.io/content/2.11/tasks/setting-up-service-profiles.md

@@ -9,7 +9,7 @@ information about a service and how to handle requests for a service.
 
 When an HTTP (not HTTPS) request is received by a Linkerd proxy, the
 `destination service` of that request is identified. If a service profile for
-that destination service exists, then that service profile is used to to provide
+that destination service exists, then that service profile is used to provide
 [per-route metrics](getting-per-route-metrics/), [retries](configuring-retries/)
 and [timeouts](configuring-timeouts/).
 

linkerd.io/content/2.11/tasks/troubleshooting.md

@@ -755,7 +755,7 @@ Example failure:
     see https://linkerd.io/2/checks/#l5d-proxy-injector-webhook-cert-not-expiring-soon for hints
 ```
 
-This warning indicates that the expiry of proxy-injnector webhook cert is
+This warning indicates that the expiry of proxy-injector webhook cert is
 approaching. In order to address this problem without incurring downtime, you
 can follow the process outlined in
 [Automatically Rotating your webhook TLS Credentials](automatically-rotating-webhook-tls-credentials/).