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

AKS 的网络拓扑和连接注意事项

重要

弃用通知： 本文已弃用，不再更新。 为了确保仅显示最佳指南，本文将于 2026 年 5 月删除。

有关替代指南，请参阅 Azure 体系结构中心中的 Azure Kubernetes 服务 体系结构指南。

若要保存本指南，可以选择本页左下角的 Download a PDF，或从 GitHub。

设计注意事项

Azure Kubernetes 服务 (AKS)为容器网络提供三种不同的网络模型：Kubenet、CNI 覆盖层和 CNI。 其中每个模型都有其独特的特性和优势，为 AKS 中的容器网络提供灵活性和可伸缩性选项。

Kubenet

Kubenet 是一种基本的网络解决方案，可节省 IP 地址空间并提供简单的配置。 它非常适合使用少于 400 个节点的小型 AKS 群集，可在其中手动管理和维护用户定义的路由。 它适用于内部或外部负载均衡器足以从群集外部访问 Pod 的场景。

Azure CNI

Azure CNI 是专为高级网络设计的网络模型。 它为 pod 提供完整的虚拟网络连接，允许 pod 到 pod 和 pod 到 VM 连接。 它非常适合需要高级 AKS 功能（如虚拟节点）的方案。 它适用于 IP 地址空间充足且外部资源需要直接访问 Pod 的场景。 Azure CNI 也支持 AKS 网络策略。

Azure CNI 叠加

Azure CNI 覆盖旨在解决 IP 地址短缺问题并简化网络配置。 它适用于可以扩展到 1000 个节点、每个节点支持 250 个 Pod 的场景，并且可以接受 Pod 连接时增加的跳数。 AKS 的出站要求也可以通过 Azure CNI Overlay 来满足。

有关每个网络模型推荐用例的摘要，请参阅 AKS 中的网络模型比较。

此外，在设计 AKS 群集时，请务必仔细规划虚拟网络子网的 IP 寻址和大小以支持缩放。 虚拟节点可用于快速群集缩放，但存在一些已知限制。

AKS 群集支持基本和标准Azure 负载均衡器 SKU，服务可以通过公共或内部负载均衡器公开。 AKS 使用 CoreDNS 为群集中运行的 Pod 提供名称解析，可以通过Azure 防火墙或网络虚拟设备群集发送出站（出口）网络流量。

默认情况下，AKS 群集中的所有 Pod 都可以无限制地发送和接收流量。 但是，Kubernetes 网络策略可用于改进安全性和筛选 AKS 群集中 Pod 之间的网络流量。 AKS 提供了两种网络策略模型：Azure网络策略和 Calico。

最后，AKS 在部署群集的子网上设置网络安全组（NSG）。 建议不要手动编辑此 NSG，但在 AKS 中部署的服务可能会影响它。

总的来说，选择适当的网络模型并仔细规划网络资源有助于优化 AKS 群集的性能、安全性和成本。

私有群集

AKS 群集 IP 可见性可以是公共的，也可以是专用的。 专用群集 通过专用 IP 地址公开 Kubernetes API，而不是通过公共 IP 地址公开。 此专用 IP 地址通过 专用终结点在 AKS 虚拟网络中表示。 不应通过其 IP 地址访问 Kubernetes API，而是应通过其完全限定的域名（FQDN）进行访问。 Kubernetes API FQDN 到其 IP 地址的解析通常由 Azure 专用 DNS 区域执行。 可以通过 AKS 节点资源组中的Azure创建此 DNS 区域，也可以指定存在 DNS 区域。

遵循企业规模经过验证的做法，Azure工作负载的 DNS 解析由部署在连接订阅中的集中式 DNS 服务器提供，无论是在中心虚拟网络中还是在连接到Azure 虚拟 WAN的共享服务虚拟网络中。 这些服务器将使用 Azure DNS（IP 地址 168.63.129.16）有条件地解析 Azure 特定和公共名称，并使用公司 DNS 服务器解析私有名称。 但是，这些集中式 DNS 服务器在连接到为 AKS 群集创建的 DNS 专用区域之前，将无法解析 AKS API FQDN。 每个 AKS 都有一个唯一的 DNS 专用区域，因为在区域名称前添加了一个随机 GUID。 因此，对于每个新的 AKS 群集，其相应的专用 DNS 区域应连接到中央 DNS 服务器所在的虚拟网络。

应将所有虚拟网络配置为使用这些中央 DNS 服务器进行名称解析。 但是，如果 AKS 虚拟网络配置为使用中央 DNS 服务器，并且这些 DNS 服务器尚未连接到专用 DNS 区域，AKS 节点将无法解析 Kubernetes API 的 FQDN，并且 AKS 群集的创建将失败。 AKS 虚拟网络应配置为仅在创建群集后使用中央 DNS 服务器。

