这篇文章已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已变得不正确。
v1.22 中的 Alpha 功能：Windows HostProcess 容器
Kubernetes v1.22 为包含 Windows 节点的集群引入了一项新的 Alpha 功能：HostProcess 容器。
HostProcess 容器旨在扩展 Windows 容器模型，以支持更广泛的 Kubernetes 集群管理场景。HostProcess 容器直接在宿主机上运行，并保持与常规进程相似的行为和访问权限。通过 HostProcess 容器，用户可以打包和分发需要宿主机访问权限的管理操作和功能，同时保留容器提供的版本控制和部署方法。这使得 Windows 容器可以用于 Kubernetes 中各种设备插件、存储和网络管理场景。此外，这也带来了宿主机网络模式的启用，允许 HostProcess 容器在宿主机的网络命名空间内创建，而不是它们自己的命名空间。HostProcess 容器还可以基于现有的 Windows Server 2019（或更高版本）基础镜像构建，通过 Windows 容器运行时进行管理，并作为宿主机上可用或在宿主机域内的任何用户运行。
Linux 特权容器目前用于 Kubernetes 中的多种关键场景，包括 kube-proxy（通过 kubeadm）、存储和网络场景。之前在 Windows 中支持这些场景需要通过代理或其他实现方式进行变通。使用 HostProcess 容器后，集群操作员不再需要登录并单独配置每个 Windows 节点来执行管理任务和管理 Windows 服务。操作员现在可以轻松地利用容器模型将管理逻辑部署到所需数量的集群。
工作原理是什么？
Windows HostProcess 容器使用 Windows Job Objects 实现，这与之前使用服务器容器的模式不同。Job objects 是 Windows OS 的组件，能够将一组进程作为一个组（又称 jobs）进行管理，并为整个组分配资源限制。Job objects 是 Windows OS 特有的，与 Kubernetes Job API 无关。它们没有进程或文件系统隔离，使特权负载能够以正确的权限查看和编辑宿主机文件系统以及访问其他宿主机资源。init 进程，以及它启动的或用户显式启动的任何进程，都被分配给该容器的 job object。当 init 进程退出或收到退出信号时，job 中的所有进程都会收到退出信号，job handle 将被关闭，存储将被卸载。
HostProcess 和 Linux 特权容器支持类似的场景，但在实现上差异很大（因此命名不同）。HostProcess 容器有自己的 Pod 安全策略。用于配置 Linux 特权容器的策略不适用。在 Windows 宿主机上启用特权访问与在 Linux 上是根本不同的过程，因此它们的配置和能力差异很大。下面是详细说明 Windows HostProcess 容器总体架构的图表。
如何使用它？
HostProcess 容器可以在HostProcess Pod 内运行。在 Kubernetes 1.22 或更高版本上启用此功能，使用 containerd 1.5.4 或更高版本的容器运行时以及最新版本的 hcsshim，部署具有正确 HostProcess 配置的 Pod Spec 即可运行 HostProcess 容器。要开始运行 Windows 容器，请参阅 Windows in Kubernetes 的一般指南。
如何了解更多信息？
阅读关于 Kubernetes Pod 安全标准
阅读增强提案Windows 特权容器和宿主机网络模式 (KEP-1981)
如何参与？
HostProcess 容器正在积极开发中。SIG Windows 欢迎社区的建议。加入SIG Windows 贡献力量吧！