你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Stack HCI 上的 AKS 的网络体系结构

Azure Stack HCI
Windows Server

此方案说明如何设计和实现用于在 AKS 群集上部署 Azure Kubernetes 服务 (AKS) 节点的网络概念。

本文包含 Kubernetes 节点和 Kubernetes 容器的网络设计建议。 它是由两篇文章组成的体系结构基线指南集的一部分。 请参阅此处的基线体系结构建议

重要

本文中的信息适用于 Azure Stack HCI 版本 22H2 上的 AKS 和 Windows Server 上的 AKS-HCI。 最新版本的 AKS 在 Azure Stack HCI 23H2 上运行。 有关最新版本的详细信息,请参阅 Azure Stack HCI 版本 23H2 上的 AKS 文档

体系结构

下图显示了 Azure Stack HCI 或 Windows Server 2019/2022 Datacenter 群集上 Azure Kubernetes 服务的网络体系结构:

显示网络基线体系结构的概念图。

下载此体系结构的 Visio 文件

该方案包括以下组件和功能:

  • Azure Stack HCI (22H2) 是一种超融合基础设施 (HCI) 群集解决方案,它在混合的本地环境中托管虚拟化的 Windows 和 Linux 工作负载及其存储。 Azure Stack HCI 群集实现为 2-4 节点群集。
  • Windows Server 2019/2022 Datacenter 故障转移群集是一组独立的计算机,这些计算机相互协作以提高群集角色的可用性和可伸缩性。
  • Azure Stack HCI 上的 Azure Kubernetes 服务是大规模自动运行容器化应用程序的 Azure Kubernetes 服务 (AKS) 的本地实现。
  • Active Directory 域服务是一种分层结构,用于存储网络上的对象的相关信息。 它为与安全边界中包含的用户、计算机、应用程序或其他资源关联的标识提供标识和访问解决方案。
  • 管理群集也称为 AKS 主机,负责部署和管理多个工作负载群集。 管理群集使用节点池中的 1 个 IP 地址,但你应为更新操作保留另外 2 个 IP。 管理群集还使用 VIP 池中的一个 IP。
  • 工作负载群集是 Kubernetes 的高度可用部署,使用 Linux VM 运行 Kubernetes 控制平面组件和 Linux 和/或 Windows 工作器节点。
    • 控制平面。 在 Linux 发行版上运行,并且包含用于与 Kubernetes API 交互的 API 服务器组件,以及用于存储群集的所有配置和数据的分布式键值存储 (etcd)。 它使用节点池中的一个 IP 和 VIP 池中的一个 IP。
    • 负载均衡器。 在 Linux VM 上运行,并为工作负载群集提供负载均衡服务。 它使用节点池中的一个 IP 和 VIP 池中的一个 IP。
    • 工作器节点。 在托管容器化应用程序的 Windows 或 Linux 操作系统上运行。 它使用节点池中的 IP 地址,但你应为更新操作计划至少另外 3 个 IP 地址。
    • Kubernetes 资源。 Pod 表示应用程序的单个实例,通常与容器具有 1:1 的映射关系,但某些 Pod 可以包含多个容器。 部署表示一个或多个相同的 Pod。 Pod 和部署在逻辑上分组到一个命名空间中,该命名空间控制对资源管理的访问权限。 它们使用 VIP 池中的 IP,并且每个 Pod 使用 1 个 IP。
  • Azure Arc 是一项基于云的服务,它将基于 Azure 资源管理器的管理模型扩展到非 Azure 资源,包括虚拟机 (VM)、Kubernetes 群集和容器化数据库。
  • Azure Policy 是一项基于云的服务,它将属性与可自定义的业务规则进行比较,通过与 Azure Arc 的集成来评估 Azure 和本地资源。
  • Azure Monitor 是一项基于云的服务,它提供用于收集、分析和处理来自云与本地环境的遥测数据的综合解决方案,可将应用程序和服务的可用性和性能最大化。
  • Microsoft Defender for Cloud 是一个统一的基础结构安全管理系统,可增强数据中心的安全态势,并跨云和本地混合工作负载提供高级威胁防护。

组件

方案详细信息

