AKS 旧式容器网络接口 (CNI)

重要

2028 年 3 月 31 日,Azure Kubernetes 服务 (AKS) 的 kubenet 网络将停用。

为了避免服务中断,需要在该日期之前升级到 Azure 容器网络接口 (CNI) 覆盖层,届时将不再支持在 AKS 的 kubenet 上运行的工作负荷。

在 Azure Kubernetes 服务(AKS)中,尽管大多数情况下建议使用 Azure CNI 覆盖Azure CNI Pod 子网 ,但 Azure CNI 节点子网和 kubenet 等旧网络模型仍可用且受支持。 这些旧模型提供 Pod IP 地址管理和网络的不同方法,每个方法都有自己的一组功能和注意事项。 本文概述了这些旧网络选项,详细介绍了其先决条件、部署参数和关键特征,以帮助你了解其角色以及如何在 AKS 群集中有效使用它们。

先决条件

Azure CNI 节点子网需要满足以下先决条件:

  • AKS 群集的虚拟网络必须允许出站 Internet 连接。

  • AKS 群集不得将 169.254.0.0/16172.30.0.0/16172.31.0.0/16192.0.2.0/24 用于 Kubernetes 服务地址范围、Pod 地址范围或群集虚拟网络地址范围。

  • AKS 群集使用的群集标识必须至少对虚拟网络中的子网具有 网络参与者 权限。 如果要定义 自定义角色 而不是使用内置网络参与者角色,则需要以下权限:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write
  • 分配给 AKS 节点池的子网不能是委托子网

  • AKS 不会将网络安全组 (NSG) 应用于其子网,也不会修改与该子网相关的任何 NSG。 如果提供自己的子网并添加与该子网关联的 NSG,请确保 NSG 中的安全规则允许节点 CIDR 范围内的流量。 有关详细信息,请参阅网络安全组

Azure CNI 节点子网

借助 Azure 容器网络接口 (CNI),每个 Pod 都可以从子网获得 IP 地址,并且可供直接访问。 与 AKS 群集处于同一虚拟网络中的系统将 Pod IP 视为来自 Pod 的任何流量的源地址。 AKS 群集虚拟网络外部的系统将节点 IP 视为来自 Pod 的任何流量的源地址。 这些 IP 地址在网络空间中必须唯一,并且必须事先计划。 每个节点都有一个配置参数来表示它支持的最大 Pod 数。 这样,就会为每个节点预留相应的 IP 地址数。 使用此方法需要经过更详细的规划,并且经常会耗尽 IP 地址,或者在应用程序需求增长时需要在更大的子网中重建群集。

使用 Azure CNI 节点子网,每个 Pod 都会在 IP 子网中接收 IP 地址,并且可以与其他 Pod 和服务直接通信。 群集的最大大小可为指定的 IP 地址范围上限。 但是,必须提前规划 IP 地址范围,AKS 节点根据它们支持的最大 Pod 数消耗所有 IP 地址。 Azure CNI 支持高级网络功能和方案,例如 虚拟节点 或网络策略(Azure 或 Calico)。

部署参数

创建 AKS 群集时,可为 Azure CNI 网络配置以下参数:

虚拟网络:要将 Kubernetes 群集部署到的虚拟网络。 可以创建新的虚拟网络或使用现有虚拟网络。 如果要使用现有的虚拟网络,请确保它与您的 Kubernetes 集群位于相同的位置,并在同一个 Azure 订阅中。 有关 Azure 虚拟网络的限制和配额的信息,请参阅 Azure 订阅和服务限制、配额和约束

子网:要将群集部署到的虚拟网络中的子网。 可以在群集创建过程中将新子网添加到虚拟网络中。 对于混合连接,地址范围不应与环境中的其他任何虚拟网络重叠。

Azure 网络插件:使用 Azure 网络插件时,无法从 clusterCIDR 中具有不属于 AKS 群集的 IP 的 VM 访问“externalTrafficPolicy=Local”的内部 LoadBalancer 服务。

Kubernetes 服务地址范围:该参数是 Kubernetes 分配给群集中的内部服务的一组虚拟 IP。 创建群集后,无法更新此范围。 可以使用任何专用地址范围,只要其符合以下要求即可:

  • 不得在群集的虚拟网络 IP 地址范围内。
  • 与集群虚拟网络进行对等互连的任何其他虚拟网络不得重叠。
  • 不得与任何本地 IP 重叠。
  • 不得在范围169.254.0.0/16172.30.0.0/16172.31.0.0/16192.0.2.0/24范围内。

虽然可以在群集所在的同一虚拟网络中指定服务地址范围,但不建议这样做。 重叠的 IP 范围可能会导致不可预知的行为。 有关详细信息,请参阅常见问题。 有关 Kubernetes 服务的详细信息,请参阅 Kubernetes 文档中的服务

Kubernetes DNS 服务 IP 地址:群集 DNS 服务的 IP 地址。 此地址必须在 Kubernetes 服务地址范围内。 请勿使用地址范围内的第一个 IP 地址。 子网范围内的第一个地址用于 kubernetes.default.svc.cluster.local 地址

  • Azure CNI:相同的基本 /24 子网范围只能支持群集中最多 8 个节点。 此节点数最多只能支持 240 个 Pod(每个节点的最大 Pod 数默认为 30 个)。

