Correct links

Signed-off-by: Celeste Horgan <celeste@cncf.io>

content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md

@@ -70,10 +70,10 @@ and is overridden by command-line flags. Unspecified values in the new configura
 will receive default values appropriate to the configuration version
 (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags.
 
-The status of the Node's kubelet configuration is reported via 
+The status of the Node's kubelet configuration is reported via
 `Node.Spec.Status.Config`. Once you have updated a Node to use the new
 ConfigMap, you can observe this status to confirm that the Node is using the
-intended configuration. 
+intended configuration.
 
 This document describes editing Nodes using `kubectl edit`.
 There are other ways to modify a Node's spec, including `kubectl patch`, for
@@ -136,7 +136,7 @@ adapt the steps if you prefer to extract the `kubeletconfig` subobject manually.
 
 1.  Choose a Node to reconfigure. In this example, the name of this Node is
     referred to as `NODE_NAME`.
-2.  Start the kubectl proxy in the background using the following command: 
+2.  Start the kubectl proxy in the background using the following command:
 
       ```bash
       kubectl proxy --port=8001 &
@@ -236,8 +236,8 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and
 
 The`lastKnownGood` configuration might not be present if it is set to its default value,
 the local config deployed with the node. The status will update `lastKnownGood` to
-match a valid `assigned` config after the kubelet becomes comfortable with the config. 
-The details of how the kubelet determines a config should become the `lastKnownGood` are 
+match a valid `assigned` config after the kubelet becomes comfortable with the config.
+The details of how the kubelet determines a config should become the `lastKnownGood` are
 not guaranteed by the API, but is currently implemented as a 10-minute grace period.
 
 You can use the following command (using `jq`) to filter down
@@ -287,7 +287,7 @@ by eye).
 
 If an error occurs, the kubelet reports it in the `Node.Status.Config.Error`
 structure. Possible errors are listed in
-[Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages).
+[Understanding Node.Status.Config.Error messages](#understanding-node-config-status-errors).
 You can search for the identical text in the kubelet log for additional details
 and context about the error.
 
@@ -355,7 +355,7 @@ metadata and checkpoints. The structure of the kubelet's checkpointing directory
   | - ...
 ```
 
-## Understanding Node.Status.Config.Error messages
+## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors}
 
 The following table describes error messages that can occur
 when using Dynamic Kubelet Config. You can search for the identical text
@@ -379,4 +379,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
  - For more information on configuring the kubelet via a configuration file, see
 [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
 - See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
-{{% /capture %}}
+{{% /capture %}}

content/en/docs/tasks/administer-cluster/reserve-compute-resources.md

@@ -173,7 +173,7 @@ For example: in Centos, you can do this using the tuned toolset.
 Memory pressure at the node level leads to System OOMs which affects the entire
 node and all pods running on it. Nodes can go offline temporarily until memory
 has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet
-provides [`Out of Resource`](./out-of-resource.md) management. Evictions are
+provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are
 supported for `memory` and `ephemeral-storage` only. By reserving some memory via
 `--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory
 availability on the node drops below the reserved value. Hypothetically, if
@@ -190,7 +190,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods.
 `kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
 by evicting pods whenever the overall usage across all pods exceeds
 `Allocatable`. More details on eviction policy can be found
-[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by
+[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
 specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
 
 
@@ -251,4 +251,4 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
 exceed their reservation, `kubelet` evicts pods whenever the overall node memory
 usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
 
-{{% /capture %}}
+{{% /capture %}}