你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Kubernetes 服务 (AKS) 中应用程序的网络概念
在基于容器的微服务应用程序开发方法中，应用程序组件会协同工作以处理其任务。 Kubernetes 提供了各种资源来促成这种合作：
- 可以在内部或外部连接应用程序并将其公开。
- 可以对应用程序进行负载均衡，从而生成高可用性应用程序。
- 可以限制网络流量流入 Pod 和节点或在其间流动以提高安全性。
- 对于更复杂的应用程序，可以配置 SSL/TLS 终止的入口流量或多个组件的路由。
本文介绍了为 AKS 中的应用程序提供网络的核心概念：
Kubernetes 网络基础知识
Kubernetes 使用虚拟网络层来管理应用程序或其组件之内和之间的访问：
Kubernetes 节点和虚拟网络：Kubernetes 节点连接到虚拟网络。 此设置使得 Pod（Kubernetes 中的基本部署单元）具有入站和出站连接性。
Kube-proxy 组件：kube-proxy 在每个节点上运行，并负责提供必要网络功能。
有关特定的 Kubernetes 功能：
- 负载均衡器：可以使用负载均衡器跨各种资源均匀分配网络流量。
- 入口控制器：它们辅助第 7 层路由，这对于定向应用程序流量至关重要。
- 出口流量控制：Kubernetes 让你可以管理和控制来自群集节点的出站流量。
- 网络策略：这些策略实现了安全措施，以及对 Pod 中的网络流量的筛选。
在 Azure 平台的上下文中：
- Azure 简化了 AKS（Azure Kubernetes 服务）群集的虚拟网络。
- 在 Azure 上创建 Kubernetes 负载均衡器时，会同时设置相应的 Azure 负载均衡器资源。
- 打开对 Pod 的网络端口时，Azure 会自动配置必要的网络安全组规则。
- 建立新的入口路由时，Azure 还会管理 HTTP 应用程序路由的外部 DNS 配置。
Azure 虚拟网络
在 AKS 中，可以部署使用以下网络模型之一的群集：
Kubenet 网络
通常在部署 AKS 群集时创建和配置网络资源。
Azure 容器网络接口 (CNI) 网络
AKS 群集连接到现有的虚拟网络资源和配置。
Kubenet（基本）网络
kubenet 网络选项是用于创建 AKS 群集的默认配置。 使用 kubenet：
- 节点从 Azure 虚拟网络子网接收 IP 地址。
- Pod 从逻辑上与节点 Azure 虚拟网络子网不同的地址空间接收 IP 地址。
- 然后配置网络地址转换 (NAT)，以便 Pod 可以访问 Azure 虚拟网络上的资源。
- 流量的源 IP 地址会转换为节点的主 IP 地址。
节点使用 kubenet Kubernetes 插件。 可以让 Azure 平台创建和配置虚拟网络，或选择将 AKS 群集部署到现有虚拟网络子网中。
只有节点才会接收可路由 IP 地址。 Pod 会使用 NAT 与 AKS 群集外部的其他资源通信。 这种方法减少了需要在网络空间中保留供 Pod 使用的 IP 地址数量。
注意
虽然 kubenet 是 AKS 群集创建虚拟网络和子网的默认网络选项，但不建议将其用于生产部署。 对于大多数生产部署，应根据其卓越的可伸缩性和性能特征来规划和使用 Azure CNI 网络。
有关详细信息，请参阅为 AKS 群集配置 kubenet 网络。
Azure CNI（高级）网络
借助 Azure CNI，每个 pod 都可以从子网获取 IP 地址，并且可以直接访问。 这些 IP 地址必须事先计划，并且在网络空间中必须唯一。 每个节点都有一个配置参数来表示它支持的最大 Pod 数。 这样，就会为每个节点预留相应的 IP 地址数。 此方法可能会耗尽 IP 地址，或者在应用程序需求增长时需要在更大的子网中重建群集，因此必须进行正确的计划。 为了避免这些规划挑战，可以启用 Azure CNI 网络，以便动态分配 IP 和增强子网支持功能。
注意
由于 Kubernetes 限制，资源组名称、虚拟网络名称和子网名称不得超过 63 个字符。
与 kubenet 不同，到同一虚拟网络中终结点的流量不会转换 (NAT) 到节点的主 IP。 虚拟网络中流量的源地址是 Pod IP。 虚拟网络外部的流量仍然通过 NAT 转换到节点的主 IP。
节点使用 Azure CNI Kubernetes 插件。
有关详细信息，请参阅为 AKS 群集配置 Azure CNI。
Azure CNI 覆盖网络
Azure CNI 覆盖表示 Azure CNI 的演变，解决了向 Pod 分配虚拟网络 IP 时出现的可伸缩性和规划难题。 Azure CNI 覆盖为 Pod 分配私有 CIDR IP。 专用 IP 与虚拟网络分离，可以在多个群集中重复使用。 Azure CNI 覆盖可以扩展到超出 Kubenet 群集中强制实施的 400 节点限制。 对于大多数群集，建议使用 Azure CNI 覆盖。
由 Cilium 提供支持的 Azure CNI
由 Cilium 提供支持的 Azure CNI 使用 Cilium 来提供高性能网络、可观测性和网络策略强制实施。 它以本机方式与 Azure CNI 覆盖集成，以便进行可缩放的 IP 地址管理 (IPAM)。
此外，Cilium 在默认情况下会强制实施网络策略，而无需单独的网络策略引擎。 透过使用 eBPF 程序和更高效的 API 对象结构，由 Cilium 提供支持的 Azure CNI 可以扩展到超出 Azure 网络策略管理器的 250 个节点/20K Pod 的限制。
对于需要强制实施网络策略的群集，建议使用由 Cilium 提供支持的 Azure CNI。
创建自己的 CNI
可以使用自带 CNI 功能在 AKS 中安装非 Microsoft CNI。
网络模型的比较
Kubenet 和 Azure CNI 都为 AKS 群集提供网络连接。 不过，这两个模型各有优缺点。 从较高层面讲，需要考虑以下因素：
kubenet
- 节省 IP 地址空间。
- 使用 Kubernetes 内部或外部负载均衡器可从群集外部访问 Pod。
- 可手动管理和维护用户定义的路由 (UDR)。
- 每个群集最多可包含 400 个节点。
Azure CNI
- Pod 建立了全面的虚拟网络连接，可以通过其专用 IP 地址直接从已连接的网络对其进行访问。
- 需要更多的 IP 地址空间。
| 网络模型 | 何时使用 |
|---|---|
| Kubenet | • IP 地址空间对话是优先项。 • 简单配置。 • 每个群集少于 400 个节点。 • Kubernetes 内部或外部负载均衡器足以从群集外部访问 Pod。 • 可以手动管理和维护用户定义的路由。 |
| Azure CNI | • Pod 需要完全的虚拟网络连接。 • 需要高级的 AKS 功能（如虚拟节点）。 • 有足够的 IP 地址空间。 • 需要 Pod 到 Pod 和 Pod 到虚拟机的连接。 • 外部资源需要直接到达 Pod。 • 需要 AKS 网络策略。 |
| Azure CNI 覆盖 | • IP 地址不足是个问题。 • 扩展到 1000 个节点和每个节点 250 个 Pod 就足够了。 • 可以接受额外的 Pod 连接跃点。 • 更简单的网络配置。 • 可以满足 AKS 出口需求。 |
Kubenet 和 Azure CNI 之间存在以下行为差异：
| 功能 | Kubenet | Azure CNI | Azure CNI 覆盖 | 由 Cilium 提供支持的 Azure CNI |
|---|---|---|---|---|
| 在现有或新的虚拟网络中部署群集 | 支持 - 手动应用 UDR | 支持 | 受支持 | 支持 |
| Pod-Pod 连接 | 支持 | 受支持 | 受支持 | 支持 |
| Pod-VM 连接；VM 位于同一虚拟网络中 | 由 Pod 发起时可正常工作 | 采用两种工作方式 | 由 Pod 发起时可正常工作 | 由 Pod 发起时可正常工作 |
| Pod-VM 连接；VM 位于对等互连的虚拟网络中 | 由 Pod 发起时可正常工作 | 采用两种工作方式 | 由 Pod 发起时可正常工作 | 由 Pod 发起时可正常工作 |
| 使用 VPN 或 Express Route 进行本地访问 | 由 Pod 发起时可正常工作 | 采用两种工作方式 | 由 Pod 发起时可正常工作 | 由 Pod 发起时可正常工作 |
| 访问服务终结点保护的资源 | 支持 | 受支持 | 支持 | |
| 使用负载均衡器服务、应用程序网关或入口控制器公开 Kubernetes 服务 | 支持 | 受支持 | 支持 | 使用覆盖模式时有相同限制 |
| 对 Windows 节点池的支持 | 不支持 | 支持 | 支持 | 仅适用于 Linux，不适用于 Windows。 |
| 默认的 Azure DNS 和专用区域 | 支持 | 受支持 | 支持 |
有关 Azure CNI 和 kubenet 的详细信息以及确定最适合选项的帮助，请参阅在 AKS 中配置 Azure CNI 网络和在 AKS 中使用 kubenet 网络。
网络模型之间的支持范围
无论使用哪种网络模型，都可以通过以下方式之一部署 kubenet 和 Azure CNI：
- 当你创建 AKS 群集时，Azure 平台可自动创建和配置虚拟网络资源。
- 当你创建 AKS 群集时，可以手动创建和配置虚拟网络资源并附加到这些资源。
尽管 Kubenet 和 Azure CNI 都支持服务终结点或 UDR 之类的功能，但你可以根据 AKS 的支持策略中的说明进行更改。 例如：
- 如果你为 AKS 群集手动创建虚拟网络资源，则在配置自己的 UDR 或服务终结点时将会获得支持。
- 如果 Azure 平台为 AKS 群集自动创建虚拟网络资源，则无法手动更改 AKS 管理的这些资源来配置你自己的 UDR 或服务终结点。
入口控制器
创建 LoadBalancer 类型服务时，还会创建基础 Azure 负载均衡器资源。 负载均衡器配置为在给定端口上将流量分发到服务中的 Pod。
LoadBalancer 仅在第 4 层工作。 在第 4 层，服务不知道实际的应用程序，不会考虑任何其他路由。
入口控制器在第 7 层工作，可使用更智能的规则来分配应用程序流量。 入口控制器通常基于入站 URL 将 HTTP 流量路由到不同的应用程序。
比较入口选项
下表列出了不同入口控制器选项之间的功能差异：
| 功能 | 应用程序路由加载项 | 适用于容器的应用程序网关 | Azure 服务网格/基于 Istio 的服务网格 |
|---|---|---|---|
| 入口/网关控制器 | NGINX 入口控制器 | 适用于容器的 Azure 应用程序网关 | Istio 入口网关 |
| API | 入口 API | 入口 API 和网关 API | 网关 API |
| 承载 | 在群集中 | Azure 托管 | 在群集中 |
| 缩放 | 自动缩放 | 自动缩放 | 自动缩放 |
| 负载均衡 | 内部/外部 | 外部 | 内部/外部 |
| SSL 终止 | 在群集中 | 是：卸载和 E2E SSL | 在群集中 |
| mTLS | 空值 | 是到后端 | 空值 |
| 静态 IP 地址 | 空值 | FQDN | 空值 |
| Azure Key Vault 存储的 SSL 证书 | 是 | 是 | 空值 |
| 用于 DNS 区域管理的 Azure DNS 集成 | 是 | 是 | 空值 |
下表列出了可以使用每个入口控制器的不同方案：
| 入口选项 | 何时使用 |
|---|---|
| 托管 NGINX - 应用程序路由加载项 | • 群集中托管、可自定义且可缩放的 NGINX 入口控制器。 • 基本负载均衡和路由功能。 • 内部和外部负载均衡器配置。 • 静态 IP 地址配置。 • 与 Azure Key Vault 集成，以便进行证书管理。 • 与 Azure DNS 区域集成，以便进行公共和专用 DNS 管理。 • 支持入口 API。 |
| 适用于容器的应用程序网关 | • Azure 托管入口网关。 • 由控制器管理的灵活部署策略，或自带适用于容器的应用程序网关。 • 先进的流量管理功能，如自动重试、可用性区域复原能力、后端目标的相互身份验证 (mTLS)、流量拆分/加权轮循机制以及自动缩放。 • 与 Azure Key Vault 集成，以便进行证书管理。 • 与 Azure DNS 区域集成，以便进行公共和专用 DNS 管理。 • 支持入口和网关 API。 |
| Istio 入口网关 | • 与 Istio 一起用于服务网格时，基于 Envoy。 • 高级流量管理功能，例如速率限制和断路。 • 支持 mTLS • 支持网关 API。 |
创建入口资源
建议使用应用程序路由加载项在 AKS 中配置入口控制器。 应用程序路由加载项是 Azure Kubernetes 服务 (AKS) 的完全托管入口控制器，提供以下功能：
基于 IngressKubernetes NGINX Ingress 控制器轻松配置托管 NGINX Ingress 控制器。
与 Azure DNS 集成，以便进行公共区域和专用区域管理。
SSL 终止，证书存储在 Azure Key Vault 中。
有关应用程序路由加载项的详细信息，请参阅使用应用程序路由加载项的托管 NGINX 入口。
客户端源 IP 保留
可配置入口控制器，以便在对 AKS 群集中的容器发出请求时保留客户端源 IP。 当入口控制器将客户端的请求路由到 AKS 群集中的容器时，该请求的原始源 IP 不可用于目标容器。 如果启用客户端源 IP 保留，则可以在请求标头中的 X-Forwarded-For 下使用客户端的源 IP。
如果在入口控制器上使用“客户端源 IP 保留”，则无法使用 TLS 直通。 可对其他服务（例如 LoadBalancer 类型的服务）使用“客户端源 IP 保留”和 TLS 直通。
若要详细了解客户端源 IP 保留，请参阅如何将客户端源 IP 保留用于 AKS 中的 LoadBalancer 服务。
控制出站（出口）流量
AKS 群集部署在虚拟网络上，并且对该虚拟网络之外的服务具有出站依赖关系。 这些出站依赖关系几乎完全由完全限定的域名 (FQDN) 定义。 默认情况下，AKS 群集提供不受限制的出站（出口）Internet 访问，允许运行的节点和服务根据需要访问外部资源。 如果需要，可以限制出站流量。
有关详细信息，请参阅控制 AKS 中群集节点的出口流量。
网络安全组
网络安全组筛选 VM（例如 AKS 节点）的流量。 创建服务（如 LoadBalancer）时，Azure 平台会自动配置任何必需的网络安全组规则。
无需手动配置网络安全组规则，以筛选 AKS 群集中 Pod 的流量。 你可以定义任何所需端口并将其作为 Kubernetes 服务清单的一部分进行转发，让 Azure 平台创建或更新相应的规则。
还可以使用网络策略自动向 Pod 应用流量筛选器规则。
有关详细信息，请参阅网络安全组如何筛选网络流量。
网络策略
默认情况下，AKS 群集中的所有 Pod 都可以无限制地发送和接收流量。 为了提高安全性，可定义用来控制流量流的规则，如：
- 后端应用程序只公开给所需的前端服务。
- 数据库组件只能由与其连接的应用程序层访问。
网络策略是 AKS 中提供的一项 Kubernetes 功能，允许你控制 Pod 之间的流量流。 你可以基于分配的标签、命名空间或流量端口等设置来允许或拒绝到 Pod 的流量。 虽然网络安全组更适用于 AKS 节点，不过网络策略是一种更适合于的云原生方式，可控制 pod 的流量流。 因为 Pod 是在 AKS 群集中动态创建的，则可以动态应用所需的网络策略。
有关详细信息，请参阅在 Azure Kubernetes 服务 (AKS) 中使用网络策略保护 Pod 之间的流量。
后续步骤
若要开始使用 AKS 网络，请通过 kubenet 或 Azure CNI 创建并配置采用你自己的 IP 地址范围的 AKS 群集。
如需相关的最佳做法，请参阅 AKS 中的网络连接和安全性的最佳做法。
有关核心 Kubernetes 和 AKS 概念的详细信息，请参阅以下文章：