Azure Kubernetes 服务 (AKS) 中的网络连接和安全的最佳做法

在创建和管理 Azure Kubernetes 服务 (AKS) 中的群集时，可以为节点和应用程序提供网络连接。 这些网络资源包括 IP 地址范围、负载均衡器和入口控制器。

这篇最佳实践文章重点介绍集群操作员的网络连接和安全。 在这篇文章中，你将学会如何：

选择合适的网络模型

最佳实践指南

对于大多数方案，请使用 Azure CNI 覆盖层。 如果工作负荷需要从连接的网络进行直接 Pod IP 访问，请使用具有 Azure CNI Pod 子网的平面网络。

虚拟网络为 AKS 节点和客户提供了用于访问应用程序的基本链接。 将 AKS 群集部署到虚拟网络有两种不同的方法：

• 覆盖网络：Azure CNI 覆盖网络从独立的 Pod CIDR 中为 Pod 分配 IP 地址。 离开集群的流量会被转换为节点的 IP 地址，并且连接的网络无法通过 Pod 的私有 IP 地址直接访问这些 Pod。
• 平面网络：Azure CNI Pod 子网或旧版Azure CNI 节点子网从虚拟网络空间分配 Pod IP 地址。 Pod 可以通过连接的网络的专用 IP 地址访问。

有关选择网络模型的详细信息，请参阅 规划 AKS 的 Pod 网络。

Azure CNI 网络概述

Azure CNI 为 Pod 和节点提供 IP 地址管理（IPAM）和连接。 IPAM 选项独立于网络数据平面。 例如，可以将由 Cilium 提供支持的 Azure CNI 与 Azure CNI Overlay 或平面网络模式配合使用。

下图显示了两个 AKS 节点，每个节点通过网络网桥连接到共享Azure虚拟网络。

Azure CNI 网络允许分离资源的控制和管理。 从安全角度看，通常希望不同的团队来管理和保护这些资源。 连接特征取决于网络模型。 覆盖层 Pod 通过节点 IP 地址与虚拟网络和本地部署资源建立连接。 平面网络 Pod 可以通过其专用 IP 地址直接与连接的资源通信。

使用 Azure CNI 网络时，虚拟网络资源位于 AKS 群集外单独存在的资源组中。 委托 AKS 群集标识的权限以访问和管理这些资源。 AKS 群集使用的群集标识在虚拟网络中的子网上必须至少具有网络参与者权限。

如果希望定义自定义角色而不是使用内置的网络参与者角色，则需要以下权限：

默认情况下，AKS 使用托管标识作为其群集标识。 但是，你可以改为使用服务主体。

• 有关 AKS 服务主体委托的详细信息，请参阅委托对其他 Azure 资源的访问权限。
• 有关托管标识的详细信息，请参阅使用托管标识。

根据网络模型规划地址范围。 请记住以下标准：

• 使用 Azure CNI Overlay 时，请为节点规划节点子网，并为 Pod 使用单独的专用 CIDR。 每个节点从 Pod CIDR 中接收一个 /24 地址空间。
• 对于平面网络，需要为节点和 Pod 规划虚拟网络子网的大小。 Azure CNI Pod 子网使用独立的节点子网和 Pod 子网，而旧版 Azure CNI 节点子网则对两者共用同一个子网。
• 避免使用与现有网络资源重叠的 IP 地址范围。
  • 需允许在 Azure 中连接到本地网络或对等网络。
• 若要处理横向扩展事件或群集升级，需要在分配的子网中提供额外的 IP 地址。
  • 如果使用 Windows Server 容器，此额外的地址空间尤其重要，因为这些节点池需要升级才能应用最新的安全修补程序。 若要详细了解 Windows Server 节点，请参阅升级 AKS 中的节点池。

若要计算所需的 IP 地址空间，请参阅 AKS 群集的 IP 地址规划。

使用 Azure CNI 网络创建群集时，可以指定群集的其他地址范围，例如 DNS 服务 IP 和服务地址范围。 一般情况下，请确保这些地址范围不会相互重叠或与群集关联的任何网络，包括任何虚拟网络、子网、本地网络和对等互连网络。

有关网络模型、限制和地址大小调整的详细信息，请参阅 CNI 网络概述Azure。

分配入口流量

最佳实践指南

要将 HTTP 或 HTTPS 流量分配到应用程序，请使用入口资源和控制器。 与 Azure 负载均衡器相比，入口控制器提供了附加功能，并且可作为本机 Kubernetes 资源进行管理。

虽然 Azure 负载均衡器可以将客户流量分配到 AKS 群集中的各个应用程序，但是对这些流量的了解有限。 负载均衡器资源在第 4 层工作，并根据协议或端口分配流量。

