你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
重要
在 2028年3月31日,Azure Kubernetes 服务 (AKS) 的 kubenet 网络功能将被停用。
为避免服务中断,您需要在该日期之前升级到 Azure 容器网络接口(CNI)覆盖层,届时 AKS 上运行在 kubenet 的工作负荷将不再受支持。
在 Azure Kubernetes 服务 (AKS) 中创建和管理群集时,将为节点和应用程序提供网络连接。 这些网络资源包括 IP 地址范围、负载均衡器和入口控制器。
这篇最佳做法文章关注集群操作员的网络连接和安全。 在本文中,您将学习如何:
- 介绍 AKS 中的Azure容器网络接口(CNI)网络模式。
- 为所需的 IP 地址和连接制定计划。
- 使用负载均衡器、入口控制器或 Web 应用程序防火墙 (WAF) 分配流量。
- 安全地连接到群集节点。
选择合适的网络模型
最佳实践指南
使用 AKS 中的 Azure CNI 网络与现有虚拟网络或本地网络集成。 利用此网络模型,可以更大程度地将企业环境中的资源和控制相分离。
虚拟网络为 AKS 节点和客户提供了用于访问应用程序的基本链接。 将 AKS 群集部署到虚拟网络有两种不同的方法:
- Azure CNI 网络:部署到虚拟网络并使用 Azure CNI Kubernetes 插件。 Pod 接收的各个 IP 可以路由到其他网络服务或本地资源。
Azure CNI 是生产部署的有效选项。
CNI 网络
Azure CNI 是一种供应商中立的协议,允许容器运行时向网络提供程序发出请求。 它将 IP 地址分配给 Pod 和节点,并在连接到现有Azure虚拟网络时提供 IP 地址管理(IPAM)功能。 每个节点和 Pod 资源在Azure虚拟网络中接收 IP 地址。 无需额外的路由即可与其他资源或服务通信。
值得注意的是,用于生产Azure CNI 网络可以分离资源的控制和管理。 从安全角度看,通常希望不同的团队来管理和保护这些资源。 使用 Azure CNI 网络,可以通过分配给每个 Pod 的 IP 地址直接连接到现有Azure资源、本地资源或其他服务。
使用 Azure CNI 网络时,虚拟网络资源位于 AKS 群集的单独资源组中。 授予 AKS 群集标识权限,以访问和管理这些资源。 AKS 群集使用的群集标识在虚拟网络中的子网上必须至少具有网络参与者权限。
如果希望定义自定义角色而不是使用内置的网络参与者角色,则需要以下权限:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/read
默认情况下,AKS 使用托管标识作为其群集标识。 但是,你可以改为使用服务主体。
- 有关 AKS 服务主体委托的详细信息,请参阅委托对其他 Azure 资源的访问权限。
- 有关托管标识的详细信息,请参阅使用托管标识。
每个节点和 Pod 在接收自己的 IP 地址时,请规划 AKS 子网的地址范围。 请记住以下标准:
- 子网必须大到足以为每个部署的节点、Pod 和网络资源提供 IP 地址。
- 使用Azure CNI 网络时,每个正在运行的节点对 Pod 数有默认限制。
- 避免使用与现有网络资源重叠的 IP 地址范围。
- 需允许在 Azure 中连接到本地网络或对等网络。
- 若要处理横向扩展事件或群集升级,需要在分配的子网中提供额外的 IP 地址。
- 如果使用Windows Server容器,此额外地址空间尤其重要,因为这些节点池需要升级才能应用最新的安全修补程序。 有关Windows Server节点的详细信息,请参阅 在 AKS 中更新节点池。
若要计算所需的 IP 地址,请参阅 AKS 中的 配置 Azure CNI 网络。
使用 Azure CNI 网络创建群集时,可为群集指定其他地址范围,例如 Docker 网桥地址、DNS 服务 IP 和服务地址范围。 通常,需要确保这些地址范围不相互重叠,也不与群集关联的任何网络(包括任何虚拟网络、子网、本地网络和对等网络)重叠。
有关这些地址范围限制和大小的具体详细信息,请参阅 在 AKS 中配置 Azure CNI 网络。
分配入口流量
最佳实践指南
要将 HTTP 或 HTTPS 流量分配到应用程序,请使用入口资源和控制器。 与Azure负载均衡器相比,入口控制器提供额外的功能,并且可以作为本机 Kubernetes 资源进行管理。
虽然Azure负载均衡器可以将客户流量分发到 AKS 群集中的应用程序,但它在了解该流量方面受到限制。 负载均衡器资源在第 4 层工作,并根据协议或端口分配流量。
大多数使用 HTTP 或 HTTPS 的 Web 应用程序应使用在第 7 层工作的 Kubernetes 入口资源和控制器。 入口可以根据应用程序的 URL 分配流量并处理 TLS/SSL 终端。 入口还可以减少公开和映射的 IP 地址数。
使用负载平衡器,每个应用程序通常需要分配一个公共 IP 地址并映射到 AKS 群集中的服务。 使用入口资源,单个 IP 地址可以将流量分配给多个应用程序。
入口组件有两个部分:
- 入口资源
- 入口控制器
入口资源
入口资源是 kind: Ingress 的 YAML 清单。 它定义了主机、证书以及用于将流量路由到 AKS 群集中运行的服务的规则。
以下示例 YAML 清单将 myapp.com 的流量分发到两个服务(blogservice 或 storeservice)之一,并根据客户访问的 URL 将客户定向到其中一个服务。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
spec:
ingressClassName: PublicIngress
tls:
- hosts:
- myapp.com
secretName: myapp-secret
rules:
- host: myapp.com
http:
paths:
- path: /blog
backend:
service:
name: blogservice
port: 80
- path: /store
backend:
service:
name: storeservice
port: 80
入口控制器
入口控制器是在 AKS 节点上运行的守护程序并监视传入请求。 然后根据入口资源中定义的规则分配流量。 尽管最常见的入口控制器基于 NGINX,但 AKS 并不会限制你使用特定的控制器。 可以将 应用程序网关用于容器、 轮廓、 HAProxy、 Traefik 等。
必须在 Linux 节点上调度入口控制器。 指出资源应该使用 YAML 清单或 Helm 图表部署中的节点选择器,运行在基于 Linux 的节点上。 有关详细信息,请参阅使用节点选择器控制在 AKS 中调度 Pod 的位置。
使用应用程序路由加载项的入口
建议使用应用程序路由加载项在 AKS 中配置入口控制器。 应用程序路由加载项是 Azure Kubernetes 服务 (AKS) 的一个完全托管的 Ingress 控制器,提供以下功能:
轻松配置基于 Kubernetes NGINX 入口控制器的托管 NGINX 入口控制器。
与用于公共和专用区域管理的Azure DNS集成。
SSL 终止,证书存储在Azure 密钥保管库中。
有关应用程序路由加载项的详细信息,请参阅使用应用程序路由加载项的托管 NGINX 入口。
使用 Web 应用程序防火墙 (WAF) 保护流量
最佳实践指南
若要扫描传入流量中的潜在攻击,请使用 web 应用程序防火墙(例如 Barracuda WAF for Azure 或 Azure 应用程序网关 for Containers)。 这些更加高级的网络资源还可以路由超出 HTTP 和 HTTPS 连接或基本 TLS 终止之外的流量。
一般来说,入口控制器是 AKS 集群中的 Kubernetes 资源,用于将流量分配给服务和应用程序。 控制器作为守护程序在 AKS 节点上运行,并使用一些节点资源(例如 CPU、内存和网络带宽)。 在较大的环境中,可能需要考虑以下事项:
- 将部分流量路由或 TLS 终止卸载到 AKS 群集之外的网络资源。
- 扫描传入流量是否存在潜在攻击。
对于这层额外的安全保护,Web 应用程序防火墙 (WAF) 会筛选传入流量。 使用一组规则,Open Web Application Security Project(OWASP)监视跨站点脚本或 Cookie 中毒等攻击。 适用于容器的 Azure 应用程序网关 是与 AKS 群集集成的 WAF,在流量到达 AKS 群集和应用程序之前锁定这些安全功能。
由于其他第三方解决方案也可以执行这些功能,因此你可以在偏好的产品中继续使用现有的资源和专业知识。
负载均衡器或入口资源继续在 AKS 群集中运行并优化流量分配。 容器的 Azure 应用程序网关可以作为具有资源定义的入口控制器集中进行管理。 若要开始, 请为容器创建应用程序网关。
使用网络策略控制流量流
最佳实践指南
使用网络策略来允许或拒绝 Pod 的流量。 默认情况下,将允许群集中 Pod 之间的所有流量。 为了提高安全性,请定义对 Pod 通信进行限制的规则。
网络策略是 AKS 中提供的一项 Kubernetes 功能,允许你控制 Pod 之间的流量流。 你可以基于分配的标签、命名空间或流量端口等设置来允许或拒绝到 Pod 的流量。 网络策略是一种可控制 Pod 的流量流的云原生方法。 因为 Pod 是在 AKS 群集中动态创建的,所以可以动态应用所需的网络策略。
若要 在 AKS 中使用网络策略,可以在创建群集期间或在现有 AKS 群集上启用该功能。 如果计划使用网络策略,请确保在 AKS 群集上启用该功能。
注意
网络策略可用于 AKS 中基于 Linux 或 Windows 的节点和 Pod。
使用 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) 中使用网络策略来在容器组之间实现流量安全。
使用 LocalDNS 优化 DNS 解析
最佳实践指南
在 AKS 节点池上启用 LocalDNS ,以提高 DNS 性能、可靠性和减少集中式 CoreDNS Pod 上的负载。
DNS 解析对于 Kubernetes 中的服务到服务通信至关重要。 默认情况下,来自 Pod 的所有 DNS 查询都发送到集中式 CoreDNS Pod,这可能会成为大规模瓶颈。 AKS 提供 LocalDNS,用于在每个节点上将 DNS 代理部署为 systemd 服务。 此代理在本地处理 DNS 查询,减少网络跃点和解析延迟。
LocalDNS 还会消除 DNS 流量的 conntrack 表条目,从而 conntrack 防止表耗尽和可能导致连接丢失的争用条件。 从本地缓存到 CoreDNS 的连接将升级到 TCP,从而能够重新平衡连接并更快地清理跟踪条目。
对于需要高度可用的 DNS 的工作负载,LocalDNS 支持在上游 DNS 不可用时,在可配置的时间内提供过时缓存的响应。 此功能有助于在暂时性 DNS 中断期间维护 Pod 连接和服务可靠性。
有关 LocalDNS 体系结构和功能的详细信息,请参阅 AKS 中的 DNS 解析。 有关配置说明,请参阅 “配置 LocalDNS”。
通过堡垒主机安全地连接到节点
最佳实践指南
不要暴露 AKS 节点的远程连接性。 在管理虚拟网络中创建堡垒主机或跳转盒。 使用堡垒主机将流量安全地路由到 AKS 群集,以便进行远程管理任务。
可以使用 Azure 管理工具或通过 Kubernetes API 服务器在 AKS 中完成大多数操作。 AKS 节点仅在专用网络上可用,并且不会连接到公共 Internet。 若要连接到节点并提供维护和支持,请通过堡垒主机或跳转盒路由连接。 验证此主机是否位于与 AKS 群集虚拟网络安全对等互连的单独的管理虚拟网络中。
还应保护堡垒主机的管理网络。 使用 Azure ExpressRoute 或 VPN 网关连接到本地网络并使用网络安全组控制访问。
后续步骤
本文重点介绍网络连接性和安全性。 有关 Kubernetes 中的网络基础知识的详细信息,请参阅