編輯

Share via

Azure Stack HCI 上的 AKS 網路架構

Azure Stack
Windows Server

此案例說明如何設計和實作在 AKS 混合式叢集上部署 Azure Kubernetes Service （AKS） 節點的網路概念。

本文包含 Kubernetes 節點和 Kubernetes 容器的網路設計建議。 這是兩篇文章架構基準指引集的一部分。 請參閱這裡的基準架構建議。

架構

下圖顯示 Azure Stack HCI 或 Windows Server 2019/2022 數據中心叢集上 Azure Kubernetes Service 的網路架構：

Conceptual graphic showing network baseline architecture.

下載此架構的 Visio 檔案。

此案例包含下列元件和功能：

  • Azure Stack HCI （20H2） 是超融合基礎結構 （HCI） 叢集解決方案，可裝載虛擬化的 Windows 和 Linux 工作負載，以及其在混合式內部部署環境中的記憶體。 Azure Stack HCI 叢集會實作為 2-4 節點叢集。
  • Windows Server 2019/2022 數據中心故障轉移叢集是一組獨立計算機，可共同運作，以提高叢集角色的可用性和延展性。
  • Azure Stack HCI 上的 Azure Kubernetes Service （AKS 混合式）是 Azure Kubernetes Service （AKS） 的內部部署實作，可大規模自動化執行容器化應用程式。
  • [Active Directory 網域服務][] 是階層式結構，可儲存網路上對象的相關信息。 它為與安全性界限中包含的使用者、計算機、應用程式或其他資源相關聯的身分識別提供身分識別和存取解決方案。
  • [管理叢集][] 也稱為 AKS 主機負責部署和管理多個工作負載叢集。 管理叢集會從節點集區取用 1 個 IP 位址，但您應該保留另 2 個 IP 來進行更新作業。 管理叢集也會從VIP集區取用一個IP。
  • [工作負載叢集][] 是使用 Linux VM 執行 Kubernetes 控制平面元件和 Linux 和/或 Windows 背景工作節點的高可用性部署。
    • 控制平面。 在Linux散發套件上執行，並包含與 Kubernetes API 互動的 API 伺服器元件，以及用於儲存叢集所有元件和數據之分散式索引鍵/值存放區等。 它會從節點集區取用一個IP，並從VIP集區取用一個IP。
    • 負載平衡器。 在 Linux VM 上執行，並為工作負載叢集提供負載平衡服務。 它會從節點集區取用一個IP，並從VIP集區取用一個IP。
    • 背景工作節點。 在裝載容器化應用程式的 Windows 或 Linux 作業系統上執行。 它會從節點集區取用IP位址，但您應該為更新作業規劃至少3個IP位址。
    • Kubernetes 資源。 Pod 代表應用程式的單一實例，通常具有與容器的 1：1 對應，但某些 Pod 可以包含多個容器。 部署代表一或多個相同的Pod。 Pod 和部署會以邏輯方式分組為命名空間，以控制資源的管理存取權。 它們會從VIP集區取用每個Pod 1個IP。
  • [Azure Arc][] 是雲端式服務，會將 Azure Resource Manager 型管理模型延伸至非 Azure 資源，包括虛擬機（VM）、Kubernetes 叢集和容器化資料庫。
  • [Azure 原則][] 是一項雲端式服務，可藉由比較屬性與可自定義的商務規則，透過與 Azure Arc 整合，評估 Azure 和內部部署資源。
  • [Azure 監視器][] 是一種雲端式服務，透過提供完整的解決方案來收集、分析及處理來自雲端和內部部署環境的遙測數據，將應用程式和服務的可用性和效能最大化。
  • [適用於雲端的 Microsoft Defender][] 是統一的基礎結構安全性管理系統，可強化數據中心的安全性狀態，並在雲端和內部部署的混合式工作負載之間提供進階威脅防護。

元件

  • [Azure Stack HCI （20H2）][1]
  • [Windows Server 2019/2022 數據中心故障轉移叢集][]
  • [Azure Kubernetes Service （AKS）][]
  • [Windows 管理員 Center][]
  • [Azure 訂用帳戶][]
  • [Azure Arc][2]
  • [Azure 角色型訪問控制 （RBAC）][]
  • [Azure 監視器][3]
  • [適用於雲端的 Microsoft Defender][4]

案例詳細資料

此案例的使用案例會在系列 基準架構的第一篇文章中說明。

Kubernetes 節點網路

