Tidy HostProcess task page (#30762)

* Tidy HostProcess task page

* Use spaces for indentation

Tabs for indentation are less easy to work with between different
contributors. Switch to spaces.

* Fix table for HostProcess requirements

content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md

@@ -2,7 +2,7 @@
 title: Create a Windows HostProcess Pod
 content_type: task
 weight: 20
-min-kubernetes-server-version: 1.22
+min-kubernetes-server-version: 1.23
 ---
 
 <!-- overview -->
@@ -43,9 +43,15 @@ HostProcess containers have access to the host's network interfaces and IP addre
 privileges needed by Windows nodes.
 
 
-## {{% heading "prerequisites" %}}% version-check %}}
+## {{% heading "prerequisites" %}}
 
-In 1.23 the HostProcess container feature is enabled by default. The kubelet will
+<!-- change this when graduating to stable -->
+
+This task guide is specific to Kubernetes v{{< skew currentVersion >}}.
+If you are not running Kubernetes v{{< skew currentVersion >}}, check the documentation for
+that version of Kubernetes.
+
+In Kubernetes {{< skew currentVersion >}}, the HostProcess container feature is enabled by default. The kubelet will
 communicate with containerd directly by passing the hostprocess flag via CRI. You can use the
 latest version of containerd (v1.6+) to run HostProcess containers.
 [How to install containerd.](/docs/setup/production-environment/container-runtimes/#containerd)
@@ -64,20 +70,21 @@ documentation for more details.
 
 ## Limitations
 
+These limitations are relevant for Kubernetes v{{< skew currentVersion >}}:
+
 - HostProcess containers require containerd 1.6 or higher
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
-- As of v1.23 HostProcess pods can only contain HostProcess containers. This is a current limitation
+- HostProcess pods can only contain HostProcess containers. This is a current limitation
 of the Windows OS; non-privileged Windows containers cannot share a vNIC with the host IP namespace.
 - HostProcess containers run as a process on the host and do not have any degree of
 isolation other than resource constraints imposed on the HostProcess user account. Neither
 filesystem or Hyper-V isolation are supported for HostProcess containers.
 - Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts)
-- As of 1.23, a limited set of host user accounts are available for HostProcess containers by default.
 - A limited set of host user accounts are available for HostProcess containers by default.
-See [Choosing a User Account](#choosing-a-user-account).
+  See [Choosing a User Account](#choosing-a-user-account).
 - Resource limits (disk, memory, cpu count) are supported in the same fashion as processes
 on the host.
-- Both Named pipe mounts and Unix domain sockets are **not** currently supported and should instead
+- Both Named pipe mounts and Unix domain sockets are **not** supported and should instead
 be accessed via their path on the host (e.g. \\\\.\\pipe\\\*)
 
 ## HostProcess Pod configuration requirements
@@ -91,14 +98,16 @@ When running under the privileged policy, here are
 the configurations which need to be set to enable the creation of a HostProcess pod:
 
 <table>
-	<caption style="display:none">Privileged policy specification</caption>
+  <caption style="display: none">Privileged policy specification</caption>
+  <thead>
+    <tr>
+      <th>Control</th>
+      <th>Policy</th>
+    </tr>
+  </thead>
   <tbody>
     <tr>
-			<td><strong>Control</strong></td>
-			<td><strong>Policy</strong></td>
-		</tr>
-		<tr>
-			<td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards">Windows HostProcess</a></td>
+      <td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards"><tt>securityContext.windowsOptions.hostProcess</tt></a></td>
       <td>
         <p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">
         HostProcess containers</a> which enables privileged access to the Windows node. </p>
@@ -109,7 +118,7 @@ the configurations which need to be set to enable the creation of a HostProcess
       </td>
     </tr>
     <tr>
-			<td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards">Host Networking</a></td>
+      <td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards"><tt>hostNetwork</tt></a></td>
       <td>
         <p>Will be in host network by default initially. Support
         to set network to a different compartment may be desirable in
@@ -121,7 +130,7 @@ the configurations which need to be set to enable the creation of a HostProcess
       </td>
     </tr>
     <tr>
-			<td style="white-space: nowrap"><a href="/docs/tasks/configure-pod-container/configure-runasusername/">runAsUsername</a></td>
+      <td style="white-space: nowrap"><a href="/docs/tasks/configure-pod-container/configure-runasusername/"><tt>securityContext.windowsOptions.runAsUsername</tt></a></td>
       <td>
         <p>Specification of which user the HostProcess container should run as is required for the pod spec.</p>
         <p><strong>Allowed Values</strong></p>
@@ -133,7 +142,7 @@ the configurations which need to be set to enable the creation of a HostProcess
       </td>
     </tr>
     <tr>
-			<td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards">runAsNonRoot</a></td>
+      <td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards"><tt>runAsNonRoot</tt></a></td>
       <td>
         <p>Because HostProcess containers have privileged access to the host, the <tt>runAsNonRoot</tt> field cannot be set to true.</p>
         <p><strong>Allowed Values</strong></p>
@@ -146,7 +155,7 @@ the configurations which need to be set to enable the creation of a HostProcess
   </tbody>
 </table>
 
-### Example Manifest (excerpt)
+### Example manifest (excerpt) {#manifest-example}
 
 ```yaml
 spec:
@@ -166,13 +175,13 @@ spec:
     "kubernetes.io/os": windows
 ```
 
-## Volume Mounts
+## Volume mounts
 
 HostProcess containers support the ability to mount volumes within the container volume space.
 Applications running inside the container can access volume mounts directly via relative or
-absolute paths. As of v1.23, an environment variable `$CONTAINER_SANDBOX_MOUNT_POINT` is set upon container
+absolute paths. An environment variable `$CONTAINER_SANDBOX_MOUNT_POINT` is set upon container
 creation and provides the absolute host path to the container volume. Relative paths are based
-upon the `Pod.containers.volumeMounts.mountPath` configuration.
+upon the `.spec.containers.volumeMounts.mountPath` configuration.
 
 ### Example {#volume-mount-example}
 
@@ -182,7 +191,7 @@ To access service account tokens the following path structures are supported wit
 
 `$CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\`
 
-## Resource Limits
+## Resource limits
 
 Resource limits (disk, memory, cpu count) are applied to the job and are job wide.
 For example, with a limit of 10MB set, the memory allocated for any HostProcess job object
@@ -191,9 +200,9 @@ These limits would be specified the same way they are currently for whatever orc
 or runtime is being used. The only difference is in the disk resource usage calculation
 used for resource tracking due to the difference in how HostProcess containers are bootstrapped.
 
-## Choosing a User Account
+## Choosing a user account
 
-As of 1.23, HostProcess containers support the ability to run as one of three supported Windows service accounts:
+HostProcess containers support the ability to run as one of three supported Windows service accounts:
 
 - **[LocalSystem](https://docs.microsoft.com/windows/win32/services/localsystem-account)**
 - **[LocalService](https://docs.microsoft.com/windows/win32/services/localservice-account)**