创建 Windows HostProcess Pod

Windows HostProcess 容器允许你在 Windows 主机上运行容器化工作负载。这些容器作为普通进程运行，但在获得适当的用户权限后，可以访问主机网络命名空间、存储和设备。HostProcess 容器可用于将网络插件、存储配置、设备插件、kube-proxy 和其他组件部署到 Windows 节点，而无需专用的代理或直接安装主机服务。

可以执行管理任务，例如安装安全补丁、收集事件日志等，而无需集群操作员登录到每个 Windows 节点。HostProcess 容器可以作为主机上可用或主机机器域中的任何用户运行，从而允许管理员通过用户权限限制资源访问。虽然不支持文件系统或进程隔离，但在启动容器时会在主机上创建一个新卷，为其提供一个干净且整合的工作空间。HostProcess 容器也可以构建在现有的 Windows 基础镜像之上，并且不继承与 Windows Server 容器相同的兼容性要求，这意味着基础镜像的版本不需要与主机的版本匹配。但是，建议你使用与 Windows Server 容器工作负载相同的基础镜像版本，以确保节点上没有未使用的镜像占用空间。HostProcess 容器还支持容器卷内的卷挂载。

什么时候应该使用 Windows HostProcess 容器？

• 当你需要执行需要主机网络命名空间的任务时。HostProcess 容器可以访问主机的网络接口和 IP 地址。
• 你需要访问主机上的资源，例如文件系统、事件日志等。
• 安装特定的设备驱动程序或 Windows 服务。
• 管理任务和安全策略的整合。这降低了 Windows 节点所需的权限级别。

准备工作

此任务指南专门针对 Kubernetes v1.34。如果你未运行 Kubernetes v1.34，请查阅该版本 Kubernetes 的文档。

在 Kubernetes 1.34 中，HostProcess 容器功能默认启用。kubelet 将通过 CRI 直接传递 hostprocess 标志与 containerd 通信。你可以使用最新版本的 containerd (v1.6+) 运行 HostProcess 容器。如何安装 containerd。

限制

这些限制适用于 Kubernetes v1.34

• HostProcess 容器需要 containerd 1.6 或更高版本的容器运行时，建议使用 containerd 1.7。
• HostProcess pod 只能包含 HostProcess 容器。这是 Windows 操作系统的当前限制；非特权 Windows 容器无法与主机 IP 命名空间共享 vNIC。
• HostProcess 容器作为主机上的进程运行，除了对 HostProcess 用户帐户施加的资源限制外，没有任何隔离。HostProcess 容器不支持文件系统或 Hyper-V 隔离。
• 支持卷挂载，并挂载到容器卷下。参阅卷挂载
• 默认情况下，HostProcess 容器可以使用有限的主机用户帐户集。参阅选择用户帐户。
• 资源限制（磁盘、内存、CPU 数量）以与主机上的进程相同的方式支持。
• **不支持**命名管道挂载和 Unix 域套接字，应改为通过主机上的路径访问它们（例如 \\.\pipe\*）

HostProcess Pod 配置要求

启用 Windows HostProcess Pod 需要在 Pod 安全配置中设置正确的配置。在Pod 安全标准中定义的策略中，HostProcess Pod 被基线和受限策略所禁止。因此，建议 HostProcess Pod 按照特权配置文件运行。

在特权策略下运行时，需要设置以下配置才能创建 HostProcess Pod

示例清单（摘录）

spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\Local service"
  hostNetwork: true
  containers:
  - name: test
    image: image1:latest
    command:
      - ping
      - -t
      - 127.0.0.1
  nodeSelector:
    "kubernetes.io/os": windows

卷挂载

HostProcess 容器支持在容器卷空间内挂载卷。卷挂载行为因节点上使用的 containerd 运行时版本而异。

Containerd v1.6

在容器内部运行的应用程序可以通过相对或绝对路径直接访问卷挂载。在容器创建时会设置一个环境变量 $CONTAINER_SANDBOX_MOUNT_POINT，它提供容器卷的绝对主机路径。相对路径基于 .spec.containers.volumeMounts.mountPath 配置。

要访问服务帐户令牌（例如），容器内支持以下路径结构

• .\var\run\secrets\kubernetes.io\serviceaccount\
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Containerd v1.7（及更高版本）

在容器内部运行的应用程序可以通过卷挂载指定的 mountPath 直接访问卷挂载（就像 Linux 和非 HostProcess Windows 容器一样）。

为了向后兼容，卷也可以通过使用与 containerd v1.6 配置相同的相对路径来访问。

例如，要访问容器内的服务帐户令牌，可以使用以下路径之一

• c:\var\run\secrets\kubernetes.io\serviceaccount
• /var/run/secrets/kubernetes.io/serviceaccount/
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

资源限制

资源限制（磁盘、内存、CPU 数量）应用于作业，并对整个作业生效。例如，如果限制设置为 10MB，则为任何 HostProcess 作业对象分配的内存将上限为 10MB。这与其他 Windows 容器类型行为相同。这些限制将以目前用于任何协调器或运行时的方式指定。唯一的区别在于用于资源跟踪的磁盘资源使用计算，因为 HostProcess 容器的引导方式不同。

选择用户帐户

系统帐户

默认情况下，HostProcess 容器支持以三种受支持的 Windows 服务帐户之一运行

• LocalSystem
• LocalService
• NetworkService

你应该为每个 HostProcess 容器选择一个合适的 Windows 服务帐户，旨在限制权限级别，以避免对主机造成意外（甚至恶意）损害。LocalSystem 服务帐户拥有这三个中最高的权限级别，只有在绝对必要时才应使用。在可能的情况下，使用 LocalService 服务帐户，因为它是这三个选项中权限最低的。

本地帐户

如果配置，HostProcess 容器也可以作为本地用户帐户运行，这允许节点操作员对工作负载进行精细访问。

要将 HostProcess 容器作为本地用户运行；必须首先在节点上创建本地用户组，并且必须在部署的 runAsUserName 字段中指定该本地用户组的名称。在初始化 HostProcess 容器之前，将创建一个新的**临时**本地用户帐户并加入到指定的用于运行容器的用户组中。这提供了许多好处，包括消除了管理本地用户帐户密码的需要。作为服务帐户运行的初始 HostProcess 容器可用于为后续 HostProcess 容器准备用户组。

示例

1. 在节点上创建本地用户组（这可以在另一个 HostProcess 容器中完成）。

   net localgroup hpc-localgroup /add
   

2. 授予本地用户组对节点上所需资源的访问权限。这可以通过 icacls 等工具完成。

3. 将 Pod 或单个容器的 runAsUserName 设置为本地用户组的名称。

   securityContext:
     windowsOptions:
       hostProcess: true
       runAsUserName: hpc-localgroup
   

4. 调度 Pod！

HostProcess 容器的基础镜像

HostProcess 容器可以从任何现有的Windows 容器基础镜像构建。

此外，还专门为 HostProcess 容器创建了一个新的基础镜像！有关更多信息，请查看 windows-host-process-containers-base-image github 项目。

HostProcess 容器故障排除

• HostProcess 容器启动失败，并显示 failed to create user process token: failed to logon user: Access is denied.: unknown

  确保 containerd 以 LocalSystem 或 LocalService 服务帐户运行。用户帐户（即使是管理员帐户）也无权为任何受支持的用户帐户创建登录令牌。