Azure Stack HCI 上 AKS 的網路設計主要考慮是選取可提供足夠 IP 位址的網路模型。 Azure Stack HCI 上的 AKS 會使用虛擬網路將 IP 位址配置給 Kubernetes 節點資源。 您可以使用兩個 IP 位址指派模型：

  • 靜態IP網路功能比較可預測，但會為初始設定增加額外的精力。
  • 動態主機設定通訊協定 （DHCP） 網路使用IP位址的動態配置和較少的工作量，但您必須小心不要耗盡可用的IP集區。 您也需要管理虛擬IP集區和雲端代理程式服務等特定叢集範圍保留和排除範圍。

這兩個指派模型都必須規劃IP位址：

  • 虛擬IP集區
  • Kubernetes 節點 VM IP 集區

虛擬IP集區

虛擬IP集區是 Azure Stack HCI 部署上任何 AKS 的必要IP位址集。 根據工作負載叢集和 Kubernetes 服務的數目，規劃虛擬IP集區中的IP位址數目。 虛擬IP集區會為下列類型的資源提供IP位址：

  • 雲端代理程式需要虛擬IP集區中的浮動IP位址。

  • 在 Kubernetes 虛擬裝置 （KVA） 虛擬機器 （管理叢集） 內執行的 API 伺服器元件會使用來自虛擬 IP 集區的 IP 位址。 API 伺服器是 Kubernetes 控制平面的元件，可公開 Kubernetes API。 API 伺服器是 Kubernetes 控制平面的前端。 KVA 是執行 Mariner Linux 並裝載 Kubernetes 叢集的虛擬機。 IP 位址會浮動，也用於您在 Azure Stack HCI 上的 AKS 中部署的任何其他 KVA VM。 KVA 虛擬機也會裝載 Kubernetes 虛擬 IP 負載平衡器服務。

  • 規劃目標伺服器上部署的控制平面 VM 數目的 IP 位址，因為它們也會從虛擬 IP 集區取用更多 IP 位址。 下一節將說明考慮事項。

  • 目標叢集包含負載平衡器 VM，這是 HAProxy，並擁有目標叢集的虛擬 IP 集區。 此 VM 會透過虛擬 IP 集區公開所有 Kubernetes 服務。

  • 在 Kubernetes Pod 中執行的應用程式會使用來自虛擬 IP 集區的 IP 位址。

  • HAProxy 負載平衡器會部署為特製化虛擬機，可用來平衡跨多個端點的連入要求。 他們會從虛擬IP集區取用IP位址，而且您需要規劃每個工作負載叢集的IP位址。

Kubernetes 節點 VM IP 集區

Kubernetes 節點會部署為 Azure Stack HCI 部署上 AKS 中的虛擬機。 請確定您根據 Kubernetes 節點總數規劃 IP 位址數目，並至少包含升級程式期間使用的三個 IP 位址。 針對靜態 IP 位址組態，您必須指定 Kubernetes 節點 VM IP 集區範圍，這不需要 DHCP 配置。 規劃下列專案的其他IP位址：

  • KVA VM 也會從 Kubernetes 節點 VM IP 集區使用更多 Kubernetes 的 IP 位址。 規劃在更新程式期間新增IP位址，因為 KVA VM 會針對 API 服務使用相同的虛擬IP，但需要與 Kubernetes 節點 VM IP 集區不同的IP。
  • 控制平面 VM 會從 API 伺服器服務的 Kubernetes 節點 VM IP 集區取用一個 IP。 這些虛擬機也會裝載連線到 Azure 入口網站 以進行管理之 Azure ARC 代理程式。
  • 節點集區 （Linux 或 Windows） 中的節點會從為 Kubernetes 節點 VM 配置的 IP 集區取用 IP 位址。

Microsoft 內部部署雲端服務

規劃 Microsoft 內部部署雲端 （MOC） 的 IP 位址範圍，以啟用管理堆疊，讓 Azure Stack HCI 上的 VM 在雲端中受到管理。 MOC 服務的IP位址配置位於基礎實體網路上，而針對 Azure Stack HCI 叢集節點設定的IP位址位於資料中心。 您可以在下列其中一項中為 Azure Stack HCI 的實體節點設定 IP 位址：

  • 具有 DHCP 型 IP 位址配置模式的 Azure Stack HCI 叢集節點。 MOC 服務會從實體網路上呈現的 DHCP 服務取得IP位址。
  • 具有靜態IP配置模型的 Azure Stack HCI 叢集節點。 MOC 雲端服務的 IP 位址必須明確指定為無類別網路變數間路由 （CIDR） 格式的 IP 範圍，且其必須與 Azure Stack HCI 叢集節點的 IP 位址位於相同的子網中。

