Fix broken links (#3929)

* Fix broken links in admin

* fix more broken links

Co-authored-by: Omer B <obensaadon@vmware.com>

docs/admin/install/eventing/install-eventing-with-yaml.md

@@ -212,7 +212,7 @@ The tabs below expand to show instructions for installing each Eventing extensio
         kubectl apply -f {{ artifact(org="knative-sandbox",repo="eventing-kafka-broker",file="eventing-kafka-sink.yaml")}}
         ```
 
-    For more information, see the [Kafka Sink](../../../eventing/sink/kafka-sink.md) documentation.
+    For more information, see the [Kafka Sink](../../../developer/eventing/sinks/kafka-sink.md) documentation.
 
 === "Sugar Controller"
 

docs/admin/install/operator/configuring-serving-cr.md

@@ -53,7 +53,7 @@ The KnativeServing custom resource (CR) allows you to set values for these Confi
 Knative Serving has multiple ConfigMaps that are named with the prefix `config-`.
 The `spec.config` in the KnativeServing CR has one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which will be used for the ConfigMap `data`.
 
-In the [setup a custom domain example](./../../serving/using-a-custom-domain.md), you can see the content of the ConfigMap
+In the [setup a custom domain example](../../../serving/using-a-custom-domain.md), you can see the content of the ConfigMap
 `config-domain` is:
 
 ```
@@ -123,7 +123,7 @@ location. This section is only needed when the registry images do not match the
 
 - `imagePullSecrets`: a list of Secret names used when pulling Knative container images. The Secrets
 must be created in the same namespace as the Knative Serving Deployments. See [deploying images
-from a private container registry](./../../serving/deploying-from-private-registry/README.md) for configuration details.
+from a private container registry](../../../serving/deploying-from-private-registry.md) for configuration details.
 
 
 ### Download images in a predefined format without secrets:
@@ -251,7 +251,7 @@ spec:
 
 ## SSL certificate for controller
 
-To [enable tag to digest resolution](./../../serving/tag-resolution.md), the Knative Serving controller needs to access the container registry.
+To [enable tag to digest resolution](../../../serving/tag-resolution.md), the Knative Serving controller needs to access the container registry.
 To allow the controller to trust a self-signed registry cert, you can use the Operator to specify the certificate using a ConfigMap or Secret.
 
 Specify the following fields in `spec.controller-custom-certs` to select a custom registry certificate:
@@ -277,7 +277,7 @@ spec:
 
 ## Configuration of Knative ingress gateway
 
-To set up custom ingress gateway, follow [**Step 1: Create Gateway Service and Deployment Instance**](./../../serving/setting-up-custom-ingress-gateway.md).
+To set up custom ingress gateway, follow [**Step 1: Create Gateway Service and Deployment Instance**](../../../serving/setting-up-custom-ingress-gateway.md).
 
 ### Step 2: Update the Knative gateway
 

docs/developer/serving/services/custom-domains.md

@@ -8,7 +8,7 @@ For example, if you own the domain name `example.org`, and you configure the dom
 serve a Knative Service at this domain.
 
 !!! note
-    If you create a domain mapping to map to a [private Knative Service](../private-services.md),
+    If you create a domain mapping to map to a [private Knative Service](./private-services.md),
     the private Knative Service will be accessible from public internet with the custom domain of the domain mapping.
 
 ## Prerequisites

docs/serving/autoscaling/autoscaling-metrics.md

@@ -11,7 +11,7 @@ The metric configuration defines which metric type is watched by the Autoscaler.
 
 ## Setting metrics per revision
 
-For [per-revision](./autoscaling-concepts.md) configuration, this is determined using the `autoscaling.knative.dev/metric` annotation.
+For [per-revision](./autoscaler-types.md#global-versus-per-revision-settings) configuration, this is determined using the `autoscaling.knative.dev/metric` annotation.
 The possible metric types that can be configured per revision depend on the type of Autoscaler implementation you are using:
 
 * The default KPA Autoscaler supports the `concurrency` and `rps` metrics.
@@ -19,7 +19,7 @@ The possible metric types that can be configured per revision depend on the type
 
 <!-- TODO: Add details about different metrics types, how concurrency and rps differ. Explain cpu. -->
 
-For more information about KPA and HPA, see the documentation on [Supported Autoscaler types](./autoscaling-concepts.md).
+For more information about KPA and HPA, see the documentation on [Supported Autoscaler types](./autoscaler-types.md).
 
 * **Per-revision annotation key:** `autoscaling.knative.dev/metric`
 * **Possible values:** `"concurrency"`, `"rps"` or `"cpu"`, depending on your Autoscaler type. The `cpu` metric is only supported on revisions with the HPA class.

docs/serving/autoscaling/concurrency.md

@@ -72,7 +72,7 @@ If concurrency reaches the hard limit, surplus requests will be buffered and mus
 
 ### Hard limit
 
-The hard limit is specified [per Revision](./autoscaling-concepts.md) using the `containerConcurrency` field on the Revision spec. This setting is not an annotation.
+The hard limit is specified [per Revision](./autoscaler-types.md#global-versus-per-revision-settings) using the `containerConcurrency` field on the Revision spec. This setting is not an annotation.
 
 There is no global setting for the hard limit in the autoscaling ConfigMap, because `containerConcurrency` has implications outside of autoscaling, such as on buffering and queuing of requests. However, a default value can be set for the Revision's `containerConcurrency` field in `config-defaults.yaml`.
 

docs/serving/autoscaling/scale-to-zero.md

@@ -8,7 +8,7 @@ type: "docs"
 # Configuring scale to zero
 
 !!! warning
-    Scale to zero can only be enabled if you are using the KnativePodAutoscaler (KPA), and can only be configured globally. For more information about using KPA or global configuration, see the documentation on [Autoscaling concepts](./autoscaling-concepts.md).
+    Scale to zero can only be enabled if you are using the KnativePodAutoscaler (KPA), and can only be configured globally. For more information about using KPA or global configuration, see the documentation on [Supported Autoscaler types](./autoscaler-types.md).
 
 ## Enable scale to zero
 

docs/serving/load-balancing/target-burst-capacity.md

@@ -9,7 +9,7 @@ aliases:
 
 # Configuring target burst capacity
 
-_Target burst capacity_ is a [global and per-revision](../../serving/autoscaling/autoscaling-concepts.md) integer setting that determines the size of traffic burst a Knative application can handle without buffering.
+_Target burst capacity_ is a [global and per-revision](../../serving/autoscaling/autoscaler-types.md#global-versus-per-revision-settings) integer setting that determines the size of traffic burst a Knative application can handle without buffering.
 If a traffic burst is too large for the application to handle, the _Activator_ service will be placed in the request path to protect the revision and optimize request load balancing.
 
 The Activator service is responsible for receiving and buffering requests for inactive revisions, or for revisions where a traffic burst is larger than the limits of what can be handled without buffering for that revision. It can also quickly spin up additional pods for capacity, and throttle how quickly requests are sent to pods.