注释

这些最大值未考虑到帐户升级或扩展操作。 在实践中,不可能会运行子网 IP 地址范围支持的节点数上限。 必须保留一些 IP 地址用于缩放或升级操作。

虚拟网络对等互连和 ExpressRoute 连接

可以将 Azure 虚拟网络对等互连ExpressRoute 连接Azure CNI 配合使用,以提供本地连接。 请确保仔细规划 IP 地址,以防止重叠和不正确的流量路由。 例如,许多本地网络使用通过 ExpressRoute 连接播发的 10.0.0.0/8 地址范围。 建议在此地址范围之外的 Azure 虚拟网络子网中创建 AKS 群集,例如 172.16.0.0/16

有关详细信息,请参阅 比较网络模型及其支持范围

Azure CNI Pod 子网常见问题解答

  • 是否可以在群集子网中部署 VM?

    对于 Azure CNI 节点子网,VM 可以部署在 AKS 群集所在的同一子网中。

  • 外部系统查看什么源 IP 来获取源自某个支持 Azure CNI 的 Pod 的流量?

    与 AKS 群集处于同一虚拟网络中的系统将 Pod IP 视为来自 Pod 的任何流量的源地址。 AKS 群集虚拟网络外部的系统将节点 IP 视为来自 Pod 的任何流量的源地址。 但是,对于 Azure CNI 动态 IP 分配,无论连接位于同一虚拟网络内还是跨虚拟网络,Pod IP 始终是来自 Pod 的任何流量的源地址。 这是因为 用于动态 IP 分配的 Azure CNI 实现了 Azure 容器网络 基础结构,从而提供端到端体验。 因此,它不再使用传统 Azure CNI 仍在使用的 ip-masq-agent

  • 是否可以配置基于 Pod 的网络策略?

    是的,Kubernetes 网络策略在 AKS 中可用。 若要开始使用,请参阅在 AKS 中使用网络策略保护 Pod 之间的流量

  • 可部署到节点的 Pod 数上限是否可配置?

    借助 Azure 容器网络接口 (CNI),每个 Pod 都可以从子网获得 IP 地址,并且可供直接访问。 与 AKS 群集处于同一虚拟网络中的系统将 Pod IP 视为来自 Pod 的任何流量的源地址。 AKS 群集虚拟网络外部的系统将节点 IP 视为来自 Pod 的任何流量的源地址。 这些 IP 地址在网络空间中必须唯一,并且必须事先计划。 每个节点都有一个配置参数来表示它支持的最大 Pod 数。 这样,就会为每个节点预留相应的 IP 地址数。 使用此方法需要经过更详细的规划,并且经常会耗尽 IP 地址,或者在应用程序需求增长时需要在更大的子网中重建群集。

  • 是否可以在群集子网中部署 VM?

    是的。 但对于 Azure CNI 进行动态 IP 分配,VM 不能部署在 Pod 的子网中。

  • 外部系统查看什么源 IP 来获取源自某个支持 Azure CNI 的 Pod 的流量?

    与 AKS 群集处于同一虚拟网络中的系统将 Pod IP 视为来自 Pod 的任何流量的源地址。 AKS 群集虚拟网络外部的系统将节点 IP 视为来自 Pod 的任何流量的源地址。

    但是,对于 Azure CNI 进行动态 IP 分配,无论连接位于同一虚拟网络中还是跨虚拟网络,Pod IP 始终是来自 Pod 的任何流量的源地址。 这是因为 用于动态 IP 分配的 Azure CNI 实现了 Azure 容器网络 基础结构,从而提供端到端体验。 因此,它不再使用传统 Azure CNI 仍在使用的 ip-masq-agent

  • 是否可以在我的群集虚拟网络中将另一子网用于 Kubernetes 服务地址范围?

    此配置是可以的,但建议不要这样做。 该服务地址范围是 Kubernetes 分配给群集中的内部服务的虚拟 IP (VIP) 的集合。 Azure 网络无法查看 Kubernetes 群集的服务 IP 范围。 无法了解群集的服务地址范围可能会导致问题发生。 以后在群集虚拟网络中创建新的子网时,该子网可能与该服务地址范围重叠。 如果出现这种形式的重叠,则 Kubernetes 为服务分配的 IP 可能是子网中另一资源正在使用的,导致不可预测的行为或故障。 如果能够确保所用地址范围不在群集的虚拟网络中,则可避免这种重叠风险。 是的,使用 Azure CLI 或资源管理器模板部署群集时可配置。 请参阅 每个节点的最大 Pod 数

  • 是否可以在我的群集虚拟网络中将另一子网用于 Kubernetes 服务地址范围?

    此配置是可以的,但建议不要这样做。 该服务地址范围是 Kubernetes 分配给群集中的内部服务的虚拟 IP (VIP) 的集合。 Azure 网络无法查看 Kubernetes 群集的服务 IP 范围。 无法了解群集的服务地址范围可能会导致问题发生。 以后在群集虚拟网络中创建新的子网时,该子网可能与该服务地址范围重叠。 如果出现这种形式的重叠,则 Kubernetes 为服务分配的 IP 可能是子网中另一资源正在使用的,导致不可预测的行为或故障。 如果能够确保所用地址范围不在群集的虚拟网络中,则可避免这种重叠风险。