创建群集后，在 DNS 专用区域与部署中央 DNS 服务器的虚拟网络之间创建连接。 AKS 虚拟网络还被配置为使用连接性订阅中的中央 DNS 服务器，而对 AKS Kubernetes API 的管理员访问将遵循以下步骤：

显示专用群集网络的示意图。

注释

本文中的图像反映了使用传统中心和辐射连接模型的设计。 企业规模登陆区域可以选择虚拟 WAN连接模型，其中中央 DNS 服务器将位于连接到虚拟 WAN中心的共享服务虚拟网络中。

  1. 管理员解析 Kubernetes API 的 FQDN。 本地 DNS 服务器将请求转发到权威服务器：Azure中的 DNS 解析程序。 这些服务器将请求转发到Azure DNS服务器（168.63.129.16），该服务器将从Azure 专用 DNS区域获取 IP 地址。
  2. 解析 IP 地址后，将流量从本地路由到 Azure 中的 VPN 或 ExpressRoute 网关，具体取决于连接模型。
  3. 专用终结点将在中心虚拟网络中引入 /32 路由。 VPN 和 ExpressRoute 网关会将流量直接发送到 AKS 虚拟网络中部署的 Kubernetes API 专用终结点。

从应用程序用户到群集的流量

传入（入口）控制器可用于公开 AKS 群集中运行的应用程序。

  • 入口控制器提供应用程序级路由，但这会稍微增加复杂性。
  • 入口控制器可以集成Web应用防火墙（WAF）功能。
  • 入口控制器可以在集群外部和集群内部运行：
    • 群集外入口控制器将计算（如 HTTP 流量路由或 TLS 终止）卸载到 AKS 外部的另一个服务，例如 Azure 应用程序网关 入口控制器（AGIC）加载项。
    • 群集内解决方案使用 AKS 群集资源进行计算（例如 HTTP 流量路由或 TLS 终止）。 群集内入口控制器可以提供更低的成本，但它们需要仔细的资源规划和维护。
  • 基本 HTTP 应用程序路由加载项易于使用，但 HTTP 应用程序路由中记录了一些限制。

入口控制器可以使用公共或专用 IP 地址公开应用程序和 API。

  • 配置应与出口筛选设计保持一致，以避免非对称路由。 UDR 可能会导致非对称路由（可能），但不一定。 应用程序网关可以对流量执行 SNAT，这意味着如果 UDR 仅为 Internet 流量设置，返回流量将返回到应用程序网关节点，而不是通过 UDR 路由。
  • 如果需要 TLS 终止，则必须考虑 TLS 证书的管理。

应用程序流量可以来自本地或公共 Internet。 下图描述了一个示例，其中Azure 应用程序网关配置为从本地和公共 Internet 到群集的反向代理连接。

显示应用程序相关的网络流量的关系图。

来自本地的网络流量遵循前一个图中编号的蓝色标注顺序。

  1. 客户端通过使用连接服务中的 DNS 服务器或本地的 DNS 服务器来解析分配给应用程序的 FQDN。
  2. 将应用程序 FQDN 解析为 IP 地址（应用程序网关的专用 IP 地址）后，流量将通过 VPN 或 ExpressRoute 网关进行路由。
  3. 网关子网中的路由配置为将请求发送到 Web 应用程序防火墙。
  4. Web 应用程序防火墙将有效请求发送到 AKS 群集中运行的工作负荷。

此示例中的Azure 应用程序网关可以部署在 AKS 群集所在的同一订阅中，因为它的配置与 AKS 中部署的工作负荷密切相关，因此由同一应用程序团队管理。 Internet 访问遵循上一图中标注的绿色编号流程。

  1. 来自公共 Internet 的客户端使用 Azure 流量管理器 解析应用程序的 DNS 名称。 或者，可以使用其他全局负载均衡技术，例如 Azure Front Door。
  2. 应用程序的公共 FQDN 将由流量管理器解析为应用程序网关的公共 IP 地址，客户端通过公共互联网访问该网关。
  3. 应用程序网关访问 AKS 中部署的工作负荷。

注释

这些流仅适用于 Web 应用程序。 非 Web 应用程序不在本文的作用域之外，并且可以使用中心虚拟网络中的Azure 防火墙或安全虚拟中心（如果使用虚拟 WAN连接模型）公开这些应用程序。

或者，可以让基于 Web 的应用程序的流量同时穿过连接订阅中的 Azure 防火墙和 AKS 虚拟网络中的 WAF。 此方法具有提供更多保护的优势，例如使用基于智能的筛选Azure 防火墙基于智能的筛选来删除来自 Internet 中已知恶意 IP 地址的流量。 但是，也有一些缺点。 例如，在公开应用程序时，丢失原始客户端 IP 地址，以及防火墙与应用程序团队之间所需的额外协调。 这是因为目标网络地址转换（DNAT）规则需要在Azure 防火墙中使用。

从 AKS Pod 到后端服务的流量

