Clean up absolute links in docs

docs/snippets/collecting-logs.md

@@ -1,9 +1,14 @@
+<!-- Referenced by:
+  - eventing/observability/logging/collecting-logs.md
+  - serving/observability/logging/collecting-logs.md
+-->
+
 # Logging
 
 You can use [Fluent Bit](https://docs.fluentbit.io/), a log processor and forwarder, to collect
 Kubernetes logs in a central directory.
 This is not required to run Knative, but can be helpful with
-[Knative Serving](/docs/serving/), which automatically deletes pods and associated logs when they are no longer needed.
+[Knative Serving](../../../serving/README.md), which automatically deletes pods and associated logs when they are no longer needed.
 
 Fluent Bit supports exporting to a number of other log providers. If you already have an existing log provider, for example, Splunk, Datadog, ElasticSearch, or Stackdriver, you can follow the [FluentBit documentation](https://docs.fluentbit.io/manual/pipeline/outputs) to configure log forwarders.
 

docs/snippets/collecting-metrics.md

@@ -1,3 +1,8 @@
+<!-- Referenced by:
+- eventing/observability/metrics/collecting-metrics.md
+- serving/observability/metrics/collecting-metrics.md
+-->
+
 # Collecting Metrics in Knative
 
 Knative leverages [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) for exporting metrics.

docs/snippets/no-dns.md

@@ -1,3 +1,7 @@
+<!-- Referenced by:
+- install/operator/knative-with-operators.md
+- install/yaml-install/serving/install-serving-with-yaml.md
+-->
 === "No DNS"
 
     If you are using `curl` to access [the sample applications](/docs/getting-started/first-service/), or your own Knative app, and are unable to use the "Magic DNS (sslip.io)" or "Real DNS" methods, there is a temporary approach. This is useful for those who wish to evaluate Knative without altering their DNS configuration, as per the "Real DNS" method, or cannot use the "Magic DNS" method due to using,

docs/snippets/quickstart-prereqs.md

@@ -6,8 +6,8 @@
 
 !!! warning
     Knative `quickstart` environments are for experimentation use only.
-    For a production ready installation, see the [YAML-based installation](/docs/install/yaml-install/)
-    or the [Knative Operator installation](/docs/install/operator/knative-with-operators/).
+    For a production ready installation, see the [YAML-based installation](../install/yaml-install/)
+    or the [Knative Operator installation](../install/operator/knative-with-operators/).
 
 Before you can get started with a Knative `quickstart` deployment you must install:
 

docs/versioned/eventing/brokers/README.md

@@ -7,7 +7,9 @@ function: explanation
 
 # Brokers
 
---8<-- "about-brokers.md"
+Brokers are Kubernetes custom resources that define an [event mesh](../event-mesh.md) for collecting a pool of events. Brokers provide a discoverable endpoint for event ingress, and use Triggers for event delivery. Event producers can send events to a broker by POSTing the event.
+
+![Source 1 and Source 2 are transmitting some data -- ones and twos -- to the Broker, which then gets filtered by Triggers to the desired Sink.](https://user-images.githubusercontent.com/16281246/116248768-1fe56080-a73a-11eb-9a85-8bdccb82d16c.png){draggable=false}
 
 ## Event delivery
 

docs/versioned/eventing/faq/README.md

@@ -10,4 +10,4 @@ function: reference
 ## What is a Sugar Controller?
 
 The Sugar Controller is an optional controller which will automatically create and clean up brokers based on the creation/deletion of namespaces and triggers.
-For more information on how to enable and configure the sugar controller, read the [sugar controller documentation](/docs/eventing/sugar).
+For more information on how to enable and configure the sugar controller, read the [sugar controller documentation](../sugar/README.md).

docs/versioned/serving/app-security/secure-pod-defaults.md

@@ -7,6 +7,6 @@ function: how-to
 
 Knative Serving provides a `secure-pod-defaults` configuration option that  allows operators to default Service configuration to run in the Kubernetes [restricted](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) Pod Security Standard profile without requiring application developers to explicitly set security properties. 
 
-These settings are controlled by operators so please refer to the [administration documentation](/docs/serving/configuration/secure-pod-defaults).
+These settings are controlled by operators so please refer to the [administration documentation](../../configuration/secure-pod-defaults).
 
 

docs/versioned/serving/configuration/deployment.md

@@ -180,4 +180,4 @@ The setting works with Service labels and will configure either a default or one
 
 See [Kubernetes RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/) docs for more information.
 
-Separately, there is a feature flag to allow [manual configuration of RuntimeClassName](/docs/serving/configuration/feature-flags/#kubernetes-runtime-class).
+Separately, there is a feature flag to allow [manual configuration of RuntimeClassName](./feature-flags.md#kubernetes-runtime-class).

docs/versioned/serving/request-flow.md

@@ -7,7 +7,7 @@ function: explanation
 
 # HTTP Request Flows
 
-While [the overview](/docs/serving) describes the logical components and
+While [the overview](./README.md) describes the logical components and
 [the architecture](./architecture.md) describes the over all architecture of Knative
 Serving, this page explains the behavior and flow of HTTP requests to an
 application which is running on Knative Serving.