Azure Kubernetes 服务（AKS）中节点自动预配（NAP）的网络配置概述

本文概述了使用节点自动预配（NAP）的 Azure Kubernetes 服务（AKS）群集的网络配置要求和建议。 它涵盖支持的配置、默认子网行为、基于角色的访问控制（RBAC）设置和无类域间路由（CIDR）注意事项。

有关 AKS 中的节点自动预配的概述，请参阅 Azure Kubernetes 服务（AKS）中的节点自动预配（NAP）概述。

NAP 支持的网络配置

评估 NAP 的网络支持时，请考虑 IP 地址管理（IPAM）模式、网络插件、网络数据平面和网络策略。 下表描述了 NAP 支持的选项：

配置层 选项 NAP 支持
IPAM Azure CNI 覆盖 支持
IPAM Azure CNI 节点子网 支持
IPAM 具有动态 IP 分配的 Azure CNI Pod 子网 不支持
网络插件 Kubenet 不支持
数据平面 由 Cilium 提供支持的 Azure CNI 支持受支持的 Azure CNI IPAM 模式
网络策略 Calico 不支持

将 Azure CNI Overlay 与由 Cilium 提供支持的 Azure CNI 数据平面配合使用。 Cilium 提供高级网络功能，并针对 NAP 的性能进行了优化。

NAP 的子网配置

在 vnetSubnetID 资源中设置可选的 AKSNodeClass 字段，以配置 Karpenter 在预配 NAP 节点时使用的自定义子网。 如果未指定 vnetSubnetID，Karpenter 将使用安装期间配置的默认子网，这通常是创建 AKS 群集时参数指定的 --vnet-subnet-id 子网。

NAP 会自动在 AKS 群集上部署、配置和管理 Karpenter，并且基于开源 Karpenter 和 AKS Karpenter 提供程序 项目。

AKSNodeClass AKS 群集上的资源各自可以指定不同的 vnetSubnetID，从而可在各个节点池中启用混合子网配置。 未指定 vnetSubnetID 节点类使用群集的默认子网配置。

子网偏移行为

Karpenter 监视子网配置更改，并在vnetSubnetID中AKSNodeClass被修改时检测漂移。 在管理自定义网络配置时，理解此行为至关重要。

对于使用自定义虚拟网络的群集，将 vnetSubnetID 从一个有效子网更改为另一个有效子网会导致与 AKSNodeClass 关联的现有节点发生漂移。 Karpenter 在新子网中创建替代节点，并根据 NodePool中断预算 平稳地终止发生漂移的节点。

在更改 vnetSubnetID之前，请确保群集标识对新子网具有所需的权限，并且该子网有足够的可用 IP 地址来替换节点。 Pod 干扰预算和 karpenter.sh/do-not-disrupt 注解可能会延迟自愿漂移替换。

重要

AKS 管理的虚拟网络不支持自定义子网。 vnetSubnetID仅适用于你管理的自定义虚拟网络。

NAP 的 AKS 集群 CIDR 范围

配置自定义网络 vnetSubnetID时，需要了解和管理群集的 CIDR 范围，以避免网络冲突。 与通过 Azure 资源管理器 （ARM） 模板创建的传统 AKS 节点池不同，Karpenter 应用自定义资源定义（CRD），无需 ARM 提供的扩展验证即可立即预配节点。

NAP 自定义子网配置中的 CIDR 注意事项

配置 vnetSubnetID 时，必须：

  • 验证 CIDR 兼容性：确保自定义子网不会与现有的 CIDR 范围冲突。
  • 规划 IP 容量：计算预期缩放所需的 IP 地址。
  • 验证连接：测试网络路由和安全组规则。
  • 监视使用情况：跟踪子网利用率并计划增长。
  • 文档配置：维护网络设计决策的记录。

常见 CIDR 冲突

在将自定义子网与 NAP 配合使用时，请注意以下常见的 CIDR 冲突方案：

以下示例显示了与群集 Pod 和服务CIDR 冲突的子网 CIDR 范围，以及避免这些冲突的配置。 在配置 vnetSubnetID之前，使用这些模式验证子网范围。

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

自定义子网配置的 RBAC 设置

将自定义子网配置与 NAP 配合使用时，需要确保 Karpenter 具有读取子网信息和将节点加入指定子网所需的权限。 这需要为群集的托管标识设置适当的 RBAC 权限。

运行以下命令的人员必须具有创建所需角色定义和角色分配的权限，例如 基于角色的访问控制管理员 角色。 请勿向群集标识授予写入角色分配的权限，除非它需要在其他场景中创建角色分配。

获取群集托管标识的主体 ID。 使用与群集标识类型对应的命令：

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

设置这些权限有两种主要方法： 分配广泛的虚拟网络（VNet）权限 或 分配范围子网权限。

此方法最宽松，授予群集标识权限，以读取和加入主 VNet 中的任何子网并提供网络参与者访问权限。

重要

网络参与者角色授予Microsoft.Network/*，该角色允许群集标识在分配的 VNet 范围内创建、修改和删除网络资源。 在生产环境中使用该角色之前，请检查此访问权限配置，因为在此场景下，NAP 仅需要子网读取和加入权限。

优点和注意事项

下表概述了在 VNet 范围内分配网络参与者角色的权衡。

广泛的 VNet 权限的优点 有关广泛 VNet 权限的注意事项
• 简化权限管理。
• 无需在添加新子网时更新权限。
• 适用于单租户环境。
• 订阅达到自定义角色的最大数目时的功能。		 • 提供比严格必要的更广泛的权限。
• 可能不符合严格的安全要求。

所需的权限

若要分配广泛的 VNet 权限，请授予群集的托管标识对 VNet 的以下权限：

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

有关设置自定义网络和分配广泛 VNet 权限的完整示例，请参阅 自定义 VNet 设置 - 大多数宽松的 RBAC 示例脚本。

自定义子网配置示例

以下示例演示如何使用 vnetSubnetID 资源中的 AKSNodeClass 字段为 NAP 节点配置自定义子网：

使用格式/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}将spec.vnetSubnetID字段设置为目标子网的完整Azure资源 ID。

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

以下示例演示如何使用具有不同子网配置的多个节点类：

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

自带 CNI (BYO CNI) 支持策略

用于 Azure 的 Karpenter 允许自带容器网络接口（BYO CNI）配置，它遵循与 AKS 相同的支持策略。 BYO CNI 不会使被 NAP 列为不受支持的配置（例如 kubenet 或 Calico）变为受支持的配置。 使用自定义 CNI 时，与网络相关的故障排除支持不受任何服务级别协议或保证的范围。

支持范围详细信息

下面概述了将 BYO CNI 与 Karpenter 配合使用时支持和不支持的内容：

  • 支持：使用自带 (BYO) CNI 配置时，特定于 Karpenter 的功能和集成问题。
  • 不支持：使用第三方 CNI 插件时，特定于 CNI 的网络问题、配置问题或故障排除。

后续步骤

有关 AKS 中的节点自动预配的详细信息，请参阅以下文章：

  • Last updated on