Kubernetes 中的 Windows 容器

在許多組織中，Windows 應用程式佔據了服務和應用程式的很大一部分。Windows 容器提供了一種封裝程序和打包依賴項的方式，使得 Windows 應用程式更容易採用 DevOps 實踐和遵循雲原生模式。

對基於 Windows 的應用程式和基於 Linux 的應用程式進行投資的組織無需尋找單獨的編排器來管理其工作負載，從而無論作業系統如何，都能提高其部署的運營效率。

Kubernetes 中的 Windows 節點

為了在 Kubernetes 中編排 Windows 容器，請在現有 Linux 叢集中包含 Windows 節點。在 Kubernetes 上在Pod 中排程 Windows 容器與排程基於 Linux 的容器類似。

要執行 Windows 容器，你的 Kubernetes 叢集必須包含多個作業系統。雖然你只能在 Linux 上執行控制平面，但你可以部署執行 Windows 或 Linux 的工作節點。

如果作業系統是 Windows Server 2019 或 Windows Server 2022，則支援 Windows 節點。

本文件中，術語_Windows 容器_指具有程序隔離的 Windows 容器。Kubernetes 不支援執行具有 Hyper-V 隔離的 Windows 容器。

相容性和限制

某些節點功能僅在使用特定的容器執行時時可用；其他功能在 Windows 節點上不可用，包括：

  • HugePages：Windows 容器不支援
  • 特權容器：Windows 容器不支援。HostProcess 容器提供類似功能。
  • TerminationGracePeriod：需要 ContainerD

並非所有共享名稱空間功能都受支援。有關更多詳細資訊，請參閱API 相容性。

有關 Kubernetes 測試過的 Windows 版本的詳細資訊，請參閱Windows 作業系統版本相容性。

從 API 和 kubectl 的角度來看，Windows 容器的行為方式與基於 Linux 的容器大致相同。但是，在關鍵功能方面存在一些顯著差異，本節將對此進行概述。

與 Linux 的比較

Kubernetes 的關鍵元素在 Windows 中的工作方式與在 Linux 中相同。本節將介紹幾個關鍵的工作負載抽象及其與 Windows 的對映關係。

  • Pod

    Pod 是 Kubernetes 的基本構建塊——你建立或部署的 Kubernetes 物件模型中最小和最簡單的單元。你不能在同一個 Pod 中部署 Windows 和 Linux 容器。Pod 中的所有容器都排程到單個節點上，每個節點代表一個特定的平臺和體系結構。以下 Pod 功能、屬性和事件支援 Windows 容器：

    • 每個 Pod 一個或多個具有程序隔離和卷共享的容器

    • Pod `status` 欄位

    • 就緒、存活和啟動探針

    • postStart 和 preStop 容器生命週期鉤子

    • ConfigMap、Secrets：作為環境變數或卷

    • emptyDir 卷

    • 命名管道主機掛載

    • 資源限制

    • 作業系統欄位

      .spec.os.name 欄位應設定為 windows，以表明當前 Pod 使用 Windows 容器。

      如果將 .spec.os.name 欄位設定為 windows，則不得在該 Pod 的 .spec 中設定以下欄位：

      • spec.hostPID
      • spec.hostIPC
      • spec.securityContext.seLinuxOptions
      • spec.securityContext.seccompProfile
      • spec.securityContext.fsGroup
      • spec.securityContext.fsGroupChangePolicy
      • spec.securityContext.sysctls
      • spec.shareProcessNamespace
      • spec.securityContext.runAsUser
      • spec.securityContext.runAsGroup
      • spec.securityContext.supplementalGroups
      • spec.containers[*].securityContext.seLinuxOptions
      • spec.containers[*].securityContext.seccompProfile
      • spec.containers[*].securityContext.capabilities
      • spec.containers[*].securityContext.readOnlyRootFilesystem
      • spec.containers[*].securityContext.privileged
      • spec.containers[*].securityContext.allowPrivilegeEscalation
      • spec.containers[*].securityContext.procMount
      • spec.containers[*].securityContext.runAsUser
      • spec.containers[*].securityContext.runAsGroup

      在上述列表中，萬用字元 (*) 表示列表中的所有元素。例如，spec.containers[*].securityContext 指的是所有容器的 SecurityContext 物件。如果指定了這些欄位中的任何一個，則 API 伺服器將不會接納該 Pod。

  • 工作負載資源包括：

    • 副本集
    • 部署
    • StatefulSet
    • DaemonSet
    • 作業
    • 定時作業
    • 複製控制器

  • 服務 有關更多詳細資訊，請參閱負載均衡和服務。