Azure Stack HCI 上 AKS 中的負載平衡器

針對小型部署，您可以使用內建負載平衡器，部署為使用HAProxy + KeepAlive的Linux VM，將流量傳送至部署為AKS叢集一部分的應用程式服務。 HAProxy 負載平衡器會將 Pod 設定為負載平衡器中的端點。 它會平衡對 Kubernetes API 伺服器的要求，以及管理對應用程式服務的流量。

您也可以使用自定義負載平衡器來管理服務的流量。 自定義負載平衡器可為部署提供額外的彈性，並確保 Azure Stack HCI 上的 AKS 與使用負載平衡器的軟體定義網路 （SDN） 部署等現有部署搭配運作。 針對自定義負載平衡器，kube-virtual IP 會為 LoadBalancer 類型的 控制平面和 Kubernetes Services 提供虛擬 IP 和負載平衡器，為 Kubernetes 叢集提供虛擬 IP 和負載平衡器。 kube-virtual IP 服務會自動部署在每個背景工作節點上。

Azure Stack HCI 上的 AKS 也支援使用 MetalLB 或其他 OSS Kubernetes 型負載平衡器來平衡工作負載叢集中服務目的地的流量。 MetalLB 是裸機 Kubernetes 叢集的負載平衡器實作，使用標準路由通訊協定，例如邊界網關通訊協定 BGP。 它可以與網路附加元件 Calico 和 Flannel 搭配運作，但您必須確保 Azure Stack HCI 上安裝 AKS 期間所提供的虛擬 IP 位址範圍不會與針對自定義負載平衡器規劃的 IP 位址範圍重疊。

部署此案例

部署輸入控制器

請考慮針對 TLS 終止、可逆 Proxy 或可設定的流量路由實作 [輸入控制器][]。 輸入控制器可在第 7 層運作，而且可以使用智慧型手機規則來分散應用程式流量。 Kubernetes 輸入資源可用來設定個別 Kubernetes 服務的輸入規則和路由。 當您定義輸入控制器時，會將流量路由規則合併到作為叢集一部分執行的單一資源。

使用輸入控制器透過外部可連線的 URL 公開服務。 輸入會將來自叢集外部的 HTTP 和 HTTPS 路由公開至叢集內的服務。 流量路由是由輸入資源上定義的規則所控制。 輸入 HTTP 規則包含下列資訊：

  • 選擇性主機。 如果您沒有提供主機資訊，規則會套用至所有輸入 HTTP 流量。
  • 路徑清單，其具有與 service.name 和 service.port.name service.port.number 定義之相關聯後端的路徑清單。
  • 後端，提供服務和埠名稱的組合。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

使用輸入控制器來平衡應用程式不同後端之間的流量。 流量會根據路徑資訊，分割並傳送至不同的服務端點和部署。

若要將 HTTP 流量路由傳送至相同 IP 位址上的多個主機名，您可以針對每個主機使用不同的輸入資源。 透過負載平衡器 IP 位址的流量會根據主機名和輸入規則中提供的路徑路由傳送。

Azure Stack HCI 上的 Azure Kubernetes Service (AKS) 中的容器網路概念

Kubernetes 提供虛擬網路的抽象層，讓容器型應用程式可以在內部或外部通訊。 kube-proxy 元件會在每個節點上執行，而且可以直接存取服務、使用負載平衡來散發流量，或使用輸入控制器進行更複雜的應用程式路由。 Kubernetes 會使用服務，以邏輯方式將一組 Pod 群組在一起，並提供網路連線能力。 下列 Kubernetes 服務可供使用：

  • 叢集IP：此服務會為僅限內部的應用程式建立內部IP位址。
  • NodePort：此服務會在基礎節點上建立埠對應，讓應用程式能夠透過節點IP位址和埠直接存取。
  • LoadBalancer：您可以使用負載平衡器規則或輸入控制器，在外部公開 Kubernetes 服務。
  • ExternalName：。 此服務會針對 Kubernetes 應用程式使用特定的 DNS 專案。

Kubernetes 網路

在 Azure Stack HCI 上的 AKS 中，可以使用下列其中一個網路模型來部署叢集：

  • [Project Calico 網络功能][]. 這是 Azure Stack HCI 上 AKS 的預設網路模型，並以開放原始碼網路為基礎，可為容器、虛擬機和原生主機型工作負載提供網路安全性。 Calico 網路原則可以套用至任何種類的端點，例如 Pod、容器、VM 或主機介面。 每個原則都包含規則，這些規則會使用允許、拒絕、記錄或傳遞來源和目的地端點之間的流量的動作來控制輸入和輸出流量。 Calico 可以使用 Linux 擴充 Berkeley 封包篩選器 （eBPF） 或 Linux 核心網路管線來傳遞流量。 在 Windows 上使用主機網路服務 （HNS） 建立每個容器端點的網路命名空間，也支援 Calico。 在 Kubernetes 網路模型中，每個 Pod 都會取得自己在該 Pod 內容器之間共用的 IP 位址。 Pod 會使用 Pod IP 位址在網路上通訊，並使用網路原則來定義隔離。 Calico 使用 CNI （容器網路介面） 外掛程式，在 Kubernetes Pod 網路和 CNI IPAM （IP 位址管理） 外掛程式中新增或刪除 Pod，以便配置和釋放 IP 位址。
  • [Flannel overlay networking.][] Flannel 會建立一個虛擬網路層，以重迭主機網路。 重疊網路會使用透過現有實體網路封裝網路封包。 Flannel 可簡化 IP 位址管理 （IPAM），支援不同應用程式和命名空間之間的IP重複使用，並提供容器網路與 Kubernetes 節點所使用的底層網路之間的邏輯區隔。 網路隔離是使用虛擬 eXtensible 局域網路 （VXLAN） 來達成，此封裝通訊協定使用通道透過基礎第 3 層網路延伸第 2 層連線，以提供數據中心連線能力。 使用 DaemonSet 的 Linux 容器和使用 Flannel CNI 外掛程式的 Windows 容器都支援 Flannel。

Azure Stack HCI 網路設計

整體網路設計包括 Azure Stack HCI 的規劃活動。

首先，從規劃 Azure Stack HCI 的硬體和安裝開始。 您可以從已安裝 Azure Stack HCI 作業系統的 Microsoft 硬體合作夥伴購買整合式系統，也可以自行購買已驗證的節點並自行安裝作業系統。 Azure Stack HCI 是作為虛擬化主機，因此 Kubernetes 伺服器角色必須在 VM 內執行。

Azure Stack HCI 的實體網路需求

Microsoft 不會認證網路交換器，但它具有設備廠商必須滿足的特定需求：

  • 標準：定義虛擬局域網路 （VLAN） 的 IEEE 802.1Q。
  • 標準：定義優先順序流程控制 （PFC） 的 IEEE 802.1Qbb。
  • 標準：定義增強傳輸選擇的 IEEE 802.1Qaz。
  • 標準：定義連結層拓撲探索 （LLTD） 通訊協定的 IEEE 802.1AB。

Azure Stack HCI 的主機網路需求

請考慮使用已透過標準或 進階版 額外資格 （AQ） 取得 Windows Server 軟體定義資料中心 （SDDC） 認證的網路適配器。

確定網路配接器支援：

  • [動態虛擬機多佇列][] （動態 VMMQ 或 d.VMMQ） 是智慧型手機接收端技術，可自動調整網路流量處理至 CPU 核心。
  • 遠端直接記憶體存取 （RDMA） 是網路適配器的網路堆疊卸除。 它允許SMB記憶體流量略過作業系統進行處理。
  • 客體 RDMA 可讓 VM 的 SMB 工作負載獲得在主機上使用 RDMA 的相同優點。
  • Switch Embedded Teaming （SET） 是一種軟體型小組技術。

請考慮使用 [網络 ATC][]，以提供意圖型控件來簡化主機網路設定。

Azure Stack HCI 上的 AKS 需要每個伺服器節點之間可靠的高頻寬、低延遲網路連線。 請確定至少有一張網路適配器可供使用，並專用於叢集管理。 此外，請確認網路中實體交換器已設定為允許您將使用之任何 VLAN 的流量。

虛擬交換器

Azure Stack HCI 藉由設定可用於網路分類的虛擬交換器，簡化網路設計。 虛擬網路適配器 （vNIC） 可以放在不同的 VLAN 中，讓主機為下列網路提供不同的流量流程：

  • 管理網路。 管理網路是南北網路的一部分，用於主機通訊。
  • 計算網路。 計算網路是南北網路的一部分，用於虛擬機流量。 使用服務品質（QOS）、單根 I/O 虛擬化（SR-IOV）和虛擬遠端直接記憶體取（vRDMA），根據需求調整網路效能。
  • 存放網路。 記憶體網路是東西方網路的一部分，需要具有建議輸送量 10GB+ 的 RDMA。 它用於 VM 的即時移轉。
  • VM 客體網路。