AKS 群集中运行的 Pod 可能需要访问后端服务，例如Azure 存储、Azure SQL数据库或Azure Cosmos DB NoSQL数据库。 虚拟网络服务终结点和专用链接可用于保护与这些Azure托管服务的连接。

如果您使用 Azure 专用终结点来管理后端的流量，对 Azure 服务的 DNS 解析可以通过 Azure 专用 DNS 区域完成。 由于整个环境的 DNS 解析程序位于中心虚拟网络（如果使用虚拟 WAN连接模型时共享服务虚拟网络），因此应在连接订阅中创建这些专用区域。 若要创建解析专用服务的 FQDN 所需的 A 记录，可以将专用 DNS 区域（在连接订阅中）与专用终结点（在应用程序订阅中）相关联。 此操作需要这些订阅中的某些权限。

将专用DNS区域与专用终结点关联，可以手动创建A记录，但这样设置更不容易出现配置错误。

从 AKS Pod 到通过专用终结点公开的 Azure PaaS 服务的后端连接遵循以下顺序：

后端流量

  1. AKS Pod 使用连接订阅中的中央 DNS 服务器（定义为 AKS 虚拟网络中的自定义 DNS 服务器）解析Azure平台即服务（PaaS）的 FQDN。
  2. 解析出的 IP 是用于从 AKS 工作负载直接访问专用终结点的专用 IP 地址。

默认情况下，AKS Pod 与专用终结点之间的流量不会通过中心虚拟网络中的 Azure 防火墙（或使用 虚拟 WAN 时为安全虚拟中心），即使 AKS 群集配置为使用 Azure 防火墙 进行出站筛选。 原因是专用终结点在部署 AKS 的应用程序虚拟网络的子网中创建 /32 路由。

设计建议

  • 如果安全策略要求使用专用 IP 地址（而不是公共 IP 地址）的 Kubernetes API， 请部署专用 AKS 群集。
    • 在创建专用群集时使用自定义专用 DNS 区域，而不是让创建过程使用 系统专用 DNS 区域。
  • 建议使用 Azure 容器网络接口（CNI）作为网络模型，但如果您的 AKS 群集可分配的 IP 地址范围有限，请另作考虑。
  • 使用 Azure DDoS 防护来保护用于 AKS 群集的虚拟网络无需在集中式订阅中使用 Azure 防火墙 或 WAF。
  • 使用与整个网络设置相关联的 DNS 配置，包括 Azure 虚拟 WAN 和中心辐射架构、Azure DNS 区域，以及您的 DNS 基础设施。
  • 使用专用链接保护网络连接，并使用基于 IP 的专用连接连接到支持专用链接的其他托管Azure服务，例如Azure 存储、Azure 容器注册表、Azure SQL 数据库和Azure 密钥保管库。
  • 使用入口控制器提供高级 HTTP 路由和安全性，并为应用程序提供单个终结点。
  • 配置为使用入口的所有 Web 应用程序都应使用 TLS 加密，不允许通过未加密的 HTTP 进行访问。 如果订阅在 策略中包含企业规模登陆区域的参考实现，该策略已被强制实施。
  • （可选）若要节省 AKS 群集的计算和存储资源，请使用群集外入口控制器。
    • 使用Azure 应用程序网关入口管理器（AGIC）加载项，这是由Azure托管的第一方服务。
    • 使用 AGIC，为每个 AKS 群集部署专用Azure 应用程序网关，并且不会跨多个 AKS 群集共享相同的应用程序网关。
    • 如果没有资源或操作约束，或者 AGIC 不提供所需的功能，请使用集群内的 Ingress 控制器解决方案，例如 NGINX、Traefik 或 Kubernetes 支持的任何其他解决方案。
  • 对于面向互联网和安全关键的内部 Web 应用程序，请使用带有入口控制器的 Web 应用程序防火墙。
  • 如果安全策略要求检查 AKS 群集中生成的所有出站 Internet 流量，请使用Azure 防火墙或托管中心虚拟网络中部署的第三方网络虚拟设备（NVA）保护出口网络流量。 有关详细信息，请参阅 限制出口流量。 AKS outbound 类型 UDR需要将路由表关联到 AKS 节点子网，因此它目前不能与Azure 虚拟 WAN或Azure 路由服务器支持的动态路由注入一起使用。
  • 对于非专用群集，请使用授权 IP 范围。
  • 使用标准层，而不是Azure 负载均衡器的基本层。
  • 在 Azure 中设计 Kubernetes 群集时，一个关键注意事项是选择适当的网络模型以满足特定要求。 Azure Kubernetes 服务 (AKS)提供三种不同的网络模型：Kubenet、Azure CNI 和 Azure CNI 覆盖。 若要做出明智的决策，必须了解每个模型的功能和特征。

如需比较 AKS 中的三个网络模型：Kubenet、Azure CNI 和 Azure CNI Overlay 的功能，请参阅 AKS 中的网络模型比较。

  • Last updated on