Batch fix links (4)

content/en/docs/concepts/architecture/control-plane-node-communication.md

@@ -33,7 +33,7 @@ are allowed.
 Nodes should be provisioned with the public root certificate for the cluster such that they can
 connect securely to the API server along with valid client credentials. A good approach is that the
 client credentials provided to the kubelet are in the form of a client certificate. See
-[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
 for automated provisioning of kubelet client certificates.
 
 Pods that wish to connect to the API server can do so securely by leveraging a service account so

content/en/docs/concepts/architecture/nodes.md

@@ -479,29 +479,24 @@ these pods will be stuck in terminating status on the shutdown node forever.
 To mitigate the above situation, a  user can manually add the taint `node 
 kubernetes.io/out-of-service` with either `NoExecute` or `NoSchedule` effect to 
 a Node marking it out-of-service. 
-If the `NodeOutOfServiceVolumeDetach`  [feature gate](/docs/reference/
-command-line-tools-reference/feature-gates/) is enabled on
-`kube-controller-manager`, and a Node is marked out-of-service with this taint, the 
-pods on the node will be forcefully deleted if there are no matching tolerations on
-it and volume detach operations for the pods terminating on the node will happen
-immediately. This allows the Pods on the out-of-service node to recover quickly on a
-different node. 
+If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled on `kube-controller-manager`, and a Node is marked out-of-service with this taint, the
+pods on the node will be forcefully deleted if there are no matching tolerations on it and volume
+detach operations for the pods terminating on the node will happen immediately. This allows the
+Pods on the out-of-service node to recover quickly on a different node. 
 
 During a non-graceful shutdown, Pods are terminated in the two phases:
 
 1. Force delete the Pods that do not have matching `out-of-service` tolerations.
 2. Immediately perform detach volume operation for such pods. 
 
-
 {{< note >}}
 - Before adding the taint `node.kubernetes.io/out-of-service` , it should be verified
-that the node is already in shutdown or power off state (not in the middle of
-restarting).
+  that the node is already in shutdown or power off state (not in the middle of
+  restarting).
 - The user is required to manually remove the out-of-service taint after the pods are
-moved to a new node and the user has checked that the shutdown node has been
-recovered since the user was the one who originally added the taint.
-
-
+  moved to a new node and the user has checked that the shutdown node has been
+  recovered since the user was the one who originally added the taint.
 {{< /note >}}
 
 ### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown}

content/en/docs/concepts/cluster-administration/_index.md

@@ -11,31 +11,37 @@ no_list: true
 ---
 
 <!-- overview -->
+
 The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
 It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
 
-
 <!-- body -->
+
 ## Planning a cluster
 
-See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
+See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure
+Kubernetes clusters. The solutions listed in this article are called *distros*.
 
-   {{< note  >}}
-   Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-   {{< /note >}}
+{{< note  >}}
+Not all distros are actively maintained. Choose distros which have been tested with a recent
+version of Kubernetes.
+{{< /note >}}
 
 Before choosing a guide, here are some considerations:
 
- - Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
-   latter, choose an actively-developed distro. Some distros only use binary releases, but
-   offer a greater variety of choices.
- - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
-
+- Do you want to try out Kubernetes on your computer, or do you want to build a high-availability,
+  multi-node cluster? Choose distros best suited for your needs.
+- Will you be using **a hosted Kubernetes cluster**, such as
+  [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
+- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly
+  support hybrid clusters. Instead, you can set up multiple clusters.
+- **If you are configuring Kubernetes on-premises**, consider which
+  [networking model](/docs/concepts/cluster-administration/networking/) fits best.
+- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
+- Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**?
+  If the latter, choose an actively-developed distro. Some distros only use binary releases, but
+  offer a greater variety of choices.
+- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
 
 ## Managing a cluster
 
@@ -45,29 +51,43 @@ Before choosing a guide, here are some considerations:
 
 ## Securing a cluster
 
-* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.
+* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to
+  generate certificates using different tool chains.
 
-* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
+* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes
+  the environment for Kubelet managed containers on a Kubernetes node.
 
-* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes how Kubernetes implements access control for its own API.
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes
+  how Kubernetes implements access control for its own API.
 
-* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in
+  Kubernetes, including the various authentication options.
 
-* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from
+  authentication, and controls how HTTP calls are handled.
 
-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
+* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+  explains plug-ins which intercepts requests to the Kubernetes API server after authentication
+  and authorization.
 
-* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
+* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/)
+  describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters
+.
 
-* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes'
+  audit logs.
 
 ### Securing the kubelet
-  * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
-  * [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
-  * [Kubelet authentication/authorization](/docs/reference/acess-authn-authz/kubelet-authn-authz/)
+
+* [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
+* [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+* [Kubelet authentication/authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/)
 
 ## Optional Cluster Services
 
-* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
+* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve
+  a DNS name directly to a Kubernetes service.
+
+* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/)
+  explains how logging in Kubernetes works and how to implement it.
 
-* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.

content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -8,21 +8,29 @@ card:
 ---
 
 <!-- overview -->
-This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
-
+This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
+express them in `.yaml` format.
 
 <!-- body -->
 ## Understanding Kubernetes objects {#kubernetes-objects}
 
-*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
+*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
+entities to represent the state of your cluster. Specifically, they can describe:
 
 * What containerized applications are running (and on which nodes)
 * The resources available to those applications
 * The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
 
-A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
+A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
+will constantly work to ensure that object exists. By creating an object, you're effectively
+telling the Kubernetes system what you want your cluster's workload to look like; this is your
+cluster's *desired state*.
 
-To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
+[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
+interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
+the Kubernetes API directly in your own programs using one of the
+[Client Libraries](/docs/reference/using-api/client-libraries/).
 
 ### Object Spec and Status
 
@@ -48,11 +56,17 @@ the status to match your spec. If any of those instances should fail
 between spec and status by making a correction--in this case, starting
 a replacement instance.
 
-For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+For more information on the object spec, status, and metadata, see the
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
 
 ### Describing a Kubernetes object
 
-When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
+When you create an object in Kubernetes, you must provide the object spec that describes its
+desired state, as well as some basic information about the object (such as a name). When you use
+the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
+include that information as JSON in the request body. **Most often, you provide the information to
+`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
+request.
 
 Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
 
@@ -81,7 +95,9 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
 * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
 * `spec` - What state you desire for the object
 
-The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
+The precise format of the object `spec` is different for every Kubernetes object, and contains
+nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
+can help you find the spec format for all of the objects you can create using Kubernetes.
 
 For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
 for the Pod API reference.
@@ -103,5 +119,3 @@ detail the structure of that `.status` field, and its content for each different
 * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
 * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
 
-
-