diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md index 9e18805cf8..10052fd68e 100644 --- a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md +++ b/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 --- @@ -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 + + +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,62 +98,64 @@ When running under the privileged policy, here are the configurations which need to be set to enable the creation of a HostProcess pod: - - - - - - - - - + + + + + + + + + + - - - - - +

Allowed Values

+ + + - - - + + + - - + + + + + - - +
  • false
    • + + + +
    Privileged policy specification
    ControlPolicy
    Windows HostProcess -

    Windows pods offer the ability to run +

    Privileged policy specification
    ControlPolicy
    securityContext.windowsOptions.hostProcess +

    Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node.

    -

    Allowed Values

    -
      -
    • true
      • -
    -
    Host Networking -

    Will be in host network by default initially. Support - to set network to a different compartment may be desirable in - the future.

    -

    Allowed Values

    -
      -
    • true
      • -
    -
    runAsUsername -

    Specification of which user the HostProcess container should run as is required for the pod spec.

    -

    Allowed Values

    -
      -
    • NT AUTHORITY\SYSTEM
      • -
    • NT AUTHORITY\Local service
      • -
    • NT AUTHORITY\NetworkService
      • -
    -
    hostNetwork +

    Will be in host network by default initially. Support + to set network to a different compartment may be desirable in + the future.

    +

    Allowed Values

    +
      +
    • true
      • +
    +
    runAsNonRoot -

    Because HostProcess containers have privileged access to the host, the runAsNonRoot field cannot be set to true.

    -

    Allowed Values

    -
      +
    		securityContext.windowsOptions.runAsUsername +

    Specification of which user the HostProcess container should run as is required for the pod spec.

    +

    Allowed Values

    +
      +
    • NT AUTHORITY\SYSTEM
      • +
    • NT AUTHORITY\Local service
      • +
    • NT AUTHORITY\NetworkService
      • +
    +
    runAsNonRoot +

    Because HostProcess containers have privileged access to the host, the runAsNonRoot field cannot be set to true.

    +

    Allowed Values

    +
    • Undefined/Nil
      • -
    • false
      • -
    -
    -### 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)**