Azure Arc 所啟用 AKS 的資源限制、VM 大小和區域
適用於:Azure Local 22H2 上的 AKS、Windows Server 上的 AKS
本文提供 Azure Arc 所啟用 Azure Kubernetes Service (AKS) 測試組態、資源限制、VM 大小和區域的相關信息。測試使用 Azure 本機上最新版的 AKS。
最大規格
Arc 部署所啟用的 AKS 已使用下列設定進行驗證,包括指定的最大值。 請記住,超過這些最大值的風險是您自己的風險,並可能導致非預期的行為和失敗。 本文提供有關如何避免常見的設定錯誤,並協助您建立較大的組態的一些指引。 如有疑問,請連絡您的當地Microsoft辦公室以取得協助,或在 Azure 局域網路中提交問題。
資源 | 最大值 |
---|---|
每個叢集的實體伺服器 | 8 |
VM 總數 | 200 |
根據下表,建議的限制是使用預設虛擬機 (VM) 大小進行測試:
系統角色 | VM 大小 |
---|---|
AKS-Host | Standard_A4_v2 |
目標叢集控制平面節點 | Default |
目標叢集 HAProxy 負載平衡器 (選擇性) | Standard_A4_v2 |
目標叢集 Linux 背景工作節點 | Standard_K8S3_v1 |
目標叢集 Windows 背景工作節點 | Standard_K8S3_v1 |
Azure 本機叢集中每個實體節點的硬體組態如下所示:
- 底座:Dell PowerEdge R650 伺服器或類似版本。
- RAM:RDIMM,3200 MT/秒,雙排名,總計 256 GB。
- CPU:兩個(2) Intel Xeon Silver 4316 2.3G,20C/40T,10.4 GT/秒,30M 快取,Turbo,HT(150 W) DDR4-2666。
- 磁碟:8x HDD(2 TB 或更大)和 2x 1.6 TB NVMe 以支援 S2D 記憶體設定。
- 網路:4 (4) 100-Gbit NIC (Mellanox 或 Intel)。
Microsoft使用上述組態測試 Arc 所啟用的 AKS 工程。 針對單一節點。 2 個節點、4 個節點和 8 個節點的 Windows 故障轉移叢集。 如果您需要超過測試的組態,請參閱 在 Azure 本機上調整 AKS。
重要
當您升級 AKS 的部署時,會暫時取用額外的資源。 每個虛擬機都會在滾動更新流程中升級,從控制平面節點開始。 針對 Kubernetes 叢集中的每個節點,會建立新的節點 VM。 舊的節點 VM 會受到限制,以防止工作負載部署到它。 限制的 VM 接著會清空所有容器,以將容器散發至系統中的其他 VM。 然後,已清空的 VM 會從叢集中移除、關機,並由新的更新 VM 取代。 此程式會重複執行,直到所有 VM 都更新為止。
可用的 VM 大小
下列適用於控制平面節點、Linux 背景工作節點和 Windows 背景工作節點的 VM 大小適用於 Azure 本機上的 AKS。 雖然支援Standard_K8S2_v1和Standard_K8S_v1等 VM 大小進行測試和低資源需求部署,但請小心使用這些大小,並套用嚴格的測試,因為它們可能會導致因記憶體不足而發生非預期的失敗。
VM 大小 | CPU | 記憶體 (GB) | GPU 類型 | GPU 計數 |
---|---|---|---|---|
預設 | 4 | 4 | ||
Standard_A2_v2 | 2 | 4 | ||
Standard_A4_v2 | 4 | 8 | ||
Standard_D2s_v3 | 2 | 8 | ||
Standard_D4s_v3 | 4 | 16 | ||
Standard_D8s_v3 | 8 | 32 | ||
標準 D16s_v3 | 16 | 64 | ||
標準 D32s_v3 | 32 | 128 | ||
Standard_DS2_v2 | 2 | 7 | ||
Standard_DS3_v2 | 2 | 14 | ||
Standard_DS4_v2 | 8 | 28 | ||
Standard_DS5_v2 | 16 | 56 | ||
標準 DS13_v2 | 8 | 56 | ||
Standard_K8S_v1 | 4 | 2 | ||
Standard_K8S2_v1 | 2 | 2 | ||
Standard_K8S3_v1 | 4 | 6 | ||
Standard_NK6 | 6 | 12 | Tesla T4 | 1 |
Standard_NK12 | 12 | 24 | Tesla T4 | 2 |
Azure 註冊支援的 Azure 區域
下列 Azure 區域支援 Arc 啟用的 AKS:
- 澳大利亞東部
- 美國東部
- 東南亞
- 西歐
在 Azure 本機上調整 AKS
在 Azure 本機調整 AKS 部署牽涉到事先規劃,方法是瞭解您的工作負載和目標叢集使用率。 此外,請考慮基礎結構中的硬體資源,例如 CPU 核心總計、記憶體總計、記憶體、IP 位址等等。
下列範例假設基礎結構上只會部署 AKS 型工作負載。 部署非 AKS 工作負載,例如獨立或叢集虛擬機或資料庫伺服器,可減少 AKS 可用的資源,您必須將其納入考慮。
開始之前,請考慮下列幾點,以判斷您需要支援的最大規模和目標叢集數目:
- 您在目標叢集中的 Pod 可以使用的 IP 位址數目。
- 目標叢集中 Kubernetes 服務可用的 IP 位址數目。
- 您需要執行工作負載的 Pod 數目。
若要判斷 Azure Kubernetes Service Host VM 的大小,您必須知道背景工作節點和目標叢集的數目,因為該數目會決定 AKS 主機 VM 的大小。 例如:
- 最終部署系統中的目標叢集數目。
- 節點數目,包括所有目標叢集的控制平面、負載平衡器和背景工作節點。
注意
單一 AKS 主機只能管理相同平臺上的目標叢集。
此外,若要判斷目標叢集控制平面節點的大小,您必須知道您打算在每個目標叢集中部署的 Pod、容器和背景工作節點數目。
AKS 中目前無法變更的預設設定
在部署期間或部署之後,客戶目前無法控制預設組態和設定。 這些設定可以限制指定目標叢集的規模。
- 目標叢集中 Kubernetes Pod 的 IP 位址數目僅限於子網
10.244.0.0/16
。 也就是說,所有 Kubernetes 命名空間中每個背景工作節點 255 個 IP 位址都可用於 Pod。 若要查看指派給叢集中每個背景工作節點的 Pod CIDR,請在 PowerShell 中使用下列命令:
kubectl get nodes -o json | findstr 'hostname podCIDR'
"kubernetes.io/hostname": "moc-lip6cotjt0f",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.2.0/24",
"podCIDRs": [
"kubernetes.io/hostname": "moc-lmb6zqozk4m",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.4.0/24",
"podCIDRs": [
"kubernetes.io/hostname": "moc-wgwhhijxtfv",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.5.0/24",
"podCIDRs": [
在此範例中,您可以看到有三個 CIDR 的三個節點,每個節點都能夠裝載 254 個 Pod。 Kubernetes 調整文件建議您不要因為效能原因而超過每個節點 110 個 Pod。 請參閱 大型叢集的考慮。
其他考量:
- Kubernetes 服務的IP位址數目,位於您配置的VIP集區之外,來自
10.96.0.0/16
位址池。 系統會取用 Kubernetes API 伺服器的 255 個可用位址之一。 - 當您第一次執行 Set-AksHciConfig 時,只能在安裝時設定 AKS 主機 VM 的大小。 您稍後無法加以變更。
- 您只能在目標叢集建立時設定目標叢集控制平面和負載平衡器 VM 的大小。
縮放範例
下列縮放範例是以下列一般假設/使用案例為基礎:
- 您想要能夠完全容忍 Azure 本機叢集中的一個實體節點遺失。
- 您想要支援將目標叢集升級至較新版本。
- 您想要允許目標叢集控制平面節點和負載平衡器節點的高可用性。
- 您想要為這些案例保留整體 Azure 本機容量的一部分。
建議
為了達到最佳效能,請務必將叢集容量至少設定 15%(100/8=12.5),以允許一個實體節點的所有資源轉散發至其他七個 (7) 節點。 此設定可確保您有一些保留可供執行升級或其他 AKS 第二天的作業。
如果您想要超過 200 個 VM 限制,以達到最大硬體大小 8(8) 節點 Azure 本機叢集,請增加 AKS 主機 VM 的大小。 大小翻倍,大約是可以管理的 VM 數目的兩倍。 在 8 節點的 Azure 本機叢集中,您可以根據支援的硬體規格上限中所述的 Azure 本機建議資源限制,取得 8,192 (8x1024) VM。 您應該保留大約 30% 的容量,這可讓您在所有節點之間保留 5,734 部 VM 的理論限制。
- Standard_D32s_v3,針對具有 32 個核心和 128 GB 的 AKS 主機,最多可支援 1,600 個節點。
注意
由於此設定尚未經過廣泛測試,因此需要謹慎的方法和驗證。
在這樣的規模下,您可能想要將環境分割成至少 8 個目標叢集,每個叢集有 200 個背景工作節點。
若要在一個目標叢集中執行 200 個背景工作節點,您可以使用預設控制平面和負載平衡器大小。 視每個節點的 Pod 數目而定,您可以在控制平面上至少增加一個大小,並使用 Standard_D8s_v3。
根據每個目標叢集中裝載的 Kubernetes 服務數目,您可能必須增加負載平衡器 VM 的大小,以及目標叢集建立,以確保服務可以達到高效能並據以路由傳送流量。
Arc 所啟用的 AKS 部署會使用 Azure 本機放置邏輯,將目標叢集中每個節點集區的背景工作節點分散到可用的 Azure 本機節點。
重要
節點放置不會在平臺和 AKS 升級期間保留,而且會隨著時間而變更。 失敗的實體節點也會影響虛擬機分散到其餘叢集節點。
注意
如果實體叢集已滿 50%,則請勿同時執行四個以上的目標叢集建立,因為這可能會造成暫時的資源爭用。 將目標叢集節點集區相應增加為大量時,請考慮可用的實體資源,因為 AKS 不會驗證平行執行建立/調整程式的資源可用性。 請務必確定有足夠的保留,以允許升級和故障轉移。 特別是在非常大的環境中,這些作業在平行執行時,可能會導致資源耗盡。
如有疑問,請連絡您的當地Microsoft辦公室,以取得協助或張貼在 Azure 當地社群論壇中。