RDMA 流量的東西部流量優點

東西部網路流量代表主機之間的通訊，而且不會公開任何外部存取。 流量會保留在機架頂端 （ToR） 交換器和第 2 層界限內。 包含下列型態的流量：

  • 叢集活動訊號和節點間通訊
  • [SMB]儲存體 總線層
  • [SMB]叢集共用磁碟區
  • [SMB]儲存體重建

南北交通

南北流量是到達 Azure Stack HCI 叢集 AKS 的外部流量。 您可以透過整合 Azure ARC 來規劃 Azure 服務範圍的流量，以啟用監視、計費和安全性管理。 南北流量具有下列特性：

  • 流量從 ToR 交換器流出至脊椎，或從脊椎流向 ToR 交換器。
  • 流量會離開實體機架或跨越第 3 層界限（IP）。
  • 流量包括管理（PowerShell、Windows 管理員 中心）、計算（VM）和月臺間延展式叢集流量。
  • 使用乙太網路交換器來連線到實體網路。

Azure Stack HCI 上的 AKS 可以使用數個叢集網路部署選項：

  • 結合多個網路意圖的聚合式網路（MGMT、計算、儲存體）。 這是建議針對三個以上的實體節點進行部署，而且要求所有實體網路適配器都連線到相同的ToR交換器。 強烈建議使用ROCEv2。
  • 無交換器部署會結合計算和管理網路，使用南北通訊作為網路小組。
  • 混合式部署是這兩個部署的組合。

建議

下列建議適用於大部分案例。 除非您有覆寫建議的特定需求，否則請遵循建議。

網路建議

Azure Stack HCI 上 AKS 的網路設計主要考慮是選取網路模型，為您的 Kubernetes 叢集及其服務和應用程式提供足夠的 IP 位址。

  • 請考慮實作靜態 IP 位址，以允許 Azure Stack HCI 上的 AKS 控制 IP 位址指派。

  • 適當地維度IP位址範圍，讓 Kubernetes 節點集區和虛擬IP集區有足夠的可用IP位址。 請確定您的虛擬IP集區夠大，以便在每當您升級時，都可以使用滾動升級，這需要更多IP位址。 您可以規劃下列專案：

    • Proxy 設定的尋址/主機名
    • 目標叢集控制平面的IP位址
    • Azure ARC 的 IP 位址
    • 目標叢集中背景工作和控制平面節點水平調整的IP位址

  • 您的虛擬IP集區應該夠大，以支援需要連線到外部路由器的應用程式服務部署。

  • 實作 Calico CNI 以提供增強的網路原則，以控制 Pod 和應用程式通訊。

  • 確定實體叢集節點 （HCI 或 Windows Server） 位於相同的機架中，並連線到相同的 ToR 交換器。

  • 在所有網路適配器上停用IPv6。

  • 確定現有虛擬交換器及其名稱在所有叢集節點中都相同。

  • 確認您為叢集定義的所有子網彼此之間和因特網皆可路由傳送。

  • 請確定 Azure Stack HCI 主機與租使用者 VM 之間有網路連線。

  • 在您的 DNS 環境中啟用動態 DNS 更新，以允許 Azure Stack HCI 上的 AKS 在 DNS 系統中註冊雲端代理程式一般叢集名稱以進行探索。

  • 請考慮依其方向實作網路流量分類：

    • 南北流量是來自 Azure Stack HCI 和其餘網路的流量，
      • 管理
      • 計算
      • 月臺間延展式叢集流量
    • Azure Stack HCI 內的東西流量：
      • 儲存體 流量，包括相同叢集中節點之間的實時移轉。
      • 乙太網路交換器或直接連線。

儲存體 流量模型

  • 使用多個子網和 VLAN 來分隔 Azure Stack HCI 中的記憶體流量。
  • 請考慮實作各種流量類型的流量頻寬配置。

考量

[Microsoft Azure Well-Architected Framework][] 是一組在此案例中遵循的指導原則。 下列考慮會包含在這些原則的內容中。

