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 requirementspull/30781/head
Tim Bannister
GitHub
parent
3a30941018
commit
8983d73fff
|
|
@ -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,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:
|
||||
|
||||
<table>
|
||||
<caption style="display:none">Privileged policy specification</caption>
|
||||
<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>
|
||||
<p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">
|
||||
<caption style="display: none">Privileged policy specification</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Control</th>
|
||||
<th>Policy</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<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>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li><code>true</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards">Host Networking</a></td>
|
||||
<td>
|
||||
<p>Will be in host network by default initially. Support
|
||||
to set network to a different compartment may be desirable in
|
||||
the future.</p>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li><code>true</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li><code>true</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/docs/tasks/configure-pod-container/configure-runasusername/">runAsUsername</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>
|
||||
<ul>
|
||||
<li><code>NT AUTHORITY\SYSTEM</code></li>
|
||||
<li><code>NT AUTHORITY\Local service</code></li>
|
||||
<li><code>NT AUTHORITY\NetworkService</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<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
|
||||
the future.</p>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li><code>true</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/docs/concepts/security/pod-security-standards">runAsNonRoot</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>
|
||||
<ul>
|
||||
<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>
|
||||
<ul>
|
||||
<li><code>NT AUTHORITY\SYSTEM</code></li>
|
||||
<li><code>NT AUTHORITY\Local service</code></li>
|
||||
<li><code>NT AUTHORITY\NetworkService</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<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>
|
||||
<ul>
|
||||
<li>Undefined/Nil</li>
|
||||
<li><code>false</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
<li><code>false</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</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)**
|
||||
|
|
|
|||
Loading…
Reference in New Issue