Merge pull request #44571 from hunshcn/fix/link

k8s-ci-robot · web-flow · commit cca14eff625b · 2024-01-07T23:15:35.000+01:00
fix outdated link/anchor
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
@@ -209,7 +209,7 @@ You should only create a ServiceAccount token Secret
 if you can't use the `TokenRequest` API to obtain a token,
 and the security exposure of persisting a non-expiring token credential
 in a readable API object is acceptable to you. For instructions, see
-[Manually create a long-lived API token for a ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token).
+[Manually create a long-lived API token for a ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount).
 {{< /note >}}
 
 When using this Secret type, you need to ensure that the
diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md
@@ -264,7 +264,7 @@ a way to extend Kubernetes with supports for new kinds of volumes. The volumes c
 durable external storage, or provide ephemeral storage, or they might offer a read-only interface
 to information using a filesystem paradigm.
 
-Kubernetes also includes support for [FlexVolume](/docs/concepts/storage/volumes/#flexvolume-deprecated) plugins,
+Kubernetes also includes support for [FlexVolume](/docs/concepts/storage/volumes/#flexvolume) plugins,
 which are deprecated since Kubernetes v1.23 (in favour of CSI).
 
 FlexVolume plugins allow users to mount volume types that aren't natively supported by Kubernetes. When
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -50,7 +50,7 @@ documentation for that Container Runtime, for example:
 - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
 
 For specific information about how to install and manage a CNI plugin, see the documentation for
-that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
+that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model).
 
 ## Network Plugin Requirements
 
diff --git a/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md b/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md
@@ -29,7 +29,7 @@ suitable for this use-case.
 
 ## X.509 client certificate authentication {#x509-client-certificate-authentication}
 
-Kubernetes leverages [X.509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certs) 
+Kubernetes leverages [X.509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certificates) 
 authentication for system components, such as when the Kubelet authenticates to the API Server. 
 While this mechanism can also be used for user authentication, it might not be suitable for 
 production use due to several restrictions:
diff --git a/content/en/docs/contribute/new-content/_index.md b/content/en/docs/contribute/new-content/_index.md
@@ -98,7 +98,7 @@ Scenario | Branch
 :---------|:------------
 Existing or new English language content for the current release | `main`
 Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
-Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
+Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branch-strategy) for more information.
 
 If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
 
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
@@ -102,7 +102,7 @@ following cases (not an exhaustive list):
 - The code is not generic enough for users to try out. As an example, you can
   embed the YAML
   file for creating a Pod which depends on a specific
-  [FlexVolume](/docs/concepts/storage/volumes/#flexvolume-deprecated) implementation.
+  [FlexVolume](/docs/concepts/storage/volumes/#flexvolume) implementation.
 - The code is an incomplete example because its purpose is to highlight a
   portion of a larger file. For example, when describing ways to
   customize a [RoleBinding](/docs/reference/access-authn-authz/rbac/#role-binding-examples),
diff --git a/content/en/docs/reference/access-authn-authz/kubelet-authn-authz.md b/content/en/docs/reference/access-authn-authz/kubelet-authn-authz.md
@@ -27,7 +27,7 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint
 
 * start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
 * start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
-* see the [apiserver authentication documentation](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
+* see the [apiserver authentication documentation](/docs/reference/access-authn-authz/authentication/#x509-client-certificates) for more details
 
 To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
 
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/custom-pod-dns.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/custom-pod-dns.md
@@ -24,5 +24,5 @@ stages:
 removed: true  
 ---
 Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
-Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
+Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)
 for more details.
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -360,4 +360,4 @@ The command line argument to use is `--pod-infra-container-image`.
 ## {{% heading "whatsnext" %}}
 
 As well as a container runtime, your cluster will need a working
-[network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
+[network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model).
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -331,7 +331,7 @@ Several external projects provide Kubernetes Pod networks using CNI, some of whi
 support [Network Policy](/docs/concepts/services-networking/network-policies/).
 
 See a list of add-ons that implement the
-[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model).
 
 You can install a Pod network add-on with the following command on the
 control-plane node or a node that has the kubeconfig credentials:
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -324,7 +324,7 @@ systemctl enable --now kubelet
 {{< note >}}
 The Flatcar Container Linux distribution mounts the `/usr` directory as a read-only filesystem.
 Before bootstrapping your cluster, you need to take additional steps to configure a writable directory.
-See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/)
+See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only)
 to learn how to set up a writable directory.
 {{< /note >}}
 {{% /tab %}}
diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster-services.md b/content/en/docs/tasks/access-application-cluster/access-cluster-services.md
@@ -77,7 +77,7 @@ if suitable credentials are passed, or through a kubectl proxy at, for example:
 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
 
 {{< note >}}
-See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
+See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-kubernetes-api)
 for how to pass credentials or use kubectl proxy.
 {{< /note >}}
 
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -213,7 +213,7 @@ controllerManager:
 
 ### Create certificate signing requests (CSR)
 
-See [Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)
+See [Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatessigningrequest)
 for creating CSRs with the Kubernetes API.
 
 ## Renew certificates with external CA
diff --git a/content/en/docs/tasks/debug/debug-application/debug-init-containers.md b/content/en/docs/tasks/debug/debug-application/debug-init-containers.md
@@ -26,7 +26,7 @@ Init Containers. The example command lines below refer to the Pod as
 
 * You should be familiar with the basics of
   [Init Containers](/docs/concepts/workloads/pods/init-containers/).
-* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
+* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container).
 
 <!-- steps -->
 
diff --git a/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
@@ -279,7 +279,7 @@ if not used correctly.
   of the request. If it is signed by one of the CA certificates in the file referenced by
   `--client-ca-file`, then the request is treated as a legitimate request,
   and the user is the value of the common name `CN=`, while the group is the organization `O=`.
-  See the [documentation on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs).
+  See the [documentation on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certificates).
 * `--requestheader-client-ca-file`: When a request arrives to the Kubernetes apiserver,
   if this option is enabled, the Kubernetes apiserver checks the certificate of the request.
   If it is signed by one of the CA certificates in the file reference by `--requestheader-client-ca-file`,
diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
@@ -438,7 +438,7 @@ which caused the conversion. All other changes are ignored.
 ### Deploy the conversion webhook service
 
 Documentation for deploying the conversion webhook is the same as for the
-[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
+[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy-the-admission-webhook-service).
 The assumption for next sections is that the conversion webhook server is deployed to a service
 named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
 
