Merge pull request #38276 from tengqm/fix-links

Fix nits in markdown links

Author: k8s-ci-robot

content/en/docs/concepts/security/api-server-bypass-risks.md

@@ -12,7 +12,8 @@ The Kubernetes API server is the main point of entry to a cluster for external p
 (users and services) interacting with it. 
 
 As part of this role, the API server has several key built-in security controls, such as
-audit logging and {{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}. However, there are ways to modify the configuration
+audit logging and {{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}.
+However, there are ways to modify the configuration
 or content of the cluster that bypass these controls.
 
 This page describes the ways in which the security controls built into the
@@ -65,7 +66,8 @@ every container running on the node.
 
 When Kubernetes cluster users have RBAC access to `Node` object sub-resources, that access
 serves as authorization to interact with the kubelet API. The exact access depends on
-which sub-resource access has been granted, as detailed in [kubelet authorization](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization).
+which sub-resource access has been granted, as detailed in
+[kubelet authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization).
 
 Direct access to the kubelet API is not subject to admission control and is not logged
 by Kubernetes audit logging. An attacker with direct access to this API may be able to
@@ -80,11 +82,12 @@ The default anonymous access doesn't make this assertion with the control plane.
 ### Mitigations
 
 - Restrict access to sub-resources of the `nodes` API object using mechanisms such as
-   [RBAC](/docs/reference/access-authn-authz/rbac/). Only grant this access when required,
-   such as by monitoring services.
+  [RBAC](/docs/reference/access-authn-authz/rbac/). Only grant this access when required,
+  such as by monitoring services.
 - Restrict access to the kubelet port. Only allow specified and trusted IP address
-   ranges to access the port.
-- [Ensure that kubelet authentication is set to webhook or certificate mode](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication). 
+  ranges to access the port.
+- Ensure that [kubelet authentication](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication). 
+  is set to webhook or certificate mode.
 - Ensure that the unauthenticated "read-only" Kubelet port is not enabled on the cluster.
 
 ## The etcd API

content/en/docs/concepts/storage/volumes.md

@@ -388,7 +388,8 @@ You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to th
 beforehand so that Kubernetes hosts can access them.
 {{< /note >}}
 
-See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details.
+See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)
+for more details.
 
 ### gcePersistentDisk (deprecated) {#gcepersistentdisk}
 
@@ -515,7 +516,9 @@ and the kubelet, set the `InTreePluginGCEUnregister` flag to `true`.
 ### gitRepo (deprecated) {#gitrepo}
 
 {{< warning >}}
-The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
+The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an
+[EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the
+[EmptyDir](#emptydir) into the Pod's container.
 {{< /warning >}}
 
 A `gitRepo` volume is an example of a volume plugin. This plugin
@@ -785,10 +788,13 @@ spec:
 {{< note >}}
 You must have your own NFS server running with the share exported before you can use it.
 
-Also note that you can't specify NFS mount options in a Pod spec. You can either set mount options server-side or use [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html). You can also mount NFS volumes via PersistentVolumes which do allow you to set mount options.
+Also note that you can't specify NFS mount options in a Pod spec. You can either set mount options server-side or
+use [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html).
+You can also mount NFS volumes via PersistentVolumes which do allow you to set mount options.
 {{< /note >}}
 
-See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) for an example of mounting NFS volumes with PersistentVolumes.
+See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)
+for an example of mounting NFS volumes with PersistentVolumes.
 
 ### persistentVolumeClaim {#persistentvolumeclaim}
 
@@ -1163,7 +1169,7 @@ persistent volume:
   volume expansion, the kubelet passes that data via the `NodeExpandVolume()`
   call to the CSI driver. In order to use the `nodeExpandSecretRef` field, your
   cluster should be running Kubernetes version 1.25 or later and you must enable
-  the [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)
+  the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
   named `CSINodeExpandSecret` for each kube-apiserver and for the kubelet on every
   node. You must also be using a CSI driver that supports or requires secret data during
   node-initiated storage resize operations.

content/en/docs/concepts/windows/intro.md

@@ -382,8 +382,6 @@ troubleshooting ideas prior to creating a ticket.
 
 The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control
 plane to manage the cluster it, and nodes to run your workloads.
-[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
-explains how to deploy Windows nodes to your cluster using kubeadm.
 
 The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes.
 

content/en/docs/concepts/windows/user-guide.md

@@ -22,12 +22,11 @@ This guide walks you through the steps to configure and deploy Windows container
 
 ## Before you begin
 
-* Create a Kubernetes cluster that includes a
-control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
+* Create a Kubernetes cluster that includes a control plane and a worker node running Windows Server
 * It is important to note that creating and deploying services and workloads on Kubernetes
-behaves in much the same way for Linux and Windows containers.
-[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
-The example in the section below is provided to jumpstart your experience with Windows containers.
+  behaves in much the same way for Linux and Windows containers.
+  [Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
+  The example in the section below is provided to jumpstart your experience with Windows containers.
 
 ## Getting Started: Deploying a Windows container
 

content/en/docs/reference/_index.md

@@ -41,7 +41,7 @@ client libraries:
 ## CLI
 
 * [kubectl](/docs/reference/kubectl/) - Main CLI tool for running commands and managing Kubernetes clusters.
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
+  * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
 * [kubeadm](/docs/reference/setup-tools/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
 
 ## Components
@@ -52,16 +52,18 @@ client libraries:
 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
   REST API that validates and configures data for API objects such as  pods,
   services, replication controllers.
-* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) -
+  Daemon that embeds the core control loops shipped with Kubernetes.
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can
   do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across
   a set of back-ends.
-* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) -
+  Scheduler that manages availability, performance, and capacity.
 
   * [Scheduler Policies](/docs/reference/scheduling/policies)
   * [Scheduler Profiles](/docs/reference/scheduling/config#profiles)
 
-* List of [ports and protocols](/docs/reference/ports-and-protocols/) that
+* List of [ports and protocols](/docs/reference/networking/ports-and-protocols/) that
   should be open on control plane and worker nodes
 
 ## Config APIs

content/en/docs/reference/command-line-tools-reference/feature-gates-removed.md

@@ -13,8 +13,8 @@ However, a GA'ed or a deprecated feature gate is still recognized by the corresp
 components although they are unable to cause any behavior differences in a cluster.
 
 For feature gates that are still recognized by the Kubernetes components, please refer to
-the [Alpha/Beta feature gate table](/docs/reference/command-line-tools/reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
-or the [Graduated/Deprecated feature gate table](/docs/reference/command-line-tools/reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
+the [Alpha/Beta feature gate table](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
+or the [Graduated/Deprecated feature gate table](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
 
 ### Feature gates that are removed
 

content/en/docs/reference/networking/virtual-ips.md

@@ -14,7 +14,6 @@ mechanism for {{< glossary_tooltip term_id="service" text="Services">}}
 of `type` other than
 [`ExternalName`](/docs/concepts/services-networking/service/#externalname).
 
-
 A question that pops up every now and then is why Kubernetes relies on
 proxying to forward inbound traffic to backends. What about other
 approaches? For example, would it be possible to configure DNS records that
@@ -39,15 +38,13 @@ network proxying service on a computer.  Although the `kube-proxy` executable su
 `cleanup` function, this function is not an official feature and thus is only available
 to use as-is.
 
-
 <a id="example"></a>
 Some of the details in this reference refer to an example: the back end Pods for a stateless
 image-processing workload, running with three replicas. Those replicas are
 fungible&mdash;frontends do not care which backend they use.  While the actual Pods that
 compose the backend set may change, the frontend clients should not need to be aware of that,
 nor should they need to keep track of the set of backends themselves.
 
-
 <!-- body -->
 
 ## Proxy modes
@@ -367,4 +364,5 @@ You can also:
 
 * Read about [Services](/docs/concepts/services-networking/service/) as a concept
 * Read about [Ingresses](/docs/concepts/services-networking/ingress/) as a concept
-* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API
+* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API
+

content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md

@@ -12,22 +12,22 @@ card:
 
 <img src="/images/kubeadm-stacked-color.png" align="right" width="150px"></img>
 This page shows how to install the `kubeadm` toolbox.
-For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
+For information on how to create a cluster with kubeadm once you have performed this installation process,
+see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
 
 
 ## {{% heading "prerequisites" %}}
 
 
-* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
+* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions
+  based on Debian and Red Hat, and those distributions without a package manager.
 * 2 GB or more of RAM per machine (any less will leave little room for your apps).
 * 2 CPUs or more.
 * Full network connectivity between all machines in the cluster (public or private network is fine).
 * Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-mac-address) for more details.
 * Certain ports are open on your machines. See [here](#check-required-ports) for more details.
 * Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
 
-
-
 <!-- steps -->
 
 ## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}
@@ -46,9 +46,9 @@ If you have more than one network adapter, and your Kubernetes components are no
 route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
 
 ## Check required ports
-These
-[required ports](/docs/reference/ports-and-protocols/)
-need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
+These [required ports](/docs/reference/networking/ports-and-protocols/)
+need to be open in order for Kubernetes components to communicate with each other.
+You can use tools like netcat to check if a port is open. For example:
 
 ```shell
 nc 127.0.0.1 6443

content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md

@@ -9,10 +9,7 @@ weight: 40
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes).
-
-
-
+This page explains how to upgrade a Windows node created with kubeadm.
 
 ## {{% heading "prerequisites" %}}
 
@@ -21,9 +18,6 @@ This page explains how to upgrade a Windows node [created with kubeadm](/docs/ta
 cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to
 upgrade the control plane nodes before upgrading your Windows nodes.
 
-
-
-
 <!-- steps -->
 
 ## Upgrading worker nodes
@@ -81,7 +75,8 @@ upgrade the control plane nodes before upgrading your Windows nodes.
     ```
 
 {{< note >}}
-If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests.
+If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service,
+you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests.
 {{< /note >}}
 
 ### Uncordon the node
@@ -94,6 +89,3 @@ bring the node back online by marking it schedulable:
     kubectl uncordon <node-to-drain>
     ```
 
-
-
-

content/en/docs/tasks/configure-pod-container/configure-service-account.md

@@ -47,11 +47,12 @@ kubectl get pods/<podname> -o yaml
 ```
 
 In the output, you see a field `spec.serviceAccountName`.
-Kubernetes [automatically](/docs/user-guide/working-with-resources/#resources-are-automatically-modified)
+Kubernetes [automatically](/docs/concepts/overview/working-with-objects/object-management/)
 sets that value if you don't specify it when you create a Pod.
 
 An application running inside a Pod can access the Kubernetes API using
-automatically mounted service account credentials. See [accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) to learn more.
+automatically mounted service account credentials.
+See [accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster/) to learn more.
 
 When a Pod authenticates as a ServiceAccount, its level of access depends on the
 [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules)
@@ -62,7 +63,8 @@ in use.
 If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
 to automatically mount a ServiceAccount's API credentials, you can opt out of
 the default behavior.
-You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
+You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token`
+for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
 
 For example: