建立 Windows HostProcess Pod

Windows HostProcess 容器可讓您在 Windows 主機上執行容器化工作負載。這些容器作為一般程序運作，但在獲得適當的使用者權限後，可以存取主機網路命名空間、儲存空間與裝置。HostProcess 容器可用於將網路外掛程式、儲存組態、裝置外掛程式、kube-proxy 與其他元件部署至 Windows 節點，而無需專用 Proxy 或直接安裝主機服務。

諸如安裝安全性修補程式、事件記錄收集等管理任務可以執行，而無需叢集操作員登入每部 Windows 節點。HostProcess 容器可以任何主機上可用或在主機網域中的使用者身分執行，讓管理員能夠透過使用者權限限制資源存取。雖然檔案系統或程序隔離都不受支援，但在啟動容器時，會在主機上建立新的磁碟區，以為其提供乾淨且整合的工作區。HostProcess 容器也可以在現有的 Windows 基礎映像檔之上建置，並且不繼承與 Windows 伺服器容器相同的相容性需求，這表示基礎映像檔的版本不需要與主機的版本相符。但是，建議您使用與 Windows Server 容器工作負載相同的基礎映像檔版本，以確保您沒有任何未使用的映像檔佔用節點上的空間。HostProcess 容器也支援容器磁碟區內的磁碟區掛載。

我何時應該使用 Windows HostProcess 容器？

• 當您需要執行需要主機網路命名空間的任務時。HostProcess 容器可以存取主機的網路介面與 IP 位址。
• 您需要存取主機上的資源，例如檔案系統、事件記錄等。
• 安裝特定的裝置驅動程式或 Windows 服務。
• 整合管理任務與安全性策略。這降低了 Windows 節點所需的權限程度。

事前準備

本任務指南專門針對 Kubernetes v1.32。如果您未執行 Kubernetes v1.32，請查看該 Kubernetes 版本的說明文件。

在 Kubernetes 1.32 中，預設啟用 HostProcess 容器功能。kubelet 將透過 CRI 傳遞 hostprocess 標記直接與 containerd 通訊。您可以使用最新版本的 containerd (v1.6+) 來執行 HostProcess 容器。如何安裝 containerd。

限制

這些限制與 Kubernetes v1.32 相關

• HostProcess 容器需要 containerd 1.6 或更高版本容器執行期，建議使用 containerd 1.7。
• HostProcess Pod 只能包含 HostProcess 容器。這是 Windows OS 目前的限制；非特權 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 所需設定的配置

範例 Manifest (摘錄)

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（及更高版本）

在容器內執行的應用程式可以直接透過 volumeMount 指定的 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 服務帳戶身分執行。使用者帳戶（即使是管理員帳戶）也沒有權限為任何受支援的使用者帳戶建立登入權杖。