本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
介紹 Windows 操作就緒性規範
自 2019 年 Kubernetes 1.14 將 Windows 支援升級為穩定版以來，執行 Windows 工作負載的能力備受終端使用者社群的讚賞。Windows 工作負載支援的水平和可用性一直是大型企業使用的 Kubernetes 發行版的一個主要差異化因素。然而，隨著越來越多的 Windows 工作負載被遷移到 Kubernetes，以及新的 Windows 功能不斷髮布，以有效和標準化的方式測試 Windows 工作節點變得具有挑戰性。
Kubernetes 專案重視在不要求認證的發行版或服務使用閉源許可證的情況下進行一致性認證的能力，該發行版或服務無意提供 Windows 支援。
SIG Windows 注意到的一些顯著示例包括：
- 負載均衡器源地址範圍功能在 Windows 節點上無法正常執行的問題，詳見 GitHub issue：kubernetes/kubernetes#120033。
- Windows 功能出現問題的報告，例如 “GMSA 無法與 containerd 配合使用”，相關討論見 microsoft/Windows-Containers#44。
- 在開發能夠客觀評估不同作業系統配置下容器網路介面（CNI）外掛的網路策略測試時面臨的挑戰，相關討論見 kubernetes/kubernetes#97751。
因此，SIG Windows 認識到需要一個量身定製的解決方案，以確保 Windows 節點在部署到生產環境*之前*的運維就緒性。於是，開發 Windows Operational Readiness Specification（Windows 運維就緒性規範）的想法應運而生。
我們不能直接執行官方的一致性測試嗎？
Kubernetes 專案包含一組一致性測試，這些是旨在確保 Kubernetes 叢集滿足所需 Kubernetes 規範的標準化測試。
然而，這些測試最初定義時，Linux 是與 Kubernetes 相容的*唯一*作業系統，因此它們不容易擴充套件到與 Windows 一起使用。鑑於 Windows 工作負載儘管很重要，但在 Kubernetes 社群中只佔一小部分，因此確保許多 Kubernetes 發行版用來認證 Linux 一致性的主要一致性套件，不會被 GMSA 或多作業系統 kube-proxy 行為等 Windows 特定功能或增強功能所拖累，這一點非常重要。
因此，由於對 Windows 一致性測試有特殊需求，SIG Windows 決定透過 Windows Operational Readiness Specification 提供 Windows 特定的一致性測試。
我們不能直接執行 Kubernetes 端到端測試套件嗎？
在 Linux 世界中，像 Sonobuoy 這樣的工具簡化了一致性套件的執行，使使用者無需瞭解 Kubernetes 的編譯路徑或 Ginkgo 標籤的語義。
關於需要編譯 Kubernetes 測試的問題，我們意識到 Windows 使用者可能同樣會覺得從頭開始編譯和執行 Kubernetes e2e 套件的過程不便，因此，明確需要提供一個使用者友好、“一鍵式”的即用型解決方案。此外，關於 Ginkgo 標籤，透過一組 Ginkgo 標籤將一致性測試應用於 Windows 節點，對任何使用者，包括 Linux 愛好者或經驗豐富的 Windows 系統管理員來說，都會是一種負擔。
為了彌補這一差距，併為使用者提供一種直接的方式來確認他們的叢集支援各種功能，Kubernetes SIG Windows 發現有必要建立 Windows Operational Readiness 應用程式。這個用 Go 語言編寫的應用程式，簡化了執行必要的 Windows 特定測試的過程，同時以清晰、易於理解的格式提供結果。
這項計劃是一項協作努力，得到了不同雲提供商和平臺的貢獻，包括 Amazon、Microsoft、SUSE 和 Broadcom。
深入瞭解 Windows Operational Readiness Specification
Windows Operational Readiness Specification 專門針對並執行 Kubernetes 倉庫中的測試，其方式比簡單地針對 Ginkgo 標籤更使用者友好。它引入了一個結構化的測試套件，分為核心測試和擴充套件測試兩組，每組測試都包含針對特定測試領域（如網路）的類別。核心測試針對 Windows 節點應支援的基本和關鍵功能，這些功能由 Kubernetes 規範定義。另一方面，擴充套件測試涵蓋更復雜的功能，更側重於深入探討 Windows 特定的能力，例如與 Active Directory 的整合。這些測試的目標是全面覆蓋廣泛的 Windows 特定能力，以確保與各種工作負載和配置的相容性，超越基本要求。以下是當前的類別列表。
| 類別名稱 | 類別描述 |
|---|---|
Core.Network | 測試最基本的網路功能（能夠透過 Pod IP 訪問 Pod）。 |
Core.Storage | 測試最基本的儲存功能（能夠掛載 hostPath 儲存卷）。 |
Core.Scheduling | 測試最基本的排程功能（能夠排程一個帶有 CPU 限制的 Pod）。 |
Core.Concurrent | 測試最基本的併發功能（節點能夠同時處理到多個 Pod 的流量）。 |
Extend.HostProcess | 測試與 Windows HostProcess Pod 功能相關的特性。 |
Extend.ActiveDirectory | 測試與 Active Directory 功能相關的特性。 |
Extend.NetworkPolicy | 測試與網路策略功能相關的特性。 |
Extend.Network | 測試高階網路功能（支援 IPv6 的能力）。 |
Extend.Worker | 測試與 Windows 工作節點功能相關的特性（節點能夠訪問同一叢集中的 TCP 和 UDP 服務）。 |
如何為 Windows 節點進行運維就緒性測試
要執行 Windows Operational Readiness 測試套件，請參閱該測試套件的 README，其中解釋瞭如何設定和執行它。該測試套件在執行測試方面提供了靈活性，您可以使用已編譯的二進位制檔案或 Sonobuoy 外掛。您還可以選擇針對整個測試套件執行測試，或透過指定類別列表來執行。雲提供商可以選擇上傳其一致性結果，以增強透明度和可靠性。
檢出該程式碼後，您就可以執行測試。例如，以下示例命令執行來自 Core.Concurrent 類的測試。
./op-readiness --kubeconfig $KUBE_CONFIG --category Core.Concurrent
作為 Kubernetes 的貢獻者，如果您想使用 Windows Operational Readiness Specification 針對特定的拉取請求測試您的更改，請在新的拉取請求中使用以下機器人命令。
/test operational-tests-capz-windows-2019
展望未來
我們希望透過向 Kubernetes 倉庫新增新測試並識別可以作為目標測試用例的現有測試，來改進我們精選的 Windows 特定測試列表。該規範的長期目標是不斷增強 Windows 工作節點的測試覆蓋範圍，並提高 Windows 支援的穩健性，從而促進在不同雲環境中的無縫體驗。我們還計劃將 Windows Operational Readiness 測試整合到官方的 Kubernetes 一致性套件中。
如果您有興趣幫助我們，請聯絡我們！我們歡迎任何形式的幫助，從一次性反饋到程式碼貢獻，再到長期所有者幫助我們推動變革。Windows Operational Readiness Specification 由 SIG Windows 團隊負責。您可以在 Kubernetes Slack 工作區的 #sig-windows 頻道上與該團隊聯絡。您也可以瀏覽 Windows Operational Readiness 測試套件，並直接向 GitHub 倉庫做出貢獻。
特別感謝 Kulwant Singh (AWS)、Pramita Gautam Rana (VMWare)、Xinqi Li (Google) 和 Marcio Morales (AWS) 為該規範做出的卓越貢獻。此外，還要感謝 SIG Windows 團隊的 James Sturtevant (Microsoft)、Mark Rossetti (Microsoft)、Claudiu Belu (Cloudbase Solutions) 和 Aravindh Puthiyaparambil (Softdrive Technologies Group Inc.) 的指導和支援。