大多数使用 HTTP 或 HTTPS 的 Web 应用程序应使用在第 7 层工作的 Kubernetes 入口资源和控制器。 Ingress 可以根据应用程序的 URL 分配流量，并处理 TLS/SSL 终止。 入口还可以减少公开和映射的 IP 地址数。

使用负载平衡器，每个应用程序通常需要分配一个公共 IP 地址并映射到 AKS 群集中的服务。 使用入口资源，单个 IP 地址可以将流量分配给多个应用程序。

此图显示了接收外部流量的单个公共 IP 地址，以及将流量分发到 AKS 群集中多个服务的入口控制器。

入口有两个组件：入口 资源和 入口 控制器。

入口资源

入口资源是 的 YAML 清单。kind: Ingress 它定义了主机、证书以及用于将流量路由到 AKS 群集中运行的服务的规则。

以下 YAML 清单示例使用的是应用程序路由加载项的托管 NGINX Ingress 类。 它将 myapp.com 流量 分发到两个服务之一（ 博客服务 或 商店服务）中，并根据他们访问的 URL 将客户定向到一个服务或其他服务。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

该 ingressClassName 字段选择入口类，并且必须与群集中的入口控制器上配置的类匹配。 该值 webapprouting.kubernetes.azure.com 用于指定由应用程序路由加载项提供的托管 NGINX Ingress 控制器。 如果使用其他实现，请将它替换为入口控制器的类名称。

入口控制器

群集托管 的入口控制器 在 AKS 节点上作为工作负荷运行，并监视传入请求。 然后，根据与该控制器关联的入口资源中定义的规则分发传入流量。 尽管最常见的入口控制器基于 NGINX，但 AKS 并不会限制你使用特定的控制器。 可以使用 Contour、 HAProxy、 Traefik 等。

必须将由群集承载的 Ingress 控制器调度到 Linux 节点上。 指示资源应在基于 Linux 的节点上运行，方法是在 YAML 清单或 Helm 图表部署中使用节点选择器。 有关详细信息，请参阅使用节点选择器控制在 AKS 中计划 Pod 的位置。

使用应用程序路由加载项的 Ingress

应用程序路由加载项为 AKS 提供托管入口实现。 对于新的长期运行部署，如果应用程序路由 Gateway API 实现能够满足您的要求，请使用该实现。 网关 API 是 Kubernetes 入口和第 7 层流量管理的长期标准。

托管 NGINX 实现提供以下功能：

• 轻松配置基于 Kubernetes NGINX 入口控制器的托管 NGINX 入口控制器。
• 与 Azure DNS 集成，以便进行公共区域和专用区域管理。
• SSL 终止，证书存储在 Azure 密钥保管库 中。

有关详细信息，请参阅 使用应用程序路由 Gateway API 配置入口 和 使用应用程序路由加载项托管 NGINX 入口。

使用 Web 应用程序防火墙 (WAF) 保护流量

最佳实践指南

若要扫描入站流量中的潜在攻击，请使用 Web 应用防火墙（WAF），例如 适用于 Azure 的 Barracuda WAF。 用于容器的应用程序网关路由 HTTP、HTTPS、gRPC、WebSocket 和 AI 推理流量，并支持 TLS 终止。

群集托管的入口控制器作为 AKS 群集中的 Kubernetes 工作负荷运行，并将流量分发到服务和应用程序。 它消耗节点的某些资源，例如 CPU、内存和网络带宽。 在较大的环境中，可能需要考虑以下事项：

• 将部分流量路由或 TLS 终止卸载到 AKS 群集之外的网络资源。
• 扫描传入流量是否存在潜在攻击。

此图说明了通过容器Azure 应用程序网关传递的外部流量。 配置 WAF 保护后，在用于容器的应用程序网关将允许的流量转发到 AKS 集群中的服务之前，WAF 规则会先筛选请求。

为了获得额外的安全层，Web 应用程序防火墙（WAF）会筛选传入流量。 托管规则和自定义规则可防范跨站点脚本和 SQL 注入等攻击。 用于容器的应用程序网关是支持 Azure WAF 的第 7 层负载均衡和流量管理服务。

仅部署容器应用程序网关并不会启用 WAF 保护。 在 WAF 检查流量之前，必须创建 WAF 策略并完成以下两种配置：

• 创建引用 WAF 策略的AzureSecurityPolicy子资源。
• 应用一个 Kubernetes WebApplicationFirewallPolicy 自定义资源，该资源引用同一 WAF 策略，并以 Gateway 或 HTTPRoute 资源作为保护目标。

完成这两种配置后，请先验证自定义资源状态和 WAF 日志，然后再依赖策略进行保护。

由于其他第三方解决方案也可以执行这些功能，因此你可以在偏好的产品中继续使用现有的资源和专业知识。

