本文旨在視為 AKS 基準架構的延伸模組，其會徹底檢閱建議的設定，以將 AKS 叢集部署至生產環境。 本文的重點在於提供在 AKS 上部署 Windows 容器的相關指引。 因此，本文著重於在 AKS 上部署 Windows 的特定設定，您應該回到 AKS 基準檔，以取得已說明的設定。
請參閱 AKS Windows 基準 GitHub 專案，以檢閱與此參考架構相關聯的參考實作，包括範例部署程式代碼。
網路設計
此架構中使用的網路設計是以 AKS 基準架構中使用的設計為基礎，因此除了下列變更之外，會與該設計共用所有核心元件。
- 已新增 Active Directory 域控制器，以支援以 Windows 為基礎的工作負載。
- 此架構中的輸入解決方案會使用 Azure Front Door （AFD） 和 Microsoft Entra 應用程式 Proxy （AAP），而不是 AKS 基準架構中使用的 Azure 應用程式閘道。
注意
將 Windows 工作負載移轉至 AKS 通常不包含重大重構工作，因此工作負載可能會使用相對容易實作內部部署的功能，但在 Azure 上構成挑戰。 其中一個範例是使用 gMSA 和 Kerberos 驗證的應用程式。 這是常見的使用案例，因此，此架構會提供可解決這些工作負載需求的元件。 具體而言，使用 AFD 前端的 AAP 作為輸入路徑的一部分。 如果您的工作負載不需要此支援，您可以遵循與 AKS 基準相同的指引 進行輸入。
輸入設計
元件：
- 具有 WAF 的 Azure Front Door：AFD 是 AKS 叢集上裝載之應用程式的公開對向輸入點。 AFD 進階版 用於此設計，因為它允許使用 Private Link，以鎖定內部應用程式流量到專用網，以提供最高層級的安全性。 Web 應用程式防火牆 （WAF） 可防範常見的 Web 應用程式惡意探索和弱點。
- Microsoft Entra 應用程式 Proxy：此元件可作為 AKS 所管理之內部負載平衡器前的第二個輸入點。 它已啟用 Microsoft Entra 識別符來預先驗證使用者，並使用 條件式存取原則 來防止未經授權的 IP 範圍（AAP 看到原始用戶端 IP，其與條件式存取原則比較）和使用者無法存取網站。 這是在使用支援 WAF 的 Azure 服務時路由 Kerberos 驗證要求的唯一方式。 如需提供 應用程式 Proxy 受保護應用程式的單一登錄存取權的詳細說明，請參閱使用 應用程式 Proxy 單一登錄的 Kerberos 限制委派
- 內部負載平衡器：由 AKS 管理。 此負載平衡器會透過私人靜態 IP 位址公開輸入控制器。 它可作為接收輸入 HTTP 要求的單一連絡點。
- 此架構中不會使用叢集中輸入控制器（例如 Nginx）。
若要實作此設計，必須將 AFD 設定為使用在該服務中發佈應用程式時所建立的 應用程式 Proxy URL。 此組態會將輸入流量路由傳送至 Proxy，並允許進行預先驗證。
注意
不支援用戶端來源 IP 保留，因此應用程式架構設計人員應該針對相依於來源 IP 位址的應用程式，規劃將叢集外部邏輯外部化的替代量值。
網路拓撲
下圖顯示此架構中使用的中樞輪輻網路設計。
節點集區拓撲
此架構使用三個節點集區：執行 Linux 的系統節點集區、執行 Linux 的使用者節點集區，以及執行 Windows 的使用者節點集區。 Windows 和 Linux 使用者節點集區用於工作負載，而系統節點集區則用於所有系統層級設定，例如 CoreDNS。
輸入流量流程
- 用戶端會將 HTTPS 要求傳送至功能變數名稱：bicycle.contoso.com。 該名稱與 Azure Front Door 公用 IP 位址的 DNS A 記錄相關聯。 此流量會加密，以確保無法檢查或變更用戶端瀏覽器與閘道之間的流量。
- Azure Front Door 具有整合式 Web 應用程式防火牆 （WAF），並交涉 tls 交握以進行 bicycle.contoso.com，只允許安全的加密。 Azure Front Door 閘道是 TLS 終止點，因為需要處理 WAF 檢查規則，並執行路由規則，將流量轉送至設定的後端。 TLS 憑證會儲存在 Azure Key Vault 中。
- AFD 會將使用者要求路由傳送至 Azure 應用程式 Proxy。 AFD 設定為只允許 HTTPS 流量。 如果使用者已啟用預先驗證，則必須使用 Microsoft Entra 識別碼進行驗證。
- 應用程式 Proxy 會透過 AKS 負載平衡器將使用者路由傳送至後端應用程式容器。
注意
您可以在流程中的每個躍點強制執行端對端 TLS 流量，但在決定保護 Pod 對 Pod 流量時，請考慮測量效能、延遲和操作影響。 對於大部分的單一租使用者叢集，使用適當的控制平面 RBAC 和成熟的軟體開發生命週期做法，就足以強制加密至輸入控制器，並使用 Web 應用程式防火牆 來保護後端。 該設定會將工作負載管理和網路效能影響的額外負荷降到最低。 您的工作負載和合規性需求會決定您執行 TLS 終止的位置。
輸出流量流程
AKS 基準文章中找到的所有指引都適用於此處，並針對 Windows 工作負載提供額外的建議：若要利用自動 Windows Server 更新，您不得封鎖 Azure 防火牆 規則集中所需的 FQDN。
注意
針對以Linux和Windows為基礎的工作負載使用不同的節點集區，需要使用 節點選取器 來確保當您部署指定的工作負載時，它會根據工作負載類型部署到適當的節點集區。
IP 位址規劃
不同於具有Linux節點集區的AKS叢集，具有Windows節點集區的AKS叢集需要 Azure CNI。 使用 Azure CNI 可讓 Pod 從 Azure 虛擬網絡 指派 IP 位址。 接著，Pod 可以透過 Azure 虛擬網絡 與任何其他裝置一樣進行通訊。 它可以連線到其他 Pod、使用 ExpressRoute 或 VPN 連線到對等互連網路或內部部署網路，或透過私人連結連線到其他 Azure 服務。
此處適用於規劃 AKS 基準架構文章中提供之 IP 位址的所有 指引 ，並另外建議：請考慮為您的域控制器布建專用子網。 至於 Windows 節點集區，建議您透過個別的子網，以邏輯方式將該集區與其他節點集區隔離。
節點集區升級
升級 Windows 節點的程式與 Azure Kubernetes Service （AKS） 節點映射升級檔中提供的指引不同，但您應該考慮下列排程差異來規劃升級步調。
Microsoft 會針對每月節點提供新的 Windows Server 映射，包括最新的修補程式，而且不會執行任何自動修補或更新。 因此，您必須根據此排程手動或以程序設計方式更新節點。 使用 GitHub Actions 建立依排程執行的 cron 作業，可讓您以程式設計方式排程每月升級。 上述鏈接的檔中提供的指引反映 Linux 節點程式，但您可以更新 YAML 檔案，以設定您的 cron 排程，以每月執行，而不是每兩周執行。 您也需要將 YAML 檔案中的 「runs-on」 參數變更為 「windows-latest」。，以確保您要升級至最新的 Windows Server 映射。
如需其他指引，請參閱有關 背景工作節點修補和更新 的 AKS 操作員指南。
注意
必須先升級叢集，才能執行節點和節點集區升級。 請遵循叢 集升級 指引來執行升級。
計算考量
與 Windows 伺服器型映像相關聯的較大映射大小需要在節點集區中部署適當大小的 OS 磁碟。 針對包括 Windows 在內的所有節點，仍建議使用暫時 OS 磁碟，因此請務必瞭解 規劃部署時必須遵循的大小需求 。
身分識別管理
Windows 容器無法加入網域，因此如果您需要 Active Directory 驗證和授權，您可以使用 群組受控服務帳戶 （gMSA）。 若要使用 gMSA，您必須在執行 Windows 節點的 AKS 叢集上啟用 gMSA 配置檔。 如需 完整檢閱架構和啟用配置檔的指南，請參閱 gMSA AKS 檔 。
節點和 Pod 調整
Windows 容器的叢集自動調整程式指導方針不會變更。 如需指引， 請參閱叢集自動調整程序 檔。
基準叢集文件說明可用於Pod調整的手動和自動調整方法。 這兩種方法都適用於執行 Windows 容器的叢集，以及 該文章中提供的指引 也適用於這裡。
與 Pod 調整作業相關的 Linux 和 Windows 容器之間有何不同之處在於，在大部分情況下，映射的大小。 Windows 容器的較大映射大小可能會增加調整作業完成的時間量，因此應該採取一些調整方法的考慮。 此案例常見於舊版 .NET 應用程式，因為 .NET 運行時間的大小。 為了減輕在縮放期間將映射拉低的延遲，您可以使用 DaemonSet 從 ACR 提取映像，以在每個 Windows 節點上快取，因此在預先載入映射時啟動 Pod。 從這一點開始，Pod 只需要執行針對工作負載定義的應用程式組態程式，才能上線。
應該執行基準檢驗練習，以瞭解執行調整作業的時間影響，而且此數據應根據業務需求來權衡。 如果您的工作負載需要透過自動調整來更快調整規模，建議您考慮下列替代的「熱備援」解決方案：
您必須先進行基準測試，以識別您需要在尖峰負載時間和離峰負載時間執行多少 Pod。 建立此基準之後，您可以規劃您的節點計數，以考慮在任何指定時間都必須有可用的節點總數。 此解決方案牽涉到為您的叢集使用手動調整，並將初始節點數目設定為所需的離峰節點數目。 當您接近尖峰時間週期時，您必須預先調整為尖峰載入時間數目的節點。 隨著時間的流逝，您必須定期重新建立基準，以考慮變更應用程式使用量或其他商務需求。
監視
執行 Windows 的容器可以使用 Azure 監視器和 Container Insights 來監視，就像 Linux 容器一樣。 因此， AKS 基準文章中找到的指導方針 也適用於大部分。 不過，Windows Server 叢集的 Container Insights 監視有下列限制：
- Windows 沒有記憶體 RSS 計量。 因此，不適用於 Windows 節點和容器。 可用的 工作集 計量
- 磁碟儲存體容量資訊不適用於 Windows 節點。
您也可以使用數據收集規則，從 Windows Server 系統收集事件和性能計數器，以補充 Container Insights。
注意
適用於 Windows Server 2022 操作系統的容器深入解析處於公開預覽狀態。
原則管理
AKS 基準文章中找到的所有原則 指引 都適用於 Windows 工作負載。 在 Azure Kubernetes Service 參考文章 Azure 原則 內建定義中找到的其他 Windows 特定原則如下：
- Kubernetes 叢集 Windows 容器不應過度認可 CPU 和記憶體
- Kubernetes 叢集視窗容器不應以容器管理員身分執行
- Kubernetes 叢集 Windows 容器應只使用核准的使用者與網域使用者群組執行
叢集啟動載入
如同 AKS 基準一文中提供的叢集啟動載入 指引 ，叢集操作員也應該考慮其 Windows 型工作負載的啟動載入方法。 AKS 基準文章中提供的相同指引也適用於這裡。
成本管理
AKS 基準文章中找到的所有成本優化 指引 都適用於 Windows 工作負載。 其他應考慮的成本考慮如下：
- Windows Server 的授權成本會增加 AKS 叢集的節點成本。 此因素的成本優化建議包括保留容量，或如果您已經有其他商務用途的授權，請使用現有的授權。
- 請參閱適用於 Windows Server 的 Azure Hybrid Benefit（AHUB） 檔，以了解軟體保證 （SA） 適用的 Windows Server 授權折扣。
- 如需將權益套用至新叢集和現有叢集的指示，請參閱 Windows Server 容器常見問題。
- 由於多個映像所需的記憶體數量、從 ACR 提取的並行節點數目和異地復寫需求，Windows 容器映像的大小可能會產生額外的 Azure Container Registry （ACR） 成本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Isabelle Bersano |雲端解決方案架構師
- Akshay Nimbalkar |主要雲端解決方案架構師
- 克萊頓西門子 |主要內容開發人員
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
- 深入瞭解 Windows 容器
相關資源
- 瞭解如何在 AKS 叢集上部署 Windows 節點集區