Pod、工作負載資源和服務是 Kubernetes 上管理 Windows 工作負載的關鍵元素。但是，它們本身不足以在動態雲原生環境中實現 Windows 工作負載的正確生命週期管理。

kubelet 命令列選項

一些 kubelet 命令列選項在 Windows 上的行為有所不同，如下所述：

  • --windows-priorityclass 允許你設定 kubelet 程序的排程優先順序（請參閱CPU 資源管理）
  • --kube-reserved、--system-reserved 和 --eviction-hard 標誌更新節點可分配資源
  • 未實現使用 --enforce-node-allocable 的驅逐
  • 在 Windows 節點上執行時，kubelet 沒有記憶體或 CPU 限制。--kube-reserved 和 --system-reserved 只會從 NodeAllocatable 中減去，並不能保證為工作負載提供資源。有關更多資訊，請參閱Windows 節點的資源管理。
  • 未實現 PIDPressure 條件
  • kubelet 不會執行 OOM 驅逐操作

API 相容性

由於作業系統和容器執行時，Kubernetes API 在 Windows 上的工作方式存在細微差異。某些工作負載屬性是為 Linux 設計的，無法在 Windows 上執行。

從高層次來看，這些作業系統概念是不同的：

  • 身份——Linux 使用 userID (UID) 和 groupID (GID)，它們表示為整數型別。使用者和組名不是規範的——它們只是 /etc/groups 或 /etc/passwd 中 UID+GID 的別名。Windows 使用更大的二進位制安全識別符號 (SID)，它儲存在 Windows 安全訪問管理器 (SAM) 資料庫中。此資料庫在主機和容器之間或容器之間不共享。
  • 檔案許可權——Windows 使用基於 (SID) 的訪問控制列表，而 POSIX 系統（如 Linux）使用基於物件許可權和 UID+GID 的位掩碼，以及_可選_的訪問控制列表。
  • 檔案路徑——Windows 上的約定是使用 \ 而不是 /。Go IO 庫通常同時接受兩者並使其正常工作，但當你設定在容器內解釋的路徑或命令列時，可能需要 \。
  • 訊號——Windows 互動式應用程式以不同的方式處理終止，並且可以實現以下一個或多個：
    • UI 執行緒處理明確定義的訊息，包括 WM_CLOSE。
    • 控制檯應用程式使用控制處理程式處理 Ctrl-C 或 Ctrl-break。
    • 服務註冊一個服務控制處理程式函式，該函式可以接受 SERVICE_CONTROL_STOP 控制程式碼。

容器退出程式碼遵循相同的約定，其中 0 表示成功，非零表示失敗。Windows 和 Linux 之間的特定錯誤程式碼可能有所不同。但是，從 Kubernetes 元件（kubelet、kube-proxy）傳遞的退出程式碼保持不變。

容器規範的欄位相容性

以下列表記錄了 Pod 容器規範在 Windows 和 Linux 之間工作方式的差異：

  • Windows 容器執行時未實現 Huge Pages，因此不可用。它們需要宣告使用者許可權，這對於容器是不可配置的。
  • requests.cpu 和 requests.memory——請求會從節點可用資源中扣除，因此可以用於避免節點過載。但是，它們不能用於在過載節點中保證資源。如果操作員希望完全避免過載，最好將它們應用於所有容器。
  • securityContext.allowPrivilegeEscalation——在 Windows 上不可能；所有功能都未連線
  • securityContext.capabilities——POSIX 功能在 Windows 上未實現
  • securityContext.privileged——Windows 不支援特權容器，請改用HostProcess 容器
  • securityContext.procMount——Windows 沒有 /proc 檔案系統
  • securityContext.readOnlyRootFilesystem——在 Windows 上不可能；登錄檔和系統程序需要在容器內執行，因此需要寫入訪問許可權
  • securityContext.runAsGroup——在 Windows 上不可能，因為不支援 GID
  • securityContext.runAsNonRoot——此設定將阻止容器以 ContainerAdministrator 身份執行，ContainerAdministrator 是 Windows 上最接近 root 使用者的等效項。
  • securityContext.runAsUser——改用runAsUserName
  • securityContext.seLinuxOptions——在 Windows 上不可能，因為 SELinux 是 Linux 特有的
  • terminationMessagePath——這有一些限制，因為 Windows 不支援對映單個檔案。預設值是 /dev/termination-log，它確實有效，因為它在 Windows 上預設不存在。