负载均衡器或入口资源继续在 AKS 群集中运行并优化流量分配。 通过资源定义，可以将应用程序网关作为入口控制器进行集中管理。

使用网络策略控制流量流

最佳实践指南

使用网络策略允许或拒绝到 Pod 的流量。 默认情况下，集群中 Pod 之间的所有流量都是允许的。 为了提高安全性，请定义对 Pod 通信进行限制的规则。

网络策略是 AKS 中提供的一项 Kubernetes 功能，允许你控制 Pod 之间的流量流。 你可以基于分配的标签、命名空间或流量端口等设置来允许或拒绝到 Pod 的流量。 网络策略是一种可控制 Pod 的流量流的云原生方法。 因为 Pod 是在 AKS 群集中动态创建的，所以可以动态应用所需的网络策略。

若要 在 AKS 中使用网络策略，请选择支持节点操作系统和网络数据平面的网络策略引擎。 可以在创建群集期间或在现有支持的群集上启用策略引擎。

对于 Linux 节点池，请使用由 Cilium 提供支持的 Azure CNI 及其内置的 Cilium 网络策略强制执行功能。 Cilium 不支持 Windows 节点池。 对于Windows工作负载，请使用 Calico。

使用 YAML 清单将网络策略创建为 Kubernetes 资源。 策略应用于定义的 Pod，其中包含定义流量流的入口或出口规则。

以下示例将网络策略应用于带有 app: backend 标签的 Pod。 入口规则仅允许来自具有“app: frontend”标签的 Pod 的流量。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

若要开始使用策略，请参阅在 Azure Kubernetes 服务 (AKS) 中使用网络策略保护 Pod 之间的流量。

使用 LocalDNS 优化 DNS 解析

最佳实践指南

使用 LocalDNS 提高 DNS 性能和可靠性和减少集中式 CoreDNS Pod 上的负载。 LocalDNS 在 AKS Automatic 中预配置。 在 AKS 标准版中，启用和配置每个节点池的 LocalDNS。

LocalDNS 在每个节点上部署 DNS 代理即 systemd 服务，以在本地处理 DNS 查询。 默认情况下，Pod 会将所有 DNS 查询发送到集中式 CoreDNS Pod。 大规模地集中这些查询可能会造成瓶颈，而本地分辨率可减少网络跃点和延迟。

LocalDNS 还消除了 conntrack DNS 流量的表条目，从而 conntrack 防止表耗尽和可能导致连接断开的争用条件。 从本地缓存到 CoreDNS 的连接将升级到 TCP，从而能够重新平衡连接并更快地清理跟踪条目。

对于需要高度可用的 DNS 的工作负载，LocalDNS 支持在上游 DNS 不可用时，在可配置的时间内提供过时缓存的响应。 这种尽最大努力的功能有助于在暂时性 DNS 中断期间维护 Pod 连接和服务可靠性，但不能保证过时的记录可用。

在 AKS 标准版上，在现有节点池上启用 LocalDNS 会重新映像其节点。 规划部署时应将此次中断考虑在内。

有关 LocalDNS 体系结构和功能的详细信息，请参阅 AKS 中的 DNS 解析。 有关配置说明，请参阅 “配置 LocalDNS”。

安全地连接到节点

最佳实践指南

不公开到 AKS 节点的远程连接。 对于常规 Linux 节点故障排除，请通过 Kubernetes API 使用 kubectl debug 。 需要 SSH 访问时，请通过专用网络或Azure Bastion进行连接。

可以使用 Azure 管理工具或 Kubernetes API 服务器在 AKS 中完成大多数操作。 AKS 节点仅在专用网络上可用，并且不会连接到公共 Internet。 对于 Linux 节点，使用 kubectl debug 通过 Kubernetes API 启动特权调试容器。 此方法不需要与节点建立直接 SSH 连接。

如果 Kubernetes API 访问不适用，或者您需要使用 SSH，请使用已连接网络中的节点私有 IP 地址。 Azure Bastion可以提供专用连接，而无需在节点上公开公共 IP 地址。 对于Windows节点，请使用主机进程容器或通过 Linux 代理节点进行连接。 如果代理节点不可用，Azure Bastion是替代方法。 有关详细信息，请参阅 连接到 AKS 群集节点进行维护或故障排除。

该图说明了一个管理虚拟网络，其中包含一台堡垒主机，它通过安全对等互连链路将连接路由到 AKS 群集虚拟网络。

如果使用堡垒主机或跳转盒，请将其放置在单独的安全对等互连管理虚拟网络中。 使用 Azure ExpressRoute 或 VPN 网关连接到本地网络并控制网络安全组的访问来保护管理网络。

后续步骤

本文重点介绍网络连接性和安全性。 有关 Kubernetes 中的网络基础知识的详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中应用程序的网络概念