部署 AKS 节点的网络概念
适用于:Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS
可以为 Azure Arc 启用的 AKS 网络体系结构选择两个 IP 地址分配模型。AKS 支持多个用于Azure Kubernetes 服务 (AKS) 的部署选项。
- 静态 IP 网络:虚拟网络将静态 IP 地址分配给 Kubernetes 群集 API 服务器、Kubernetes 节点、基础 VM、负载均衡器,以及群集上运行的任何 Kubernetes 服务。
- DHCP 网络:虚拟网络使用 DHCP 服务器将动态 IP 地址分配给 Kubernetes 节点、基础 VM 和负载均衡器。 向 Kubernetes 群集 API 服务器和基于群集运行的任何 Kubernetes 服务分配的仍是静态 IP 地址。
注意
此处为 AKS Arc 定义的虚拟网络体系结构可能与数据中心中的基础物理网络体系结构不同。
虚拟 IP 池
虚拟 IP (VIP) 池是 AKS Arc 中任何部署必需的 IP 地址集。VIP 池是一系列保留的 IP 地址,用于将 IP 地址分配给 Kubernetes 群集 API 服务器。 它保证始终能够访问 Kubernetes 服务上的应用程序。 请记住,无论选择哪种虚拟网络模型和地址分配模型,都必须为 AKS 主机部署提供 VIP 池。
VIP 池中的 IP 地址数取决于计划用于部署的工作负载群集和 Kubernetes 服务的数量。
根据网络模型,VIP 池定义在以下方面有所不同:
- 静态 IP:如果使用静态 IP,请确保虚拟 IP 地址来自提供的同一子网。
- DHCP:如果网络配置了 DHCP,请与网络管理员协作,从用于 Azure Stack HCI 部署 AKS 的 DHCP 范围中排除 VIP 池 IP 范围。
Kubernetes 节点 VM IP 池
Kubernetes 节点部署为 AKS Arc 中的专用虚拟机。AKS 将 IP 地址分配给这些虚拟机,以启用 Kubernetes 节点之间的通信。
- 静态 IP:必须指定 Kubernetes 节点 VM IP 池范围。 此范围中的 IP 地址数取决于你计划用于在 AKS 主机和工作负载 Kubernetes 群集中部署的 Kubernetes 节点总数。 请记住,更新在更新期间使用一到三个额外的 IP 地址。
- DHCP:无需指定 Kubernetes 节点 VM 池,因为 Kubernetes 节点的 IP 地址由网络上的 DHCP 服务器动态分配。
采用静态 IP 网络的虚拟网络(推荐)
此网络模型会创建一个虚拟网络,将静态定义的地址池中的 IP 地址分配给部署中的所有对象。 使用静态 IP 网络的一个额外好处是,可以保证长期的部署和应用程序工作负荷始终都可供访问。
定义采用静态 IP 配置的虚拟网络时,请指定以下参数:
重要
部署 AKS 主机或工作负荷群集后,此版本的 AKS 不允许进行任何网络配置更改。 若要更改网络设置,必须通过删除工作负载群集 () 并卸载 AKS 来重新开始。
名称:虚拟网络的名称。
地址前缀:要用于子网的 IP 地址前缀。
网关:子网的默认网关的 IP 地址。
DNS 服务器:指向要用于子网的 DNS 服务器的 IP 地址的数组。 最少可以提供 1 个服务器,最多提供 3 个。
Kubernetes 节点 VM 池:用于 Kubernetes 节点 VM 的连续 IP 地址范围。
虚拟 IP 池:用于 Kubernetes 群集 API 服务器和 Kubernetes 服务的连续 IP 地址范围。
注意
VIP 池必须与 Kubernetes 节点 VM 池位于同一子网。
vLAN ID:虚拟网络的 vLAN ID。 如果省略,则不标记虚拟网络。
采用 DHCP 网络的虚拟网络
此网络模型会创建一个虚拟网络,采用 DHCP 将 IP 地址分配给部署中的所有对象。
当你定义采用静态 IP 配置的虚拟网络时,必须指定以下参数:
重要
在此版本的 AKS 中,部署 AKS 主机或工作负荷群集后,无法更改网络配置。 更改网络设置的唯一方法是通过删除工作负载群集 () 并卸载 AKS 来重新启动。
名称:虚拟网络的名称。
虚拟 IP 池:要用于 Kubernetes 群集 API 服务器和 Kubernetes 服务的连续 IP 地址范围。
注意
VIP 池地址需要与 DHCP 范围位于同一子网中,并且为了避免地址冲突,必须从 DHCP 范围中排除这些地址。
vLAN ID:虚拟网络的 vLAN ID。 如果省略,则不标记虚拟网络。
Microsoft 本地云服务
Microsoft 本地云 (MOC) 是一种管理堆栈,支持在云中管理 Azure Stack HCI 和基于 Windows Server 的 SDDC 上的虚拟机。 MOC 包括:
- 部署在群集中的高度可用
cloud agent
服务的单个实例。 此代理在 Azure Stack HCI 或 Windows Server 群集内的任意一个节点上运行,并配置为故障转移到另一个节点。 - 在每个 Azure Stack HCI 物理节点上运行的
node agent
。
若要启用与 MOC 的通信,必须提供用于服务的 IP 地址 CIDR。 -cloudserviceCIDR
是 Set-AksHciConfig
命令中的一个参数,用于将 IP 地址分配给云代理服务并实现云代理服务的高可用性。
MOC 服务的 IP 地址选择取决于 Azure Stack HCI 或 Windows Server 上的群集部署使用的基础网络模型。
注意
MOC 服务的 IP 地址分配与 Kubernetes 虚拟网络模型无关。 IP 地址分配取决于基础物理网络,以及为数据中心中的 Azure Stack HCI 或 Windows Server 群集节点配置的 IP 地址。
使用基于 DHCP 的 IP 地址分配模式的 Azure Stack HCI 和 Windows Server 群集节点:如果从物理网络上存在的 DHCP 服务器为 Azure Stack HCI 节点分配了 IP 地址,则无需向 MOC 服务显式提供 IP 地址,因为 MOC 服务也会从 DHCP 服务器接收 IP 地址。
使用静态 IP 分配模型的 Azure Stack HCI 和 Windows Server 群集节点:如果为 Azure Stack HCI 群集节点分配了静态 IP 地址,则必须为 MOC 云服务显式提供 IP 地址。 MOC 服务的 IP 地址必须与 Azure Stack HCI 和 Windows Server 群集节点的 IP 地址位于同一子网中。 若要为 MOC 服务显式分配 IP 地址,请在
Set-AksHciConfig
命令中使用-cloudserviceCIDR
参数。 请确保输入 CIDR 格式的 IP 地址,例如“10.11.23.45/16”。
网络模型的比较
DHCP 和静态 IP 在 Azure Stack HCI 和 Windows Server 上的 AKS 部署上提供网络连接。 不过,这两个模型各有优缺点。 从较高层面讲,需要考虑以下因素:
DHCP - 不保证 AKS 部署中某些资源类型的长期 IP 地址。 - 如果部署超出最初的预期大小,则支持扩展保留的 DHCP IP 地址。
静态 IP - 保证 AKS 部署中所有资源的长生存期 IP 地址。 - 由于不支持自动扩展 Kubernetes 节点 IP 池,因此,在用尽 Kubernetes 节点 IP 池后,可能会无法创建新的群集。
下表比较了静态 IP 和 DHCP 网络模型的资源 IP 地址分配情况:
功能 | 静态 IP | DHCP |
---|---|---|
Kubernetes 群集 API 服务器 | 使用 VIP 池静态分配。 | 使用 VIP 池静态分配。 |
Kubernetes 节点(在虚拟机上) | 使用 Kubernetes 节点 IP 池进行分配。 | 动态分配。 |
Kubernetes 服务 | 使用 VIP 池静态分配。 | 使用 VIP 池静态分配。 |
HAProxy 负载均衡器 VM | 使用 Kubernetes 节点 IP 池进行分配。 | 动态分配。 |
Microsoft 本地云服务 | 取决于 Azure Stack HCI 和 Windows Server 群集节点的物理网络配置。 | 取决于 Azure Stack HCI 和 Windows Server 群集节点的物理网络配置。 |
VIP 池 | 必需 | 必需 |
Kubernetes 节点 VM IP 池 | 必需 | 不支持 |
AKS 部署的最小 IP 地址预留
无论部署模型如何,保留 IP 地址数都仍然保持不变。 本部分介绍需要根据 AKS Arc 部署模型保留的 IP 地址数。
最少 IP 地址预留
至少应为部署预留以下数量的 IP 地址:
群集类型 | 控制平面节点 | 工作器节点 | 对于更新操作 | 负载均衡器 |
---|---|---|---|---|
AKS 主机 | 一个 IP | NA | 两个 IP | NA |
工作负载群集 | 每个节点一个 IP | 每个节点一个 IP | 5 个 IP | 一个 IP |
此外,至少应为 VIP 池预留以下数量的 IP 地址:
资源类型 | IP 地址数 |
---|---|
群集 API 服务器 | 每个群集 1 个 |
Kubernetes 服务 | 每个服务 1 个 |
应用程序服务 | 计划每个服务 1 个 |
如你所看到的,所需的 IP 地址数是可变的,具体取决于 AKS 部署的体系结构,以及在 Kubernetes 群集上运行的服务数。 建议为部署最少保留 256 个 IP 地址(/24 子网)。
分步演示示例部署
Jane 是一名 IT 管理员,刚从 Azure Arc 启用的 AKS 开始。她想要在 Azure Stack HCI 群集上部署两个 Kubernetes 群集:Kubernetes 群集 A 和 Kubernetes 群集 B。 她还需要基于自己的群集运行一个投票应用程序。 此应用程序有在两个群集中运行的 3 个前端 UI 实例,还有 1 个后端数据库实例。
- Kubernetes 群集 A 具有 3 个控制平面节点和 5 个工作器节点。
- Kubernetes 群集 B 有 1 个控制平面节点和 3 个工作器节点。
- 前端 UI 的 3 个实例 (端口 443) 。
- 后端数据库的 1 个实例 (端口 80) 。
根据上表,她必须保留:
- AKS 主机的 3 个 IP 地址 (一个 IP 用于控制平面节点,两个 IP 用于) 运行更新操作。
- 群集 A 中控制平面节点的 3 个 IP 地址 (每个控制平面节点) 一个 IP。
- 群集 A 中工作器节点的 5 个 IP 地址 (每个工作器节点) 一个 IP。
- 另外,群集 A 的 6 个 IP 地址 (5 个 IP 用于运行更新操作,1 个 IP 用于负载均衡器) 。
- 群集 B 中控制平面节点的 1 个 IP 地址 (每个控制平面节点) 一个 IP。
- 群集 B 中工作器节点的 3 个 IP 地址 (每个工作器节点) 一个 IP。
- 另外,群集 B 的 6 个 IP 地址 (5 个 IP 用于运行更新操作,1 个 IP 用于负载均衡器) 。
- Kubernetes 群集 API 服务器的 2 个 IP 地址 (每个 Kubernetes 群集) 一个 IP。
- Kubernetes 服务的 3 个 IP 地址 (每个前端 UI 实例的一个 IP 地址,因为它们都使用相同的端口。后端数据库可以使用三个 IP 地址中的任何一个,只要它将使用不同的端口) 。
如前所述,Jane 总共需要 32 个 IP 地址才能部署群集。 因此,Jane 应为其虚拟网络保留一个 /26 子网。
基于静态 IP 网络模型拆分保留的 IP 地址
保留的 IP 地址的总数保持不变,由部署模型决定如何在 IP 组中分配这些 IP 地址。 静态 IP 网络模型具有 2 个 IP 池:
- Kubernetes 节点 VM IP 池:适用于 Kubernetes 节点 VM 和负载均衡器 VM。 此 IP 池还包括运行更新操作所需的 IP 地址。
- 虚拟 IP 池:适用于 Kubernetes API 服务器和 Kubernetes 服务。
使用此示例,Jane 必须在 VIP 池和 Kubernetes 节点 IP 池中进一步划分这些 IP 地址:
- 将 32 个 IP 地址中的 5 个(2 个用于 Kubernetes 群集 API 服务器,3 个用于 Kubernetes 服务)用于她的 VIP 池。
- 将其他 27 个(所有 IP 地址均用于 Kubernetes 节点和底层 VM、负载均衡器 VM 和更新操作)用于她的 Kubernetes 节点 IP 池。
基于 DHCP 网络模型拆分保留的 IP 地址
尽管保留 IP 地址的总数保持不变,但部署模型将决定如何将这些 IP 地址划分到多个 IP 组。 如前文所述,DHCP 网络模型具有 1 个 IP 范围:
- 虚拟 IP 池:适用于 Kubernetes API 服务器和 Kubernetes 服务
使用上一个示例:
- Jane 必须在她的 DHCP 服务器上总共保留 32 个 IP 地址或保留一个 /26 子网。
- 她必须将 32 个 IP 地址中的 5 个(2 个用于 Kubernetes 群集 API 服务器,3 个用于 Kubernetes 服务)从 DHCP 范围中排除以用于她的 VIP 池
入口控制器
在部署目标群集期间,会创建基于 HAProxy
的负载均衡器资源。 负载均衡器配置为在给定端口上将流量分配到服务中的 Pod。 负载均衡器仅在第 4 层工作,这表示服务不知道实际应用程序;也就是说,它不能进行任何其他路由注意事项。
入口控制器在第 7 层工作,可使用更智能的规则来分发应用程序流量。 入口控制器的常见用途是根据入站 URL 将 HTTP 流量路由到不同的应用程序。
后续步骤
本文介绍了在 Azure Stack HCI 上部署 AKS 节点的一些网络概念。 有关详细信息,请参阅以下文章:
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