Pod 規範的欄位相容性

以下列表記錄了 Pod 規範在 Windows 和 Linux 之間工作方式的差異：

  • hostIPC 和 hostpid——在 Windows 上無法共享主機名稱空間
  • hostNetwork——在 Windows 上無法進行主機網路
  • dnsPolicy——在 Windows 上不支援將 Pod dnsPolicy 設定為 ClusterFirstWithHostNet，因為未提供主機網路。Pod 始終使用容器網路執行。
  • podSecurityContext 見下文
  • shareProcessNamespace——這是一個 Beta 版功能，依賴於 Linux 名稱空間，而 Windows 上未實現。Windows 無法共享程序名稱空間或容器的根檔案系統。只能共享網路。
  • terminationGracePeriodSeconds——這在 Windows 上的 Docker 中尚未完全實現，請參閱GitHub issue。今天的行為是，ENTRYPOINT 程序收到 CTRL_SHUTDOWN_EVENT，然後 Windows 預設等待 5 秒，最後使用正常的 Windows 關機行為關閉所有程序。5 秒的預設值實際上位於容器內的 Windows 登錄檔中，因此可以在構建容器時覆蓋。
  • volumeDevices——這是一個 Beta 版功能，在 Windows 上未實現。Windows 無法將原始塊裝置連線到 Pod。
  • 卷
    • 如果定義 emptyDir 卷，則不能將其卷源設定為 memory。
  • 不能為卷掛載啟用 mountPropagation，因為 Windows 上不支援此功能。

主機網路訪問

Kubernetes v1.26 到 v1.32 包含在主機網路名稱空間中執行 Windows Pod 的 Alpha 支援。

Kubernetes v1.34 不包括 WindowsHostNetwork 功能門或在主機網路名稱空間中執行 Windows Pod 的支援。

Pod 安全上下文的欄位相容性

僅 Pod securityContext 欄位中的 securityContext.runAsNonRoot 和 securityContext.windowsOptions 在 Windows 上有效。

節點問題檢測器

節點問題檢測器（請參閱監控節點健康狀況）對 Windows 有初步支援。有關更多資訊，請訪問該專案的 GitHub 頁面。

暫停容器

在 Kubernetes Pod 中，首先建立一個基礎結構或“暫停”容器來託管容器。在 Linux 中，構成 Pod 的 cgroups 和名稱空間需要一個程序來維持其持續存在；暫停程序提供了這一點。屬於同一 Pod 的容器，包括基礎結構和工作容器，共享一個共同的網路端點（相同的 IPv4 和/或 IPv6 地址，相同的網路埠空間）。Kubernetes 使用暫停容器來允許工作容器崩潰或重新啟動而不會丟失任何網路配置。

Kubernetes 維護一個支援 Windows 的多架構映象。對於 Kubernetes v1.34.0，推薦的暫停映象為 registry.k8s.io/pause:3.6。其原始碼可在 GitHub 上找到。

Microsoft 維護另一個多架構映象，支援 Linux 和 Windows amd64，你可以在 mcr.microsoft.com/oss/kubernetes/pause:3.6 找到。此映象與 Kubernetes 維護的映象使用相同的源構建，但所有 Windows 二進位制檔案都經過 Microsoft Authenticode 簽名。如果部署到生產或類似生產的環境需要簽名二進位制檔案，Kubernetes 專案建議使用 Microsoft 維護的映象。

容器執行時

你需要在叢集中的每個節點上安裝容器執行時，以便 Pod 可以在那裡執行。

以下容器執行時適用於 Windows：

ContainerD

特性狀態： Kubernetes v1.20 [stable]

