Bump markdownlint to latest version (#2068)

Author: travisbeckham

.devcontainer/on-create.sh

@@ -14,7 +14,7 @@ scurl https://htmltest.wjdp.uk | bash
 sudo mv bin/htmltest /usr/local/bin
 
 # markdownlint
-sudo npm install -g markdownlint-cli@0.26.0
+sudo npm install -g markdownlint-cli@0.39.0
 
 # gcloud
 echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" \

linkerd.io/.markdownlint.blog.yaml

@@ -9,3 +9,5 @@ line_length:
   tables: false
 no-trailing-punctuation:
   punctuation: '.,;:'
+no-duplicate-heading:
+  siblings_only: true

linkerd.io/.markdownlint.yaml

@@ -6,5 +6,6 @@ line_length:
   code_blocks: false
   tables: false
 no-trailing-punctuation:
-  punctuation: ".,;:"
-no-duplicate-header: false
+  punctuation: '.,;:'
+no-duplicate-heading:
+  siblings_only: true

linkerd.io/assets/authors/charles.jpg …rd.io/assets/authors/charles-pretzer.jpglinkerd.io/assets/authors/charles.jpg renamed to linkerd.io/assets/authors/charles-pretzer.jpg linkerd.io/assets/authors/charles.jpg renamed to linkerd.io/assets/authors/charles-pretzer.jpg

@@ -3,16 +3,15 @@ title: Failfast
 description: Failfast means that no endpoints are available.
 ---
 
-If Linkerd reports that a given service is in the _failfast_ state, it
-means that the proxy has determined that there are no available endpoints
-for that service. In this situation there's no point in the proxy trying
-to actually make a connection to the service - it already knows that it
-can't talk to it - so it reports that the service is in failfast and
-immediately returns an error from the proxy.
+If Linkerd reports that a given service is in the _failfast_ state, it means
+that the proxy has determined that there are no available endpoints for that
+service. In this situation there's no point in the proxy trying to actually make
+a connection to the service - it already knows that it can't talk to it - so it
+reports that the service is in failfast and immediately returns an error from
+the proxy.
 
-The error will be either a 503 or a 504; see below for more information,
-but if you already know that the service is in failfast because you saw
-it in the logs, that's the important part.
+The error will be either a 503 or a 504; see below for more information, but if
+you already know that the service is in failfast because you saw it in the logs,
+that's the important part.
 
-To get out of failfast, some endpoints for the service have to
-become available.
+To get out of failfast, some endpoints for the service have to become available.

linkerd.io/content/2-edge/common-errors/failfast.md

@@ -3,9 +3,9 @@ title: HTTP 502 Errors
 description: HTTP 502 means connection errors between proxies.
 ---
 
-The Linkerd proxy will return a 502 error for connection errors between
-proxies. Unfortunately it's fairly common to see an uptick in 502s when
-first meshing a workload that hasn't previously been used with a mesh,
-because the mesh surfaces errors that were previously invisible!
+The Linkerd proxy will return a 502 error for connection errors between proxies.
+Unfortunately it's fairly common to see an uptick in 502s when first meshing a
+workload that hasn't previously been used with a mesh, because the mesh surfaces
+errors that were previously invisible!
 
 There's actually a whole page on [debugging 502s](../tasks/debugging-502s/).

linkerd.io/content/2-edge/common-errors/http-502.md

@@ -3,25 +3,23 @@ title: HTTP 503 and 504 Errors
 description: HTTP 503 and 504 mean overloaded workloads.
 ---
 
-503s and 504s show up when a Linkerd proxy is trying to make so many
-requests to a workload that it gets overwhelmed.
+503s and 504s show up when a Linkerd proxy is trying to make so many requests to
+a workload that it gets overwhelmed.
 
-When the workload next to a proxy makes a request, the proxy adds it
-to an internal dispatch queue. When things are going smoothly, the
-request is pulled from the queue and dispatched almost immediately.
-If the queue gets too long, though (which can generally happen only
-if the called service is slow to respond), the proxy will go into
-_load-shedding_, where any new request gets an immediate 503. The
-proxy can only get _out_ of load-shedding when the queue shrinks.
+When the workload next to a proxy makes a request, the proxy adds it to an
+internal dispatch queue. When things are going smoothly, the request is pulled
+from the queue and dispatched almost immediately. If the queue gets too long,
+though (which can generally happen only if the called service is slow to
+respond), the proxy will go into _load-shedding_, where any new request gets an
+immediate 503. The proxy can only get _out_ of load-shedding when the queue
+shrinks.
 
-Failfast also plays a role here: if the proxy puts a service into
-failfast while there are requests in the dispatch queue, all the
-requests in the dispatch queue get an immediate 504 before the
-proxy goes into load-shedding.
+Failfast also plays a role here: if the proxy puts a service into failfast while
+there are requests in the dispatch queue, all the requests in the dispatch queue
+get an immediate 504 before the proxy goes into load-shedding.
 
-To get out of failfast, some endpoints for the service have to
-become available.
+To get out of failfast, some endpoints for the service have to become available.
 
-To get out of load-shedding, the dispatch queue has to start
-emptying, which implies that the service has to get more capacity
-to process requests or that the incoming request rate has to drop.
+To get out of load-shedding, the dispatch queue has to start emptying, which
+implies that the service has to get more capacity to process requests or that
+the incoming request rate has to drop.

linkerd.io/content/2-edge/common-errors/http-503-504.md

@@ -1,36 +1,37 @@
 ---
 title: Protocol Detection Errors
-description: Protocol detection errors indicate that Linkerd doesn't understand the
+description:
+  Protocol detection errors indicate that Linkerd doesn't understand the
   protocol in use.
 ---
 
 Linkerd is capable of proxying all TCP traffic, including TLS connections,
-WebSockets, and HTTP tunneling. In most cases where the client speaks first
-when a new connection is made, Linkerd can detect the protocol in use,
-allowing it to perform per-request routing and metrics.
+WebSockets, and HTTP tunneling. In most cases where the client speaks first when
+a new connection is made, Linkerd can detect the protocol in use, allowing it to
+perform per-request routing and metrics.
 
-If your proxy logs contain messages like `protocol detection timed out after
-10s`, or you're experiencing 10-second delays when establishing connections,
-you're probably running a situation where Linkerd cannot detect the protocol.
-This is most common for protocols where the server speaks first, and the
-client is waiting for information from the server. It may also occur with
-non-HTTP protocols for which Linkerd doesn't yet understand the wire format of
-a request.
+If your proxy logs contain messages like
+`protocol detection timed out after 10s`, or you're experiencing 10-second
+delays when establishing connections, you're probably running a situation where
+Linkerd cannot detect the protocol. This is most common for protocols where the
+server speaks first, and the client is waiting for information from the server.
+It may also occur with non-HTTP protocols for which Linkerd doesn't yet
+understand the wire format of a request.
 
 You'll need to understand exactly what the situation is to fix this:
 
-- A server-speaks-first protocol will probably need to be configured as a
-  `skip` or `opaque` port, as described in the [protocol detection
-  documentation](../features/protocol-detection/#configuring-protocol-detection).
+- A server-speaks-first protocol will probably need to be configured as a `skip`
+  or `opaque` port, as described in the
+  [protocol detection documentation](../features/protocol-detection/#configuring-protocol-detection).
 
-- If you're seeing transient protocol detection timeouts, this is more likely
-  to indicate a misbehaving workload.
+- If you're seeing transient protocol detection timeouts, this is more likely to
+  indicate a misbehaving workload.
 
-- If you know the protocol is client-speaks-first but you're getting
-  consistent protocol detection timeouts, you'll probably need to fall back on
-  a `skip` or `opaque` port.
+- If you know the protocol is client-speaks-first but you're getting consistent
+  protocol detection timeouts, you'll probably need to fall back on a `skip` or
+  `opaque` port.
 
-Note that marking ports as `skip` or `opaque` has ramifications beyond
-protocol detection timeouts; see the [protocol detection
-documentation](../features/protocol-detection/#configuring-protocol-detection)
+Note that marking ports as `skip` or `opaque` has ramifications beyond protocol
+detection timeouts; see the
+[protocol detection documentation](../features/protocol-detection/#configuring-protocol-detection)
 for more information.

linkerd.io/content/2-edge/common-errors/protocol-detection.md

@@ -13,15 +13,17 @@ configures access logging.
 
 HTTP access logging is disabled by default because it has a performance impact,
 compared to proxies without access logging enabled. Enabling access logging may
-increase tail latency and CPU consumption under load. The severity of
-this performance cost may vary depending on the traffic being proxied, and may
-be acceptable in some environments.
+increase tail latency and CPU consumption under load. The severity of this
+performance cost may vary depending on the traffic being proxied, and may be
+acceptable in some environments.
 
 {{< note >}}
+
 The proxy's HTTP access log is distinct from proxy debug logging, which is
-configured separately. See the documentation on [modifying the proxy log
-level](../tasks/modifying-proxy-log-level/) for details on configuring the
-proxy's debug logging.
+configured separately. See the documentation on
+[modifying the proxy log level](../tasks/modifying-proxy-log-level/) for details
+on configuring the proxy's debug logging.
+
 {{< /note >}}
 
 ## Access Log Formats
@@ -30,8 +32,9 @@ The value of the `config.linkerd.io/access-log` annotation determines the format
 of HTTP access log entries, and can be either "apache" or "json".
 
 Setting the `config.linkerd.io/access-log: "apache"` annotation configures the
-proxy to emit HTTP access logs in the [Apache Common Log
-Format](https://en.wikipedia.org/wiki/Common_Log_Format). For example:
+proxy to emit HTTP access logs in the
+[Apache Common Log Format](https://en.wikipedia.org/wiki/Common_Log_Format). For
+example:
 
 ```text {class=disable-copy}
 10.42.0.63:51160 traffic.booksapp.serviceaccount.identity.linkerd.cluster.local - [2022-08-23T20:28:20.071809491Z] "GET http://webapp:7000/ HTTP/2.0" 200
@@ -57,6 +60,7 @@ to emit access logs in a JSON format. For example:
 The HTTP access log is written to the proxy container's `stderr` stream, while
 the proxy's standard debug logging is written to the proxy container's `stdout`
 stream. Currently, the `kubectl logs` command will always output both the
-container's `stdout` and `stderr` streams. However, [KEP
-3289](https://github.com/kubernetes/enhancements/pull/3289) will add support for
-separating a container's `stdout` or `stderr` in the `kubectl logs` command.
+container's `stdout` and `stderr` streams. However,
+[KEP 3289](https://github.com/kubernetes/enhancements/pull/3289) will add
+support for separating a container's `stdout` or `stderr` in the `kubectl logs`
+command.