Windows HostProcess Beta 1.23 Documentation (#30391)

* Added initial version change

* Added more information for HostProcess in 1.23, removed content relating to 1.22 specifically.

* Made containerd mention specific to 1.6

* Added note about base images and removed annotation mentions

* Reworded prerequisites section.

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

@@ -203,7 +203,7 @@ different Kubernetes components.
 | `WinDSR` | `false` | Alpha | 1.14 | |
 | `WinOverlay` | `false` | Alpha | 1.14 | 1.19 |
 | `WinOverlay` | `true` | Beta | 1.20 | |
-| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | |
+| `WindowsHostProcessContainers` | `false` | Beta | 1.23 | |
 {{< /table >}}
 
 ### Feature gates for graduated or deprecated features

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

@@ -7,7 +7,7 @@ min-kubernetes-server-version: 1.22
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
 Windows HostProcess containers enable you to run containerized
 workloads on a Windows host. These containers operate as
@@ -28,7 +28,9 @@ to give it a clean and consolidated workspace. HostProcess containers can also b
 top of existing Windows base images and do not inherit the same
 [compatibility requirements](https://docs.microsoft.com/virtualization/windowscontainers/deploy-containers/version-compatibility)
 as Windows server containers, meaning that the version of the base images does not need
-to match that of the host. HostProcess containers also support 
+to match that of the host. It is, however, recommended that you use the same base image
+version as your Windows Server container workloads to ensure you do not have any unused
+images taking up space on the node. HostProcess containers also support
 [volume mounts](./create-hostprocess-pod#volume-mounts) within the container volume.
 
 ### When should I use a Windows HostProcess container?
@@ -41,56 +43,36 @@ HostProcess containers have access to the host's network interfaces and IP addre
 privileges needed by Windows nodes.
 
 
-## {{% heading "prerequisites" %}}
+## {{% heading "prerequisites" %}}% version-check %}}
 
-{{% version-check %}}
+In 1.23 the HostProcess container feature is enabled by default. The kublet 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)
+
+To *disable* HostProcess containers you need to pass the following feature gate flag to the
+**kubelet** and **kube-apiserver**:
+
+```powershell
+--feature-gates=WindowsHostProcessContainers=false
+```
 
-To enable HostProcess containers while in Alpha you need to pass the following feature gate flag to 
-**kubelet** and **kube-apiserver**. 
 See [Features Gates](/docs/reference/command-line-tools-reference/feature-gates/#overview)
 documentation for more details.
 
-```
---feature-gates=WindowsHostProcessContainers=true
-```
 
-You can use the latest version of Containerd (v1.5.4+) with the following settings using the containerd 
-v2 configuration. Add these annotations to any runtime configurations were you wish to enable the 
-HostProcess container feature.
-
-
-```
-[plugins]
-  [plugins."io.containerd.grpc.v1.cri"]
-    [plugins."io.containerd.grpc.v1.cri".containerd]
-      [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
-        container_annotations = ["microsoft.com/hostprocess-container"]
-        pod_annotations = ["microsoft.com/hostprocess-container"]
-    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
-      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runhcs-wcow-process]
-        container_annotations = ["microsoft.com/hostprocess-container"]
-        pod_annotations = ["microsoft.com/hostprocess-container"]
-```
-
-The current versions of containerd ship with a version of hcsshim that does not have support. 
-You will need to build a version of hcsshim from the main branch following the 
-[instructions in hcsshim](https://github.com/Microsoft/hcsshim/#containerd-shim). 
-Once the containerd shim is built you can replace the file in your contianerd installation. 
-For example if you followed the instructions to 
-[install containerd](/docs/setup/production-environment/container-runtimes/#containerd)
-replace the `containerd-shim-runhcs-v1.exe` is installed at `$Env:ProgramFiles\containerd` with the newly built shim.
 
 ## Limitations
 
-- HostProcess containers require version 1.5.4 or higher of the containerd {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
+- HostProcess containers require containerd 1.6 or higher
-- As of v1.22 HostProcess pods can only contain HostProcess containers. This is a current limitation 
+{{< 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
 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. 
+- Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts)
-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).
 - Resource limits (disk, memory, cpu count) are supported in the same fashion as processes
 on the host.
@@ -187,7 +169,7 @@ spec:
 
 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. An environment variable `$CONTAINER_SANDBOX_MOUNT_POINT` is set upon container 
+absolute paths. As of v1.23, 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.
 
@@ -199,13 +181,22 @@ 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 (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
+will be capped at 10MB. This is the same behavior as other Windows container types.
+These limits would be specified the same way they are currently for whatever orchestrator
+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
 
-HostProcess containers support the ability to run as one of three supported Windows service accounts:
+As of 1.23, HostProcess containers support the ability to run as one of three supported Windows service accounts:
 
-- **[LocalSystem](https://docs.microsoft.com/en-us/windows/win32/services/localsystem-account)**
+- **[LocalSystem](https://docs.microsoft.com/windows/win32/services/localsystem-account)**
-- **[LocalService](https://docs.microsoft.com/en-us/windows/win32/services/localservice-account)**
+- **[LocalService](https://docs.microsoft.com/windows/win32/services/localservice-account)**
-- **[NetworkService](https://docs.microsoft.com/en-us/windows/win32/services/networkservice-account)**
+- **[NetworkService](https://docs.microsoft.com/windows/win32/services/networkservice-account)**
 
 You should select an appropriate Windows service account for each HostProcess
 container, aiming to limit the degree of privileges so as to avoid accidental (or even