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 OS 版本相容性。

從 API 和 kubectl 的角度來看，Windows 容器的行為方式與基於 Linux 的容器非常相似。但是，關鍵功能上存在一些顯著差異，本節將概述這些差異。

與 Linux 的比較

關鍵 Kubernetes 元素在 Windows 中的工作方式與在 Linux 中的工作方式相同。本節介紹了幾個關鍵的工作負載抽象以及它們如何映射到 Windows。

• Pod

  Pod 是 Kubernetes 的基本建構組塊——您建立或部署的 Kubernetes 物件模型中最小且最簡單的單元。您可能無法在同一個 Pod 中部署 Windows 和 Linux 容器。Pod 中的所有容器都排程到單個節點上，其中每個節點代表一個特定的平台和架構。Windows 容器支援以下 Pod 功能、屬性和事件

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

  • Pod status 欄位

  • 就緒度、存活度和啟動探針

  • postStart & preStop 容器生命週期掛鉤

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

  • emptyDir 卷

  • 命名管道主機掛載

  • 資源限制

  • OS 欄位

    .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 進入。

• 工作負載資源，包括

  • ReplicaSet
  • 部署
  • StatefulSet
  • DaemonSet
  • 任務
  • CronJob
  • ReplicationController

• 服務 (Services)。請參閱 負載平衡與服務 (Services) 以了解更多詳細資訊。

Pods、工作負載資源和服務 (Services) 是管理 Kubernetes 上 Windows 工作負載的關鍵要素。然而，單靠它們不足以在動態雲原生環境中實現 Windows 工作負載的適當生命週期管理。

• kubectl exec
• Pod 和容器指標
• 水平 Pod 自動擴展
• 資源配額
• 排程器搶佔

kubelet 的命令列選項

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

• --windows-priorityclass 可讓您設定 kubelet 程序的排程優先順序 (請參閱 CPU 資源管理)
• --kube-reserved、--system-reserved 和 --eviction-hard 標誌會更新 NodeAllocatable
• 使用 --enforce-node-allocatable 進行驅逐尚未實作
• 在 Windows 節點上執行時，kubelet 沒有記憶體或 CPU 限制。--kube-reserved 和 --system-reserved 僅從 NodeAllocatable 中扣除，並不保證為工作負載提供的資源。如需更多資訊，請參閱 Windows 節點的資源管理。
• PIDPressure 條件尚未實作
• kubelet 不會採取 OOM 驅逐動作

API 相容性

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

在高階層次上，這些作業系統概念有所不同

• 身分識別 - Linux 使用使用者 ID (UID) 和群組 ID (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。
  • 服務 (Services) 註冊可以接受 SERVICE_CONTROL_STOP 控制代碼的服務控制處理常式函數。

容器結束代碼遵循相同的慣例，其中 0 表示成功，非零表示失敗。特定的錯誤代碼在 Windows 和 Linux 之間可能有所不同。但是，從 Kubernetes 組件 (kubelet、kube-proxy) 傳遞的結束代碼保持不變。

容器規格的欄位相容性

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

• Windows 容器運行時中未實作巨頁，因此不可用。它們需要宣告使用者權限，該權限對於容器是不可配置的。
• 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 身分執行，這是 Windows 上最接近 root 使用者的等效身分。
• securityContext.runAsUser - 請改用 runAsUserName
• securityContext.seLinuxOptions - 在 Windows 上不可行，因為 SELinux 是 Linux 特有的
• terminationMessagePath - 這有一些限制，因為 Windows 不支援映射單個檔案。預設值為 /dev/termination-log，這確實有效，因為預設情況下它在 Windows 上不存在。

Pod 規格的欄位相容性

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

• hostIPC 和 hostpid - 主機命名空間共用在 Windows 上不可行
• hostNetwork - 請參閱下方
• dnsPolicy - 在 Windows 上不支援將 Pod dnsPolicy 設定為 ClusterFirstWithHostNet，因為未提供主機網路。Pod 始終使用容器網路執行。
• podSecurityContext 請參閱下方
• shareProcessNamespace - 這是一個 Beta 功能，並且取決於 Linux 命名空間，而 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 上不支援此功能。

hostNetwork 的欄位相容性

kubelet 現在可以請求在 Windows 節點上執行的 Pod 使用主機的網路命名空間，而不是建立新的 Pod 網路命名空間。若要啟用此功能，請將 --feature-gates=WindowsHostNetwork=true 傳遞給 kubelet。

Pod 安全環境的欄位相容性

Pod securityContext 欄位中，只有 securityContext.runAsNonRoot 和 securityContext.windowsOptions 在 Windows 上有效。

節點問題偵測器

節點問題偵測器 (請參閱監控節點健康狀況) 初步支援 Windows。如需更多資訊，請造訪專案的 GitHub 頁面。

Pause 容器

在 Kubernetes Pod 中，首先建立基礎架構或「pause」容器以託管容器。在 Linux 中，構成 Pod 的 cgroups 和命名空間需要一個程序來維持其持續存在；pause 程序提供了這個功能。屬於同一個 Pod 的容器 (包括基礎架構容器和工作容器) 共用一個通用的網路端點 (相同的 IPv4 和/或 IPv6 位址，相同的網路埠空間)。Kubernetes 使用 pause 容器，以便在工作容器崩潰或重新啟動時不會遺失任何網路設定。

Kubernetes 維護一個包含 Windows 支援的多架構映像檔。對於 Kubernetes v1.32.0，建議的 pause 映像檔是 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

您可以將 ContainerD 1.4.0+ 用作執行 Windows 的 Kubernetes 節點的容器運行時。

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

Mirantis Container Runtime

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

請參閱 在 Windows Server 上安裝 MCR 以取得更多資訊。

Windows 作業系統版本相容性

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

對於 Kubernetes v1.32，Windows 節點 (和 Pod) 的作業系統相容性如下

Windows Server LTSC 版本

Windows Server 2019

Windows Server 2022

Windows Server SAC 版本

Windows Server 版本 20H2

Kubernetes 版本偏差政策也適用。

硬體建議與考量

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

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

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

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

取得協助和疑難排解

您尋求 Kubernetes 叢集疑難排解的主要協助來源應從疑難排解頁面開始。

本節包含一些額外的 Windows 特定疑難排解協助。記錄檔是 Kubernetes 中疑難排解問題的重要元素。每當您向其他貢獻者尋求疑難排解協助時，請務必包含它們。請遵循 SIG Windows 貢獻指南中關於收集記錄檔的說明。

報告問題和功能請求

如果您發現看起來像是錯誤，或者您想要提出功能請求，請遵循 SIG Windows 貢獻指南以建立新 issue。您應首先搜尋 issue 列表，以防之前已報告過該 issue，並在 issue 上評論您的經驗並新增其他記錄檔。Kubernetes Slack 上的 SIG Windows 頻道也是在建立工單之前獲得一些初步支援和疑難排解想法的好途徑。

驗證 Windows 叢集可操作性

Kubernetes 專案提供Windows 運作準備就緒規格，並附帶結構化測試套件。此套件分為兩組測試：核心和擴展，每組都包含旨在測試特定領域的類別。它可用於全面驗證 Windows 和混合系統 (與 Linux 節點混合) 的所有功能。

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

部署工具

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

Kubernetes cluster API 專案也提供自動化部署 Windows 節點的方法。

Windows 發佈管道

如需 Windows 發佈管道的詳細說明，請參閱 Microsoft 文件。

有關不同 Windows Server 服務管道 (包括其支援模型) 的資訊，請參閱 Windows Server 服務管道。