本系列的第一篇文章基线体系结构中介绍了此方案的用例。

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 API 的 Kubernetes 控制平面的一个组件。 API 服务器是 Kubernetes 控制平面的前端。 KVA 是运行 Mariner Linux 的虚拟机,并且托管 Kubernetes 群集。 IP 地址是浮动的,还用于在 Azure Stack HCI 上的 AKS 中部署的任何其他 KVA VM。 KVA 虚拟机还托管 Kubernetes 虚拟 IP 负载均衡器服务。

  • 为目标服务器上部署的控制平面 VM 的数量规划 IP 寻址,因为它们还会使用虚拟 IP 池中的更多 IP 地址。 下一部分将介绍注意事项。

  • 目标群集包含一个负载均衡器 VM,该 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 使用 Kubernetes 节点 VM IP 池中的更多 IP 地址。 计划在更新过程中添加 IP 地址,因为 KVA VM 为 API 服务使用相同的虚拟 IP,但需要 Kubernetes 节点 VM IP 池中的单独 IP。
  • 控制平面 VM 为 API 服务器服务使用 Kubernetes 节点 VM IP 池中的一个 IP。 这些虚拟机还托管 Azure ARC 代理,该代理连接到 Azure 门户以进行管理。
  • 节点池(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 将流量发送到作为 AKS 群集的一部分部署的应用程序服务的 Linux VM。 HAProxy 负载均衡器将 Pod 配置为负载均衡器中的终结点。 它对针对 Kubernetes API 服务器的请求进行负载均衡,并管理应用程序服务的流量。

还可以使用自定义负载均衡器来管理发往服务的流量。 自定义负载均衡器为部署提供了更大的灵活性,并确保 Azure Stack HCI 上的 AKS 与现有部署(如使用负载均衡器的软件定义网络 (SDN) 部署)一起工作。 对于自定义负载均衡器,kube 虚拟 IP 为 Kubernetes 群集提供了一个虚拟 IP,以及用于控制平面和 LoadBalancer 类型的 Kubernetes 服务的负载均衡器。 Kube 虚拟 IP 服务会自动部署在每个工作器节点上。

Azure Stack HCI 上的 AKS 还支持使用 MetalLB 或其他基于 OSS Kubernetes 的负载均衡器来平衡发往工作负载群集中服务的流量。 MetalLB 是裸机 Kubernetes 群集的负载均衡器实现,使用标准路由协议(如边界网关协议 BGP)。 它可以与网络附加组件 Calico 和 Flannel 一起使用,但你需要确保在安装 Azure Stack HCI 上的 AKS 期间提供的虚拟 IP 地址范围不会与为自定义负载均衡器规划的 IP 地址范围重叠。

部署此方案

部署入口控制器

考虑为 TLS 终止、可逆代理或可配置流量路由实现入口控制器。 入口控制器在第 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 服务 (AKS) 中的容器网络概念

Kubernetes 为虚拟网络提供了一个抽象层,因此基于容器的应用程序可以在内部或外部进行通信。 Kube-proxy 组件在每个节点上运行,可以提供对服务的直接访问、使用负载均衡分配流量或使用入口控制器进行更复杂的应用程序路由。 Kubernetes 使用服务将一组 Pod 按逻辑组合在一起,并提供网络连接。 以下 Kubernetes 服务可用:

  • 群集 IP:此服务为仅限内部的应用程序创建内部 IP 地址。
  • NodePort:此服务在基础节点上创建端口映射,从而允许使用节点 IP 地址和端口直接访问应用程序。
  • LoadBalancer:你可以使用负载均衡器规则或入口控制器在外部公开 Kubernetes 服务。
  • ExternalName: 此服务为 Kubernetes 应用程序使用特定的 DNS 条目。

Kubernetes 网络

在 Azure Stack HCI 上的 AKS 中,可以使用以下网络模型之一部署群集:

  • 项目 Calico 网络。 这是 Azure Stack HCI 上的 AKS 的默认网络模型,它基于开源网络,该网络为容器、虚拟机和基于本机主机的工作负载提供网络安全。 Calico 网络策略可以应用于任何类型的终结点,例如 Pod、容器、VM 或主机接口。 每项策略都包含规则,这些规则通过使用可以允许、拒绝、记录或传递源终结点和目标终结点之间的流量的操作来控制入口和出口流量。 Calico 可以使用 Linux 扩展的 Berkeley 数据包筛选器 (eBPF) 或 Linux 内核网络管道进行流量传递。 Windows 上也支持 Calico,使用主机网络服务 (HNS) 为每个容器终结点创建网络命名空间。 在 Kubernetes 网络模型中,每个 Pod 都可以获取自己的 IP 地址,该地址在该 Pod 中的容器之间共享。 Pod 使用 Pod IP 地址在网络上进行通信,隔离通过网络策略定义。 Calico 使用 CNI(容器网络接口)插件在 Kubernetes Pod 网络中添加或删除 Pod,使用 CNI IPAM(IP 地址管理)插件分配和释放 IP 地址。
  • Flannel 覆盖网络。 Flannel 创建了一个覆盖主机网络的虚拟网络层。 覆盖网络通过现有物理网络使用网络数据包的封装。 Flannel 简化了 IP 地址管理 (IPAM),支持在不同应用程序和命名空间之间重复使用 IP,并提供了容器网络与 Kubernetes 节点使用的底层网络的逻辑分离。 网络隔离使用虚拟可扩展局域网 (VXLAN) 实现,后者是一种封装协议,它使用隧道提供数据中心连接,以通过底层第 3 层网络拉伸第 2 层连接。 使用 DaemonSet 的 Linux 容器和使用 Flannel CNI 插件的 Windows 容器均支持 Flannel。

Azure Stack HCI 网络设计

总体网络设计包括 Azure Stack HCI 的规划活动。

首先,规划 Azure Stack HCI 的硬件和安装。 你可以从 Microsoft 硬件合作伙伴处购买集成系统(已预装 Azure Stack HCI 操作系统),也可以购买验证节点,然后自行安装操作系统。 Azure Stack HCI 旨在作为虚拟化主机,因此 Kubernetes 服务器角色必须在 VM 内部运行。

Azure Stack HCI 的物理网络要求

Microsoft 不认证网络交换机,但它具有设备供应商必须满足的某些要求:

  • 标准:定义虚拟局域网 (VLAN) 的 IEEE 802.1Q。
  • 标准:定义优先流量控制 (PFC) 的 IEEE 802.1Qbb。
  • 标准:定义增强传输选择 (ETS) 的 IEEE 802.1Qaz。
  • 标准:定义链路层拓扑发现 (LLTD) 协议的 IEEE 802.1AB。

Azure Stack HCI 的主机网络要求

考虑使用已通过 Windows Server 软件定义的数据中心 (SDDC) 认证并拥有标准或高级附加资质 (AQ) 的网络适配器。

确保该网络适配器支持:

  • 动态虚拟机多队列(动态 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) 根据需要优化网络性能。
  • 存储网络。 存储网络是东-西网络的一部分,需要 RDMA,建议的吞吐量为 10GB+。 它用于 VM 的实时迁移。
  • VM 来宾网络。

RDMA 流量的东-西向流量优势

东-西向网络流量表示主机之间的通信,并且不会公开任何外部访问。 流量保留在架顶 (ToR) 交换机和 2 层边界内。 它包括以下类型的流量:

  • 群集检测信号和节点间通信
  • [SMB] 存储总线层
  • [SMB] 群集共享卷
  • [SMB] 存储重新生成

北-南向流量

北-南向流量是到达 Azure Stack HCI 上的 AKS 群集的外部流量。 可以为一系列 Azure 服务规划流量,这些服务通过 Azure ARC 集成实现监视、计费和安全管理。 北-南向流量具有以下特征:

  • 流量从 ToR 交换机流向脊或从脊流向 ToR 交换机。
  • 流量离开物理机架或跨越 3 层边界 (IP)。
  • 流量包括管理(PowerShell、Windows Admin Center)、计算 (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 地址的滚动升级。 可以规划以下各项:

    • 代理设置的寻址/主机名
    • 目标群集控制平面的 IP 地址
    • Azure ARC 的 IP 地址
    • 用于在目标群集中水平缩放工作器和控制平面节点的 IP 地址
  • 虚拟 IP 池应足够大,以支持部署需要连接到外部路由器的应用程序服务。

  • 实现 Calico CNI,以提供用于控制 Pod 和应用程序通信的增强网络策略。

  • 确保物理群集节点(HCI 或 Windows Server)位于同一机架中,并且连接到同一 ToR 交换机。

  • 在所有网络适配器上禁用 IPv6。

  • 确保现有虚拟交换机及其名称在所有群集节点上都相同。

  • 验证为群集定义的所有子网是否都可以在彼此之间路由并连接到 Internet。

  • 确保 Azure Stack HCI 主机和租户 VM 之间存在网络连接。

  • 在 DNS 环境中启用动态 DNS 更新,以允许 Azure Stack HCI 上的 AKS 在 DNS 系统中注册云代理通用群集名称以进行发现。

  • 考虑按方向实现网络流量分类:

    • 北-南向流量是来自 Azure Stack HCI 和网络其余部分的流量,
      • Management
      • 计算
      • 站点间拉伸群集流量
    • Azure Stack HCI 中的东-西向流量:
      • 存储流量,包括同一群集中节点之间的实时迁移。
      • 以太网交换机或直接连接。

存储流量模型

  • 使用多个子网和 VLAN 在 Azure Stack HCI 中隔离存储流量。
  • 考虑实现各种流量类型的流量带宽分配。

注意事项

Microsoft Azure 架构良好的框架是此方案中遵循的一组指导原则。 以下注意事项是在这些原则的背景下提出的。

可靠性

  • 内置复原能力,是 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 进行 Kubernetes 授权

成本优化

  • 使用 Azure 定价计算器估算体系结构使用的服务的成本。 Microsoft Azure 架构良好的框架中的成本优化部分介绍了其他最佳做法。
  • 考虑在物理计算机上实现超线程,以优化成本,因为 Azure Stack HCI 上的 AKS 计费单元是一个虚拟核心。
  • Azure Arc 控制平面功能不收取额外的费用。 这包括通过 Azure 管理组和标记支持资源组织,以及通过 Azure RBAC 进行访问控制。 与已启用 Azure Arc 的服务器结合使用的 Azure 服务根据其使用量收费。
  • 若要实现成本效益,可以使用最少两个群集节点,其中每个节点只有四个磁盘和 64 GB 内存。 若要进一步降低成本,可以在节点之间使用无交换机互连,从而消除对冗余交换机设备的需求。

卓越运营

  • 使用 Windows Admin Center 简化管理。 Windows Admin Center 是用于创建和管理 Azure Stack HCI 上的 AKS 的用户界面。 它可以安装在需要在 Azure 中注册并且与 Azure Stack HCI 或 Windows Server Datacenter 群集位于同一域中的 Windows 10/11 或 Windows Server VM 上。
  • 与 Azure Arc 或提供更多管理、维护和复原能力的一系列 Azure 服务(Azure Monitor、Azure 备份)集成。
  • 如果你的 Kubernetes 群集已附加到 Azure Arc,则你可使用 GitOps 管理 Kubernetes 群集。 若要查看有关将混合 Kubernetes 群集连接到 Azure Arc 的最佳做法,请查看 Kubernetes 群集的 Azure Arc 混合管理和部署方案。
  • Azure Stack HCI 平台还通过以高度可用的方式提供“基础”网络,帮助简化 Azure Stack HCI 上的 AKS 群集的虚拟网络。

性能效率

  • 使用 Azure Stack HCI 认证的硬件可提高应用程序运行时间和性能,简化管理和操作,并降低总拥有成本。
  • 存储:存储空间直通
    • 卷配置(嵌套双向镜像与嵌套镜像加速奇偶校验)
    • 磁盘配置(缓存、层)
  • 确保群集节点物理上位于同一机架中,并且连接到同一 ToR 交换机。
  • 规划 IP 地址预留以配置 AKS 主机、工作负载群集、群集 API 服务器、Kubernetes 服务和应用程序服务。 Microsoft 建议为 Azure Stack HCI 上的 AKS 部署至少预留 256 个 IP 地址。
  • 考虑实现入口控制器,使其在第 7 层工作并使用更智能的规则来分配应用程序流量。
  • 对大量工作负载使用图形处理单元 (GPU) 加速。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

其他参与者:

后续步骤