你可以使用 ContainerD 1.4.0+ 作為執行 Windows 的 Kubernetes 節點的容器執行時。

瞭解如何在Windows 節點上安裝 ContainerD。

Mirantis 容器執行時

Mirantis 容器執行時 (MCR) 可作為所有 Windows Server 2019 及更高版本的容器執行時。

有關更多資訊，請參閱在 Windows Server 上安裝 MCR。

Windows 作業系統版本相容性

在 Windows 節點上，嚴格的相容性規則適用，即主機作業系統版本必須與容器基礎映象作業系統版本匹配。僅完全支援容器作業系統為 Windows Server 2019 的 Windows 容器。

對於 Kubernetes v1.34，Windows 節點（和 Pod）的作業系統相容性如下：

Windows Server LTSC 釋出
Windows Server 2019
Windows Server 2022
Windows Server SAC 釋出
Windows Server 版本 20H2

Kubernetes 版本偏差策略也適用。

硬體建議和注意事項

  • 64 位處理器，4 個或更多 CPU 核，能夠支援虛擬化
  • 8GB 或更多記憶體
  • 50GB 或更多可用磁碟空間

有關最低硬體要求的最新資訊，請參閱Windows Server 硬體要求 Microsoft 文件。有關為生產工作節點決定資源的指南，請參閱生產工作節點 Kubernetes 文件。

為了最佳化系統資源，如果不需要圖形使用者介面，則最好使用不包括Windows 桌面體驗安裝選項的 Windows Server 作業系統安裝，因為此配置通常會釋放更多系統資源。

在評估 Windows 工作節點的磁碟空間時，請注意 Windows 容器映象通常比 Linux 容器映象大，單個容器映象的大小範圍從 300MB 到超過 10GB。此外，請注意，Windows 容器中的 C: 驅動器預設表示 20GB 的虛擬可用空間，這並不是實際消耗的空間，而是單個容器在使用主機上的本地儲存時可以增長佔用的磁碟大小。有關更多詳細資訊，請參閱Windows 上的容器 - 容器儲存文件。

獲取幫助和故障排除

故障排除 Kubernetes 叢集的主要幫助來源應從故障排除頁面開始。

本節包含一些額外的、特定於 Windows 的故障排除幫助。日誌是故障排除 Kubernetes 問題的重要元素。在向其他貢獻者尋求故障排除幫助時，請務必包含它們。請遵循 SIG Windows 貢獻指南中的日誌收集說明。

報告問題和功能請求

如果您發現問題或想提出功能請求，請遵循 SIG Windows 貢獻指南 來建立新問題。您應該首先搜尋問題列表，以防之前已報告過，並評論您對此問題的經驗並新增額外的日誌。Kubernetes Slack 上的 SIG Windows 頻道也是在建立工單之前獲得初步支援和故障排除想法的好途徑。

驗證 Windows 叢集可操作性

Kubernetes 專案提供了一份_Windows 可操作性就緒_規範，並附帶一套結構化測試套件。這套套件分為兩組測試：核心測試和擴充套件測試，每組都包含旨在測試特定類別的測試。它可以用於全面驗證 Windows 和混合系統（與 Linux 節點混合）的所有功能。

要在新建立的叢集上設定該專案，請參閱專案指南中的說明。

部署工具

kubeadm 工具可幫助你部署 Kubernetes 叢集，提供控制平面來管理叢集，並提供節點來執行你的工作負載。

Kubernetes 叢集 API 專案還提供自動化部署 Windows 節點的方法。

Windows 分發渠道

有關 Windows 分發渠道的詳細說明，請參閱Microsoft 文件。

有關包括其支援模型在內的不同 Windows Server 服務渠道的資訊，請參見Windows Server 服務渠道。

本頁中的專案引用了提供 Kubernetes 所需功能的第三方產品或專案。Kubernetes 專案作者不對這些第三方產品或專案負責。有關更多詳細資訊，請參閱 CNCF 網站指南。

在提議新增額外第三方連結的更改之前，你應該閱讀內容指南。

上次修改時間為 2025 年 6 月 11 日上午 10:32 PST：在 cri en 頁面中將 mcr 從 20.10 更新到 25.0 (1081a625a8)