可靠性

  • Microsoft 軟體定義的計算固有的內建復原能力（Hyper-V 節點的故障轉移叢集）、記憶體（儲存空間直接存取 巢狀復原），以及網路功能（軟體定義網路）。
  • 請考慮選取支援業界標準的網路交換器，並確保節點之間的可靠通訊。 下列標準包括：
    • 標準：IEEE 802.1Q
    • 標準 IEEE 802.1Qbb
    • 標準 IEEE 802.1 Qas
    • 標準 IEEE 802.1 AB
  • 請考慮在管理叢集和 Kubernetes 叢集中實作多個主機，以符合工作負載的最低可用性層級。
  • Azure Stack HCI 上的 AKS 會使用故障轉移叢集和即時移轉，以提供高可用性和容錯。 即時移轉是一項 Hyper-V 功能，可讓您以透明方式將執行中的虛擬機從一部 Hyper-V 主機移至另一部主機，而不會察覺到停機。
  • 您應該確定 Azure Arc 部署所在的區域支援 [架構] 區段中所參考的服務。

安全性

  • 在 Azure Stack HCI 上使用 AKS 中的網路原則保護 Pod 之間的流量。
  • Azure Stack HCI 上 AKS 中的 API 伺服器包含證書頒發機構單位，該證書頒發機構單位會簽署憑證，以便從 Kubernetes API 伺服器到 kubelet 進行通訊。
  • 使用 Microsoft Entra 單一登入 （SSO） 建立與 Kubernetes API 伺服器的安全連線。
  • 您可以使用 Azure RBAC，使用 Microsoft Entra 身分識別來管理跨 Azure 和內部部署環境啟用 Azure Arc 的 Kubernetes 存取權。 如需詳細資訊，請參閱 [使用 Azure RBAC for Kubernetes Authorization][]。

成本最佳化

  • 使用 [Azure 定價計算機][] 來估計架構中使用的服務成本。 [Microsoft Azure Well-Architected Framework] 中的 [成本優化][] 一節會說明其他最佳做法。[]
  • 請考慮在實體計算機上實作超線程，以將成本優化，因為 Azure Stack HCI 計費單位上的 AKS 是虛擬核心。
  • Azure Arc 控制平面功能不需額外費用。 這包括透過 Azure 管理群組和標籤支援資源組織，以及透過 Azure RBAC 的訪問控制。 與已啟用 Azure Arc 的伺服器搭配使用的 Azure 服務會根據其使用量產生成本。
  • 為了符合成本效益，每個節點只能使用只有四個磁碟和 64 GB 記憶體的兩個叢集節點。 若要進一步降低成本，您可以在節點之間使用無開關互連，藉此消除備援交換器裝置的需求。

卓越營運

  • 使用 Windows 管理員 Center 簡化的管理。 Windows 管理員 中心是用來在 Azure Stack HCI 上建立和管理 AKS 的使用者介面。 它可以安裝在需要在 Azure 中註冊的 Windows 10/11 或 Windows Server VM 上，且與 Azure Stack HCI 或 Windows Server Datacenter 叢集位於相同的網域中。
  • 與 Azure Arc 或一系列 Azure 服務整合，以提供更多管理、維護和復原功能（Azure 監視器、Azure 備份）。
  • 如果您的 Kubernetes 叢集 [鏈接至 Azure Arc][已啟用 Azure Arc 的 Kubernetes 服務]，您可以 [使用 GitOps 管理 Kubernetes 叢集][]。 若要檢閱將混合式 Kubernetes 叢集連線至 Azure Arc 的最佳做法，請參閱 [Kubernetes 叢集的 Azure Arc 混合式管理和部署][] 案例。
  • Azure Stack HCI 平臺也可藉由以高可用性的方式提供「基礎」網路，協助簡化 Azure Stack HCI 叢集上 AKS 的虛擬網路。

效能效益

  • 使用 Azure Stack HCI 認證的硬體來改善應用程式運行時間和效能、簡化的管理與作業，以及降低總擁有成本。
  • 儲存體：儲存空間直接存取
    • 磁碟區設定 （巢狀雙向鏡像與巢狀鏡像加速同位）
    • 磁碟組態（快取、層）
  • 請確定叢集節點位於相同的機架中，並連線到相同的 ToR 交換器。
  • 規劃IP位址保留，以設定 AKS 主機、工作負載叢集、叢集 API 伺服器、Kubernetes Services 和應用程式服務。 Microsoft 建議為 Azure Stack HCI 上的 AKS 部署保留至少 256 個 IP 位址。
  • 請考慮實作在第 7 層運作的輸入控制器，並使用更智慧的規則來散發應用程式流量。
  • 針對廣泛的工作負載使用圖形處理單位 （GPU） 加速。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他參與者：

下一步