通过

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

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

  • 项目

设计注意事项

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 连接的额外跃点。 还可以使用 Azure CNI 覆盖满足 AKS 出口要求。

有关每个网络模型推荐用例的摘要，请参阅 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 地址（而非公共 IP 地址）公开 Kubernetes API。 此专用 IP 地址通过专用终结点在 AKS 虚拟网络中表示。 Kubernetes API 不应通过其 IP 地址访问，而应通过其完全限定域名 (FQDN) 访问。 从 Kubernetes API FQDN 到其 IP 地址的解析通常由 Azure 专用 DNS 区域执行。 此 DNS 区域可以由 Azure 在 AKS 节点资源组中创建，也可以指定现有的 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 地址后，到 Kubernetes API 的流量会从本地路由到 Azure 中的 VPN 或 ExpressRoute 网关，具体取决于连接模型。
  3. 专用终结点将在中心虚拟网络中引入路由 /32 。 VPN 和 ExpressRoute 网关会将流量直接发送到 AKS 虚拟网络中部署的 Kubernetes API 专用终结点。

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

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

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

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

  • 配置应符合出口筛选设计，以避免非对称路由。 UDR 可能会导致非对称路由，但不一定如此。 应用程序网关流量上的 SNAT，这意味着如果仅为 Internet 流量设置 UDR，则返回流量将返回到应用程序网关节点，而不是 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 地址，客户端通过公共 Internet 访问该地址。
  3. 应用程序网关访问 AKS 中部署的工作负荷。

注意

这些流程仅对 Web 应用程序有效。 非 Web 应用程序不在本文的讨论范围内，它们可以通过中心虚拟网络中的 Azure 防火墙公开，如果使用虚拟 WAN 连接模型，则可以通过安全虚拟中心公开。

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

从 AKS Pod 到后端服务的流量

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

如果对后端流量使用 Azure 专用终结点，则可以使用 Azure 私人 DNS 区域执行 Azure 服务的 DNS 解析。 由于整个环境的 DNS 解析器都位于中心虚拟网络（或共享服务虚拟网络（如果使用的是虚拟 WAN 连接模型）），因此应在连接订阅中创建这些专用区域。 要创建解析专用服务的 FQDN 所需的 A 记录，可以将专用 DNS 区域（在连接订阅中）与专用终结点（在应用程序订阅中）相关联。 此操作需要这些订阅中的某些特权。

可以手动创建 A 记录，但将专用 DNS 区域与专用终结点相关联可以减少设置配置错误的可能性。

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

后端流量

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

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

设计建议

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

有关 AKS 中三个网络模型之间的功能比较;Kubenet、Azure CNI 和 Azure CNI 覆盖层，请参阅 “比较 AKS 中的网络模型”。