通过

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

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

  • 项目

在 Azure Kubernetes 服务 (AKS) 中，虽然建议将 Azure CNI 覆盖和 Azure CNI Pod 子网用于大多数场景，但 Azure CNI 节点子网和 kubenet 等旧的网络模型仍然可用并受支持。 这些旧的模型提供了不同的 Pod IP 地址管理和网络方法，每种方法都有自己的功能和注意事项。 本文概述了这些旧的网络选项，详细介绍了它们的先决条件、部署参数和主要特点，以帮助你了解它们的作用以及如何在 AKS 群集中有效使用它们。

先决条件

Azure CNI 节点子网和 kubenet 需要以下先决条件：

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

  • AKS 群集不得将 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16 或 192.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 范围内的流量。 有关详细信息，请参阅网络安全组。

注意

Kubenet 不适用于 Windows Server 容器。 若要使用 Windows Server 节点池，需要使用 Azure CNI。

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/16、172.30.0.0/16、172.31.0.0/16 或 192.0.2.0/24 范围内。

虽然可以在与群集相同的虚拟网络内指定服务地址范围，但我们不建议这样做。 重叠的 IP 范围可能导致不可预测的行为。 有关详细信息，请参阅常见问题解答。 有关 Kubernetes 服务的详细信息，请参阅 Kubernetes 文档中的服务。

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

Kubenet

默认情况下，AKS 群集使用 kubenet，并为你创建 Azure 虚拟网络和子网。 节点使用 kubenet 从 Azure 虚拟网络子网获取 IP 地址。 Pod 接收从逻辑上不同的地址空间到节点的 Azure 虚拟网络子网的 IP 地址。 然后配置网络地址转换 (NAT)，以便 Pod 可以访问 Azure 虚拟网络上的资源。 流量的源 IP 地址通过 NAT 转换为节点的主 IP 地址。 这种方法大大减少了需要在网络空间中保留供 Pod 使用的 IP 地址数量。

可以在创建群集时或新建节点池时，配置可部署到节点的最大 Pod 数。 如果在创建新节点池时未指定 maxPods，则会收到 kubenet 的默认值 110。

使用自有子网的 kubenet 网络概述

在许多环境中，你已定义分配了 IP 地址范围的虚拟网络和子网，并且你会使用这些资源来支持多个服务和应用程序。 若要提供网络连接，AKS 群集可以使用 kubenet（基本网络）或 Azure CNI（高级网络）。

使用 kubenet 时，只有节点接收虚拟网络子网中的 IP 地址。 Pod 无法直接相互通信。 用户定义的路由 (UDR) 和 IP 转发处理不同节点中 Pod 之间的连接。 默认情况下，UDR 和 IP 转发配置由 AKS 服务进行创建和维护，但如果需要，你可以自带路由表以进行自定义路由管理。 此外，可以在接收分配的 IP 地址的服务后面部署 Pod，并对应用程序的流量进行负载均衡。 下图显示了 AKS 节点（不是 Pod）如何接收虚拟网络子网中的 IP 地址：

示意图显示两个节点，上面三个 Pod 都在覆盖网络中运行。到集群外部终结点的 Pod 流量通过 NAT 进行路由。

Azure 在一个 UDR 中最多支持 400 个路由，因此，AKS 群集中的节点数不能超过 400 个。 kubenet 不支持 AKS 虚拟节点和 Azure 网络策略。 支持 Calico 网络策略。

Kubenet 的限制和注意事项

注意

群集中的某些系统 Pod（例如 konnectivity）使用主机节点 IP 地址，而不使用覆盖地址空间中的 IP。 系统 Pod 仅使用节点 IP，而不使用虚拟网络中的 IP 地址。

IP 地址可用性和耗尽

Azure CNI 的一个常见问题是分配的 IP 地址范围太小，无法在扩展或升级群集时添加更多节点。 网络团队可能无法提供足够大的 IP 地址范围来支持预期的应用程序需求。 作为一种折衷方案，可以创建使用 kubenet 的 AKS 群集并连接到现有虚拟网络子网。 这种方法可让节点接收定义的 IP 地址，而无需提前为群集中可能运行的所有潜在 Pod 节点预留大量的 IP 地址。

使用 kubenet 时，可以大幅减小要使用的 IP 地址范围，并且可以支持大型群集和应用程序的需求。 例如，在子网上使用 /27 IP 地址范围时，可运行包括 20-25 个节点的群集，空间足以进行缩放或升级。 此群集大小最多支持 2,200-2,750 个 Pod（每个节点的最大 Pod 数默认为 110 个）。 可以在 AKS 中使用 kubenet 配置的每个节点的最大 Pod 数为 250。

以下基本计算方法对网络模型的差异做了比较：

  • kubenet：一个简单的 /24 IP 地址范围可以支持群集中最多 251 个节点。 每个 Azure 虚拟网络子网保留前三个 IP 地址用于管理操作。 此节点计数最多支持 27,610 个 Pod（每个节点的最大 Pod 数默认为 110 个）。
  • Azure CNI：相同的基本 /24 子网范围最多只能支持群集中的 8 个节点。 此节点数最多只能支持 240 个 Pod（每个节点的最大 Pod 数默认为 30 个）。

注意

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

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

可以将 Azure 虚拟网络对等互联或 ExpressRoute 连接与 Azure CNI 和 kubenet 结合使用以提供内部连接。 确保精心规划 IP 地址，以防止地址重叠和流量路由错误。 例如，许多本地网络使用通过 ExpressRoute 连接播发的 10.0.0.0/8 地址范围。 建议在此地址范围（例如 172.16.0.0/16）外部的 Azure 虚拟网络子网中创建 AKS 群集。

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

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 实施了 Microsoft Azure 容器网络基础结构，该基础结构提供端到端体验。 因此，它不再使用传统 Azure CNI 仍在使用的 ip-masq-agent。

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

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

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

    默认情况下，AKS 群集使用 kubenet 并创建虚拟网络和子网络。 使用 kubenet，节点从虚拟网络子网获取 IP 地址。 然后会在节点上配置网络地址转换 (NAT)，并且 Pod 将接收“隐藏”在节点 IP 背后的 IP 地址。 这种方法减少了需要在网络空间中保留供 Pod 使用的 IP 地址数量。

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

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

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

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

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

    但对于用于动态 IP 分配的 Azure CNI，无论连接位于同一虚拟网络中还是跨虚拟网络，Pod IP 始终是来自 Pod 的任何流量的来源地址。 这是因为用于动态 IP 分配的 Azure CNI 实施了 Microsoft 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 可能是子网中另一资源正在使用的，导致不可预测的行为或故障。 如果能够确保所用地址范围不在群集的虚拟网络中，则可避免这种重叠风险。