本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Windows 的最佳實務
本指南提供有關執行 Windows 容器和節點的建議。
**Topics**
+ [Amazon EKS 最佳化 Windows AMI 管理](windows-ami.md)
+ [為 Windows Pod 和容器設定 gMSA](windows-gmsa.md)
+ [Windows 工作者節點強化](windows-hardening.md)
+ [容器映像掃描](windows-images.md)
+ [Windows Server 版本和授權](windows-licensing.md)
+ [日誌](windows-logging.md)
+ [監控](windows-monitoring.md)
+ [Windows 網路](windows-networking.md)
+ [避免 OOM 錯誤](windows-oom.md)
+ [修補 Windows 伺服器和容器](windows-patching.md)
+ [執行異質工作負載](windows-scheduling.md)
+ [Pod 安全內容](windows-security.md)
+ [持久性儲存選項](windows-storage.md)
+ [強化 Windows 容器映像](windows-hardening-containers-images.md)
# Amazon EKS 最佳化 Windows AMI 管理
Amazon EKS 最佳化 AMI 是根據 Windows Server 2019 和 Windows Server 2022 所建置。這些 AMI 已設定為 Amazon EKS 節點的基礎映像。預設情況下，AMI 會包括以下組件：
+ [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)
+ [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
+ [適用於 Kubernetes 的 AWS IAM Authenticator ](https://github.com/kubernetes-sigs/aws-iam-authenticator)
+ [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)
+ [containerd](https://containerd.io/)
您可以查詢 AWS Systems Manager 參數存放區 API，以程式設計方式擷取 Amazon EKS 最佳化 AMIs 的 Amazon Machine Image (AMI) ID。此參數讓您無需手動查詢 Amazon EKS 最佳化 AMI ID。如需 Systems Manager 參數存放區 API 的詳細資訊，請參閱 [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html)。您的使用者帳戶必須具有 ssm：GetParameter IAM 許可，才能擷取 Amazon EKS 最佳化 AMI 中繼資料。
下列範例會擷取適用於 Windows Server 2019 LTSC Core 的最新 Amazon EKS 最佳化 AMI 的 AMI ID。AMI 名稱中列出的版本編號與其準備使用的對應 Kubernetes 組建相關。
```
aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-EKS_Optimized-1.21/image_id --region us-east-1 --query "Parameter.Value" --output text
```
輸出範例：
```
ami-09770b3eec4552d4e
```
## 管理您自己的 Amazon EKS 最佳化 Windows AMI
生產環境的重要步驟是在整個 Amazon EKS 叢集中維護相同的 Amazon EKS 最佳化 Windows AMI 和 kubelet 版本。
在 Amazon EKS 叢集中使用相同版本可減少故障診斷期間的時間，並提高叢集一致性。[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) 可協助建立和維護要在 Amazon EKS 叢集中使用的自訂 Amazon EKS 最佳化 Windows AMIs。
使用 Amazon EC2 Image Builder 在 Windows Server 版本、AWS Windows Server AMI 發行日期和/或作業系統建置版本之間進行選取。建置元件步驟可讓您在現有的 EKS Optimized Windows Artifacts 和 kubelet 版本之間進行選取。如需詳細資訊：https：//https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html
![\[建置元件\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/build-components.png)
**注意：**選取基礎映像之前，請參閱 [Windows Server 版本和授權](windows-licensing.md)一節，以取得有關發行頻道更新的重要詳細資訊。
## 為自訂 EKS 最佳化 AMIs 設定更快速的啟動
使用自訂 Windows Amazon EKS 最佳化 AMI 時，透過啟用快速啟動功能，Windows 工作者節點的啟動速度最多可加快 65%。此功能會維護一組預先佈建的快照，這些快照具有 *Sysprep 專業*、*Windows Out of Box Experience (OOBE)* 步驟，以及已完成的必要重新啟動。然後，這些快照會用於後續的啟動，以減少擴展或取代節點的時間。只有您透過 EC2 主控台或 AWS CLI *擁有*的 AMIs 才能啟用快速啟動，且可設定維護的快照數量。
**注意：**快速啟動與預設 Amazon 提供的 EKS 最佳化 AMI 不相容，請先如上述建立自訂 AMI，然後再嘗試啟用它。
如需詳細資訊：[AWS Windows AMIs- 設定您的 AMI 以加快啟動](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-ami-version-history.html#win-ami-config-fast-launch)速度
## 在自訂 AMIs上快取 Windows 基本層
Windows 容器映像大於其 Linux 對應映像。如果您執行任何容器化 .NET Framework 型應用程式，平均映像大小約為 8.24GB。在 Pod 排程期間，容器映像必須完全提取並擷取在磁碟中，Pod 才會達到執行中狀態。
在此過程中，容器執行時間 （容器） 會在磁碟中提取和擷取整個容器映像。提取操作是平行程序，表示容器執行時間會平行提取容器映像層。相反地，擷取操作會在循序程序中發生，而且是 I/O 密集型操作。因此，容器映像可能需要超過 8 分鐘才能完全解壓縮，並準備好供容器執行時間 （容器） 使用，因此，Pod 啟動時間可能需要幾分鐘。
如**修補 Windows Server 和容器**主題所述，您可以選擇使用 EKS 建置自訂 AMI。在 AMI 準備期間，您可以新增額外的 EC2 映像建置器元件，以在本機提取所有必要的 Windows 容器映像，然後產生 AMI。此策略將大幅減少 Pod 達到**執行**中狀態的時間。
在 Amazon EC2 Image Builder 上，建立[元件](https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html)以下載必要的映像，並將其連接至映像配方。下列範例會從 ECR 儲存庫提取特定映像。
```
name: ContainerdPull
description: This component pulls the necessary containers images for a cache strategy.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: containerdpull
action: ExecutePowerShell
inputs:
commands:
- Set-ExecutionPolicy Unrestricted -Force
- (Get-ECRLoginCommand).Password | docker login --username AWS --password-stdin 111000111000.dkr.ecr.us-east-1.amazonaws.com
- ctr image pull mcr.microsoft.com/dotnet/framework/aspnet:latest
- ctr image pull 111000111000.dkr.ecr.us-east-1.amazonaws.com/myappcontainerimage:latest
```
為了確保下列元件如預期運作，請檢查 EC2 Image Builder (EC2InstanceProfileForImageBuilder) 所使用的 IAM 角色是否具有連接的政策：
![\[許可政策\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/permissions-policies.png)
## 部落格文章
在下列部落格文章中，您將逐步了解如何實作自訂 Amazon EKS Windows AMIs 的快取策略：
[使用 EC2 映像建置器和映像快取策略加速 Windows 容器啟動時間](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)
# 為 Windows Pod 和容器設定 gMSA
## 什麼是 gMSA 帳戶
.NET 應用程式等 Windows 型應用程式通常會使用 Active Directory 做為身分提供者，使用 NTLM 或 Kerberos 通訊協定提供授權/身分驗證。
與 Active Directory 交換 Kerberos 票證的應用程式伺服器需要加入網域。Windows 容器不支援網域聯結，而且由於容器是暫時性資源，對 Active Directory RID 集區造成負擔，因此沒有什麼意義。
不過，管理員可以利用 [gMSA Active Directory](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) 帳戶來交涉 Windows 容器、NLB 和伺服器陣列等資源的 Windows 身分驗證。
## Windows 容器和 gMSA 使用案例
利用 Windows 身分驗證並以 Windows 容器的形式執行的應用程式受益於 gMSA，因為 Windows 節點用於代表容器交換 Kerberos 票證。有兩個選項可用於設定 Windows 工作者節點以支援 gMSA 整合：
在此設定中，Windows 工作者節點在 Active Directory 網域中加入網域，Windows 工作者節點的 AD 電腦帳戶用於對 Active Directory 進行身分驗證，並擷取要與 Pod 搭配使用的 gMSA 身分。
在加入網域的方法中，您可以使用現有的 Active Directory GPOs 輕鬆管理和強化 Windows 工作者節點；不過，在加入 Kubernetes 叢集的 Windows 工作者節點期間會產生額外的操作額外負荷和延遲，因為它需要在節點啟動期間進行額外的重新啟動，並在 Kubernetes 叢集終止節點後進行 Active Directory 車庫清理。
在下列部落格文章中，您將找到如何實作加入網域的 Windows 工作者節點方法的詳細step-by-step說明：
[Amazon EKS Windows Pod 上的 Windows 身分驗證](https://aws.amazon.com/blogs/containers/windows-authentication-on-amazon-eks-windows-pods/)
在此設定中，Windows 工作者節點不會加入 Active Directory 網域，而且會使用「可攜式」身分 （使用者/密碼） 對 Active Directory 進行身分驗證，並擷取要與 Pod 搭配使用的 gMSA 身分。
![\[無網域 gmsa\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/domainless_gmsa.png)
可攜式身分是 Active Directory 使用者；身分 （使用者/密碼） 存放在 AWS Secrets Manager 或 AWS System Manager 參數存放區中，而稱為 ccg\$1plugin 的 AWS 開發外掛程式將用於從 AWS Secrets Manager 或 AWS System Manager 參數存放區擷取此身分，並將其傳遞至容器化以擷取 gMSA 身分，並將其提供給 Pod。
在此無網域方法中，您可以在使用 gMSA 時，在 Windows 工作者節點啟動期間不進行任何 Active Directory 互動，並降低 Active Directory 管理員的操作開銷。
在下列部落格文章中，您將找到如何實作無網域 Windows 工作者節點方法的詳細step-by-step說明：
[Amazon EKS Windows Pod 的無網域 Windows 身分驗證](https://aws.amazon.com/blogs/containers/domainless-windows-authentication-for-amazon-eks-windows-pods/)
雖然 Pod 能夠使用 gMSA 帳戶，但也必須相應地設定應用程式或服務以支援 Windows 身分驗證，例如，若要設定 Microsoft IIS 以支援 Windows 身分驗證，您應該透過 dockerfile 進行準備：
```
RUN Install-WindowsFeature -Name Web-Windows-Auth -IncludeAllSubFeature
RUN Import-Module WebAdministration; Set-ItemProperty 'IIS:\AppPools\SiteName' -name processModel.identityType -value 2
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/anonymousAuthentication' -Name Enabled -Value False -PSPath 'IIS:\' -Location 'SiteName'
RUN Import-Module WebAdministration; Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name Enabled -Value True -PSPath 'IIS:\' -Location 'SiteName'
```
# Windows 工作者節點強化
作業系統強化是作業系統組態、修補和移除不必要軟體套件的組合，旨在鎖定系統並減少攻擊面。最佳實務是使用貴公司所需的強化組態來準備您自己的 EKS Optimized Windows AMI。
AWS 每月提供新的 EKS 最佳化 Windows AMI，其中包含最新的 Windows Server 安全修補程式。不過，無論使用者是使用自我管理還是受管節點群組，使用者仍有責任透過套用必要的作業系統組態來強化其 AMI。
Microsoft 提供各種工具，例如 [Microsoft 安全合規工具組](https://www.microsoft.com/en-us/download/details.aspx?id=55319)和[安全基準](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-baselines)，可協助您根據您的安全政策需求實現強化。[CIS 基準](https://learn.cisecurity.org/benchmarks)也可供使用，並且應該在生產環境的 Amazon EKS Optimized Windows AMI 上實作。
## 使用 Windows Server Core 減少攻擊面
Windows Server Core 是最小的安裝選項，可作為 [EKS Optimized Windows AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) 的一部分使用。部署 Windows Server Core 有幾個優點。首先，其磁碟佔用空間相對較小，在具有桌面體驗的 Windows Server 上，在 Server Core 上為 6GB，在 Windows Server 上為 10GB。其次，它具有較小的攻擊面，因為它的程式碼基礎和可用的 APIs 較小。
AWS 每月為客戶提供新的 Amazon EKS Optimized Windows AMIs，包含最新的 Microsoft 安全性修補程式，無論 Amazon EKS 支援的版本為何。根據最佳實務，Windows 工作者節點必須取代為以最新 Amazon EKS 最佳化 AMI 為基礎的新節點。任何執行超過 45 天的節點，如果沒有更新或節點替換，則缺少安全最佳實務。
## 避免 RDP 連線
遠端桌面通訊協定 (RDP) 是由 Microsoft 開發的連線通訊協定，可提供使用者圖形界面，以透過網路連線至其他 Windows 電腦。
根據最佳實務，您應該將 Windows 工作者節點視為暫時性主機。這表示沒有管理連線、沒有更新，也沒有故障診斷。任何修改和更新都應實作為新的自訂 AMI，並以更新 Auto Scaling 群組取代。請參閱**修補 Windows 伺服器和容器**，以及 **Amazon EKS 最佳化 Windows AMI 管理**。
在部署期間，透過在 ssh 屬性上傳遞 **false** 值來停用 Windows 節點上的 RDP 連線，如以下範例所示：
```
nodeGroups:
- name: windows-ng
instanceType: c5.xlarge
minSize: 1
volumeSize: 50
amiFamily: WindowsServer2019CoreContainer
ssh:
allow: false
```
如果需要存取 Windows 節點，請使用 [AWS System Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 透過 AWS 主控台和 SSM 代理程式建立安全的 PowerShell 工作階段。若要了解如何實作解決方案，[請使用 AWS Systems Manager Session Manager 監看安全存取 Windows 執行個體](https://www.youtube.com/watch?v=nt6NTWQ-h6o)
若要使用 System Manager Session Manager，必須將額外的 IAM 政策套用至用來啟動 Windows 工作者節點的 IAM 角色。以下是`eksctl`叢集資訊清單中指定 **AmazonSSMManagedInstanceCore** 的範例：
```
nodeGroups:
- name: windows-ng
instanceType: c5.xlarge
minSize: 1
volumeSize: 50
amiFamily: WindowsServer2019CoreContainer
ssh:
allow: false
iam:
attachPolicyARNs:
- arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
- arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
- arn:aws:iam::aws:policy/ElasticLoadBalancingFullAccess
- arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
## Amazon Inspector
[Amazon Inspector](https://aws.amazon.com/inspector/) 是一種自動化安全評估服務，可協助改善部署在 AWS 上應用程式的安全性和合規性。Amazon Inspector 會自動評估應用程式是否有暴露、漏洞和與最佳實務的偏差。執行評估後，Amazon Inspector 會依據嚴重性層級，產生詳細的安全調查結果清單。這些調查結果可以直接檢閱，也可以作為詳細評估報告的一部分，這些報告可透過 Amazon Inspector 主控台或 API 取得。
Amazon Inspector 可用於在 Windows 工作者節點上執行 CIS Benchmark 評估，並且可以透過執行下列任務將其安裝在 Windows Server Core 上：
1. 下載下列 .exe 檔案：https：//https://inspector-agent.amazonaws.com/windows/installer/latest/AWSAgentInstall.exe
1. 將代理程式轉移到 Windows 工作者節點。
1. 在 PowerShell 上執行下列命令來安裝 Amazon Inspector Agent： `.\AWSAgentInstall.exe /install`
以下是第一次執行後的輸出。如您所見，它會根據 [CVE](https://cve.mitre.org/) 資料庫產生調查結果。您可以使用它來強化工作者節點，或根據強化的組態建立 AMI。
![\[檢測器代理程式\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/inspector-agent.png)
如需 Amazon Inspector 的詳細資訊，包括如何安裝 Amazon Inspector 代理程式、設定 CIS 基準評估和產生報告，請觀看[透過 Amazon Inspector 影片改善 Windows 工作負載的安全性和合規性](https://www.youtube.com/watch?v=nIcwiJ85EKU)。
## Amazon GuardDuty
[Amazon GuardDuty](https://aws.amazon.com/guardduty/) 是一種威脅偵測服務，可持續監控惡意活動和未經授權的行為，以保護存放在 Amazon S3 中的 AWS 帳戶、工作負載和資料。雲端可簡化帳戶和網路活動的收集和彙總，但安全團隊可能需要花費一些時間來持續分析事件日誌資料，以找出潛在的威脅。
透過使用 Amazon GuardDuty，您對 Windows 工作者節點的惡意動作具有可見性，例如 RDP 暴力破解和 Port Probe 攻擊。
[使用 Amazon GuardDuty 影片觀看 Windows 工作負載的威脅偵測](https://www.youtube.com/watch?v=ozEML585apQ)，了解如何在最佳化 EKS Windows AMI 上實作和執行 CIS 基準
## Amazon EC2 for Windows 中的安全性
閱讀 [Amazon EC2 Windows 執行個體的安全最佳實務](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security.html)，在每一層實作安全控制。
# 容器映像掃描
映像掃描是一種自動化漏洞評估功能，可透過掃描各種作業系統漏洞，協助改善應用程式容器映像的安全性。
目前，Amazon Elastic Container Registry (ECR) 只能掃描 Linux 容器映像是否有漏洞。不過，有第三方工具可以與現有適用於 Windows 容器映像掃描的 CI/CD 管道整合。
+ [Anchore](https://anchore.com/blog/scanning-windows-container-images/)
+ [PaloAlto Prisma 雲端](https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/vulnerability_management/windows_image_scanning.html)
+ [Trend Micro - Deep Security Smart Check](https://www.trendmicro.com/en_us/business/products/hybrid-cloud/smart-check-image-scanning.html)
若要進一步了解如何將這些解決方案與 Amazon Elastic Container Repository (ECR) 整合，請檢查：
+ [Anchore，在 Amazon Elastic Container Registry (ECR) 上掃描映像](https://anchore.com/blog/scanning-images-on-amazon-elastic-container-registry/)
+ [PaloAlto，在 Amazon Elastic Container Registry (ECR) 上掃描映像](https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/vulnerability_management/registry_scanning0/scan_ecr.html)
+ [TrendMicro，在 Amazon Elastic Container Registry (ECR) 上掃描映像](https://cloudone.trendmicro.com/docs/container-security/sc-about/)
# Windows Server 版本和授權
## Windows Server 版本
Amazon EKS Optimized Windows AMI 是以長期服務管道 (LTSC) 上的 Windows Server 2019 和 2022 Datacenter 版本為基礎。Datacenter 版本對工作者節點上執行的容器數量沒有限制。如需詳細資訊：https：//https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/faq
### 長期服務管道 (LTSC)
先前稱為「長期服務分支」，這是您已熟悉的發行模型，其中每 2-3 年會發行新的 Windows Server 主要版本。使用者有權獲得 5 年的主流支援和 5 年延長支援。
## 授權
使用 Windows Server 型 AMI 啟動 Amazon EC2 執行個體時，Amazon 會為您支付授權成本和授權合規。
# 日誌
容器化應用程式通常會將應用程式日誌導向 STDOUT。容器執行期會捕捉這些日誌，並對其執行一些操作 - 通常寫入檔案。這些檔案的儲存位置取決於容器執行時間和組態。
Windows Pod 的一個基本差異是它們不會產生 STDOUT。您可以執行 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)，從執行 Windows 容器和管道格式化日誌輸出擷取 ETW （適用於 Windows 的事件追蹤）、Windows 事件日誌和其他應用程式特定日誌到 STDOUT。然後，您可以使用 fluent-bit 或 fluentd 將這些日誌串流到所需的目的地，例如 Amazon CloudWatch。
日誌收集機制會從 Kubernetes Pod 擷取 STDOUT/STDERR 日誌。[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 是從容器收集日誌的常見方式。它可讓您獨立於應用程式管理日誌routing/filtering/enrichment。Fluentd DaemonSet 可用來將這些日誌和任何其他應用程式產生的日誌串流到所需的日誌彙總器。
此處說明從 Windows 工作負載到 CloudWatch 的日誌串流詳細資訊 [https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/](https://aws.amazon.com/blogs/containers/streaming-logs-from-amazon-eks-windows-pods-to-amazon-cloudwatch-logs-using-fluentd/)
## 記錄建議
在 Kubernetes 中操作 Windows 工作負載時，一般記錄最佳實務並無不同。
+ 一律記錄**結構化日誌項目** (JSON/SYSLOG)，讓處理日誌項目變得更輕鬆，因為這類結構化格式有許多預先編寫的剖析器。
+ **集中日誌** - 專用日誌容器可用於收集日誌訊息，並將日誌訊息從所有容器轉送至目的地
+ 保持**日誌詳細程度**，除除除除除偵錯之外。Verbosity 會對日誌記錄基礎設施造成許多壓力，而且在噪音中可能會遺失重大事件。
+ 一律記錄**應用程式資訊**以及**交易/請求 ID **以供追蹤。Kubernetes 物件不會攜帶應用程式名稱，因此例如，偵錯日誌時，Pod 名稱`windows-twryrqyw`可能沒有任何意義。這有助於使用彙總日誌對應用程式進行可追蹤性和故障診斷。
如何產生這些交易/關聯 ID 的方式取決於程式設計建構。但是，非常常見的模式是使用記錄 Aspect/攔截器，它可以使用 [MDC](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html) （映射診斷內容） 將唯一的交易/關聯 ID 注入到每個傳入的請求，如下所示：
```
import org.slf4j.MDC;
import java.util.UUID;
Class LoggingAspect { //interceptor
@Before(value = "execution(* *.*(..))")
func before(...) {
transactionId = generateTransactionId();
MDC.put(CORRELATION_ID, transactionId);
}
func generateTransactionId() {
return UUID.randomUUID().toString();
}
}
```
# 監控
Prometheus，一個[漸進式 CNCF 專案](https://www.cncf.io/projects/)是到目前為止最熱門的監控系統，具有與 Kubernetes 的原生整合。Prometheus 會收集容器、Pod、節點和叢集的相關指標。此外，Prometheus 利用 AlertsManager，可讓您編寫警示程式，在叢集發生錯誤時警告您。Prometheus 會將指標資料儲存為由指標名稱和索引鍵/值對識別的時間序列資料。Prometheus 包括離開使用稱為 PromQL 的語言進行查詢，Prometheus 查詢語言很短。
Prometheus 指標集合的高階架構如下所示：
![\[Prometheus 指標集合\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/prom.png)
Prometheus 使用提取機制，並使用匯出工具從目標抓取指標，並使用 [kube 狀態指標從 Kubernetes API 抓取指標](https://github.com/kubernetes/kube-state-metrics)。這表示應用程式和服務必須公開包含 Prometheus 格式指標的 HTTP(S) 端點。然後，Prometheus 會根據其組態，定期從這些 HTTP(S) 端點提取指標。
匯出工具可讓您使用第三方指標做為 Prometheus 格式指標。Prometheus 匯出工具通常部署在每個節點上。如需匯出者的完整清單，請參閱 Prometheus [匯出者](https://prometheus.io/docs/instrumenting/exporters/)。雖然[節點匯出器](https://github.com/prometheus/node_exporter)適用於匯出 Linux 節點的主機硬體和作業系統指標，但不適用於 Windows 節點。
當您使用穩定的 [Prometheus Helm Chart](https://github.com/prometheus-community/helm-charts) 時，在**具有 Windows 節點的混合節點 EKS 叢集**中，您會在 Windows 節點上看到失敗的 Pod，因為此匯出工具不適用於 Windows。您需要分開處理 Windows 工作者集區，而是在 [Windows 工作者節點群組上安裝 Windows 匯出工具](https://github.com/prometheus-community/windows_exporter)。
若要設定 Windows 節點的 Prometheus 監控，您需要在 Windows 伺服器本身下載並安裝 WMI 匯出工具，然後在 Prometheus 組態檔案的湊集組態內設定目標。[版本頁面](https://github.com/prometheus-community/windows_exporter/releases)提供所有可用的 .msi 安裝程式，以及個別的功能集和錯誤修正。安裝程式會將 windows\$1exporter 設定為 Windows 服務，並在 Windows 防火牆中建立例外狀況。如果在沒有任何參數的情況下執行安裝程式，匯出程式將以已啟用收集器、連接埠等的預設設定執行。
您可以查看本指南的**排程最佳實務**章節，其中建議使用污點/容錯或 RuntimeClass 來選擇性地將節點匯出器僅部署到 linux 節點，而 Windows 匯出器在您引導節點或使用您選擇的組態管理工具 （例如 Chef、Ansible、SSM 等） 時安裝在 Windows 節點上。
請注意，與節點匯出器安裝為協助程式集 的 linux 節點不同，在 Windows 節點上，WMI 匯出器會安裝在主機本身。匯出者將匯出指標，例如 CPU 用量、記憶體和磁碟 I/O 用量，也可以用來監控 IIS 網站和應用程式、網路介面和服務。
Windows\$1exporter 預設會公開已啟用收集器的所有指標。這是收集指標以避免錯誤的推薦方法。不過，對於進階使用，Windows\$1exporter 可以傳遞選用的收集器清單來篩選指標。在 Prometheus 組態中的 collect【】 參數可讓您執行此操作。
Windows 的預設安裝步驟包括在引導程序期間使用引數下載和啟動匯出程式做為服務，例如您要篩選的收集器。
```
> Powershell Invoke-WebRequest https://github.com/prometheus-community/windows_exporter/releases/download/v0.13.0/windows_exporter-0.13.0-amd64.msi -OutFile
> msiexec /i ENABLED_COLLECTORS="cpu,cs,logical_disk,net,os,system,container,memory"
```
根據預設，指標可以在連接埠 9182 的 /metrics 端點上抓取。此時，Prometheus 可以透過將下列 scrape\$1config 新增至 Prometheus 組態來取用指標
```
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ['localhost:9090']
...
- job_name: "wmi_exporter"
scrape_interval: 10s
static_configs:
- targets: [':9182', ':9182', ...]
```
使用 重新載入 Prometheus 組態
```
> ps aux | grep prometheus
> kill HUP
```
新增目標的更好建議方式是使用稱為 ServiceMonitor 的自訂資源定義，該定義是做為 [Prometheus 運算子](https://github.com/prometheus-operator/kube-prometheus/releases)的一部分】，為 ServiceMonitor 物件和控制器提供定義，以啟用我們定義的 ServiceMonitors，並自動建置所需的 Prometheus 組態。
ServiceMonitor 會明確指定應如何監控 Kubernetes 服務群組，用來定義您希望從 Kubernetes 內抓取指標的應用程式。在 ServiceMonitor 中，我們指定 Kubernetes 標籤，讓操作員用來識別 Kubernetes 服務，進而識別我們想要監控的 Pod。
為了利用 ServiceMonitor，請為 Windows 節點建立指向特定 Windows 目標的端點物件、無周邊服務和 ServiceMontor。
```
apiVersion: v1
kind: Endpoints
metadata:
labels:
k8s-app: wmiexporter
name: wmiexporter
namespace: kube-system
subsets:
- addresses:
- ip: NODE-ONE-IP
targetRef:
kind: Node
name: NODE-ONE-NAME
- ip: NODE-TWO-IP
targetRef:
kind: Node
name: NODE-TWO-NAME
- ip: NODE-THREE-IP
targetRef:
kind: Node
name: NODE-THREE-NAME
ports:
- name: http-metrics
port: 9182
protocol: TCP
---
apiVersion: v1
kind: Service ##Headless Service
metadata:
labels:
k8s-app: wmiexporter
name: wmiexporter
namespace: kube-system
spec:
clusterIP: None
ports:
- name: http-metrics
port: 9182
protocol: TCP
targetPort: 9182
sessionAffinity: None
type: ClusterIP
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor ##Custom ServiceMonitor Object
metadata:
labels:
k8s-app: wmiexporter
name: wmiexporter
namespace: monitoring
spec:
endpoints:
- interval: 30s
port: http-metrics
jobLabel: k8s-app
namespaceSelector:
matchNames:
- kube-system
selector:
matchLabels:
k8s-app: wmiexporter
```
如需 運算子和 ServiceMonitor 使用方式的詳細資訊，請參閱官方[運算子](https://github.com/prometheus-operator/kube-prometheus)文件。請注意，Prometheus 確實支援使用許多[服務探索選項的動態目標探索](https://prometheus.io/blog/2015/06/01/advanced-service-discovery/)。
# Windows 網路
## Windows 容器聯網概觀
Windows 容器與 Linux 容器基本上不同。Linux 容器使用 Linux 建構，例如命名空間、聯集檔案系統和 cgroup。在 Windows 上，這些建構會從[主機運算服務 (HCS)](https://github.com/microsoft/hcsshim) 所容器化的 中抽象。HCS 充當位於 Windows 上容器實作上方的 API 層。Windows 容器也會利用 Host Network Service (HNS) 來定義節點上的網路拓撲。
![\[Windows 聯網\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/windows-networking.png)
從聯網的角度來看，HCS 和 HNS 可讓 Windows 容器像虛擬機器一樣運作。例如，每個容器都有連接到 Hyper-V 虛擬切換 (vSwitch) 的虛擬網路轉接器 (vNIC)，如上圖所示。
## IP 地址管理
Amazon EKS 中的節點會使用其彈性網路界面 (ENI) 來連線至 AWS VPC 網路。目前，**每個 Windows 工作者節點僅支援單一 ENI**。Windows 節點的 IP 地址管理是由在控制平面中執行的 [VPC 資源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)執行。如需 Windows 節點 IP 地址管理工作流程的詳細資訊，請參閱[此處](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management)。
Windows 工作者節點可支援的 Pod 數量取決於節點的大小和可用的 IPv4 地址數量。您可以計算節點上可用的 IPv4 地址，如下所示：
+ 根據預設，只有次要 IPv4 地址會指派給 ENI。在這種情況下：
```
Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1
```
我們從總數中減去一個，因為一個 IPv4 地址將用作 ENI 的主要地址，因此無法配置給 Pod。
+ 如果叢集已透過啟用[字首委派功能](prefix-mode-win.md)設定為高 Pod 密度，則
```
Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16
```
在這裡，VPC 資源控制器將配置次要 IPv4 地址，`/28 prefixes`因此，可用 IPv4 地址的整體數量將增加 16 次。
使用上述公式，我們可以根據 m5.large 執行個體計算 Windows 工作者節點的 Pod 上限，如下所示：
+ 根據預設，在次要 IP 模式下執行時 -
```
10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses
```
+ 使用 時 `prefix delegation`-
```
(10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses
```
如需執行個體類型可支援多少 IP 地址的詳細資訊，請參閱每個[執行個體類型每個網路界面的 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)。
另一個關鍵考量因素是網路流量的流程。使用 Windows 時，超過 100 個服務的節點會有連接埠耗盡的風險。當出現此條件時，節點會開始擲回錯誤，並顯示下列訊息：
**「政策建立失敗：hcnCreateLoadBalancer 在 Win32 中失敗：指定的連接埠已存在。」**
為了解決此問題，我們利用 Direct Server Return (DSR)。DSR 是非對稱網路負載分佈的實作。換句話說，請求和回應流量會使用不同的網路路徑。此功能可加速 Pod 之間的通訊，並降低連接埠耗盡的風險。因此，我們建議您在 Windows 節點上啟用 DSR。
預設會在 Windows Server SAC EKS 最佳化 AMIs 中啟用 DSR。對於 Windows Server 2019 LTSC EKS 最佳化 AMIs，您將需要使用以下指令碼和使用 Windows Server 2019 Full 或 Core 做為 `eksctl` nodeGroup 中的 amiFamily，在執行個體佈建期間啟用它。如需其他資訊，請參閱 [eksctl 自訂 AMI](https://eksctl.io/usage/custom-ami-support/)。
```
nodeGroups:
- name: windows-ng
instanceType: c5.xlarge
minSize: 1
volumeSize: 50
amiFamily: WindowsServer2019CoreContainer
ssh:
allow: false
```
若要在 Windows Server 2019 及更高版本中使用 DSR，您需要在執行個體啟動期間指定下列 [https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) 旗標。您可以透過調整與[自我管理節點群組啟動範本](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)相關聯的使用者資料指令碼來執行此操作。
```
[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile
& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://" -Base64ClusterCA "" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
```
DSR 啟用可以依照 [Microsoft 網路部落格](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710)和 [AWS Lab 上的 Windows 容器](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters)中的指示進行驗證。
![\[dsr\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/dsr.png)
如果保留可用的 IPv4 地址並盡量減少浪費對您的子網路至關重要，通常建議避免使用字首委派模式，如 [Windows 字首模式中所述 - 何時避免](prefix-mode-win.md#windows-prefix-avoid)。如果仍然需要使用字首委派，您可以採取步驟來最佳化子網路中的 IPv4 地址使用率。如需如何微調 IPv4 地址請求和配置程序的詳細說明，請參閱[設定字首委派的參數](prefix-mode-win.md#windows-network-conserve)。調整這些組態可協助您在保留 IPv4 地址和字首委派的 Pod 密度優勢之間取得平衡。
使用指派次要 IPv4 地址的預設設定時，目前沒有支援的組態可操作 VPC 資源控制器請求和配置 IPv4 地址的方式。更具體地說， `minimum-ip-target`和 `warm-ip-target` 僅支援字首委派模式。另請注意，在次要 IP 模式中，視界面上的可用 IP 地址而定，VPC 資源控制器通常會代表您在節點上配置 3 個未使用的 IPv4 地址，以維持暖 IPs以加快 Pod 啟動時間。如果您想要將未使用的暖 IP 地址 IP 浪費降至最低，您可以瞄準在指定的 Windows 節點上排程更多 Pod，以便盡可能使用 ENI 的 IP 地址容量。更明確地說， IPs 如果節點和執行中的 Pod 已在使用 ENI 上的所有 IP 地址，您可以避免使用暖未使用的 IP。另一個解決方法可協助您解決子網路中 IP 地址可用性的限制，可能是探索[增加子網路大小](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html)，或將您的 Windows 節點分成自己的專用子網路。
此外，請務必注意 Windows 節點目前不支援 IPv6。
## 容器網路界面 (CNI) 選項
AWSVPC CNI 是適用於 Windows 和 Linux 工作者節點的事實 CNI 外掛程式。雖然 AWSVPC CNI 滿足許多客戶的需求，但有時候您可能需要考慮替代方法，例如覆蓋網路，以避免 IP 耗盡。在這些情況下，可以使用 Calico CNI 取代 AWSVPC CNI。[Project Calico](https://www.projectcalico.org/) 是由 [Tigera](https://www.tigera.io/) 開發的開放原始碼軟體。該軟體包含可與 EKS 搭配使用的 CNI。您可以在專案 Calico EKS 安裝頁面上找到在 [EKS 中安裝 Calico CNI ](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks)的說明。
## 網路政策
最佳實務是將 Kubernetes 叢集上 Pod 之間的預設開放通訊模式變更為根據網路政策限制存取。開放原始碼 [Project Calico](https://www.tigera.io/tigera-products/calico/) 對同時使用 Linux 和 Windows 節點的網路政策具有強大的支援。此功能是獨立的，不依賴使用 Calico CNI。因此，我們建議您安裝 Calico 並將其用於網路政策管理。
如需在 EKS 中安裝 Calico 的說明，請參閱在 [Amazon EKS 上安裝 Calico ](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)頁面。
此外，[Amazon EKS 安全最佳實務指南 - 網路區段](https://docs.aws.amazon.com/eks/latest/best-practices/network-security.html)中提供的建議同樣適用於具有 Windows 工作者節點的 EKS 叢集，不過，Windows 目前不支援某些功能，例如「Pod 安全群組」。
# 避免 OOM 錯誤
Windows 沒有與 Linux out-of-memory程序刪除程式。Windows 一律會將所有使用者模式記憶體配置視為虛擬，且 pagefile 是強制性的。淨效果是 Windows 不會像 Linux 那樣脫離記憶體條件。程序將分頁到磁碟，而不是因記憶體不足 (OOM) 而終止。如果記憶體過度佈建且所有實體記憶體都用盡，分頁可能會降低效能。
## 保留系統和 kubelet 記憶體
與 Linux 不同，Linux 會`--kubelet-reserve`**擷取** kubelet、容器執行時間等 kubernetes 系統常駐程式的資源保留，以及`--system-reserve`**擷取** sshd、udev 等作業系統常駐程式的資源保留。在 **Windows** 上，這些標記不會**擷取**和**設定**在節點****上執行的 **kubelet** 或程序的記憶體限制。
不過，您可以結合這些旗標來管理 **NodeAllocatable**，以使用 Pod 資訊清單**記憶體資源限制**來減少節點上的容量，以控制每個 Pod 的記憶體配置。使用此策略，您可以更好地控制記憶體配置，以及將 Windows 節點上的out-of-memory(OOM) 降至最低的機制。
在 Windows 節點上，最佳實務是為作業系統和程序保留至少 2GB 的記憶體。使用 `--kubelet-reserve`和/或 `--system-reserve` 減少 NodeAllocatable。
遵循 [Amazon EKS 自我管理 Windows 節點](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)文件，使用 CloudFormation 範本啟動具有 kubelet 組態自訂功能的新 Windows 節點群組。CloudFormation 有一個名為 的元素`BootstrapArguments`，與 相同`KubeletExtraArgs`。搭配下列旗標和值使用：
```
--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"
```
如果 eksctl 是部署工具，請檢查下列文件以自訂 kubelet 組態 https：//https://eksctl.io/usage/customizing-the-kubelet/
## Windows 容器記憶體需求
根據 [Microsoft 文件](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/system-requirements)，NANO 的 Windows Server 基礎映像至少需要 30MB，而 Server Core 則需要 45MB。這些數字會隨著您新增 Windows 元件而增加，例如 .NET Framework、Web Services as IIS 和應用程式。
您必須了解 Windows 容器映像所需的最低記憶體量，即基礎映像及其應用程式層，並將其設定為 Pod 規格中的容器資源/請求。您也應該設定限制，以避免 Pod 在應用程式發生問題時消耗所有可用的節點記憶體。
在下面的範例中，當 Kubernetes 排程器嘗試在節點上放置 Pod 時，會使用 Pod 的請求來判斷哪個節點有足夠的資源可供排程。
```
spec:
- name: iis
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
resources:
limits:
cpu: 1
memory: 800Mi
requests:
cpu: .1
memory: 128Mi
```
## 結論
使用此方法可將記憶體耗盡的風險降至最低，但無法防止發生這種情況。使用 Amazon CloudWatch 指標，您可以在記憶體耗盡時設定提醒和修復。
# 修補 Windows 伺服器和容器
修補 Windows Server 是 Windows 管理員的標準管理任務。這可以使用 Amazon System Manager - Patch Manager、WSUS、System Center Configuration Manager 等不同工具來完成。不過，Amazon EKS 叢集中的 Windows 節點不應視為一般 Windows 伺服器。它們應被視為不可變伺服器。簡單來說，避免更新現有的節點，只要根據新的更新 AMI 啟動新的節點即可。
使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/)，您可以透過建立配方和新增元件來自動化 AMIs 建置。
下列範例顯示**元件**，這些元件可以是由 AWS (Amazon 受管） 建置的預先存在元件，以及您建立的元件 （由我擁有）。請密切注意稱為 **update-windows** 的 Amazon 受管元件，這會在透過 EC2 Image Builder 管道產生 AMI 之前更新 Windows Server。
![\[相關聯的元件\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/associated-components.png)
EC2 Image Builder 可讓您根據 Amazon Managed Public AMI 建置 AMIs，並自訂它們以符合您的業務需求。然後，您可以將這些 AMIs 與啟動範本建立關聯，以便將新的 AMI 連結至 EKS 節點群組建立的 Auto Scaling 群組。完成後，您可以開始終止現有的 Windows 節點，並根據新的更新 AMI 啟動新的節點。
## 推送和提取 Windows 映像
Amazon 發佈 EKS 最佳化 AMIs，其中包含兩個快取的 Windows 容器映像。
```
mcr.microsoft.com/windows/servercore
mcr.microsoft.com/windows/nanoserver
```
![\[images\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/images.png)
快取映像會在主要作業系統的更新之後更新。當 Microsoft 發行直接影響 Windows 容器基礎映像的新 Windows 更新時，更新將作為主要作業系統上的一般 Windows Update 啟動。讓環境保持在up-to-date可在節點和容器層級提供更安全的環境。
Windows 容器映像的大小會影響推送/提取操作，這可能會導致容器啟動時間變慢。[快取 Windows 容器映像](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)允許在 AMI 建置建立時執行昂貴的 I/O 操作 （檔案擷取），而非容器啟動。因此，AMI 上將擷取所有必要的影像層，並準備好可供使用，以加快 Windows 容器啟動的時間，並可以開始接受流量。在推送操作期間，只會將構成映像的圖層上傳到儲存庫。
下列範例顯示 Amazon ECR 上的 **fluentd-windows-sac2004** 映像只有 **390.18MB**。這是推送操作期間發生的上傳量。
下列範例顯示推送到 Amazon ECR 儲存庫[的流暢 Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) 映像。存放在 ECR 中的 layer 大小為 **533.05MB。**
![\[ecr 映像\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/ecr-image.png)
以下來自 的輸出`docker image ls`，磁碟上 Fluentd v1.14-windows-ltsc2019-1 的大小為 **6.96GB**，但這並不表示它下載並擷取了該數量的資料。
實際上，在提取操作期間，只會下載和擷取**壓縮的 533.05MB。**
```
REPOSITORY TAG IMAGE ID CREATED SIZE
111122223333.dkr.ecr.us-east-1.amazonaws.com/fluentd-windows-coreltsc latest 721afca2c725 7 weeks ago 6.96GB
fluent/fluentd v1.14-windows-ltsc2019-1 721afca2c725 7 weeks ago 6.96GB
amazonaws.com/eks/pause-windows latest 6392f69ae6e7 10 months ago 255MB
```
大小欄顯示影像的整體大小，6.96GB。將其分解：
+ Windows Server Core 2019 LTSC 基礎映像 = 5.74GB
+ Fluentd 未壓縮的基礎映像 = 6.96GB
+ 磁碟差異 = 1.2GB
+ Fluentd [壓縮最終映像 ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) = 533.05MB
本機磁碟上已存在基礎映像，導致磁碟上的總量為額外 1.2GB。下次在大小欄中看到 GBs 的數量時，請不要太擔心，可能超過 70% 的 GB 已經在磁碟上做為快取的容器映像。
## 參考資料
[使用 EC2 映像建置器和映像快取策略加速 Windows 容器啟動時間](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)
# 執行異質工作負載
Kubernetes 支援異質叢集，您可以在相同叢集中混合使用 Linux 和 Windows 節點。在該叢集中，您可以混合使用在 Linux 上執行的 Pod 和在 Windows 上執行的 Pod。您甚至可以在同一個叢集中執行多個版本的 Windows。不過，在做出此決策時，需要考慮幾個因素 （如下所述）。
## 將 PODs 指派給節點最佳實務
為了將 Linux 和 Windows 工作負載保留在其各自的作業系統特定節點上，您需要使用節點選取器和污點/容錯的一些組合。在異質環境中排程工作負載的主要目標是避免中斷現有 Linux 工作負載的相容性。
## 確保作業系統特定的工作負載登陸適當的容器主機
使用者可以確保使用 nodeSelectors 在適當的主機上排程 Windows 容器。目前所有 Kubernetes 節點都有下列預設標籤：
```
kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]
```
如果 Pod 規格不包含如 的 nodeSelector`"kubernetes.io/os": windows`，則可以在任何主機、Windows 或 Linux 上排程 Pod。這可能會有問題，因為 Windows 容器只能在 Windows 上執行，Linux 容器只能在 Linux 上執行。
在企業環境中，針對 Linux 容器擁有大量預先存在的部署，以及 Helm Chart 等off-the-shelf組態的生態系統並不罕見。在這些情況下，您可能會對部署的 nodeSelectors 進行變更感到遲疑。**另一種方法是使用 Taints**。
例如：`--register-with-taints='os=windows:NoSchedule'`
如果您使用的是 EKS，eksctl 提供透過 clusterConfig 套用污點的方法：
```
NodeGroups:
- name: windows-ng
amiFamily: WindowsServer2022FullContainer
...
labels:
nodeclass: windows2022
taints:
os: "windows:NoSchedule"
```
將污點新增至所有 Windows 節點，排程器不會在這些節點上排程 Pod，除非它們能容忍污點。Pod 資訊清單範例：
```
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## 處理相同叢集中的多個 Windows 組建
每個 Pod 使用的 Windows 容器基礎映像必須符合與節點相同的核心建置版本。如果您想要在相同叢集中使用多個 Windows Server 組建，則應設定其他節點標籤、nodeSelectors 或利用稱為 **windows-build** 的標籤。
Kubernetes 1.17 會自動新增標籤 **node.kubernetes.io/windows-build**，以簡化相同叢集中多個 Windows 組建的管理。如果您執行的是較舊的版本，建議您手動將此標籤新增至 Windows 節點。
此標籤反映需要符合相容性的 Windows 主要、次要和建置編號。以下是目前用於每個 Windows Server 版本的值。
請務必注意，Windows Server 正在移至長期服務頻道 (LTSC) 做為主要發行頻道。Windows Server 半年頻道 (SAC) 已於 2022 年 8 月 9 日淘汰。Windows Server 未來不會有 SAC 版本。
| 產品名稱 | 組建編號 (s) |
| --- | --- |
| 伺服器完整 2022 LTSC | 20348 年 10 月 0 日 |
| 伺服器核心 2019 LTSC | 10.0.17763 |
您可以透過下列命令檢查作業系統建置版本：
```
kubectl get nodes -o wide
```
KERNEL-VERSION 輸出符合 Windows 作業系統建置版本。
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-10-2-235.ec2.internal Ready 23m v1.24.7-eks-fb459a0 10.10.2.235 3.236.30.157 Windows Server 2022 Datacenter 10.0.20348.1607 containerd://1.6.6
ip-10-10-31-27.ec2.internal Ready 23m v1.24.7-eks-fb459a0 10.10.31.27 44.204.218.24 Windows Server 2019 Datacenter 10.0.17763.4131 containerd://1.6.6
ip-10-10-7-54.ec2.internal Ready 31m v1.24.11-eks-a59e1f0 10.10.7.54 3.227.8.172 Amazon Linux 2 5.10.173-154.642.amzn2.x86_64 containerd://1.6.19
```
以下範例會將額外的 nodeSelector 套用至 Pod 資訊清單，以便在執行不同的 Windows 節點群組作業系統版本時符合正確的 Windows 建置版本。
```
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## 使用 RuntimeClass 簡化 Pod 資訊清單中的 NodeSelector 和公差
您也可以使用 RuntimeClass 來簡化使用污點和容錯的程序。這可以透過建立用於封裝這些污點和容錯的 RuntimeClass 物件來完成。
透過執行下列資訊清單來建立 RuntimeClass：
```
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: windows-2022
handler: 'docker'
scheduling:
nodeSelector:
kubernetes.io/os: 'windows'
kubernetes.io/arch: 'amd64'
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- effect: NoSchedule
key: os
operator: Equal
value: "windows"
```
建立 Runtimeclass 之後，請使用 做為 Pod 資訊清單上的規格來指派：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: iis-2022
labels:
app: iis-2022
spec:
replicas: 1
template:
metadata:
name: iis-2022
labels:
app: iis-2022
spec:
runtimeClassName: windows-2022
containers:
- name: iis
```
## 受管節點群組支援
為了協助客戶以更簡化的方式執行 Windows 應用程式，AWS 於 2022 年 12 月 15 日啟動對 [Windows 容器的 Amazon EKS 受管節點群組 (MNG) 支援](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/)。為了協助協調營運團隊，[Windows MNGs](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)會使用與 [Linux MNGs](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) 相同的工作流程和工具來啟用。支援 Windows Server 2019 和 2022 的完整和核心 AMI (Amazon Machine Image) 系列版本。
受管節點群組 (MNG) 支援下列 AMI 系列。
| AMI 系列 |
| --- |
| WINDOWS\$1CORE\$12019\$1x86\$164 |
| WINDOWS\$1FULL\$12019\$1x86\$164 |
| WINDOWS\$1CORE\$12022\$1x86\$164 |
| WINDOWS\$1FULL\$12022\$1x86\$164 |
## 其他文件
AWS 官方文件：https：//https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
若要進一步了解 Pod Networking (CNI) 的運作方式，請查看以下連結：https：//https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
部署適用於 Windows on EKS 的受管節點群組的 AWS 部落格：https：//https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/
# Pod 安全內容
**Pod 安全政策 (PSP)** 和 **Pod 安全標準 (PSS)** 是在 Kubernetes 中強制執行安全性的兩種主要方式。請注意，自 PodSecurityPolicy 已棄用，並將在 v1.25 中移除，且 Pod 安全標準 (PSS) 是 Kubernetes 建議的方法，可強制執行安全性。
Pod 安全政策 (PSP) 是 Kubernetes 中實作安全政策的原生解決方案。PSP 是叢集層級的資源，可控制 Pod 規格的安全敏感層面。使用 Pod 安全政策，您可以定義一組 Pod 必須滿足的條件，才能由叢集接受。PSP 功能已從 Kubernetes 的早期開始提供，旨在封鎖在指定叢集上建立設定錯誤的 Pod。
如需 Pod 安全政策的詳細資訊，請參閱 Kubernetes [文件](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)。根據 [Kubernetes 棄用政策](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)，較舊版本將在功能棄用九個月後停止取得支援。
另一方面，Pod 安全標準 (PSS) 是建議的安全性方法，通常使用安全內容實作，在 Pod 資訊清單中定義為 Pod 和容器規格的一部分。PSS 是 Kubernetes 專案團隊為解決 Pod 的安全相關最佳實務而定義的官方標準。它定義了政策，例如基準 （最低限制性、預設性）、特殊權限 （無限制性） 和限制性 （最高限制性）。
我們建議您從基準描述檔開始。PSS 基準描述檔在安全性和潛在摩擦之間提供穩固的平衡，需要最少的例外狀況清單，可作為工作負載安全性的良好起點。如果您目前正在使用 PSPs我們建議您切換到 PSS。如需 PSS 政策的詳細資訊，請參閱 Kubernetes [文件](https://kubernetes.io/docs/concepts/security/pod-security-standards/)。這些政策可以使用多種工具強制執行，包括來自 [OPA](https://www.openpolicyagent.org/) 和 [Kyverno](https://kyverno.io/) 的工具。例如，Kyverno [在此處](https://kyverno.io/policies/pod-security/)提供 PSS 政策的完整集合。
安全內容設定可讓 提供選取程序的權限、使用程式描述檔限制個別程式的功能、允許權限提升、篩選系統呼叫等。
在安全性內容方面，Kubernetes 中的 Windows Pod 與標準 Linux 型工作負載有一些限制和差異。
Windows 使用每個容器的任務物件搭配系統命名空間篩選條件，以包含容器中的所有程序，並提供與主機的邏輯隔離。如果沒有命名空間篩選，就無法執行 Windows 容器。這表示無法在主機的內容中宣告系統權限，因此 Windows 上無法使用特權容器。
以下是唯一記錄`windowsOptions`的 [Windows 安全內容選項](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#windowssecuritycontextoptions-v1-core)，其餘則是一般[安全內容選項](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#securitycontext-v1-core)
如需 Windows 和 linux 支援的安全內容屬性清單，請參閱[此處](https://kubernetes.io/docs/setup/production-environment/windows/_print/#v1-container)的官方文件。
Pod 特定設定會套用至所有容器。如果未指定，則會使用 PodSecurityContext 中的選項。如果同時在 SecurityContext 和 PodSecurityContext 中設定，則 SecurityContext 中指定的值優先。
例如，Pod 和容器的 runAsUserName 設定是 Windows 選項的大約相當於 Linux 特定 runAsUser 設定，並且在下列資訊清單中，Pod 特定安全內容會套用至所有容器
```
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-pod-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
nodeSelector:
kubernetes.io/os: windows
```
但在下列情況下，容器層級安全內容會覆寫 Pod 層級安全內容。
```
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-container-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
..
securityContext:
windowsOptions:
runAsUserName: "ContainerAdministrator"
nodeSelector:
kubernetes.io/os: windows
```
runAsUserName 欄位可接受的值範例：ContainerAdministrator、ContainerUser、NT AUTHORITY\$1NETWORK SERVICE、NT AUTHORITY\$1LOCAL SERVICE
一般而言，最好使用 ContainerUser for Windows Pod 執行容器。容器和主機之間不會共用使用者，但 ContainerAdministrator 在容器中具有 的其他權限。請注意，有使用者名稱[限制](https://kubernetes.io/docs/tasks/configure-pod-container/configure-runasusername/#windows-username-limitations)需要注意。
使用 ContainerAdministrator 的良好範例是設定 PATH。您可以使用 USER 指令來執行此操作，如下所示：
```
USER ContainerAdministrator
RUN setx /M PATH "%PATH%;C:/your/path"
USER ContainerUser
```
另請注意，秘密會在節點磁碟區上以純文字撰寫 （相較於 linux 上的 tmpfs/記憶體內）。這表示您必須執行兩件事
+ 使用檔案 ACLs 保護秘密檔案位置
+ 使用 [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) 使用磁碟區層級加密
# 持久性儲存選項
## 什麼是樹狀內與out-of-tree磁碟區外掛程式？
在推出容器儲存介面 (CSI) 之前，所有磁碟區外掛程式都是在樹狀結構中，這表示它們是建置、連結、編譯和隨附於核心 Kubernetes 二進位檔，並擴展核心 Kubernetes API。這表示將新的儲存系統新增至 Kubernetes （磁碟區外掛程式） 需要檢查核心 Kubernetes 程式碼儲存庫中的程式碼。
Out-of-tree磁碟區外掛程式是獨立於 Kubernetes 程式碼庫開發，並部署 （安裝） 在 Kubernetes 叢集上做為延伸模組。這可讓廠商更新out-of-band驅動程式，即與 Kubernetes 發行週期分開。這在很大程度上是可能的，因為 Kubernetes 已建立儲存界面或 CSI，為廠商提供與 k8 連接的標準方式。
您可以在 https://docs.aws.amazon.com/eks/latest/userguide/storage.html：// 查看有關 Amazon Elastic Kubernetes Services (EKS) 儲存類別和 CSI 驅動程式的詳細資訊
## 適用於 Windows 的樹狀內磁碟區外掛程式
Kubernetes 磁碟區可讓具有資料持久性需求的應用程式部署在 Kubernetes 上。持久性磁碟區的管理包含佈建/取消佈建/調整磁碟區大小、將磁碟區連接至 Kubernetes 節點或從 Kubernetes 節點移除磁碟區，以及將磁碟區掛載/卸載至 Pod 中的個別容器。針對特定儲存後端或通訊協定實作這些磁碟區管理動作的程式碼，會以 Kubernetes 磁碟區外掛程式 **（樹狀內磁碟區外掛程式）** 的形式運送。在 Amazon Elastic Kubernetes Services (EKS) 上，Windows 支援以下類別的 Kubernetes 磁碟區外掛程式：
*樹狀內磁碟區外掛程式：*[awsElasticBlockStore](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)
若要在 Windows 節點上使用樹狀內磁碟區外掛程式，必須建立額外的 StorageClass，才能使用 NTFS 做為 fsType。在 EKS 上，預設 StorageClass 使用 ext4 作為預設 fsType。
StorageClass 可讓管理員描述其提供的「類別」儲存體。不同的類別可能會對應至由叢集管理員決定quality-of-service層級、備份政策或任意政策。Kubernetes 對於代表的類別不建議。此概念有時在其他儲存系統中稱為「設定檔」。
您可以執行下列命令來檢查：
```
kubectl describe storageclass gp2
```
輸出：
```
Name: gp2
IsDefaultClass: Yes
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClas
","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"gp2"},"parameters":{"fsType"
"ext4","type":"gp2"},"provisioner":"kubernetes.io/aws-ebs","volumeBindingMode":"WaitForFirstConsumer"}
,storageclass.kubernetes.io/is-default-class=true
Provisioner: kubernetes.io/aws-ebs
Parameters: fsType=ext4,type=gp2
AllowVolumeExpansion:
MountOptions:
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events:
```
若要建立新的 StorageClass 以支援 **NTFS**，請使用下列資訊清單：
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ntfs
volumeBindingMode: WaitForFirstConsumer
```
執行下列命令來建立 StorageClass：
```
kubectl apply -f NTFSStorageClass.yaml
```
下一個步驟是建立持久性磁碟區宣告 (PVC)。
PersistentVolume (PV) 是由管理員佈建或使用 PVC 動態佈建的叢集儲存體。它是叢集中的資源，就像節點是叢集資源一樣。此 API 物件會擷取儲存體實作的詳細資訊，包括 NFS、iSCSI 或cloud-provider-specific儲存系統。
PersistentVolumeClaim (PVC) 是使用者提出的儲存請求。宣告可以請求特定大小和存取模式 （例如，可以掛載 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany)。
對於不同的使用案例，使用者需要具有不同屬性的 PersistentVolumes，例如效能。叢集管理員需要能夠提供各種相異於大小和存取模式的PersistentVolumes，而無需讓使用者了解這些磁碟區如何實作的詳細資訊。對於這些需求，有 StorageClass 資源。
在下面的範例中，已在命名空間視窗中建立 PVC。
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-windows-pv-claim
namespace: windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2-windows
resources:
requests:
storage: 1Gi
```
執行下列命令來建立 PVC：
```
kubectl apply -f persistent-volume-claim.yaml
```
下列資訊清單會建立 Windows Pod、將 VolumeMount 設定為 ，`C:\Data`並使用 PVC 做為 上連接的儲存體`C:\Data`。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: windows-server-ltsc2019
namespace: windows
spec:
selector:
matchLabels:
app: windows-server-ltsc2019
tier: backend
track: stable
replicas: 1
template:
metadata:
labels:
app: windows-server-ltsc2019
tier: backend
track: stable
spec:
containers:
- name: windows-server-ltsc2019
image: mcr.microsoft.com/windows/servercore:ltsc2019
ports:
- name: http
containerPort: 80
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: "C:\\data"
name: test-volume
volumes:
- name: test-volume
persistentVolumeClaim:
claimName: ebs-windows-pv-claim
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.17763'
```
透過 PowerShell 存取 Windows Pod 來測試結果：
```
kubectl exec -it podname powershell -n windows
```
在 Windows Pod 中，執行： `ls`
輸出：
```
PS C:\> ls
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/8/2021 1:54 PM data
d----- 3/8/2021 3:37 PM inetpub
d-r--- 1/9/2021 7:26 AM Program Files
d----- 1/9/2021 7:18 AM Program Files (x86)
d-r--- 1/9/2021 7:28 AM Users
d----- 3/8/2021 3:36 PM var
d----- 3/8/2021 3:36 PM Windows
-a---- 12/7/2019 4:20 AM 5510 License.txt
```
**資料目錄**由 EBS 磁碟區提供。
## Out-of-tree
與 CSI 外掛程式相關聯的程式碼會以out-of-tree指令碼和二進位形式提供，通常以容器映像形式分佈，並使用 DaemonSets 和 StatefulSets 等標準 Kubernetes 建構模組進行部署。CSI 外掛程式可在 Kubernetes 中處理各種磁碟區管理動作。CSI 外掛程式通常由節點外掛程式 （以 DaemonSet 的形式在每個節點上執行） 和控制器外掛程式組成。
CSI 節點外掛程式 （特別是與以區塊型儲存設備或透過共用檔案系統公開的持久性磁碟區相關聯的外掛程式） 需要執行各種特殊權限操作，例如掃描磁碟裝置、掛載檔案系統等。這些操作會因每個主機作業系統而有所不同。對於 Linux 工作者節點，容器化 CSI 節點外掛程式通常會部署為特權容器。對於 Windows 工作者節點，使用 [csi-proxy 支援容器化 CSI 節點外掛程式的特權操作，csi-proxy](https://github.com/kubernetes-csi/csi-proxy) 是需要在每個 Windows 節點上預先安裝的社群受管、獨立二進位檔。
[Amazon EKS Optimized Windows AMI 從 ](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html)2022 年 4 月開始包含 CSI-proxy。客戶可以使用 Windows 節點上的 [SMB CSI 驅動程式](https://github.com/kubernetes-csi/csi-driver-smb)來存取 [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/)、[Amazon FSx for NetApp ONTAP SMB Shares](https://aws.amazon.com/fsx/netapp-ontap/) 和/或 [AWS Storage Gateway — File Gateway](https://aws.amazon.com/storagegateway/file/)。
下列[部落格](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/)提供實作詳細資訊，說明如何設定 SMB CSI 驅動程式使用 Amazon FSx for Windows File Server 做為 Windows Pod 的持久性儲存體。
## Amazon FSx for Windows File Server
選項是透過稱為 [SMB Global Mapping](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) 的 SMB 功能使用 Amazon FSx for Windows File Server，這可讓您在主機上掛載 SMB 共用，然後將共用上的目錄傳遞到容器中。容器不需要設定特定的伺服器、共用、使用者名稱或密碼 - 它們都是在主機上處理。容器的運作方式與具有本機儲存體相同。
SMB 全域映射對協調器來說是透明的，它透過 HostPath 掛載，這可能**暗示著安全問題**。
在下面的範例中，路徑`G:\Directory\app-state`是 Windows 節點上的 SMB 共享。
```
apiVersion: v1
kind: Pod
metadata:
name: test-fsx
spec:
containers:
- name: test-fsx
image: mcr.microsoft.com/windows/servercore:ltsc2019
command:
- powershell.exe
- -command
- "Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\\ServiceMonitor.exe'; echo '