本文概述了使用节点自动预配（NAP）的 Azure Kubernetes 服务（AKS）群集的网络配置要求和建议。 它涵盖支持的配置、默认子网行为、基于角色的访问控制（RBAC）设置和无类域间路由（CIDR）注意事项。
有关 AKS 中的节点自动预配的概述，请参阅 Azure Kubernetes 服务（AKS）中的节点自动预配（NAP）概述。
NAP 支持的网络配置
NAP 支持以下网络配置：
建议将 Azure CNI 与 Cilium 配合使用。 Cilium 提供高级网络功能，并针对 NAP 的性能进行了优化。
NAP 不支持的网络配置
NAP 不支持以下网络配置：
- Calico 网络策略
- 动态 IP 分配
NAP 的子网配置
NAP 会自动在 AKS 群集上部署、配置和管理 Karpenter，并基于开源 Karpenter 和 AKS Karpenter 提供程序 项目。 可以通过设置可选AKSNodeClass字段，使用vnetSubnetID资源为节点池中的 NAP 节点指定自定义子网配置，Karpenter 使用为节点预配指定的子网。 如果未指定子网，Karpenter 将使用在 Karpenter 安装期间配置的默认子网。 此默认子网通常是在创建 AKS 群集时，通过命令中的 --vnet-subnet-id 参数指定的子网。
此方法允许混合使用节点类，其中一些使用特定工作负荷的自定义子网，而另一些则使用群集的默认子网配置。
子网偏移行为
Karpenter 监视子网配置更改，并在vnetSubnetID中AKSNodeClass被修改时检测漂移。 在管理自定义网络配置时，理解此行为至关重要。
将 vnetSubnetID 从一个有效子网修改到另一个有效子网不是一个被支持的操作。 如果将 vnetSubnetID 更改为指向一个不同的有效子网，则 Karpenter 会将此检测为子网漂移，并阻止节点预配，直到问题通过将 vnetSubnetID 还原到原子网来解决。 此行为可确保仅在预期子网中预配节点，维护网络完整性和安全性。 但是，此规则有例外情况。 只能在以下情形中修改 vnetSubnetID：
- 更正导致节点预配失败的格式不正确的子网 ID。
- 修复导致配置错误的无效子网引用。
- 更新指向不存在或无法访问的子网的子网标识符。
了解 AKS 集群无类别域际路由选择 (CIDR) 范围
配置自定义网络 vnetSubnetID时，你负责了解和管理群集的 CIDR 范围，以避免网络冲突。 与通过 ARM 模板创建的传统 AKS 节点池不同，Karpenter 应用自定义资源定义（CRD），无需 ARM 提供的扩展验证即可立即预配节点。
自定义子网配置的 CIDR 注意事项
配置 vnetSubnetID 时，必须：
- 验证 CIDR 兼容性：确保自定义子网不会与现有的 CIDR 范围冲突。
- 规划 IP 容量：计算预期缩放所需的 IP 地址。
- 验证连接：测试网络路由和安全组规则。
- 监视使用情况：跟踪子网利用率并计划增长。
- 文档配置：维护网络设计决策的记录。
常见 CIDR 冲突
在将自定义子网与 NAP 配合使用时，请注意以下常见的 CIDR 冲突方案：
# 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 权限。
设置这些权限有两种主要方法： 分配广泛的虚拟网络（VNet）权限 或 分配范围子网权限。
此方法最宽松，授予群集标识权限，以读取和加入主 VNet 中的任何子网并提供网络参与者访问权限。
重要
在将此方法应用到生产群集之前，请调查“网络参与者”角色。
优点和注意事项
下表概述了分配广泛 VNet 权限的好处和注意事项：
| 优点 | 注意事项 |
|---|---|
| • 简化权限管理。 • 无需在添加新子网时更新权限。 • 适用于单租户环境。 • 订阅达到自定义角色的最大数目时的功能。 |
• 提供比严格必要的更广泛的权限。 • 可能不符合严格的安全要求。 |
所需的权限
若要分配广泛的 VNet 权限，请授予群集的托管标识对 VNet 的以下权限：
# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)
# 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 $CLUSTER_IDENTITY \
--role "Network Contributor" \
--scope $VNET_ID
有关设置自定义网络和分配广泛 VNet 权限的完整示例，请参阅 自定义 VNET 设置 - 大多数宽松的 RBAC 示例脚本。
自定义子网配置示例
以下示例演示如何使用 vnetSubnetID 资源中的 AKSNodeClass 字段为 NAP 节点配置自定义子网：
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
name: custom-networking
spec:
vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$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/$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/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"
自带 CNI (BYO CNI) 支持策略
适用于 Azure 的 Karpenter 允许自带容器网络接口（BYO CNI）配置，遵循与 AKS 相同的支持策略。 这意味着，使用自定义 CNI 时，与网络相关的故障排除支持不受任何服务级别协议或保证的范围。
支持范围详细信息
下面概述了将 BYO CNI 与 Karpenter 配合使用时支持和不支持的内容：
- 支持：使用自带 (BYO) CNI 配置时，特定于 Karpenter 的功能和集成问题。
- 不支持：使用第三方 CNI 插件时，特定于 CNI 的网络问题、配置问题或故障排除。
后续步骤
有关 AKS 中的节点自动预配的详细信息，请参阅以下文章：